Windows DNS Sorunlarını Giderme: nslookup ve dcdiag Araçları

Yazar:komut.io ekibi Windows DNS Sunucusu Kurulum ve Yönetimi
0 Yorum

Yıllar içinde kaç tane “DNS çalışmıyor” çağrısı aldım bilemiyorum. Çoğu zaman sorun basit bir şeydir ama bazen saatler içinde çözülmeyen, üretimi etkileyen, herkesin birbirine baktığı o türden krizlere de giriyorsunuz. Windows ortamlarında DNS sorunları, Active Directory ile iç içe geçmiş olduğu için özellikle can sıkıcı bir hal alabilir. Bu yazıda sizi kurtaracak iki araca odaklanacağım: nslookup ve dcdiag. Bunları doğru kullanmayı öğrenirseniz, çoğu DNS krizini 15-20 dakika içinde teşhis edebilirsiniz.

Neden Bu Kadar Karmaşık?

Windows DNS, sade bir isim çözümleme servisi değil. Active Directory entegrasyonu, dinamik DNS güncellemeleri, Conditional Forwarder’lar, Stub Zone’lar, DNS scavenging… Bunların hepsi bir arada çalışıyor ve herhangi biri patladığında sorunu izole etmek için sistematik bir yaklaşım gerekiyor.

Rastgele tıklamak yerine önce “bu sorun hangi katmanda?” sorusunu sormak gerekiyor. Client tarafında mı? DNS sunucusunda mı? Zone verilerinde mi? AD replikasyonunda mı? Bu soruyu doğru cevaplamak için nslookup ve dcdiag tam olarak biçilmiş kaftan.

nslookup: Temel Ama Güçlü

İlk Bakış: Basit Sorgular

nslookup’ı herkes bilir ama çoğu kişi yüzeyin altını kazımaz. Gelin biraz derine inelim.

En temel kullanım:

nslookup sunucu01.sirket.local

Bu komut işe yaramadığında, yani “Non-existent domain” veya timeout aldığınızda asıl iş başlıyor. Hemen şu soruyu sorun: Hangi DNS sunucusunu sorguluyor? Çünkü nslookup varsayılan olarak makinenin tanımlı DNS sunucusunu kullanır ve o sunucu sorunluysa hiçbir şey çalışmaz.

Farklı bir DNS sunucusuna doğrudan sorgu atmak için:

nslookup sunucu01.sirket.local 192.168.1.10

Bu komutla client’ın DNS ayarından bağımsız olarak doğrudan bir sunucuyu test ediyorsunuz. Örneğin bu sorgu çalışıyor ama ilk sorgu çalışmıyorsa, client’ın DNS adresi yanlış yapılandırılmış demektir.

İnteraktif Mod: Gerçek Güç Burada

nslookup’ın interaktif modunu pek kullanan olmaz, ama sahadaki en kullanışlı özelliklerden biri budur:

nslookup
> server 192.168.1.10
> set type=SOA
> sirket.local
> set type=NS
> sirket.local
> set type=A
> dc01.sirket.local
> exit

Interaktif modda oturumu açık tutarak farklı sunuculara, farklı record tiplerini sorgulayabilirsiniz. Büyük ortamlarda birden fazla DNS sunucusunu kıyaslarken bu çok işe yarıyor.

SOA Kaydını Kontrol Etmek

Zone’un SOA (Start of Authority) kaydı size çok şey söyler. Özellikle serial number kritik:

nslookup -type=SOA sirket.local 192.168.1.10
nslookup -type=SOA sirket.local 192.168.1.11

İki DNS sunucusunun SOA serial numaraları farklıysa, AD replikasyonu veya zone transfer sorununa işaret ediyor olabilir. Bu önemli bir ipucu.

PTR Kayıtları: Tersine DNS

