DNS Çözümleme Sorunları: Windows Server Rehberi

Tarafındankomut
0 Comments

Sabah 8’de ofise geliyorsunuz, kullanıcılar çıldırmış durumda: “İnternet yok!”, “Paylaşım klasörlerine bağlanamıyorum!”, “Uygulama sunucusuna erişemiyorum!” Bunların büyük çoğunluğunun arkasında tek bir şey yatıyor: DNS. Windows Server ortamlarında DNS çözümleme sorunları, sysadmin’lerin en sık karşılaştığı ve bazen saatler alan sorunların başında geliyor. Bu rehberde sistematik bir yaklaşımla bu sorunları nasıl teşhis edip çözeceğinizi anlatacağım.

DNS Neden Bu Kadar Kritik?

Active Directory ortamında DNS sadece “isim çözümleme” değil, tüm altyapının omurgası. Domain Controller’lar birbirini DNS üzerinden buluyor, Kerberos kimlik doğrulaması DNS’e bağımlı, Group Policy uygulanması DNS olmadan çalışmıyor. Bir DNS sorunu domino etkisiyle onlarca farklı semptomu tetikliyor ve siz de sabahları “neden bu kadar çok şey bozuk?” sorusunu soruyorsunuz.

Temel kuralı şöyle özetleyebilirim: Bir Windows sorununda önce DNS’i şüpheli olarak kabul et, sonra aksi ispat et.

Temel Teşhis Araçları

Önce araç kutunuzu hazırlayalım. Windows Server’da DNS sorunlarını araştırmak için birkaç temel komut var.

nslookup ile Hızlı Kontrol

nslookup eski ama altın değerinde bir araç. En basit kullanımıyla:

nslookup sunucu01.sirket.local
nslookup sirket.local
nslookup -type=SRV _ldap._tcp.sirket.local

Bir DC’nin DNS kayıtlarını kontrol etmek için SRV sorgusu yapmanız çok önemli. Active Directory SRV kayıtlarına dayanıyor ve bu kayıtlar eksikse ya da yanlışsa domain işlevleri çöküyor.

Belirli bir DNS sunucusuna sorgu yapmak için:

nslookup sirket.local 192.168.1.10
nslookup sirket.local 8.8.8.8

İkinci komut ilginç bir tanı sağlıyor: Eğer internal DNS’te çözülemeyen bir kayıt Google DNS’te çözülüyorsa, sorun internal zone’unuzda demektir.

Resolve-DnsName ile Modern Yaklaşım

PowerShell’in Resolve-DnsName cmdlet’i nslookup‘tan çok daha fazla bilgi veriyor:

Resolve-DnsName -Name sirket.local -Type A
Resolve-DnsName -Name sirket.local -Type SOA
Resolve-DnsName -Name _kerberos._tcp.sirket.local -Type SRV
Resolve-DnsName -Name sirket.local -Server 192.168.1.10 -Type NS

Bu komutların çıktısı structred data olduğundan pipeline’a sokup işleyebilirsiniz. Birden fazla DNS sunucusunu test ederken bu çok işe yarıyor.

ipconfig ile DNS Cache Durumu

İstemci tarafında sorun araştırırken DNS cache’in durumunu görmek önemli:

ipconfig /displaydns
ipconfig /flushdns
ipconfig /registerdns

/displaydns komutu cache’deki tüm kayıtları gösteriyor. Eski veya yanlış bir kayıt cache’de takılı kalmışsa /flushdns ile temizleyebilirsiniz. /registerdns ise makinenin kendi A kaydını DNS sunucusuna yeniden kaydetmesini zorluyor.

Gerçek Dünya Senaryosu 1: “İnternet Var Ama Sunuculara Giremiyorum”

Bu klasik bir senaryo. Kullanıcı chrome’da google.com açabiliyor ama \fileserverpaylaşım erişemiyor. İlk düşünce network sorunu ama aslında DNS’in bölünmüş çalışması söz konusu.

Önce DNS sunucu yapılandırmasını kontrol edin:

Get-DnsClientServerAddress -InterfaceAlias "Ethernet" | Format-List

Eğer istemci sadece public DNS (8.8.8.8 gibi) kullanıyorsa internal kayıtları çözemez. Kurumsal ortamda istemciler mutlaka internal DNS sunucularını primary olarak kullanmalı.

