Bir alan adının arkasında hangi sunucunun, hangi sağlayıcının ve hangi coğrafyanın olduğunu bilmek; sıradan bir merak konusu değil, ağ yöneticileri, geliştiriciler, SEO uzmanları ve güvenlik analistleri için günlük bir refleks haline gelmiş bir tekniktir. Domain IP sorgulama dediğimiz şey, görünüşte basit bir isim → numara dönüşümünden ibaret; oysa altında DNS protokolü, otoritatif sunucular, cache hiyerarşileri, reverse pointerlar, WHOIS/RDAP veri tabanları ve hatta TLS sertifikalarındaki SAN listeleri yatar. Bu rehber, bir alan adının IP adresini bulmaktan, o IP'nin kime ait olduğunu çözmeye, açık portlarını taramaktan aynı sunucuda hangi başka sitelerin barındığını tespit etmeye kadar tüm pratik yöntemleri gerçek komutlarla — copy-paste edilebilecek netlikte — derliyor.
İlgili rehberler: Domain sorgulama araçları (WHOIS, RDAP, DNS) · DNS nedir, ayarları değiştirme · Domain nedir, WHOIS sorgulama · Nginx yapılandırma rehberi · HTTPS ve TLS 1.3 · Tüm araçlar
Domain IP Sorgulama Nedir?
İnternette her cihazın ve her sunucunun bir IP adresi vardır; insan zihni 32 bitlik bir sayıyı (192.0.2.45) ya da 128 bitlik bir hex dizisini (2001:db8::1) hatırlamak için tasarlanmadığı için, bu numaraları kolay okunur isimlere bağlayan DNS sistemi devreye girer. Tarayıcınıza kelimeler.com yazdığınızda işletim sistemi önce yerel cache'ine, sonra resolver'a, ondan sonra otoritatif DNS sunucularına sorar; geri dönen A veya AAAA kayıtları sayfanın indirileceği gerçek IP'yi söyler. Domain IP sorgulama aslında bu zinciri elinizle yürütmek, her halkada ne döndüğünü görmek demektir.
Sorgu yapmak isteyebileceğiniz nedenler çok çeşitlidir: bir taşımanın gerçekten gerçekleştiğini doğrulamak, CDN'in doğru noktayı işaret ettiğine emin olmak, bir spam ağındaki IP aralığını incelemek, hosting sağlayıcısı tahmin etmek, açık port taraması yapmak, GeoIP üzerinden coğrafyayı çıkarmak, aynı sunucuda barınan diğer alan adlarını listelemek (reverse IP), ya da sadece SSL sertifikasının doğru hostname'i kapsadığını teyit etmek. Bu rehber bütün bu senaryoları sırayla ele alıyor.
DNS'in Kısa Tekrarı: Neden A, AAAA, CNAME Önemli?
Bir A kaydı bir alan adını 32 bitlik IPv4 adresine eşler. AAAA kaydı (dört A) IPv6 muadilidir. CNAME alan adının başka bir alan adının takma adı olduğunu söyler; nihayetinde takip edildiğinde bir A/AAAA'ya bağlanır. Modern bir www alt etki alanı genellikle bir CNAME ile CDN'e bakar (örneğin cdn.cloudflare.net); CDN tarafı edge konumuna göre dinamik bir A kaydı döndürür. Yani aynı domain için sorulan iki farklı resolver, çoğu zaman farklı IP'ler söyler — bu bug değil, mimaridir.
Bir alan adının IP'sinin tek bir sabit cevabı yoktur; kim sorduğuna, nereden sorduğuna ve hangi otoritatife gittiğine bağlıdır. Sorgu sırasında bunu hesaba katın. DNS rehberi içinde DNS hiyerarşisi, kök sunucular ve TTL kavramı detaylı şekilde anlatılıyor; bu rehber boyunca o temele başvuracağız.
En Kısa Yöntem: Tek Komutla A Kaydı
Komut satırı varsa, ayrı bir araç açmaya gerek yoktur. Linux/macOS sistemlerde dig ve host, Windows'ta nslookup kutudan çıkar çıkmaz çalışır. Aşağıdaki örneklerde varsayılan resolver Google'ın 8.8.8.8 ya da Cloudflare'in 1.1.1.1 sunucusudur — kendi internet sağlayıcınızın resolver'ını kullanmak isterseniz @ parametresini değiştirin.
# IPv4 (A kaydı)
dig +short trt.net.tr A
# IPv6 (AAAA kaydı)
dig +short trt.net.tr AAAA
# Belirli bir resolver kullan
dig @1.1.1.1 +short ahbap.org A
dig @8.8.8.8 +short ahbap.org A
# Tüm yaygın kayıtlar (ANY kalktı, bu pratik özet):
dig anadolu.edu.tr A AAAA NS MX TXT +noall +answer
# 'host' aracının kısa çıktısı
host milliyet.com.tr
# Windows: nslookup
nslookup hurriyet.com.tr 1.1.1.1+short bayrağı çıktıyı sadece IP'lere indirger; otomasyon ve script senaryolarında bu form gözünüzü dinlendirir. Pek çok sistem yöneticisi, deploy sonrasında DNS yayılmasını test ederken watch -n 5 'dig +short example.com.tr' gibi bir döngüyle TTL'in yenilenmesini gözlemler.
dig: En Çok Kullanacağınız Tek Araç
dig (Domain Information Groper), BIND ile birlikte gelen ve neredeyse her senaryoda işinize yarayan bir DNS sorgulama aracıdır. Çıktısı uzun görünse de bilgi yoğundur ve standart bir biçimi vardır: HEADER, QUESTION, ANSWER, AUTHORITY, ADDITIONAL bölümleri.
# Tam çıktı
dig hurriyet.com.tr
# Sadece cevap bölümü
dig +noall +answer hurriyet.com.tr
# İz sürme: kök sunucudan otoritatife inerek
dig +trace hurriyet.com.tr
# Otoritatif sunucudan sor (cache'e güvenmeden)
NS=$(dig +short NS hurriyet.com.tr | head -1)
dig @$NS hurriyet.com.tr A
# DNSSEC ile imzalı cevap iste
dig +dnssec example.com
# TCP üzerinden sor (büyük cevaplar için)
dig +tcp largezone.example.com ANY+trace özellikle eğiticidir; sorgunun kök (.) sunucularından TLD'ye, oradan otoritatife nasıl yürüdüğünü adım adım gösterir. Yeni başlayan ağ yöneticileri için DNS hiyerarşisini içselleştirmenin en iyi yoludur. Otoritatif cevapla resolver cache'i arasındaki farkı görmek için dig @ns1.example.com ile resolver'ı atlayıp doğrudan kaynağa sorabilirsiniz.
Windows Kullanıcısı İçin: nslookup, PowerShell ve Resolve-DnsName
Windows'ta nslookup klasik araçtır; ancak Resolve-DnsName PowerShell cmdlet'i daha zengin bir nesne tabanlı çıktı verir, otomasyona daha uygundur.
# Klasik nslookup
nslookup mynet.com 1.1.1.1
# PowerShell — tüm kayıt tipleri
Resolve-DnsName -Name mynet.com -Type A
Resolve-DnsName -Name mynet.com -Type AAAA
Resolve-DnsName -Name mynet.com -Type MX | Format-Table
# Belirli sunucudan sor, cache'i atla
Resolve-DnsName -Name mynet.com -Server 9.9.9.9 -DnsOnly
# Sadece IP adreslerini al
(Resolve-DnsName -Name mynet.com -Type A).IPAddressYerel DNS cache'i temizlemek bazen şart olur — özellikle DNS kaydını az önce değiştirdiğiniz halde tarayıcınız hâlâ eski IP'ye gidiyorsa. Windows'ta ipconfig /flushdns, macOS'ta sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, systemd-resolved kullanan Linux dağıtımlarında sudo resolvectl flush-caches ile cache silinir.
Web Tarayıcısından Hızlı Sorgu: Tek Tıkla IP Bulma
Komut satırına ulaşamayacağınız ortamlarda (mobil cihaz, kısıtlı kurumsal makine), tarayıcı tabanlı sorgu araçları işinizi görür. DNS Lookup aracımız doğrudan A, AAAA, CNAME, MX, TXT ve NS kayıtlarını gösterir; tüm araçlar sayfası üzerinden ek hizmetlere de erişebilirsiniz. Üçüncü parti referans olarak dnschecker.org, mxtoolbox.com, viewdns.info ve whois.domaintools.com sektörde standart isimlerdir.
Tarayıcı araçlarının önemli bir avantajı, dünyanın farklı bölgelerindeki resolver'lardan eşzamanlı cevap alabilmesidir. Yeni bir DNS değişikliğinden sonra propagation'ı görmek için bu çoklu sorgu çok değerlidir; CDN üzerinden coğrafi bölgeye göre farklı IP atayan domain'lerde her bölgenin gerçekten beklenen edge'i aldığını da bu sayede doğrularsınız.
Reverse DNS: IP'den Domain'e Geri Yürüme
Reverse DNS, bir IP adresinden hostname'e ulaşmaya çalışan ters yönlü sorgulamadır. Teknik olarak in-addr.arpa (IPv4) ve ip6.arpa (IPv6) özel zonelarındaki PTR kayıtları üzerinden yapılır. PTR kaydını koymak hosting sahibinin sorumluluğundadır; eksikse cevap dönmez.
# IP'den hostname'e (klasik)
dig -x 8.8.8.8 +short
# Sonuç: dns.google.
# host komutu
host 1.1.1.1
# 1.1.1.1.in-addr.arpa domain name pointer one.one.one.one.
# IPv6 için
dig -x 2606:4700:4700::1111 +short
# whois ile birlikte: IP sahibi + organizasyon
whois 8.8.8.8 | grep -Ei 'OrgName|NetName|Country|CIDR'Reverse DNS özellikle e-posta sunucuları için kritiktir: kurumsal mail server'ınızın IP'si geriye doğru kendi domain'ine çözünmüyorsa, gönderdiğiniz mailler büyük olasılıkla spam klasörüne düşer. Güvenlik tabanlı yazılarımızda ve OWASP rehberinde e-posta omurgasının önemini ayrıntılı işliyoruz; bu rehber için yalnızca PTR kaydı şart, demek yeterli.
Bir IP'nin Sahibini Bulmak: WHOIS ve RDAP
Bir IP'nin kime ait olduğunu öğrenmek için iki kanonik kaynak vardır: WHOIS (RFC 3912, eski metin tabanlı protokol) ve RDAP (Registration Data Access Protocol, RFC 7480 — JSON tabanlı modern halefi). RDAP yapılandırılmış cevap döndürür; WHOIS ise insan okuması için tasarlanmış serbest metindir.
# Komut satırı whois
sudo apt install whois
whois 185.220.101.42
whois -h whois.ripe.net 185.220.101.42
# Bölgesel registry'lere göre:
# ARIN -> Kuzey Amerika
# RIPE -> Avrupa, Orta Doğu
# APNIC -> Asya-Pasifik
# LACNIC-> Latin Amerika
# AFRINIC-> Afrika
# RDAP (HTTP üzerinden JSON)
curl -s https://rdap.arin.net/registry/ip/8.8.8.8 | jq '.entities[].vcardArray[1]'
curl -s https://rdap.db.ripe.net/ip/89.150.0.1 | jq '.name,.country,.entities[0].handle'WHOIS çıktısı tipik olarak NetRange (IP bloğu), OrgName (sahibi), OrgAbuseEmail (kötüye kullanım bildirim adresi), Country ve NetName alanlarını içerir. Spam ya da saldırı kaynağı bir IP gördüğünüzde, ilgili abuse adresine hızlı bir bildirim gönderebilirsiniz. WHOIS sorgulama rehberi ve domain sorgulama araçları yazısı bu konulara çok daha derin bakıyor.
GeoIP: IP'den Coğrafyaya
Bir IP'nin fiziksel konumunu öğrenmek isteyebilirsiniz: hangi ülkede, hangi şehirde, hangi ASN'de? Bu işlem GeoIP veritabanlarıyla yapılır. Açık kaynak alternatifleri arasında MaxMind GeoLite2, IP2Location LITE ve db-ip.com ücretsiz veri setleri sunar. Ülke düzeyinde doğruluk %95+'tır; ancak sokak düzeyinde bekleyen herkesin yüzü kızarır — IP konumu kabaca ISP'nin internet hub'ının konumudur.
# Hızlı CLI lookup (ip-api.com ücretsiz, sınırlı)
curl -s "http://ip-api.com/json/8.8.8.8?fields=country,regionName,city,isp,org,as,reverse"
# ipinfo.io
curl -s ipinfo.io/8.8.8.8/json
# MaxMind GeoLite2 (yerel)
sudo apt install mmdb-bin
mmdblookup -f /usr/share/GeoIP/GeoLite2-City.mmdb \
--ip 78.88.0.1 country names en
mmdblookup -f /usr/share/GeoIP/GeoLite2-ASN.mmdb \
--ip 78.88.0.1 autonomous_system_organizationGeoIP sonuçlarını kanıt olarak değil ipucu olarak alın: VPN, proxy, mobil operatör NAT'ları ve uydu internet sağlayıcıları sıkça yanıltır. Bir kullanıcının fiziksel konumunu kesin gerektiren legal süreçlerde mahkeme kararıyla ISP kayıtları çekilir; web tabanlı sorgu hiçbir zaman yeterli değildir.
ASN ve BGP: IP Hangi Ağa Ait?
Her IP bir ASN'ye (Autonomous System Number) aittir; ASN'ler internet üzerinde rota anonsları yapan operatörlerin kimliğidir. Türk Telekom AS9121, Turkcell AS16135, Vodafone Türkiye AS15897, Cloudflare AS13335 gibi. ASN bilmek, IP'nin perdesini birkaç kat aralar.
# whois üzerinden ASN bulma
whois -h whois.cymru.com " -v 8.8.8.8"
# bgp.tools / Hurricane Electric (web)
curl -s "https://bgp.tools/asn/AS13335"
# Team Cymru DNS arayüzü (TXT kaydı içinden)
dig +short TXT "8.8.8.8.origin.asn.cymru.com"
# Sonuç örneği: "15169 | 8.8.8.0/24 | US | arin | 1992-12-01"
# Yerel BGP look-up: looking glass
# https://lg.he.net https://lg.ring.nlnog.netASN bilgisi, özellikle DDoS analizi sırasında çok değerlidir: aynı saldırı kümesinin hangi botnet'e ya da sömürülmüş hosting sağlayıcısına ait olduğunu hızla görebilirsiniz. DDoS koruma rehberi bu konuyu ayrıntılı işliyor.
Reverse IP Lookup: Aynı Sunucuda Kim Var?
Reverse IP lookup, bir IP'de barınan tüm domain'leri listelemeye çalışan tekniktir. Shared hosting'de yüzlerce, hatta binlerce domain aynı IP'yi paylaşır; reverse IP araçları (örneğin viewdns.info/reverseip, hackertarget.com/reverse-ip-lookup, spyse, SecurityTrails) bu listeyi farklı veri setlerinden derler.
# hackertarget.com basit API
curl -s "https://api.hackertarget.com/reverseiplookup/?q=104.21.16.1"
# Censys CLI ile kapsamlı arama (API anahtarı gerekir)
censys search 'services.tls.certificates.leaf_data.subject_dn: "CN=example.com"' \
--index-type hosts
# Crt.sh — TLS sertifika geçmişinden alt domain çıkarma
curl -s "https://crt.sh/?q=%25.example.com&output=json" | \
jq -r '.[].name_value' | sort -uReverse IP doğruluğu CDN ya da Cloudflare arkasındaki sitelerde düşer; çünkü bütün domain'ler aynı edge IP'ye bakar. Bu durumda asıl origin IP'yi bulmak için sertifika şeffaflık logları, eski DNS kayıtları (SecurityTrails historical data), e-posta header'ları ve subdomain'ler üzerinden iz sürmek gerekir.
Sertifika Şeffaflık (CT) Logları
Her geçerli TLS sertifikası, halka açık Certificate Transparency log'larına yazılır. Bu loglar, bir kurumun isminden, alan adı parçasından ya da bir IP'nin geçmiş sertifikalarından domain envanteri çıkarmak için altın madenidir. crt.sh en bilinen arayüzdür; censys.io ve certspotter da aynı veriye erişir.
# Bir alan adının geçmiş tüm sertifikaları (alt domain dahil)
curl -s "https://crt.sh/?q=%25.example.com.tr&output=json" | \
jq -r '.[] | [.entry_timestamp,.common_name,.name_value] | @tsv' | \
sort -u | head -50
# Bir IP'nin sunduğu güncel TLS sertifikası (SAN listesi)
echo | openssl s_client -connect 188.166.1.1:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -text \
| grep -E 'DNS:|IP Address:|Issuer:'
# Bir host'un tüm portlarındaki TLS bağlantı bilgisi
nmap --script ssl-cert -p 443,8443,465,993,995 example.comSertifika SAN (Subject Alternative Name) listesi sıkça unutulan bir bilgi kaynağıdır; bir cdn.example.com sertifikası içinde internal-api.example.com beraber tanımlanmışsa, dış dünyanın bilmediği bir alt domain'i ifşa etmiş olur. Pen-test ve OSINT senaryolarında ilk başvurulacak yerlerden biridir.
IP ve Port Sorgulama: nmap, masscan, naabu
Bir IP'nin açık portlarını ve hangi servisleri sunduğunu öğrenmek tamamen ayrı bir disiplindir. nmap, son 25 yılın endüstri standardıdır; masscan ve naabu daha geniş aralıklı tarama için tasarlanmıştır.
# En yaygın 1000 portu hızlıca tara
nmap -F 192.0.2.10
# Servis sürümlerini ve OS tahminini de iste
nmap -sV -O 192.0.2.10
# Spesifik port + script
nmap -p 80,443,22,3306 --script vuln 192.0.2.10
# Banner grabbing (HTTP)
nmap -p 80 --script http-headers 192.0.2.10
# Hızlı UDP taraması
nmap -sU -p 53,123,161,500 192.0.2.10
# Geniş IP aralığı için masscan
sudo masscan 192.0.2.0/24 -p1-1000 --rate 1000
# ProjectDiscovery'nin naabu aracı
naabu -host example.com -top-ports 1000Port taraması yasal olarak hassas bir alandır; sahibi olmadığınız sistemlere izinsiz tarama yapmak Türkiye'de TCK 243 ve 244 kapsamına girebilir. Sahip olduğunuz, bug bounty kapsamındaki ya da yazılı izninizin olduğu sistemler dışında tarama yapmayın. OWASP Top 10 yazımız uygulama düzeyinde, Fail2ban yazımız ise saldırgan tarafından gelen erken keşif sinyallerini nasıl tutacağınızı anlatıyor.
Traceroute ve mtr: Paketler Hangi Yoldan Gidiyor?
Bir alan adının IP'sine ulaşırken paketlerinizin hangi rotalardan ve hangi ASN'lerden geçtiğini bilmek, gecikme ve paket kaybı hata ayıklamasının kalbidir. traceroute klasik araçtır; mtr (My Traceroute) traceroute ile ping'i birleştirip canlı izlem sağlar.
# Klasik traceroute (UDP)
traceroute hurriyet.com.tr
# ICMP ile (bazı ağlar UDP'yi engeller)
traceroute -I hurriyet.com.tr
# TCP traceroute (port 80 üzerinden)
sudo traceroute -T -p 443 hurriyet.com.tr
# mtr — gerçek zamanlı, hop bazında istatistik
mtr --report --report-cycles 30 hurriyet.com.tr
# Windows: tracert + pathping
tracert hurriyet.com.tr
pathping hurriyet.com.trİlk birkaç hop sizin yerel ağınızdır (genellikle 192.168.x.x); sonra ISP'nizin omurgası, ardından peering noktaları (TRIX, IXP), sonunda hedef ASN'nin sınır router'ı görünür. Ortada bir hop sürekli star (* * *) gösteriyorsa o cihaz büyük olasılıkla ICMP TTL exceeded mesajını sessizce düşürüyor — sorun olmak zorunda değil, sadece görünmez.
HTTP Header'lar: IP Belirlerken Sıklıkla Atlanan Bilgi
Bir alan adının arkasındaki sunucu, çoğu zaman kendisini HTTP header'larıyla ele verir. Server, X-Powered-By, CF-Ray, Via, X-Cache alanları neredeyse parmak izi gibidir.
# Sadece header'ları getir
curl -sI https://www.aa.com.tr | head -30
curl -sI https://www.tcmb.gov.tr | head -30
# Server header'ı ne diyor?
curl -sI https://example.com.tr | grep -i server
# Cloudflare arkasında mı? CF-Ray varsa evet
curl -sI https://example.com | grep -i 'cf-ray\|server: cloudflare'
# HTTP/2 ve HTTP/3 desteği
curl --http2 -sI https://example.com
curl --http3 -sI https://example.com 2>&1 | grep -i alt-svcServer: cloudflare görüyorsanız, gördüğünüz IP edge IP'sidir, origin değildir. Via header'ı bir reverse proxy'ye işaret eder; X-Cache CDN cache durumunu söyler. nginx-yapilandirma-rehberi yazımızda Nginx ile bu header'ları nasıl ayarlayacağınızı detaylı işledik.
DNSSEC ve DNS over HTTPS
Klasik DNS şifresizdir; kurum içinden ya da operatörünüzün networkünden bakanlar her sorgunuzu görebilir. DNS over HTTPS (DoH) ve DNS over TLS (DoT) bu sızıntıyı engeller; DNSSEC ise dönen cevabın gerçekten otoritatif sunucudan geldiğini imza ile doğrular.
# DoH üzerinden sorgu (Cloudflare)
curl -s 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' \
-H 'accept: application/dns-json' | jq
# DoH (Google)
curl -s 'https://dns.google/resolve?name=example.com&type=A' | jq
# DNSSEC durum kontrolü
delv +cd +trust +short example.com
dig +dnssec +short example.com
# kdig (knot-utils) ile DoT
kdig @1.1.1.1 +tls example.comOfis ağınızdaki captive portal ya da güvenlik duvarı klasik 53/UDP DNS'i engelliyorsa, DoH üzerinden sorgu açık kalır — bu hem nimet, hem siber güvenlik tarafında bilinen bir bypass yoludur. Kurumsal ağ tasarlarken dikkate alın.
DNS Propagasyonu: Değişiklik Ne Zaman Yansır?
DNS değişiklikleri ağa hemen yansımaz; önceki cevabın TTL süresi dolana kadar resolver'lar ellerindeki cache'i kullanır. Tipik TTL değerleri 300–86400 saniye arasıdır. Bir taşımanın küresel yayılmasını izlemek için çoklu coğrafyadan eşzamanlı sorgu yapan araçlar (örneğin dnschecker.org, whatsmydns.net) idealdir.
# TTL'yi gör
dig hurriyet.com.tr A | grep -E '^hurriyet'
# Geçişten önce TTL'yi düşürmek (örnek BIND zone)
# www IN A 192.0.2.10 ; eski TTL: 86400 -> 300
# Birden fazla resolverdan eş zamanlı sorgu (kaba propagation kontrolü)
for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222 4.2.2.2; do
echo "== $r =="; dig @$r +short example.com.tr A
donePratik kural: Domain veya IP değişikliği planladığınız günden 24 saat önce TTL'yi 300'e indirin; geçişten sonra propagation tamamlandığında tekrar normale çekin. Bu basit disiplin olası kesintilerin %90'ını ortadan kaldırır.
Kendi IP'nizi Bulmak: İçeriden ve Dışarıdan
Bir cihazın iç ağ IP'si ile dış (public) IP'si farklıdır. NAT yapan ev/ofis modemleri, içeride 192.168.0.0/16, 10.0.0.0/8 ya da 172.16.0.0/12 bloklarından bir IP atar; dış dünya yalnızca modemin tek public IP'sini görür.
# Linux/macOS — yerel IP
ip -4 addr show | grep inet | head -5
ifconfig en0 | grep 'inet '
# Windows — yerel IP
ipconfig | findstr IPv4
# Public IP — istemci dışına çıkıp soran servisler
curl -s ifconfig.me
curl -s ipinfo.io/ip
curl -s https://api.ipify.org
curl -s https://ifconfig.co
# DNS üzerinden public IP (OpenDNS özel kayıt)
dig +short myip.opendns.com @resolver1.opendns.comMobil veri kullanıyorsanız muhtemelen büyük bir CGNAT arkasındasınız: yüzlerce/binlerce abonenin paylaştığı tek bir public IP. Bu durumda port forwarding gibi tekniklerin çalışmadığını göreceksiniz. DNS yazımız içinde özel/genel IP ayrımına detaylı değiniyor.
Komut Satırı Dışındaki Sorgu Yöntemleri
Programatik olarak sorgu yapmak isteyen geliştiriciler için her dilin kendi DNS kütüphanesi vardır. Aşağıda Node.js, Python ve PHP için tipik örnekler:
// Node.js — built-in dns modülü
import dns from 'node:dns/promises';
const a = await dns.resolve4('hurriyet.com.tr');
const aaaa = await dns.resolve6('hurriyet.com.tr').catch(() => []);
const mx = await dns.resolveMx('hurriyet.com.tr');
const txt = await dns.resolveTxt('hurriyet.com.tr');
// Belirli resolver kullan
const { Resolver } = dns;
const r = new Resolver();
r.setServers(['1.1.1.1', '8.8.8.8']);
console.log(await r.resolve4('hurriyet.com.tr'));# Python — dnspython
import dns.resolver
r = dns.resolver.Resolver()
r.nameservers = ['1.1.1.1', '8.8.8.8']
for rdata in r.resolve('hurriyet.com.tr', 'A'):
print(rdata)
for rdata in r.resolve('hurriyet.com.tr', 'MX'):
print(rdata.preference, rdata.exchange)
# Reverse lookup
import dns.reversename
addr = dns.reversename.from_address('8.8.8.8')
print(r.resolve(addr, 'PTR')[0])<?php
// PHP — built-in
$ip = gethostbyname('hurriyet.com.tr');
var_dump($ip);
// Tüm A kayıtları
$records = dns_get_record('hurriyet.com.tr', DNS_A);
print_r($records);
// MX kayıtları
if (getmxrr('hurriyet.com.tr', $hosts, $weights)) {
array_multisort($weights, $hosts);
print_r(array_combine($hosts, $weights));
}
// Reverse lookup
echo gethostbyaddr('8.8.8.8');Yüksek hacimli toplu sorgular için DoH endpoint'leri (örn. https://1.1.1.1/dns-query) HTTPS rate limit'lerine takılmadan binlerce sorgu kabul eder. Yine de kibar olun: kendi resolver'ınızı kurup orada cacheleyerek dış servislere yük bindirmemek olgun bir mühendislik refleksidir. Redis temelleri yazımız bu cache fikrini başka bağlamlarda da gösteriyor.
Cloudflare ve CDN Arkasında Origin IP Bulma
Bir site Cloudflare gibi bir CDN proxy'sinin arkasındaysa, dig +short site.com size CDN edge IP'sini söyler — orijinal sunucunun IP'sini değil. Origin'i bulmak zor; hatta CDN'in temel güvenlik kazanımlarından biri budur. Yine de bazı yöntemler işe yarayabilir:
- Sertifika geçmişi:
crt.shüzerinde domain'in CDN'e geçmeden önceki sertifikalarını ve eski subdomain'lerini tarayın. Geçmişte direct.example.com doğrudan origin'e bağlanıyor olabilir. - Tarihi DNS verisi:
SecurityTrails,DNSDumpster,Shodanhistorical DNS data verir. CDN'e geçişten önceki A kaydı genelde origin'in kendisidir. - E-posta header'ları: Sitenin gönderdiği bir mail (kontak formu, parola sıfırlama)
Receivedzincirinde mail server'ın IP'sini ifşa eder; bu çoğu zaman web origin ile aynı sunucudur. - Subdomain sızıntıları: cpanel.example.com, dev.example.com, ftp.example.com gibi alt etki alanları genelde Cloudflare arkasında değildir.
- Yanlış yapılandırılmış servisler: SSH banner, FTP banner, mail server veya monitoring endpoint hostname'i ifşa edebilir.
- Default web sayfası: Origin IP'sine doğrudan tarayıcıyla bağlandığınızda gelen web server default sayfası ipucu verebilir.
Defansif tarafta bu mühendislik, Cloudflare'i yapılandırırken Authenticated Origin Pulls (Cloudflare'in mTLS modu) ya da IP Allowlist ile origin'i sadece Cloudflare IP aralıklarına açmaktan geçer. DDoS koruma rehberi bu konfigürasyonu adım adım gösteriyor.
Zone Transfer ve AXFR: Eski Hata, Hâlâ Karşılaşılan
DNS protokolünde zone'un tamamını çekmek için AXFR sorgusu vardır; modern uygulamada yalnızca yetkilendirilmiş ikincil sunuculara açık olmalıdır. Yanlış yapılandırılmış otoritatif DNS'ler, AXFR'ı herkese açık bırakır ve tüm zone (tüm subdomain'ler, tüm A/AAAA/MX/TXT kayıtları) üçüncü tarafın eline geçer.
# AXFR denemesi (kapalıysa REFUSED dönmesi beklenir)
dig @ns1.example.com example.com AXFR
# fierce — DNS recon aracı
fierce --domain example.com
# dnsrecon ile tam zone enumeration
dnsrecon -d example.com -t std,brt,axfrKendi domain'iniz için AXFR kapalı olduğunu yılda en az bir kez doğrulayın — bu küçük adım, attack surface'ı ciddi düşürür. OWASP rehberinin A05 (Security Misconfiguration) bölümü konuyla ilgili.
BTK Site Sorgu ve Türkiye'ye Özgü Kaynaklar
Türkiye'de BTK tarafından sunulan resmi Site Sorgu aracı, halka açık veriler üzerinden alan adı ve IP bilgisi döndürür. Aynı şekilde TR-NIC (TRABIS) .tr uzantılı domain'lerin tescil bilgilerine erişim sağlar. Bu kaynakların yetkili registrar'lar üzerinden de WHOIS arayüzleri vardır. Avrupa kapsamında RIPE NCC web arayüzü, IPv4/IPv6 blok sahipleri ve ASN'ler için kanonik kaynaktır.
Yerel kaynakların avantajı; özellikle .com.tr, .org.tr, .gov.tr uzantıları için tescil tarihçesi ve resmi sahip bilgisini doğru almaktır. Genel uluslararası WHOIS aracı .tr alt uzantılarında bazen kısıtlı bilgi döndürür; TRABIS doğrudan kaynaktır.
Spam, Blacklist ve IP İtibarı Sorgulama
Bir IP'nin kara listede olup olmadığı, mail göndericiliği ve hatta SEO sıralaması açısından önemlidir. RBL (Realtime Blackhole List) servisleri (Spamhaus ZEN, Barracuda BRBL, SORBS, SpamCop) 80'den fazla farklı listenin toplamını sunar.
# Spamhaus ZEN üzerinden tek IP kontrol
dig +short 8.8.8.8.zen.spamhaus.org
# Cevap dönerse: listede; boş cevap: temiz
# Octet'leri ters çevirme örneği (IP 1.2.3.4 -> 4.3.2.1.zen.spamhaus.org)
IP=192.0.2.45
REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
for list in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org dnsbl.sorbs.net; do
R=$(dig +short "$REV.$list")
echo "$list: ${R:-temiz}"
done
# MXToolBox toplu kontrol (web)
# https://mxtoolbox.com/blacklists.aspxMail server'ınızın IP'si bir blacklist'e düştüyse, ilgili servisin delisting formunu doldurmadan önce asıl sebebi bulun: virüslü cihazlardan gönderilen spam, açık SMTP relay, yanlış SPF/DKIM/DMARC yapılandırması en sık nedenlerdir. OWASP yazısında hesap güvenliği, JWT güvenlik yazısında session yönetimi tarafları işliyoruz.
Anonim Sorgu: Tor, VPN ve Proxy Üzerinden
Kendi IP'nizi sızdırmadan başka domain'leri sorgulamak istediğiniz senaryolar olabilir — özellikle güvenlik araştırması, OSINT, savunma analizi gibi alanlarda. Tor (torsocks dig), VPN üzerinde split tunneling, ya da SOCKS5 proxy ile curl --socks5 bunu sağlar.
# Tor üzerinden DNS (torsocks gerekli)
sudo apt install tor torsocks
sudo systemctl start tor
torsocks dig example.com
# Tor üzerinde curl ile public IP gör
torsocks curl -s ifconfig.me
# SOCKS5 proxy ile curl
curl --socks5 127.0.0.1:9050 -s ifconfig.me
# DoH + Tor: gizli ve şifreli
torsocks curl -s 'https://1.1.1.1/dns-query?name=example.com&type=A' \
-H 'accept: application/dns-json'Yasal sınır: anonim sorgu sadece sorgu yöntemini gizler; hedef sisteme bilinçli bir tarama veya saldırı niyetiyle dokunmak hâlâ yasalara tabidir. Anonimleşme bir araştırma rahatlığıdır, ihlal lisansı değildir.
Çoklu Resolver Karşılaştırma Tablosu
Hangi resolver'ı kullanacağınız önemlidir; bazıları daha hızlı, bazıları daha gizliliği koruyucu, bazıları içerik filtreleme uygular. Aşağıda kabaca bir karşılaştırma:
- 1.1.1.1 / 1.0.0.1 (Cloudflare): Hız odaklı, DoH/DoT destekli, no-log politikası iddiası, içerik filtresi yok.
- 8.8.8.8 / 8.8.4.4 (Google Public DNS): Yaygın, kararlı, log tutar (anonimleştirilmiş).
- 9.9.9.9 / 149.112.112.112 (Quad9): Kötü amaçlı domain'leri otomatik bloklar, IBM/PCH konsorsiyumu, gizlilik dostu.
- 208.67.222.222 (OpenDNS / Cisco Umbrella): İçerik filtreleme paketleri var, kurumsal kullanıma uygun.
- 89.233.43.71 (UncensoredDNS, Danimarka): Filtreleme yapmayan, AB GDPR kapsamında.
- 185.222.222.222 (DNS.sb): Çince/uluslararası, DoH/DoT destekli.
- İSS resolver: Türk Telekom, Vodafone, Turkcell — varsayılan; bazen yerel filtreleme veya hijack uygulayabilir, özellikle.tr içerikte yavaş kalabilir.
Sorgu sonuçlarınızı kıyaslayın; özellikle hassas içerik üreten yayıncılar, yerel ISS resolver'ında engellenip Cloudflare'da çözülen aynı domain'in vakalarını gözlemler. DDoS rehberi ve HTTPS/TLS rehberi birlikte okumanızı öneririm.
Subdomain Enumeration: Tek Bir Alan Adından Yüzlerce IP
Bir kurumun ana alan adı dışında onlarca subdomain'i olabilir; her biri kendi IP'sine, kendi sunucusuna sahiptir. Subdomain envanteri çıkarmak hem güvenlik analizinde, hem altyapı denetiminde, hem migrasyon planlamada belirleyicidir.
# Sublist3r — pasif kaynaklardan toplama
sublist3r -d example.com
# amass — kapsamlı pasif + aktif keşif
amass enum -d example.com -src
# subfinder (ProjectDiscovery)
subfinder -d example.com -all -recursive
# Brute-force ile subdomain bulma + DNS
dnsx -d example.com -w /usr/share/wordlists/dns/subdomains-top1m.txt
# Bulunanları IP'ye çevir
subfinder -d example.com -silent | dnsx -a -resp -silentSubdomain listenizin tutarlı kalması için kurum içinde bir asset inventory sistemi şarttır; aksi halde unutulmuş bir old-staging.example.com ileride sızıntıların başlangıcı olur. OWASP yazısı ve VPS güvenlik sertleştirme bu konuyu farklı açılardan ele alıyor.
DNS Cache Poisoning ve Sorgu Bütünlüğü
Klasik DNS protokolünün bir başka zayıflığı, cache poisoning'e açık olmasıdır: saldırgan, resolver'a sahte cevap göndererek belirli bir alan adının yanlış IP'ye çözünmesini sağlar. DNSSEC bu saldırıyı şifresel imzalarla engeller; ancak henüz tüm zone'lar imzalı değil. +dnssec bayrağıyla cevap geldiğinde ad (Authenticated Data) flag'inin set edilip edilmediğini kontrol edin.
# DNSSEC doğrulama
dig +dnssec +short example.org
dig example.org +noall +answer +comments | grep flags
# delv ile kapsamlı doğrulama
delv +cd +trust example.org
# Yanıtın AD flag'i set ise DNSSEC doğrulanmış demektirResolver tarafındaki best practice: 0x20 randomization (büyük/küçük harf rastgeleliği), kaynak port rastgeleliği (Kaminsky koruması) ve QNAME minimization aktif olmalı. unbound ya da knot-resolver kurarken bu seçenekleri açık bırakın.
DNS Logging ve İzleme: Sorgu Trafiğinizi Görmek
Bir sunucunun yaptığı tüm DNS sorgularını görmek operasyonel telemetri için değerlidir. tcpdump, dnstap, tshark gibi araçlarla portlar üzerinde gerçek zamanlı izleme yapılabilir.
# tcpdump ile 53/UDP trafiği canlı izle
sudo tcpdump -i any -n -l 'udp port 53' | head -100
# Sadece sorgu adlarını çıkar
sudo tcpdump -i any -nn -s0 -A 'udp port 53' | strings | grep -E '^[a-z0-9.-]+\.com'
# tshark ile DNS sorgu özeti
sudo tshark -i any -f 'udp port 53' -Y 'dns.flags.response==0' \
-T fields -e dns.qry.name -e dns.qry.typeDüzenli logları SIEM'e (Splunk, ELK, Loki) gönderin. ELK stack yazımız ve Prometheus/Grafana yazımız bu tip telemetrinin kurulumunu detaylı gösteriyor. Anomali tespiti açısından, normal trafik içinde olmayan uzun, base64'lenmiş gibi görünen alt etki alanları DNS tunneling sinyalidir.
Adım Adım: Bir Domain Sorgu Senaryosu
Tüm parçaları birleştirelim. Diyelim bir tedarikçi web sitesini denetliyorsunuz ve başlangıç olarak yalnızca alan adı elinizde. Üstte değindiğimiz araçları sırayla kullanmak şu rotayı çizer:
- 1. A/AAAA kayıtları:
dig +short tedarikci.com.tr A AAAAile başlayın. Aldığınız IP'yi not edin. - 2. NS sunucuları:
dig NS tedarikci.com.trile otoritatif sunucuları öğrenin; otoritatife sorup cache farkını görün. - 3. Reverse DNS:
dig -x <ip>ile geri yönde hostname olup olmadığına bakın. - 4. WHOIS / RDAP:
whois <ip>vewhois tedarikci.com.trhem alan adı sahibini hem IP sahibini verir. - 5. ASN ve coğrafya:
whois -h whois.cymru.com " -v <ip>"ile sağlayıcı,ipinfo.io/<ip>ile coğrafya. - 6. HTTP header'lar:
curl -sI https://tedarikci.com.trile sunucu, CDN, framework ipuçları. - 7. Açık portlar (yetkiniz varsa):
nmap -F <ip>hızlı bir profil çıkarır. - 8. SAN listesi: TLS sertifikası içindeki SAN'ler kapsanan tüm hostname'leri ifşa eder.
- 9. Subdomain envanteri:
subfinder -d tedarikci.com.trek hostname'leri çıkarır. - 10. CT logları:
crt.shile geçmişte hangi sertifikalar yayınlanmış görün. - 11. Reverse IP: aynı IP'de barınan diğer site'leri listeleyin.
- 12. Dökümantasyon: tüm bulguları zaman damgalı bir dosyada saklayın; tekrar denetimde fark görmek kıymetlidir.
Bu rota yarım saatte tamamlanır ve hemen hemen her küçük-orta ölçekli web varlık denetiminin altyapısını kurar. Sürdürülebilir izlem için bu adımları otomatik bir script haline getirip haftada bir koşturmak en iyi pratiktir.
Sonuçları Otomasyona Bağlamak: Tek Dosya Bash Skripti
#!/usr/bin/env bash
# domain-recon.sh — özet alan adı + IP raporu
# Kullanım:./domain-recon.sh ornek.com.tr
set -euo pipefail
DOMAIN="${1:?Alan adı verin}"
OUT="$DOMAIN-recon-$(date +%F).txt"
{
echo "### Hedef: $DOMAIN"
echo "### Tarih: $(date -Iseconds)"
echo
echo "## A kayıtları"; dig +short "$DOMAIN" A
echo "## AAAA kayıtları"; dig +short "$DOMAIN" AAAA
echo "## NS"; dig +short "$DOMAIN" NS
echo "## MX"; dig +short "$DOMAIN" MX
echo "## TXT"; dig +short "$DOMAIN" TXT
IP=$(dig +short "$DOMAIN" A | head -1)
if [ -n "$IP" ]; then
echo
echo "## Reverse DNS ($IP)"
dig -x "$IP" +short
echo
echo "## ASN / Coğrafya"
curl -s "https://ipinfo.io/$IP/json" | jq '.'
fi
echo
echo "## WHOIS (alan adı, kısa)"
whois "$DOMAIN" 2>/dev/null | grep -Ei '^(Registrar|Registry Expiry|Updated Date|Creation Date|Name Server)' | sort -u
echo
echo "## HTTP header'lar"
curl -sI "https://$DOMAIN" | head -25 || true
} | tee "$OUT"
echo ">> Rapor: $OUT"Bu script tek dosyada başlangıç keşfini özetler. Üretim ortamında bunu cron'a bağlayıp diff ile geçmişe kıyasladığınızda, sessizce değişen DNS kayıtlarını ya da CDN geçişlerini erkenden yakalayabilirsiniz. GitHub Actions yazımız bu tarz scriptleri pipeline'a sokmak için iyi bir başlangıçtır.
Yaygın Hatalar ve Tuzaklar
- Tek resolverla yetinmek: tek bir resolver, hem cache hem coğrafi yanlılık sebebiyle sizi yanıltır. En az 3 farklı resolver'a sorun.
- TTL'i göz ardı etmek: 'IP'yi değiştirdim ama hâlâ eskisi geliyor' şikayetlerinin %95'i TTL'in dolmamış olmasıdır. Önceki TTL'i not edin.
- CDN edge'i origin sanmak: gördüğünüz IP Cloudflare ya da Akamai edge'i olabilir; gerçek origin başka yerdedir.
- Reverse IP'ye fazla güvenmek: özellikle popüler shared hosting'lerde aynı IP'de yüzlerce ilgisiz site barınır.
- Yetkisiz port taraması: izin almadığınız sistemlere tarama yapmak yasal sorun yaratır.
- WHOIS gizliliğini kanıt sanmak: birçok registrar artık privacy servisi sunuyor; WHOIS'te 'Whois Guard' görseniz bu sahibin gerçekten 'gizli kişi' olduğu anlamına gelmez.
- GeoIP'i sokak olarak okumak: GeoIP kabaca ülke ve şehir verir; bireyin fiziksel adresi değildir.
- DNSSEC olmadan cevaba güvenmek: kafe Wi-Fi'sinde yapılan sorgular kolayca manipüle edilebilir.
Hızlı Referans: Komut Cheatsheet
# === DNS ===
dig +short site.com A # IPv4
dig +short site.com AAAA # IPv6
dig +trace site.com # kök -> otoritatif iz
dig @1.1.1.1 +short site.com # belirli resolver
dig -x 8.8.8.8 +short # reverse
dig +dnssec +short site.com # imzalı sorgu
host site.com # kısa form
Resolve-DnsName site.com -Type A # PowerShell
# === WHOIS / RDAP ===
whois site.com
whois 8.8.8.8
curl -s https://rdap.org/ip/8.8.8.8 | jq
curl -s https://rdap.org/domain/site.com | jq
# === IP itibarı / coğrafya ===
curl -s ipinfo.io/8.8.8.8
curl -s 'http://ip-api.com/json/8.8.8.8'
dig +short TXT 8.8.8.8.origin.asn.cymru.com
# === Port + servis ===
nmap -F 1.2.3.4
nmap -sV -p 22,80,443 1.2.3.4
mtr --report 1.2.3.4
# === HTTP / TLS ===
curl -sI https://site.com
curl --resolve site.com:443:1.2.3.4 -sI https://site.com
openssl s_client -connect site.com:443 -servername site.com </dev/null \
| openssl x509 -noout -text | grep -E 'DNS:|Issuer'
# === CT logları + alt domain ===
curl -s 'https://crt.sh/?q=%25.site.com&output=json' | jq -r '.[].name_value' | sort -u
subfinder -d site.com -silent
# === Public IP ===
curl -s ifconfig.me
dig +short myip.opendns.com @resolver1.opendns.comBu cheatsheet'i ekibinize yapıştırın ya da terminalinize alias olarak ekleyin; aynı senaryoya defalarca dönecek mühendisler için zaman tasarrufu büyüktür.
Yasal ve Etik Çerçeve
Türkiye'de TCK 243 (bilişim sistemine girme), TCK 244 (sistemleri engelleme, bozma, verileri yok etme/değiştirme) ve KVKK kapsamı, sahibi olmadığınız sistemlere izinsiz teknik müdahaleyi suç sayar. DNS sorgu yapmak ile port taraması arasındaki çizgi; pasif sorgu (DNS, WHOIS, RDAP, public Web) çoğunlukla problemsizken, aktif tarama (port scan, banner grab, brute force) yetki gerektirir.
Profesyonel pen-test ve bug bounty senaryolarında her zaman yazılı izin ve net scope şarttır. Açık kurumsal politikası olmayan sistemlerde tarama yapmayın; iyi niyetli bir uyarı bile, çıkış noktanız iyi belgelenmemişse hukuki sorun doğurabilir.
Sıkça Sorulan Sorular
Bir alan adının IP'si zaman içinde değişir mi?
Evet — bazen sık sık. Hosting taşımaları, CDN değişiklikleri, load balancer arkasındaki dinamik IP atamaları, mavi-yeşil deploy, multi-region failover hepsi A kaydını değiştirir. CDN kullananlar için aynı domain her sorguda farklı bir edge IP'si dahi dönebilir; bu dağıtık mimari için normaldir.
IP'mi gizleyebilir miyim?
Tamamen değil — ama çoğu pratik durumda yeterince. VPN, Tor, residential proxy, mobil hotspot rotation gibi yöntemler dış dünyaya görünen IP'yi değiştirir. Bununla birlikte tarayıcı parmak izi, çerez izleri, hesap girişleri, ödeme bilgileri gibi başka kanallardan kimliğiniz tespit edilebilir. Anonimlik katmanlıdır.
Birinin IP'sini öğrenmek yasal mı?
Yöntemine bağlı: bir kişinin gönüllü olarak girdiği web sitenizde Apache/Nginx loglarında IP görmek normal ve yasaldır (KVKK kapsamında işleme amacı tanımlanmış olmalı). Aynı kişinin IP'sini, izinsiz olarak truva atı, phishing ya da yasadışı bir teknikle ele geçirmek suçtur.
IP üzerinden birinin kim olduğunu öğrenebilir miyim?
Hayır. IP size yalnızca ISS'i ve kabaca bir bölgeyi söyler. Belirli bir aboneye bağlamak için ISS kayıtlarına erişim gerekir; bu da yalnızca yargısal süreçle (mahkeme kararı) mümkündür.
Aynı IP'de birden fazla site barınması güvenlik riski mi?
Doğrudan değil. Shared hosting'in tanımı budur. Risk, aynı sunucunun zayıf yapılandırıldığı durumlarda çapraz site sızıntısı (komşu hesaba erişim) ya da bir komşu site'nin kötü reputation'ı yüzünden RBL'e düşüş gibi yan etkilerdir. VPS rehberimiz ayrı IP almanın değerine değiniyor.
DNS değişikliğim neden hâlâ geçmedi?
Üç olası sebep: (a) eski TTL süresinin dolmaması, (b) ISS resolver'ının agresif cache'lemesi, (c) yerel cihazınızın DNS cache'i. Her biri için tarif ettiğimiz cache temizleme komutlarını ve çoklu resolver sorgusu yöntemini birleştirin.
Origin IP'mi nasıl gizlerim?
Cloudflare proxy'leme + Authenticated Origin Pulls, sadece CDN aralıklarına izin veren firewall, ayrı subdomain'lerden cPanel/SSH erişimini saklamamak, e-posta için ayrı IP/SMTP relay kullanmak, eski sertifikaları rotate etmek temel adımlardır. DDoS rehberi detaylı işliyor.
DNS sorgusu yaparken loglarım kalır mı?
Evet — kullandığınız resolver çoğu zaman sorgularınızın bir özetini saklar (anonimleştirilmiş ya da değil). Hassas bir sorguysa Tor üzerinden DoH ya da kendi cache resolver'ınızı (unbound) çalıştırmak iyi alışkanlıktır.
Daha İleri: Kendi DNS Sorgu Sunucunuzu Çalıştırmak
İleri kullanıcılar bir cache resolver kurarak hem hızı hem gizliliği iyileştirebilir. unbound hafif, knot-resolver modern ve performanslıdır. Her ikisi de DNSSEC, QNAME minimization ve isteğe bağlı DoT upstream destekler.
# Ubuntu üzerinde unbound
sudo apt install unbound
sudo tee /etc/unbound/unbound.conf.d/local.conf <<'EOF'
server:
interface: 127.0.0.1
access-control: 127.0.0.0/8 allow
qname-minimisation: yes
use-caps-for-id: yes
prefetch: yes
hide-identity: yes
hide-version: yes
harden-glue: yes
harden-dnssec-stripped: yes
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 9.9.9.9@853#dns.quad9.net
EOF
sudo systemctl restart unbound
# Kullan
echo 'nameserver 127.0.0.1' | sudo tee /etc/resolv.conf
dig example.comYerel cache resolver, sıkça sorduğunuz domain'leri saniyenin altında çözer ve dış dünyaya gönderdiğiniz sorgu sayısını ciddi azaltır. Bir VPS'iniz ya da home lab'ınız varsa, ailenizin/şirketinizin DNS trafiğini buradan geçirmek de yapılabilir bir kazançtır. VPS sertleştirme yazısı bu kurulumun güvenli yanını anlatıyor.
Performans Notu: Sorgu Süresi Neye Bağlı?
Bir DNS sorgusunun süresi şunlara bağlıdır: yerel cache (cache hit ise mikrosaniye), resolver'ın size mesafesi (Anycast olan büyük operatörler genelde 5–20 ms), TTL'nin canlı olup olmaması, otoritatif sunucunun coğrafyası, UDP paket boyutu ve potansiyel TCP fallback'i. Ölçmek için dig'in Query time alanına bakın.
# Sorgu süresini ölç
dig site.com | grep 'Query time'
# ;; Query time: 12 msec
# Tekrarlanan sorgu (cache hit göreceksiniz)
for i in 1 2 3 4 5; do dig site.com +short; done
# Çoklu resolver hız kıyaslaması
for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
echo -n "$r: "
dig @$r site.com +noall +stats 2>/dev/null | grep 'Query time'
doneDNS gecikmesi her sayfanın ilk byte'ından önce yaşanan görünmez maliyetlerdendir; sayfa hızı yazımız ve site optimizasyonu yazımız bu maliyeti TTFB içinde görmenizin yollarını anlatıyor.
İçerik Yayıncıları İçin Pratik Senaryolar
Dijital pazarlama ve SEO ekipleri için domain IP sorgulama günlük rutinin bir parçasıdır: yarışmacı analizinde rakibin barınma sağlayıcısını anlamak, taşımalardan sonra arama sonuç sayfasındaki cache'lerin yenilenmesini izlemek, Google Search Console'a yansımayan DNS yapılandırma hatalarını yakalamak gibi. Teknik SEO kontrol listesi bu kontrolleri haftalık disipline bağlamayı önerir.
Site sahipleri içinse iki kritik refleks: (1) hosting değişikliği yaptığınızda, eski IP'ye giden trafiğin tamamen kesildiğini propagation araçları ve dig ile doğrulamak; (2) ana domain ile www alt domain'inin doğru CNAME/A yapısına sahip olduğunu, HTTPS sertifikasının her ikisini de kapsadığını kontrol etmek.
Kapanış: Disiplinli Bir Sorgu Refleksi
Domain IP sorgulama, çok çeşitli aracın altında saklanan tek bir mantık etrafında döner: isim → numara, numara → sahip, sahip → bağlam. Aracı değişebilir, çıktı formatı değişebilir, tek bir komut yerine bir script tercih edebilirsiniz; ama hangi katmanda hangi soruyu sorduğunuzu bilmek tek değişmezdir. Bu rehber bütün katmanları (DNS, reverse, WHOIS/RDAP, GeoIP, ASN, TLS/SAN, CT logları, port, traceroute, header) tek bir akış içinde ifade etmek için yazıldı.
Pratiğe dökmek için bir domain seçin, yukarıdaki 12 adımlık senaryoyu adım adım çalıştırın ve çıktıları bir dosyaya kaydedin. İki hafta sonra aynı sorgu setini tekrar koşturun ve diff'leri inceleyin — değişen ve değişmeyen şeyler size mimariyi öğretir. Bu refleks oturduğunda, panel arayüzlerine ya da basit web araçlarına bel bağlamadan, alan adlarının arkasındaki gerçek iskeleti her seferinde kendi kendinize çıkarabilirsiniz.
Daha Fazla Okuma
- DNS Nedir? DNS Ayarları, Değiştirme ve En İyi DNS Sunucuları
- Domain Sorgulama Araçları: WHOIS, RDAP ve DNS Rehberi
- Domain Adı Nedir?.com Alan Adı ve WHOIS Sorgulama
- WHOIS Sorgulama: Domain Sahibi Bulma Rehberi
- HTTPS ve TLS 1.3: Modern Web Şifreleme
- DDoS Saldırılarına Karşı Çok Katmanlı Koruma
- OWASP Top 10 2026
- Nginx Yapılandırma Rehberi
- Sayfa Hızı ve Core Web Vitals 2026
- Teknik SEO Kontrol Listesi 2026
- Tüm Web Araçları
DNS, WHOIS, reverse, port ve TLS kontrollerini tek arayüzde toplayan ücretsiz araçlarımıza göz atın; karmaşık komutları ezberlemek yerine sonuçlara doğrudan ulaşın. Araçlara git