Pek çok uygulama ve güvenlik sistemi reverse DNS çözümlemesi yapar. PTR kayıtları eksik veya yanlışsa garip sorunlarla karşılaşırsınız, çoğu zaman da bunu DNS ile ilişkilendiremezsiniz:

nslookup -type=PTR 192.168.1.10

Ya da doğrudan:

nslookup 192.168.1.10

Sonuç “can’t find 10.1.168.192.in-addr.arpa: Non-existent domain” ise reverse lookup zone eksik veya bu IP için PTR kaydı girilmemiş demektir.

SRV Kayıtları: Active Directory’nin Can Damarı

Active Directory’nin çalışması için DNS’te SRV kayıtlarının doğru olması şart. Domain Controller’ı bulamayan client’lar, logon yapamayan kullanıcılar, Group Policy’nin uygulanmaması… Hepsinin arkasında çoğu zaman eksik SRV kayıtları var:

nslookup -type=SRV _ldap._tcp.sirket.local
nslookup -type=SRV _kerberos._tcp.sirket.local
nslookup -type=SRV _ldap._tcp.dc._msdcs.sirket.local

Bu sorgulardan boş veya hatalı sonuç geliyorsa, DC’nin DNS’e SRV kayıtlarını kaydedemediği anlamına geliyor. net logon servisini restart etmek ilk adım olabilir. Ama sorun devam ediyorsa daha derine inmek gerekiyor.

Conditional Forwarder Test Etmek

Diyelim ki şirketinizde partner.com domain’i için conditional forwarder yapılandırdınız. Çalışıp çalışmadığını test etmek için:

nslookup www.partner.com 192.168.1.10

Eğer internal DNS sunucunuz bu sorguya cevap veremiyorsa, forwarder konfigürasyonuna bakın. DNS Manager’da Conditional Forwarders bölümünden ya da PowerShell ile:

Get-DnsServerForwarder
Get-DnsServerZone | Where-Object {$_.ZoneType -eq "Forwarder"}

dcdiag: AD ve DNS’in Röntgeni

dcdiag, Active Directory ortamlarında DNS sorunlarını teşhis etmek için olmazsa olmaz bir araç. Tek başına veya belirli testler için kullanılabilir.

DNS Testlerini Çalıştırmak

Sadece DNS testlerini koşmak için:

dcdiag /test:dns /v

/v bayrağı verbose çıktı verir. Uzun bir çıktı alırsınız ama her satır değerlidir. Başarısız testler “FAIL” veya “WARNING” ile işaretlenir.

Belirli bir DC üzerinde test yapmak için:

dcdiag /test:dns /s:DC01 /v

Tüm DC’lerde DNS testini çalıştırmak için:

dcdiag /test:dns /e /v

/e bayrağı forest’taki tüm DC’leri test eder. Birden fazla site varsa ve inter-site replikasyon sorunları yaşıyorsanız bu komut çok değerli.

dcdiag DNS Çıktısını Okumak

dcdiag’ın DNS test çıktısı ilk bakışta korkutucu görünüyor. Ama sistematik bakarsanız anlaşılır. Temel test kategorileri şunlardır:

  • Authentication: DNS sunucusuna authenticate olabiliniyor mu?
  • Basic: Temel bağlantı ve yanıt testleri
  • Records Registration: SRV kayıtları doğru kaydedilmiş mi?
  • Forwarders/Root Hints: Forwarder veya root hint’ler çalışıyor mu?
  • Delegations: Zone delegation’ları doğru mu?
  • Dynamic Update: Dinamik DNS güncelleme çalışıyor mu?

Başarısız bir test gördüğünüzde paniklemeden önce şu soruyu sorun: “Bu test gerçekten benim ortamım için geçerli mi?” Bazı testler sizin spesifik konfigürasyonunuzda anlamlı olmayabilir.

Replikasyon Testleri

DNS sorunları çoğu zaman AD replikasyon sorunlarının bir yansımasıdır. AD entegre zone kullanıyorsanız, zone verisi AD üzerinden replike edilir. Replikasyon bozulursa zone verileri tutarsız hale gelir:

