DNS sorun giderme: nslookup, dig ve Resolve-DnsName

Belirti

DNS arızası nadiren "DNS bozuk" diye gelir. Bana gelen çağrılar genelde şu beş kalıptan birine uyar:

• IP ile açılıyor, adla açılmıyor. ping 10.0.0.39 cevap veriyor, ping intranet.example.com "could not find host" diyor; tarayıcıda Chrome DNS_PROBE_FINISHED_NXDOMAIN gösteriyor.
• Bazı istemcilerde çalışıyor, bazılarında çalışmıyor. Aynı VLAN'daki iki makineden biri adı çözüyor. Fark genellikle istemci tarafında: farklı DNS sunucusu, eski önbellek kaydı, unutulmuş bir hosts satırı ya da VPN'in eklediği NRPT kuralı.
• Yalnızca iç ağda (ya da yalnızca dışarıda) çalışıyor. Ofiste açılan portal evden açılmıyor veya tersi. Bu, iç ve dış için ayrı bölge tutulan split-brain (bölünmüş beyin) DNS'in klasik işaretidir.
• Etki alanına katılım başarısız. "An Active Directory Domain Controller for the domain could not be contacted" mesajı ve 0x54b hatası. Microsoft'un belgesine göre bu çoğunlukla DC'yi bulmak için sorgulanan SRV kaydının zaman aşımına uğramasından çıkar.
• Aralıklı SERVFAIL. Aynı ad bazen çözülüyor, bazen "DNS server failure" dönüyor. Yönlendirici gecikmesi, DNSSEC doğrulama hatası ya da büyük yanıtların ağda takılması akla gelmelidir.

Neden

Bir uygulama ad sorduğunda soru beş halkadan geçer. Windows'ta önce DNS İstemcisi hizmeti yerel önbelleğe ve hosts dosyasına bakar, NRPT (Name Resolution Policy Table, ad çözümleme ilke tablosu) kuralı varsa soruyu o kuralın sunucusuna yönlendirir. Cevap yoksa soru arayüzde yapılandırılmış DNS sunucusuna gider. O sunucu bölgenin sahibi değilse koşullu yönlendiriciye, genel yönlendiriciye ya da kök ipuçlarına (root hints) başvurur. Zincirin sonunda kök, TLD ve yetkili ad sunucusu vardır.

Her halka kendi önbelleğini tutar ve kendi hatasını üretir. Bu yüzden "nslookup çalışıyor" cümlesi tek başına bir şey kanıtlamaz: Microsoft'un istemci sorun giderme belgesi, nslookup'ın istemcinin DNS önbelleğini kullanmadığını ve doğrudan yapılandırılmış sunucuya gittiğini açıkça yazar. Yani nslookup ilk iki halkayı atlar; tarayıcı atlamaz.

İç ağ ile internet aynı adı farklı cevaplıyorsa (split-brain) bir halka daha karışır: cevap, soruyu hangi sunucuya sorduğunuza bağlıdır. VPN istemcisi NRPT ile .corp.example.com sorularını iç sunucuya, gerisini ev modemine gönderebilir. Aynı makinede iki komutun iki farklı cevap vermesi bu durumda arıza değil, tasarımdır; arıza, beklenmeyen görünümün dönmesidir.

Çözüm

Sırayla gidin ve her adımda bir halkayı eleyin. Örneklerde <AD> sorunlu ad, <IC-DNS> istemcinin kullandığı iç DNS sunucusu, <YETKILI-NS> bölgenin yetkili ad sunucusudur.

1. İstemci yapılandırmasını ve önbelleği kontrol edin

   Önce istemcinin gerçekten hangi sunucuya sorduğunu görün. DHCP'den yanlış DNS adresi gelmesi, ikinci bağdaştırıcıdaki (Hyper-V vSwitch, VPN) unutulmuş bir adres ya da yanlış DNS soneki en sık bulduğum nedenler.

   Get-DnsClientServerAddress -AddressFamily IPv4

   Get-DnsClientCache -Entry <AD>

   Microsoft'un belgesine göre ipconfig /displaydns çıktısında sorunlu adın altında "Name does not exist" görüyorsanız sunucudan gelen olumsuz cevap istemcide önbelleğe alınmıştır. Temizleyip tekrar deneyin:

   Clear-DnsClientCache

   Linux'ta /etc/resolv.conf içinde nameserver 127.0.0.53 görüyorsanız systemd-resolved'ın yerel stub çözümleyicisini görüyorsunuz; dig'in bu adrese sorduğu soru gerçek sunucuyu göstermez. Gerçek üst sunucular ve bağlantı başına ayarlar resolvectl status çıktısındadır, önbelleği resolvectl flush-caches temizler.

