Domain IP Sorgulama: Site IP Adresi Bulma, DNS, Reverse Lookup ve WHOIS Rehberi

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.

+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.

+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.

Yerel 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.

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.

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.

GeoIP 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.

ASN 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.

Reverse 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.

Sertifika 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.

Port 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.

İ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.

Server: 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.

Ofis 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.

Pratik 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.

Mobil 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:

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, Shodan historical 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) Received zincirinde 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.

Kendi 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.

Mail 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.

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.

Subdomain 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.

Resolver 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.

Dü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 AAAA ile başlayın. Aldığınız IP'yi not edin.
• 2. NS sunucuları: dig NS tedarikci.com.tr ile 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> ve whois tedarikci.com.tr hem 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.tr ile 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.tr ek hostname'leri çıkarır.
• 10. CT logları: crt.sh ile 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

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

Bu 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.

Yerel 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.

DNS 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ı