dcdiag /test:replications /v

Bu test DC’ler arası replikasyon durumunu gösterir. “FAIL” görürseniz, DNS sorunlarınızın kökeninin burada olma ihtimali yüksek.

Replikasyon durumunu daha detaylı görmek için repadmin aracını da ekleyin:

repadmin /replsummary
repadmin /showrepl

Netlogon Servis Testi

SRV kayıtları eksikse, netlogon servisinin durumunu kontrol etmek kritik:

dcdiag /test:netlogons /v

Netlogon servisi, DC’nin DNS’e SRV kayıtlarını kaydetmesinden sorumludur. Servis çalışıyor görünse bile DNS kaydı yapamıyor olabilir. Servisi restart edip ardından SRV kayıtlarını kontrol edin:

net stop netlogon
net start netlogon

Restart sonrası birkaç dakika bekleyin ve SRV sorgularını tekrar deneyin.

Gerçek Dünya Senaryoları

Senaryo 1: “VPN’den domain’e bağlanamıyorum”

Klasik bir uzak çalışma sorunu. Kullanıcı VPN’e bağlanıyor, domain resource’larına erişemiyor. İlk adım:

nslookup sirket.local

Eğer VPN’li makinede bu sorgu başarısız oluyorsa, split DNS yapılandırması eksik ya da VPN client DNS push çalışmıyor demektir. Makineye hangi DNS sunucusu atandığını kontrol edin:

ipconfig /all

DNS sunucusu VPN adresi üzerinden internal DNS’e işaret ediyor mu? Etmiyorsa, VPN konfigürasyonunuzda DNS push ayarlarına bakın.

Senaryo 2: “Bazı sunucular resolve oluyor, bazıları olmuyor”

Bu senaryo özellikle sinir bozucu. Ortamınızda birden fazla DNS sunucusu varsa ve bunlar farklı veriye sahipse bu olur. Test:

nslookup sorunlu-sunucu.sirket.local 192.168.1.10
nslookup sorunlu-sunucu.sirket.local 192.168.1.11

İki DNS sunucusundan farklı sonuçlar alıyorsanız, zone verisi tutarsız. AD entegre zone kullanıyorsanız replikasyona bakın. Standard primary/secondary zone kullanıyorsanız zone transfer loglarını kontrol edin.

Senaryo 3: “Logon yavaş, group policy uygulanmıyor”

Bu sorunun DNS ile bağlantısı hemen görülmez. Ama %70 ihtimalle SRV kayıtlarında sorun var:

dcdiag /test:dns /v > dns_rapor.txt
notepad dns_rapor.txt

Raporda “Records Registration” testine bakın. Eğer DC’nin SRV kayıtları DNS’te düzgün görünmüyorsa, client’lar DC’yi bulamaz ve logon yavaşlar.

Senaryo 4: Scavenging Kurbanı

DNS scavenging yanlış yapılandırıldığında geçerli kayıtları siler. Sabah geldiniz, bazı sunucular resolve olmuyorsa ve bu sunuculara kimse dokunmadıysa şüphelenin:

nslookup silinen-sunucu.sirket.local

“Non-existent domain” dönüyorsa ama sunucu ayaktaysa, scavenging kurbanı olmuş olabilir. DNS Manager’dan zone properties’e gidin, scavenging ayarlarını kontrol edin. Kaydı manuel ekleyebilirsiniz ama kalıcı çözüm için scavenging interval’lerini gözden geçirin. No-Refresh ve Refresh interval değerleri çok agresif ayarlanmış olabilir.

DNS Cache Sorunları

Sunucu tarafında DNS cache bazen eski veya yanlış verileri tutabilir. Özellikle IP değişikliklerinden sonra:

ipconfig /flushdns

Bu komutu istemcide çalıştırın. DNS sunucusunun cache’ini temizlemek için:

dnscmd /clearcache

Ya da DNS Manager’dan: DNS sunucusuna sağ tıklayın, “Clear Cache” seçeneğini kullanın.

PowerShell ile de yapabilirsiniz:

Clear-DnsServerCache -Force

Cache temizleme sonrası tekrar test edin. Sorun devam ediyorsa kaynak veri sorunlu demektir.

DNS Günlükleri: Gözden Kaçan Hazine

Debug logging açıkken DNS sunucusu son derece detaylı log tutar. Üretimde performans etkisi yaratır ama sorun giderme sırasında çok değerli:

DNS Manager’da sunucuya sağ tıklayın, Properties, Debug Logging sekmesinden etkinleştirin. Ya da:

dnscmd /config /loglevel 0x8100F331
dnscmd /config /logfilepath "C:DNSdns.log"

Log seviyesini ve dosya yolunu ihtiyacınıza göre ayarlayın. Sorunu tespit ettikten sonra debug logging’i kapatmayı unutmayın:

dnscmd /config /loglevel 0

Windows Event Log’ları da ihmal etmeyin. DNS sunucu olayları “DNS Server” kaynağı altında System log’a, bazıları Applications and Services Logs > Microsoft > Windows > DNS-Server > Audit altına düşer.

Pratik Bir Kontrol Listesi

Bir DNS sorunu aldığınızda şu sırayı takip etmek işinizi kolaylaştırır:

  • 1. Adım: ipconfig /all ile client’ın DNS sunucu adresini doğrulayın
  • 2. Adım: nslookup ile sorunlu adı doğrudan DNS sunucusuna sorgulayın
  • 3. Adım: Farklı DNS sunucularında aynı sorguyu tekrarlayın
  • 4. Adım: SRV kayıtlarını kontrol edin
  • 5. Adım: dcdiag /test:dns /v ile kapsamlı analiz yapın
  • 6. Adım: Replikasyon durumunu dcdiag /test:replications ile kontrol edin
  • 7. Adım: DNS cache’i temizleyin ve tekrar test edin
  • 8. Adım: DNS debug log’ları etkinleştirip canlı trafik analizi yapın

PowerShell ile Modern Yaklaşım

Windows Server 2012 ve sonrasında DNS yönetimi için güçlü PowerShell cmdlet’leri mevcut:

# Zone listesi
Get-DnsServerZone

# Belirli bir kayıt sorgula
Get-DnsServerResourceRecord -ZoneName "sirket.local" -Name "sunucu01"

# Tüm A kayıtlarını listele
Get-DnsServerResourceRecord -ZoneName "sirket.local" -RRType "A"

# DNS sunucu durumu
Get-DnsServer

# Forwarder listesi
Get-DnsServerForwarder

Bu cmdlet’ler özellikle raporlama ve bulk işlemler için nslookup’tan çok daha kullanışlı. Birden fazla DNS sunucusunu kıyaslamak veya tüm zone’daki kayıtları export etmek istediğinizde PowerShell’e geçin.

Sonuç

DNS sorunları, sistem yöneticiliğinin en stresli anlarından birini oluşturur çünkü etkisi çok geniş yayılır ve kök neden hemen görünmez. Ama nslookup ve dcdiag doğru kullanıldığında, bu sorunların büyük çoğunluğu 15-30 dakika içinde teşhis edilebilir hale gelir.

Önemli olan paniklemeden sistematik gitmek. Hangi katmanda sorun var? Client mı, sunucu mu, veri mi, replikasyon mu? Bu soruları sırayla cevaplandırırken yukarıdaki araçları ve komutları kullanın.

Son olarak: Sorun çözüldükten sonra ne olduğunu mutlaka kayıt altına alın. DNS ortamları değişkendir, aynı sorun altı ay sonra tekrar çıkabilir. O an hazırlıklı olmak için bugün 5 dakika harcamak değer.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir