Windows DNS Performans Optimizasyonu ve Cache Yönetimi
Prodüksiyon ortamında Windows DNS sunucusu yönetiyorsanız, performans sorunlarıyla er ya da geç yüzleşmek zorunda kalırsınız. Sabah erken saatlerde kullanıcılardan gelen “internet yok” şikayetleri, aslında çoğu zaman DNS kaynaklıdır. Ben de yıllar içinde bu tür sorunlarla defalarca boğuştuğumdan, bu yazıda öğrendiklerimi ve uyguladığım optimizasyon tekniklerini paylaşacağım.
Windows DNS’in Çalışma Mantığını Anlamak
Optimizasyon yapmadan önce neyi optimize ettiğinizi anlamanız gerekiyor. Windows DNS Server, sorguları yanıtlarken birkaç katmandan geçiriyor: önce yerel cache’e bakıyor, orada bulamazsa zone’larına, sonra forwarder’lara ya da root hints’e gidiyor. Cache yönetimi bu zincirin en kritik halkası.
Windows DNS’te cache mekanizması, DNS istemci tarafında (DNS Client Service) ve sunucu tarafında ayrı ayrı işliyor. Sunucu tarafında toplanan cache, tüm istemcilere hizmet verirken istemci tarafındaki cache sadece o makineye özgü. Bu ayrımı gözden kaçıran sysadminlerin yanlış yerde sorun aradığını çok gördüm.
DNS sunucunuzun mevcut durumunu görmek için PowerShell ile başlayalım:
# DNS sunucu istatistiklerini görüntüle
Get-DnsServerStatistics | Select-Object -ExpandProperty CacheStatistics
# Cache'deki kayıt sayısını kontrol et
Get-DnsServerCache | Measure-Object | Select-Object Count
# Detaylı cache içeriğini listele
Get-DnsServerCache | Sort-Object TimeToLive -Descending | Select-Object Name, Type, TimeToLive -First 50
Bu çıktıyı düzenli aralıklarla kaydetmeye başlarsanız, zaman içinde trafik paternlerinizi anlamak çok kolaylaşıyor.
Cache Ayarlarını Optimize Etmek
MaxCacheTTL ve MaxNegativeCacheTTL
Windows DNS Server’ın varsayılan TTL sınırları, büyük kurumsal ortamlar için her zaman uygun değil. Varsayılan olarak MaxCacheTTL 86400 saniye (1 gün), MaxNegativeCacheTTL ise 900 saniye olarak ayarlı geliyor.
Eğer iç ağda sık değişen kayıtlarınız varsa ya da dış DNS değişikliklerinin hızlı yansımasını istiyorsanız bu değerleri düşürmek gerekiyor. Öte yandan kararlı bir ortamda cache sürelerini uzatmak performansı artırıyor çünkü upstream sorgular azalıyor.
# Mevcut DNS sunucu ayarlarını görüntüle
Get-DnsServerCache
# MaxCacheTTL değerini 3 saate düşür (güncelleme sıklığı yüksek ortamlar için)
Set-DnsServerCache -MaxKBSize 10240 -MaxNegativeCacheTTL 00:05:00 -MaxTTL 03:00:00
# Negatif cache TTL'i 5 dakikaya ayarla
# (var olmayan domainler için gereksiz tekrar sorguyu önler ama esnek tutar)
Set-DnsServerCache -MaxNegativeCacheTTL 00:05:00
Burada dikkat edilmesi gereken bir nokta var: negatif cache TTL’i çok uzun tutarsanız, yeni eklediğiniz kayıtlar bu süre dolmadan görünmeyebilir. Ben genellikle iç ortamlar için 5 dakika dışarıya açık sorgular için 15 dakika kullanıyorum.
Cache Boyutunu Yönetmek
Varsayılan cache boyutu 10240 KB yani 10 MB. Orta büyüklükte bir kurumsal ağ için bu değer zamanla yetersiz kalabiliyor. Cache dolduğunda DNS sunucusu eski kayıtları atmaya başlıyor ve bu da gereksiz upstream sorgulara yol açıyor.
# Cache boyutunu 50 MB'a çıkar
Set-DnsServerCache -MaxKBSize 51200
# Cache'i temizle ve boyutu doğrula (dikkat: tüm cache silinir!)
Clear-DnsServerCache
Get-DnsServerCache | Select-Object MaxKBSize
Cache temizleme işlemini çalışma saatlerinde yapmaktan kaçının. Ben bunu her zaman gece maintenance window’unda veya en azından kullanıcı yükünün düşük olduğu saatte yapıyorum.
Forwarder Optimizasyonu
DNS performansının ikinci büyük bileşeni forwarder yapılandırması. Yanlış ayarlanmış forwarder’lar, her sorguyu timeout’a kadar bekletip sonraki sunucuya geçebiliyor. Bu da kullanıcı deneyimini ciddi şekilde etkiliyor.
# Mevcut forwarder'ları listele
Get-DnsServerForwarder
# Forwarder'ları optimize edilmiş timeout ile yapılandır
# Timeout değerini 3 saniyeye düşür (varsayılan 5 saniye)
Set-DnsServerForwarder -IPAddress "8.8.8.8","8.8.4.4","1.1.1.1" -Timeout 3
# Forwarder başarısız olursa root hints'e fallback etmesini kapat
# (kontrollü ortamlarda daha öngörülebilir davranış için)
Set-DnsServerForwarder -UseRootHint $false
Forwarder sıralaması önemli. DNS sunucusu listedeki sunucuları sırayla değil, geçmiş yanıt sürelerine göre dinamik olarak seçiyor. Ancak ilk sıradaki sunucu ilk denemede tercih ediliyor. Bu yüzden en güvenilir ve hızlı sunucuyu başa almanız mantıklı.
Kurumsal ağlarda kendi recursive resolver’ınızı çalıştırıyorsanız (örneğin Unbound veya iç bir forwarder), dış DNS servislerine olan bağımlılığı azaltmış olursunuz.
Zone Transfer ve SOA Ayarları
İç zone’larınız için SOA (Start of Authority) kayıtlarındaki refresh ve retry değerleri de performansı etkiliyor. Özellikle secondary DNS sunucularınız varsa, gereksiz zone transfer trafiği ağ yükünü artırıyor.
# Zone'un SOA kaydını görüntüle
Get-DnsServerResourceRecord -ZoneName "sirket.local" -RRType SOA
# SOA değerlerini optimize et
$zone = "sirket.local"
$soaRecord = Get-DnsServerResourceRecord -ZoneName $zone -RRType SOA
$newSOA = $soaRecord.Clone()
$newSOA.RecordData.RefreshInterval = [TimeSpan]::FromHours(1)
$newSOA.RecordData.RetryDelay = [TimeSpan]::FromMinutes(15)
$newSOA.RecordData.ExpireLimit = [TimeSpan]::FromDays(1)
$newSOA.RecordData.MinimumTimeToLive = [TimeSpan]::FromMinutes(5)
Set-DnsServerResourceRecord -ZoneName $zone -OldInputObject $soaRecord -NewInputObject $newSOA
Refresh interval’ı 1 saat, retry’ı 15 dakika yapmanız genellikle iyi bir denge sağlıyor. Çok sık transfer yaptırırsanız secondary sunucu CPU ve ağ kullanımı artıyor; çok seyrek yaparsanız zone tutarsızlıkları uzun süre fark edilmiyor.
DNS Debug Logging ile Sorun Tespiti
Performans sorunlarını çözmek için önce neyin yavaş olduğunu bulmanız lazım. Windows DNS’in debug logging özelliği bunu sağlıyor, ama varsayılanda kapalı ve doğru açılmazsa disk’i doldurabilir.
# DNS debug logging'i etkinleştir (sadece sorgulama ve yanıtları logla)
Set-DnsServerDiagnostics -Queries $true -Answers $true -SendPackets $false `
-ReceivePackets $false -NaAdditional $false -NaQuestion $false `
-LogFilePath "C:DNS_Logsdns_debug.log" -MaxMBFileSize 100
# Log dosyasının nereye yazıldığını doğrula
Get-DnsServerDiagnostics | Select-Object LogFilePath, MaxMBFileSize
# Belirli bir süre sonra logging'i kapat
Set-DnsServerDiagnostics -All $false
Bu logları açık bırakmayın. Yoğun bir ortamda log dosyası dakikalar içinde şişebilir. Ben genellikle sorun anında 10-15 dakika açık tutup kapatıyorum, sonra logları analiz ediyorum.
Log analizi için basit bir PowerShell script’i:
# DNS log dosyasından yavaş sorguları filtrele
# (Timeout içeren satırları bul)
Select-String -Path "C:DNS_Logsdns_debug.log" -Pattern "TIMEOUT|timeout" |
Select-Object LineNumber, Line |
Export-Csv "C:DNS_Logstimeout_queries.csv" -NoTypeInformation
# En çok sorgulanan domainleri bul
$logContent = Get-Content "C:DNS_Logsdns_debug.log"
$queries = $logContent | Where-Object { $_ -match "QUERY" } |
ForEach-Object { ($_ -split "s+")[8] }
$queries | Group-Object | Sort-Object Count -Descending | Select-Object -First 20
DNS İstemci Tarafı Optimizasyonu
Sunucu tarafını optimize etseniz bile istemci DNS ayarları da performansı etkiliyor. Windows DNS Client Service’in cache’i ve ayarları gözden kaçan bir alan.
# İstemcideki DNS cache içeriğini görüntüle
ipconfig /displaydns
# İstemci DNS cache'ini temizle
Clear-DnsClientCache
# DNS istemci ayarlarını PowerShell ile görüntüle
Get-DnsClientCache
# Belirli bir ağ adaptörünün DNS ayarlarını kontrol et
Get-DnsClientServerAddress -InterfaceAlias "Ethernet"
# DNS istemci cache boyutunu registry üzerinden artır
# (Varsayılan 1000 kayıt)
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesDnscacheParameters" `
-Name "CacheHashTableBucketSize" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesDnscacheParameters" `
-Name "CacheHashTableSize" -Value 384 -Type DWord
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesDnscacheParameters" `
-Name "MaxCacheEntryTtlLimit" -Value 86400 -Type DWord
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesDnscacheParameters" `
-Name "MaxSOACacheEntryTtlLimit" -Value 120 -Type DWord
# DNS Client servisini yeniden başlat
Restart-Service Dnscache
Bu registry değerlerini değiştirirken dikkatli olun. Her değişiklikten önce mevcut değerleri not edin ve test ortamında deneyin.
Conditional Forwarder ve Split-Brain DNS
Büyük ortamlarda sık karşılaşılan bir senaryo: hem iç hem dış kaynaklara hızlı çözümleme yapılması gereken durumlar. Conditional forwarder yapılandırması burada kritik.
# Conditional forwarder ekle (örneğin partner şirket domainleri için)
Add-DnsServerConditionalForwarderZone -Name "partner.com" `
-MasterServers "192.168.100.10","192.168.100.11" `
-ReplicationScope "Forest"
# Mevcut conditional forwarder'ları listele
Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Forwarder" } |
Select-Object ZoneName, MasterServers
# Conditional forwarder timeout ayarını güncelle
Set-DnsServerConditionalForwarderZone -Name "partner.com" `
-MasterServers "192.168.100.10","192.168.100.11"
Split-brain DNS kullanıyorsanız yani aynı domain adı için iç ve dış kayıtlarınız farklıysa, zone yapılandırmasının tutarlı olması gerekiyor. Aksi halde VPN üzerinden bağlanan kullanıcılar ya da DMZ’deki sunucular yanlış IP’leri resolve edebilir.
Performans İzleme ve Alerting
Tek seferlik optimizasyon yetmez. Sürekli izleme olmadan hangi değişikliğin ne etki yaptığını bilemezsiniz.
# DNS Performance counter'larını izle
# Önemli counter'lar:
# - DNSTotal Query Received/sec
# - DNSTotal Response Sent/sec
# - DNSRecursive Queries/sec
# - DNSRecursive Query Failure/sec
# - DNSCache Hits %
# Performance counter'ları PowerShell ile çek
$counters = @(
"DNSTotal Query Received/sec",
"DNSRecursive Queries/sec",
"DNSCache Hits %",
"DNSUDP Query Received/sec",
"DNSTCP Query Received/sec"
)
Get-Counter -Counter $counters -SampleInterval 5 -MaxSamples 12 |
Export-Counter -Path "C:DNS_Logsdns_perf_$(Get-Date -Format 'yyyyMMdd_HHmm').blg" -FileFormat BLG
# Anlık snapshot al
Get-Counter -Counter "DNSCache Hits %" |
Select-Object -ExpandProperty CounterSamples |
Select-Object Path, CookedValue
Cache Hit oranı en önemli metrik. %85’in altına düşmeye başladıysa ya cache boyutunuz yetersiz, ya TTL değerleriniz çok düşük ya da olağandışı bir sorgu dalgası var demektir.
Kritik bir prodüksiyon ortamında bu counter’ları Windows Performance Monitor üzerinden kaydetmenizi ve grafana/zabbix gibi araçlarla görselleştirmenizi öneririm. Bir eşik değeri aşıldığında mail ile uyarı almak da hayat kurtarıcı oluyor.
DNSSEC ve Performans Dengesi
DNSSEC etkinleştirilmiş zone’larda sorgu boyutu ve işlem süresi artıyor. DNSSEC validation yükünü azaltmak için birkaç yöntem var:
# DNSSEC validasyonu için trust anchor durumunu kontrol et
Get-DnsServerTrustAnchor -Name "."
# DNSSEC ayarlarını görüntüle
Get-DnsServerDnsSecZoneSetting -ZoneName "sirket.local"
# Validation başarısız olan domainler için bypass (dikkatli kullanın)
Add-DnsServerQueryResolutionPolicy -Name "BypassDNSSEC_Internal" `
-Action PASS -Fqdn "EQ,*.internal.sirket.local" `
-ProcessingOrder 1
DNSSEC’i tamamen devre dışı bırakmak güvenlik açısından riskli. Ancak iç zone’larda DNSSEC zorunlu değilse, sadece dış çözümlemede aktif tutmak hem güvenliği korur hem de gereksiz işlem yükünü azaltır.
Sonuç
Windows DNS performans optimizasyonu tek seferlik bir iş değil, sürekli takip ve ayarlama gerektiren bir süreç. Yukarıda anlattıklarımı özetlemek gerekirse:
- Cache TTL ayarları ortamınıza özel olmalı, kopyala-yapıştır değil
- Forwarder timeout değerleri varsayılan 5 saniye yerine 3 saniye daha gerçekçi bir değer
- Cache boyutu aktif kullanıcı sayısına ve domain çeşitliliğine göre hesaplanmalı
- Debug logging sorun anında açılıp kapatılmalı, sürekli açık bırakılmamalı
- Performance counter izleme özellikle Cache Hit oranı, rutin bakımın parçası olmalı
- SOA değerleri secondary sunucularınız varsa mutlaka gözden geçirilmeli
- İstemci tarafı cache sunucu kadar olmasa da etkili, özellikle terminal server ortamlarında
En büyük hatalardan biri optimizasyon değişikliklerini kayıt altına almamak. Bir ayar yaptığınızda ne zaman yaptığınızı, neden yaptığınızı ve sonucunda ne değiştiğini not edin. Birkaç ay sonra “bu neden böyle yapılmıştı” diye kendi kendinize ya da ekibinize sorduğunuz anlar mutlaka gelecek.
DNS küçük ve önemsiz görünebilir ama ağ altyapısının sessiz kahramanı. Düzgün yapılandırıldığında kimse fark etmez, kötü yapılandırıldığında herkes şikayet eder.