2. hosts dosyasını ve NRPT kurallarını eleyin

   hosts dosyası (C:\Windows\System32\drivers\etc\hosts) DNS'ten önce gelir. Aynı adı hosts'u atlayarak sorun; iki sonuç farklıysa sorun dosyadadır:

   Resolve-DnsName -Name <AD> -NoHostsFile

   Select-String -Path "$env:windir\System32\drivers\etc\hosts" -Pattern '^\s*[^#\s]'

   Sonra NRPT'ye bakın. DirectAccess, Always On VPN veya GPO ile gelen bir kural, bir ad alanını tamamen farklı sunuculara yönlendirebilir ve ipconfig /flushdns bunu düzeltmez. -Effective parametresi o an uygulanan ilkeyi gösterir:

   Get-DnsClientNrptPolicy -Effective

   Resolve-DnsName varsayılan olarak DNS başarısız olunca LLMNR ve NetBIOS'a da düşebilir; -DnsOnly bunu keser. Bu yayın protokollerini zaten kapattıysanız (Windows Server 2025 sertleştirme listesindeki LLMNR ve NetBIOS maddesi) tek kaynak DNS olur ve sonuçlar daha öngörülebilir hâle gelir.

3. Yapılandırılmış sunucuya doğrudan sorun

   Şimdi istemci katmanını devre dışı bırakıp iç sunucunun ne dediğine bakın. -Server sorguyu belirttiğiniz sunucuya gönderir, -DnsOnly ve -NoHostsFile yerel kaynakları dışarıda bırakır:

   Resolve-DnsName -Name <AD> -Type A -Server <IC-DNS> -DnsOnly -NoHostsFile

   dig @<IC-DNS> <AD> A

   İç sunucu doğru cevap veriyor ama istemci vermiyorsa sorun ilk iki halkadadır; geri dönün. İç sunucu da yanlış cevap veriyorsa bir sonraki adıma geçin. Ters kayıt sorunlarında aynı testi PTR ile yapın; ters bölge adı adresin oktetleri ters çevrilerek in-addr.arpa altında oluşur ve hangi bölgenin hangi alt ağı kapsadığını subnet ve CIDR rehberindeki sınırlar belirler:

   Resolve-DnsName -Name 39.0.0.10.in-addr.arpa -Type PTR -Server <IC-DNS>

4. Yetkili sunucuya sorun ve yolu izleyin

   Önce bölgenin yetkili sunucularını bulun, sonra birine özyineleme istemeden sorun. Cevaptaki aa (authoritative answer) bayrağı, cevabın önbellekten değil kaynaktan geldiğini gösterir:

   dig <ALAN-ADI> NS +short

   dig @<YETKILI-NS> <AD> A +norecurse

   Yetkili sunucu doğru, iç sunucu yanlış cevap veriyorsa arıza aradaki halkadadır: önbellek, yönlendirici ya da koşullu yönlendirici. Windows DNS Sunucusunda Microsoft'un yönlendirici sorun giderme belgesindeki sırayı izliyorum: önce ad için koşullu yönlendirici var mı, yoksa genel yönlendiriciler ve kök ipuçları:

   Get-DnsServerZone -Name <ALAN-ADI>

   Get-DnsServerForwarder

   Delegasyon şüphesi varsa dig <AD> +trace kökten başlayıp her yönlendirmeyi (referral) gösterir. Bu sorgu iç sunucuyu atlayıp doğrudan kök sunuculara gider; kurumsal ağda dışarıya UDP/TCP 53 kapalıysa takılır, bunu arıza sanmayın. Dış görünümü kontrol ederken kendi genel adresinizi ve ters kaydınızı IP adresim aracıyla görebilirsiniz.

5. Yanıt kodunu okuyun

   Her sorgu bir yanıt kodu (RCODE) döndürür ve sorunun türünü bu kod söyler. dig bunu başlıktaki status: alanında, nslookup İngilizce bir mesajla, Resolve-DnsName Windows hata metniyle gösterir. NODATA ayrı bir kod değildir; RFC 2308 bunu "NOERROR ve cevap bölümü boş" olarak tanımlar.

   Kod	dig	nslookup	Windows (Resolve-DnsName)	Anlamı	İlk bakılacak yer
   NOERROR	status: NOERROR	Ad ve adres	Kayıtlar listelenir	Cevap var	Cevap yanlışsa önbellek ve split-brain
   NODATA	NOERROR, ANSWER: 0	No records	9501, yalnızca SOA döner	Ad var, bu türde kayıt yok	Sorgu türü (A/AAAA/SRV)
   NXDOMAIN	status: NXDOMAIN	Non-existent domain	9003 DNS name does not exist	Ad yok	Yazım, DNS soneki, olumsuz önbellek
   SERVFAIL	status: SERVFAIL	Server failure	9002 DNS server failure	Sunucu cevap üretemedi	Yönlendirici, DNSSEC, bölge yükleme
   REFUSED	status: REFUSED	Query refused	9005 DNS operation refused	Sunucu sizi reddetti	Özyineleme ayarı, DNS ilkeleri
   Zaman aşımı	connection timed out	timed out	timeout period expired	Cevap hiç gelmedi	UDP/TCP 53, sunucu durumu

   

   Microsoft'un yönlendirici belgesindeki iki senaryo bu tabloyu iyi özetliyor: koşullu yönlendirici sorguyu reddederse (REFUSED) iç sunucu istemciye SERVFAIL döner; yönlendiricide kayıt yoksa NXDOMAIN aynen istemciye taşınır. Yani istemcinin gördüğü kod, zincirin başka bir halkasında üretilmiş olabilir.

6. TTL ve olumsuz önbelleği hesaba katın

   Kaydı düzelttiniz ama eski cevap dönüyorsa önbellek süresini hesaplayın. RFC 2308'e göre olumsuz cevabın önbellek süresi, SOA kaydının MINIMUM alanı ile SOA'nın kendi TTL'inden küçük olanıdır. NXDOMAIN cevabının yetki (authority) bölümündeki SOA satırının TTL'i bu süreyi doğrudan gösterir:

   dig @<YETKILI-NS> olmayan-ad.<ALAN-ADI> A +noall +authority

   Windows DNS Sunucusu tarafında Microsoft'un Set-DnsServerCache belgesine göre olumlu kayıtlar varsayılan olarak en fazla bir gün, olumsuz cevaplar en fazla 15 dakika tutulur. Sunucu önbelleğini temizlemek için:

   Clear-DnsServerCache

7. AD ortamında SRV kayıtlarını ve DC bulmayı test edin

   Etki alanına katılım ve oturum açma, DC'nin DNS üzerinden bulunmasına dayanır. Microsoft'un DC locator belgesine göre Netlogon, SRV kayıtlarını sorgular ve bulduğu DC'lere UDP üzerinden LDAP ping gönderir. Önce kaydın varlığını, sonra bulmanın kendisini test edin:

   Resolve-DnsName -Name _ldap._tcp.dc._msdcs.<ETKI-ALANI> -Type SRV -Server <IC-DNS>

   nltest /dsgetdc:<ETKI-ALANI> /force

   SRV sorgusu NXDOMAIN dönüyorsa istemci büyük olasılıkla AD bölgesini barındırmayan bir sunucuya (ör. ISP veya genel çözümleyici) soruyordur. Kayıt var ama nltest başarısızsa sorun DNS'ten çıkıp ağa (LDAP 389, RPC 135, SMB 445) kaymıştır. DC'lerin kayıt ve çoğaltma sağlığını Active Directory sağlık kontrolü yazısındaki dcdiag ve repadmin adımlarıyla doğrulayın.

8. Ağı kontrol edin: UDP/TCP 53 ve büyük yanıtlar

   DNS sorguları varsayılan olarak UDP 53 kullanır, büyük yanıtlarda TCP 53'e geçer; RFC 7766 TCP desteğini zorunlu tutar. Dikkat: Test-NetConnection -Port yalnızca TCP'yi test eder, UDP 53 için bir şey söylemez. UDP'yi en iyi gerçek bir sorgu test eder:

   Test-NetConnection -ComputerName <IC-DNS> -Port 53

   Resolve-DnsName -Name <AD> -Server <IC-DNS> -TcpOnly

   Küçük cevaplar gelip büyükleri (DNSSEC imzalı, çok sayıda TXT veya SRV içeren) takılıyorsa EDNS arabellek boyutu ve parçalanma (fragmentation) şüphelisidir. DNS Flag Day 2020, parçalanmayı önlemek için 1232 baytlık EDNS arabelleğini önerdi. Aşağıdaki iki sorgudan biri gelip diğeri gelmiyorsa güvenlik duvarı UDP parçalarını ya da TCP 53'ü kesiyordur:

   dig @<IC-DNS> <AD> +dnssec +bufsize=1232

   dig @<IC-DNS> <AD> +tcp

   Aralıklı SERVFAIL ve DNSSEC şüphesinde +cd (checking disabled) ile doğrulamayı kapatın. RFC 4035'e göre doğrulayan sunucu sahte veride SERVFAIL döndürür, CD bayrağı ayarlıysa veriyi verir; +cd ile cevap geliyorsa sorun imzadadır.

Sunucu tarafında kanıt toplamak