DHCP üzerinden dağıtılan DNS ayarlarını kontrol etmek için:

Get-DhcpServerv4OptionValue -ScopeId 192.168.1.0 | Where-Object {$_.OptionId -eq 6}

OptionId 6, DNS sunucusu opsiyonuna karşılık geliyor. Çıktıda internal DNS IP’lerinizin olduğundan emin olun.

DNS Sunucu Sağlık Kontrolü

Sorun istemcide değil sunucu tarafında olabilir. DNS Server servisinin durumunu kontrol edin:

Get-Service -Name DNS | Select-Object Status, StartType
Get-EventLog -LogName System -Source "Microsoft-Windows-DNS-Server-Service" -Newest 50

DNS Server event log’larına bakmak altın değerinde. Event ID’lerinden bazıları:

  • 4013: DNS sunucusu Active Directory’yi bekliyor, AD entegrasyonlu zone yüklenemedi
  • 4015: DNS sunucusu Active Directory’den zone verisini yükleyemedi
  • 4000: DNS Server servisi başlatılamadı

Daha detaylı DNS debug logging açmak için:

Set-DnsServerDiagnostics -All $true

Bu komut DNS sunucusunda detaylı loglama açıyor. Log dosyası varsayılan olarak C:WindowsSystem32dnsdns.log konumunda oluşuyor. Dikkat: Bu log çok hızlı büyüyor, sorun çözüldükten sonra kapatmayı unutmayın:

Set-DnsServerDiagnostics -All $false

Zone Sorunlarını Teşhis Etme

DNS zone’larında sorun olup olmadığını PowerShell ile sistematik şekilde kontrol edebilirsiniz:

Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated, IsReverseLookupZone, ZoneFile

Bu komut tüm zone’ların listesini ve tiplerini veriyor. Dikkat etmeniz gerekenler:

  • ZoneType: Primary, Secondary veya Stub olabilir
  • IsDsIntegrated: Active Directory entegreli mi?
  • IsReverseLookupZone: Reverse lookup zone’u mu?

Zone transferi sorunlarını test etmek için:

Test-DnsServer -IPAddress 192.168.1.10 -ZoneName sirket.local -Context ZoneMaster

Gerçek Dünya Senaryosu 2: DC’ler Birbirini Bulamıyor

Multi-site ortamda veya birden fazla DC olan bir yapıda DC’lerin birbirini DNS üzerinden bulamaması replikasyonu durdurur. Bu genellikle şu semptomlarla ortaya çıkar: repadmin hataları, event 1925 veya 2088.

Önce DC’lerin DNS kayıtlarını kontrol edin:

dcdiag /test:DNS /v /e /c

Bu komut tüm domain controller’ları test eder ve DNS ile ilgili kapsamlı bir rapor üretir. Çıktısı uzun ama her satır değerli.

Daha spesifik olarak SRV kayıtlarını kontrol etmek için:

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

Bu kayıtlar eksikse domain işlevi ciddi şekilde bozulur. Eksik SRV kayıtlarını yeniden oluşturmak için DC’de şu komutu çalıştırın:

net stop netlogon
net start netlogon

Netlogon servisi başlarken bu SRV kayıtlarını DNS’e yeniden kaydeder. Basit ama etkili bir çözüm.

Reverse Lookup Zone Sorunları

Birçok uygulama, özellikle SQL Server ve bazı üretici yazılımlar, çalışmak için başarılı reverse DNS lookup (PTR kaydı) istiyor. Reverse lookup zone olmadığında veya PTR kayıtları eksik olduğunda garip hatalar alırsınız.

Reverse lookup zone’ların durumunu kontrol edin:

Get-DnsServerZone | Where-Object {$_.IsReverseLookupZone -eq $true}

Belirli bir IP için PTR sorgusunu test edin:

Resolve-DnsName -Name "10.1.168.192.in-addr.arpa" -Type PTR
# Ya da daha kolay:
nslookup 192.168.1.10

Eksik PTR kayıtlarını toplu olarak eklemek için PowerShell kullanabilirsiniz:

$zone = "1.168.192.in-addr.arpa"
Add-DnsServerResourceRecordPtr -ZoneName $zone -Name "10" -PtrDomainName "sunucu01.sirket.local."

Gerçek Dünya Senaryosu 3: Yavaş DNS Çözümlemesi

Kullanıcılar “her şey yavaş” diyorsa ve siz de network’ün gayet iyi olduğunu biliyorsanız, DNS yanıt sürelerini ölçmeniz gerekiyor.

Measure-Command { Resolve-DnsName -Name sunucu01.sirket.local }

Normal bir internal DNS sorgusu 10ms’in altında yanıt vermeli. 100ms üzeri ciddi bir sorunu işaret ediyor.

Forwarder yapılandırmasını kontrol edin:

Get-DnsServerForwarder

Internal DNS sunucunuz bilinmeyen sorgular için forwarder’a yönlendiriyor. Eğer forwarder olarak eski veya erişilemeyen bir IP yazılıysa, DNS sunucusu her external sorgu için bu IP’yi deneyecek ve timeout bekleyecek. Bu tüm DNS çözümlemesini yavaşlatır.

Forwarder güncellemek için:

Set-DnsServerForwarder -IPAddress 8.8.8.8, 8.8.4.4
# Ya da internal resolverınız:
Set-DnsServerForwarder -IPAddress 192.168.1.1

DNS sunucunuzda conditional forwarder olup olmadığını da kontrol edin:

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

DNS Cache Sorunları ve Negatif Caching

DNS sunucusunun cache’indeki eski veya hatalı kayıtlar da sorun yaratıyor. Sunucu tarafında cache’i temizlemek için:

Clear-DnsServerCache -Force

Ya da GUI üzerinden DNS Manager’da sunucu adına sağ tıklayıp “Clear Cache” diyebilirsiniz.

Negatif caching konusuna dikkat: Bir kayıt bulunamadığında DNS bu “bulunamadı” cevabını da cache’liyor. Yeni bir A kaydı eklediğinizde bazı istemciler eski negatif cache yanıtı nedeniyle hala çözemiyor olabilir. Hem sunucu hem istemci tarafında cache temizliği yapmanız gerekiyor.

TTL değerlerini kontrol etmek de önemli:

Get-DnsServerResourceRecord -ZoneName "sirket.local" -Name "sunucu01" -RRType A | Select-Object -ExpandProperty TimeToLive

Çok düşük TTL (60 saniye gibi) yüksek DNS trafiği yaratır. Çok yüksek TTL (86400 saniye = 1 gün) ise değişikliklerin yayılmasını geciktirir. Internal ortamlar için 300-900 saniye makul bir değer.

Scavenging ve Stale Kayıt Sorunları

Uzun süredir çalışan ortamlarda DNS veritabanı eski, kullanılmayan kayıtlarla dolup taşıyor. Bu “stale record” problemi aynı hostname’e birden fazla IP adresi veya geçersiz IP’lere işaret eden kayıtlar nedeniyle çözümleme hatalarına yol açıyor.

DNS Scavenging ayarlarını kontrol edin:

Get-DnsServerScavenging
Get-DnsServerZone -Name "sirket.local" | Select-Object ZoneName, IsScavengeEnabled, ScavengeServers

Scavenging aktif değilse etkinleştirmek için:

Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00
Set-DnsServerZoneAging -ZoneName "sirket.local" -Aging $true -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00

Dikkat: Scavenging’i açmadan önce NoRefresh ve Refresh interval’larının mantıklı değerlere ayarlandığından emin olun. Yanlış yapılandırma aktif kayıtları silebilir.

DNS Replication Sorunları

Active Directory entegreli DNS zone’ları AD replikasyonu üzerinden replika alıyor. AD replikasyonu sorunluysa DNS de sorunlu olur.

repadmin /showrepl
repadmin /replsummary

DNS application partition’larının replikasyon durumunu kontrol etmek için:

repadmin /showrepl * /csv | ConvertFrom-Csv | Where-Object {$_."Number of Failures" -gt 0}

DNS zone’larının hangi partition’da tutulduğunu kontrol edin:

Get-DnsServerZone -Name "sirket.local" | Select-Object ZoneName, ReplicationScope

ReplicationScope değerleri:

  • Forest: Tüm ormandaki DNS sunucularına replika
  • Domain: Sadece domain içindeki DNS sunucularına replika
  • Legacy: Eski DC’lere replikasyon
  • Custom: Özel application partition

Çoğu durumda Forest veya Domain scope kullanıyorsunuz. Eğer yeni bir DC DNS kayıtlarını görmüyorsa zone’un replication scope’unu kontrol edin.

netsh ile Gelişmiş DNS Teşhis

Eski ama güvenilir netsh aracı bazı senaryolarda hala çok işe yarıyor:

netsh interface ip show dns
netsh interface ip show config
netsh dns show state

DNS istemci servisini sıfırlamak bazen basit sorunları çözüyor:

net stop dnscache
net start dnscache

Ya da PowerShell ile:

Restart-Service -Name dnscache -Force

Güvenlik Duvarı ve DNS Sorunları

DNS UDP 53 üzerinden çalışıyor ama büyük yanıtlar için TCP 53 de gerekli. Özellikle DNSSEC aktifse veya büyük zone transfer varsa TCP 53’ün açık olması şart.

Windows Firewall kurallarını kontrol edin:

Get-NetFirewallRule | Where-Object {$_.DisplayName -like "*DNS*"} | Select-Object DisplayName, Enabled, Direction, Action

DNS sunucusu makinelerde şu portların açık olması gerekiyor:

  • UDP 53: Standard DNS sorguları
  • TCP 53: Büyük yanıtlar ve zone transferleri
  • TCP/UDP 88: Kerberos (DC’ler için)
  • TCP 135: RPC (Active Directory replikasyonu)

Pratik Kontrol Listesi: Sorun Geldiğinde

Bir DNS sorunu geldiğinde şu adımları sırayla uygulayın:

  • Önce istemci tarafında ipconfig /all ile DNS sunucu IP’lerini kontrol edin
  • nslookup ile hem forward hem reverse lookup test edin
  • DNS sunucu servisinin çalıştığını doğrulayın
  • Event Viewer’da DNS hata loglarını kontrol edin
  • dcdiag /test:DNS ile kapsamlı AD DNS testi yapın
  • Forwarder yapılandırmasını kontrol edin
  • Zone sağlığını ve replikasyon durumunu gözden geçirin
  • Gerekirse hem istemci hem sunucu DNS cache’ini temizleyin

Hızlı sağlık kontrol scripti olarak şunu kullanabilirsiniz:

$dnsServers = @("192.168.1.10", "192.168.1.11")
$testNames = @("sirket.local", "sunucu01.sirket.local", "_ldap._tcp.sirket.local")

foreach ($server in $dnsServers) {
    Write-Host "`nDNS Sunucu: $server" -ForegroundColor Cyan
    foreach ($name in $testNames) {
        try {
            $result = Resolve-DnsName -Name $name -Server $server -ErrorAction Stop
            Write-Host "  [OK] $name" -ForegroundColor Green
        } catch {
            Write-Host "  [HATA] $name - $($_.Exception.Message)" -ForegroundColor Red
        }
    }
}

Bu scripti özelleştirip ortamınızdaki kritik hostnames ile günlük monitoring scriptinize ekleyebilirsiniz.

Sonuç

DNS sorunları sinir bozucu çünkü semptomu ile kaynağı arasındaki mesafe çok büyük olabiliyor. Kullanıcı “email açılmıyor” diyor, siz sonunda DNS’te yanlış bir PTR kaydı buluyorsunuz. Bu yüzden sistematik yaklaşım şart.

En önemli pratikal tavsiyem: DNS değişikliklerini yaparken TTL’leri anlayın ve her değişikliği belgeleyin. Hangi zone’da ne zaman ne değiştirdiniz, bu kaydı tutan servisi kaydedin. Gece 2’de “dün ne değiştirildi?” sorusu geldiğinde bu belgeler hayat kurtarıyor.

Windows Server DNS’i hem güçlü hem de karmaşık bir araç. Active Directory ile derin entegrasyonu onu vazgeçilmez yapıyor ama aynı zamanda tek bir yanlış yapılandırmanın çok büyük etki yaratmasına neden oluyor. PowerShell cmdlet’lerini ve dcdiag gibi araçları düzenli sağlık kontrollerinde kullanma alışkanlığı edinin. Sorun çıkmadan önce baseline değerlerinizi bilin ki sorun çıktığında “normal” ile “anormal” arasındaki farkı hemen görebilin.

Bir yanıt yazın

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