İstemci testleri sunucuyu işaret ediyorsa tahmin yerine günlüğe bakın. Windows Server'da DNS Sunucusu analitik günlüğü (Microsoft-Windows-DNSServer/Analytical) her başarılı cevabı 257, her başarısız cevabı 258, her özyinelemeli sorgu zaman aşımını 262 olay kimliğiyle yazar. Microsoft'un belgesine göre analitik günlük, saniyede 100.000 sorgu alan bir sunucuda yaklaşık yüzde 5 performans kaybına yol açabilir; 50.000 ve altında belirgin etki yoktur. Eski hata ayıklama günlüğü (dns.log) ise kaynak tükettiği için yalnızca kısa süreli açılmalıdır.

Komut karşılıkları

Kalıcı önlem

Arızayı kullanıcıdan önce görmek için iç DNS sunucularını zamanlanmış bir görevle sorguluyorum. Aşağıdaki betik her sunucuya kritik adları (etki alanı, DC SRV kaydı, bir dış ad) sorar ve sonucu CSV'ye ekler; Görev Zamanlayıcı ile beş dakikada bir çalıştırıp hata satırlarını izleme sisteminize okutabilirsiniz. Klasörü önceden oluşturun.

$sunucular = @('<IC-DNS-1>', '<IC-DNS-2>')
$sorgular = @(
  @{ Ad = '<ETKI-ALANI>'; Tur = 'A' },
  @{ Ad = '_ldap._tcp.dc._msdcs.<ETKI-ALANI>'; Tur = 'SRV' },
  @{ Ad = 'www.microsoft.com'; Tur = 'A' }
)
foreach ($s in $sunucular) {
  foreach ($q in $sorgular) {
    try {
      $null = Resolve-DnsName -Name $q.Ad -Type $q.Tur -Server $s -DnsOnly -NoHostsFile -QuickTimeout -ErrorAction Stop
      $durum = 'OK'
    } catch {
      $durum = $_.Exception.Message
    }
    [pscustomobject]@{ Zaman = (Get-Date -Format s); Sunucu = $s; Ad = $q.Ad; Tur = $q.Tur; Durum = $durum } |
      Export-Csv -Path 'C:\Izleme\dns-kontrol.csv' -Append -NoTypeInformation -Encoding UTF8
  }
}

Tasarım tarafında üç kuralım var. Birincisi, her istemcide ve her DC'de en az iki iç DNS sunucusu tanımlı olsun; Microsoft'un istemci ayarları belgesi de DC'leri ISP'nin DNS sunucularına yönlendirmemeyi öneriyor, çünkü o sunucular AD bölgesini bilmez. İkincisi, yönlendirici zinciri kısa ve tek yönlü olsun: iç sunucular iki üst çözümleyiciye yönlendirsin, ortak etki alanları için koşullu yönlendirici kullanılsın, iki sunucu birbirine yönlendirerek döngü kurmasın. Üçüncüsü, değişiklikten önce TTL düşürülsün ve hosts dosyası kalıcı çözüm olarak kullanılmasın.

İlgili hatalar

Kaynaklar

• Microsoft Learn, Troubleshooting DNS clients (erişim: Ekim 2026)
• Microsoft Learn, Troubleshooting DNS servers (erişim: Ekim 2026)
• Microsoft Learn, Troubleshoot DNS name resolution failures related to DNS forwarders (erişim: Ekim 2026)
• Microsoft Learn, Resolve-DnsName (erişim: Ekim 2026)
• Microsoft Learn, Get-DnsClientCache (erişim: Ekim 2026)
• Microsoft Learn, Get-DnsClientNrptPolicy (erişim: Ekim 2026)
• Microsoft Learn, nslookup (erişim: Ekim 2026)
• Microsoft Learn, Set-DnsServerCache (erişim: Ekim 2026)
• Microsoft Learn, Enable DNS logging and diagnostics in Windows Server (erişim: Ekim 2026)
• Microsoft Learn, Use DNS Policy for split-brain DNS deployment (erişim: Ekim 2026)
• Microsoft Learn, Locating Active Directory domain controllers (DC locator) (erişim: Ekim 2026)
• Microsoft Learn, Domain join error code 0x54b (erişim: Ekim 2026)
• Microsoft Learn, Recommendations for DNS client settings (erişim: Ekim 2026)
• Microsoft Learn, Test-NetConnection (erişim: Ekim 2026)
• Microsoft Learn, System error codes 9000-11999 (erişim: Ekim 2026)
• ISC, BIND 9 manual pages: dig (erişim: Ekim 2026)
• ISC bind-users listesi, Deprecating BIND 9.18+ on Windows (erişim: Ekim 2026)
• man7.org, resolvectl(1) ve systemd-resolved.service(8) (erişim: Ekim 2026)
• IETF, RFC 2308: Negative caching of DNS queries (erişim: Ekim 2026)
• IETF, RFC 4035: DNSSEC protocol modifications (erişim: Ekim 2026)
• IETF, RFC 7766: DNS transport over TCP (erişim: Ekim 2026)
• DNS Flag Day, DNS Flag Day 2020 (erişim: Ekim 2026)