Active Directory DNS Yapılandırması: Forwarder, Scavenging ve Bölgeler

“Etki alanına katılamıyorum”, “GPO gelmiyor”, “oturum açma yavaş” şikâyetlerinin önemli kısmının kökü DNS’tir. İstemciler DC’leri SRV kayıtlarıyla bulur; Kerberos ve Group Policy doğru ad çözümlemeye bağlıdır. DNS yanlışsa Active Directory de yanlış çalışır. Aşağıda AD entegre DNS’in replikasyon kapsamlarını, DC’lerin DNS istemci ayarını, forwarder seçeneklerini, aging/scavenging işleyişini ve DHCP ile dinamik güncellemeyi iç DNS işletimi açısından, sahada bozulduğu noktalarla birlikte anlatıyoruz.

AD entegre bölgeler ve replikasyon kapsamı

AD entegre bölge kayıtlarını dosyada değil dizin veritabanında tutar ve AD replikasyonuyla çoğaltılır. Bu sayede çok yöneticili (multi-master) güncelleme ve yalnızca kimliği doğrulanmış bilgisayarların kayıt yazabildiği güvenli dinamik güncelleme mümkün olur. Bölgenin hangi DC’lere kopyalanacağını replikasyon kapsamı belirler:

Tek etki alanlı ormanlarda Forest ve Domain kapsamı pratikte aynı sunuculara denk gelir; fark çok etki alanlı ormanlarda ortaya çıkar. Birincil bölgede dinamik güncellemenin yalnızca güvenli modda olduğunu kontrol edin. “Nonsecure and secure” seçili bölge, ağdaki her cihazın kayıt yazabildiği bölgedir:

Get-DnsServerZone | Where-Object IsDsIntegrated |
  Select-Object ZoneName, ReplicationScope, DynamicUpdate, IsReverseLookupZone

Set-DnsServerPrimaryZone -Name "contoso.local" -DynamicUpdate Secure

Ters arama (reverse lookup) bölgelerini de AD entegre ve güvenli güncellemeli oluşturun. Ters bölge eksikse bazı uygulamalar ve günlük analiz araçları IP’den isim bulamaz; olay incelemesinde saatler kaybedilir.

DC’lerin DNS istemci ayarları

Sunucu ve sistem altyapısında en sık rastladığımız yanlış yapılandırma, DC’nin ağ kartındaki DNS istemci ayarıdır. Uygulanabilir kural:

• Birincil DNS: Aynı sitedeki başka bir DC.
• İkincil DNS: DC’nin kendisi, loopback adresi 127.0.0.1 olarak. Loopback listede olmalı, ama ilk sırada değil.
• Dış DNS adresi yok: Modem, sağlayıcı veya genel çözümleyici adresleri DC’lerin ve etki alanı üyelerinin DNS istemci ayarına yazılmaz. “Yedek olsun” diye eklenen 8.8.8.8, aralıklı ve teşhisi zor arızaların klasik kaynağıdır.

DC’nin önce kendini göstermesi, açılışta DNS hizmeti AD’nin hazır olmasını beklerken çözümleme gecikmelerine ve “island” durumuna yol açabilir: DC yalnızca kendi kopyasından beslenir, güncel kalamaz. Birden fazla ağ kartı olan DC’lerde (ör. yedekleme ağı) yalnızca istemcilere hizmet veren kart DNS’e kaydolmalı; diğer kartlarda “Register this connection’s addresses in DNS” seçeneğini kapatın. Kapatmazsanız istemciler ulaşamadıkları bir IP’ye yönlenir. Belirti rastgele görünür. Neden değildir.

Forwarder, conditional forwarder ve kök ipuçları

İç DNS sunucusu kendi bölgelerinde olmayan bir adı çözmek için ya kök ipuçlarıyla (root hints) özyinelemeli çözümleme yapar ya da sorguyu bir forwarder’a iletir. Seçimi güvenlik duvarı politikası belirler: DC’lerin internete UDP/TCP 53 ile doğrudan çıkması istenmiyorsa sorgular güvenlik duvarındaki veya ayrı bir çözümleyici katmanındaki forwarder’a gider.

Set-DnsServerForwarder -IPAddress 10.10.0.1, 10.10.0.2 -UseRootHint $false
Get-DnsServerForwarder

Add-DnsServerConditionalForwarderZone -Name "partner.local" `
  -MasterServers 172.16.5.10, 172.16.5.11 -ReplicationScope "Forest"

• Forwarder sunucu düzeyinde bir ayardır ve AD ile çoğaltılmaz. Her DC’de ayrı ayarlanır; yeni DC eklendiğinde ilk kontrol edilecek yerlerden biridir.
• Conditional forwarder belirli bir alan adını belirli sunuculara yönlendirir: iş ortağı ormanı, VPN arkasındaki bir şube, bulut özel DNS bölgesi. -ReplicationScope ile AD’de saklanırsa tüm DC’lere dağılır.
• -UseRootHint $false, forwarder’lar yanıt vermediğinde kök ipuçlarına düşülmesini engeller. Çıkış politikası katı ağlarda davranış tutarlı olur; ancak forwarder’lar çöktüğünde dış çözümleme tamamen durur. En az iki forwarder tanımlayın. Tek forwarder tek arıza noktasıdır.

İç ve dış alan adının ayrılması, split-horizon ve dışa dönük çözümleyici mimarisi ağ tarafının konusudur; bu katmanın tasarımı için kurumsal DNS mimarisi ve split-horizon yazısına bakın.

Aging ve scavenging

Dinamik kaydolan istemci ağdan ayrıldığında kaydı kendiliğinden silinmez. Zamanla aynı IP’yi gösteren birden fazla isim, yanlış makineye giden RDP bağlantıları ve tutmayan envanter ortaya çıkar. Aging/scavenging bu eski kayıtları zaman damgasına göre temizler. İşleyiş iki aralığa dayanır:

• No-refresh aralığı (varsayılan 7 gün): Kayıt yeni zaman damgası aldıktan sonra bu süre boyunca damga yenilenmez; amaç gereksiz replikasyon trafiğini önlemektir.
• Refresh aralığı (varsayılan 7 gün): Kaydın sahibi bu süre içinde kaydı yenileyebilir. İki aralığın toplamı geçince kayıt temizlenmeye uygun hale gelir.

İki aralığın toplamı DHCP kira süresinden kısa olmamalı; aksi halde hâlâ kullanılan istemcilerin kaydı silinir. Örnek hesap: 8 günlük kira süresi kullanan bir kapsamda 7+7 gün güvenlidir, 2+2 gün değildir. Uygulamada şu sırayı izleyin:

# Bölge düzeyinde aging
Set-DnsServerZoneAging -Name "contoso.local" -Aging $true `
  -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00

# Yalnızca bir DNS sunucusunda otomatik temizlik
Set-DnsServerScavenging -ComputerName DC01 -ScavengingState $true -ScavengingInterval 7.00:00:00

# Silinmeye aday kayıtları önceden görmek
Get-DnsServerResourceRecord -ZoneName "contoso.local" -RRType A |
  Where-Object { $_.Timestamp -and $_.Timestamp -lt (Get-Date).AddDays(-14) } |
  Select-Object HostName, Timestamp, @{n='IP';e={$_.RecordData.IPv4Address}}

Temizliği tek bir sunucuda etkinleştirin; hangi sunucunun kayıt sildiğini izlemek kolaylaşır. Bölge özelliklerinde temizliğe izin verilen sunucuları kısıtlamak da mümkündür (Set-DnsServerZoneAging -ScavengeServers).

DHCP ile dinamik DNS güncellemesi

Windows istemciler A kayıtlarını kendileri günceller; DHCP sunucusu varsayılan olarak PTR kaydını ve istenirse kendini kaydedemeyen cihazların kayıtlarını yazar. Burada iki ayara bakın: DHCP hangi kimlikle güncelleme yapıyor ve kira bittiğinde kayıt siliniyor mu?

Set-DhcpServerDnsCredential -ComputerName DHCP01 -Credential (Get-Credential CONTOSO\svc-dhcpdns)

Set-DhcpServerv4DnsSetting -ComputerName DHCP01 -DynamicUpdates Always `
  -DeleteDnsRROnLeaseExpiry $true -UpdateDnsRRForOlderClients $true

Adanmış kimlik bilgisi tanımlanmazsa DHCP hizmeti sunucunun bilgisayar hesabıyla kayıt yazar. DHCP bir DC üzerinde çalışıyorsa kayıtlar DC hesabının yetkisiyle oluşur; adanmış ve ayrıcalıksız bir hizmet hesabı bu riski kaldırır. Failover ile çalışan iki DHCP sunucusunda aynı kimlik bilgisini tanımlayın; aksi halde birinin oluşturduğu kaydı diğeri güncelleyemez ve istemci adı eski IP’de kalır. DHCP yedekliliğinin kendisi için Windows Server DHCP failover yapılandırması yazısına bakın.

Yanlış yapılandırma belirtileri

Belirti GPO tarafındaysa ayrıntılı teşhis için Group Policy sorun giderme yazısını kullanın.

PowerShell ile denetim

Aşağıdaki komutlar, DnsServer PowerShell modülü ve yerleşik araçlarla periyodik bakım sırasında yapılacak DNS denetiminin çekirdeğidir. Her DC’de çalıştırın ve çıktıları yan yana koyun; farklı çıkan satır, sorunun yeridir:

# DC'nin bulunabilirliği
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.contoso.local
nltest /dsgetdc:contoso.local

# Sunucu yapılandırması
Get-DnsServerForwarder
Get-DnsServerScavenging
Get-DnsServerZoneAging -Name "contoso.local"
Get-DnsServerRootHint

# Kapsamlı DNS testi
dcdiag /test:dns /v /e /f:C:\Temp\dcdiag-dns.txt

# Eksik SRV kayıtlarını yeniden kaydetmek (DC'de)
nltest /dsregdns
ipconfig /registerdns

dcdiag /test:dns çıktısında forwarder, delegasyon, dinamik kayıt ve kayıt kaydı (record registration) başlıkları her DC için “Pass” olmalı. Bu denetimi Active Directory sağlık kontrolü sürecine eklemek, sorunu kullanıcı şikâyetine dönüşmeden yakalar. DNS ve dizin hizmetlerinin düzenli işletimini sunucu ve bulut yönetimi kapsamında üstleniyoruz.

Sık sorulan sorular

Domain controller’ın DNS ayarına 8.8.8.8 gibi bir adres eklemek sorun olur mu?

Evet. DC veya istemci dış bir çözümleyiciye sorgu gönderdiğinde iç bölgedeki SRV kayıtlarını bulamaz; sonuç etki alanına katılma, Group Policy ve kimlik doğrulama hatalarıdır. Dış çözümleme DNS sunucusu tarafında forwarder ile yapılır.

Scavenging’i açtıktan sonra kayıtlar ne zaman silinmeye başlar?

Bölgede aging açıldıktan sonra en az bir refresh aralığı (varsayılan 7 gün) beklenir; bu süre dolmadan temizlik yapılmaz. Sonra zaman damgası no-refresh ve refresh aralıklarının toplamından (varsayılan 7+7 = 14 gün) eski olan dinamik kayıtlar ilk temizlik çalışmasında silinir. Aday listesini aging’i açtığınız hafta içinde inceleyin.

Conditional forwarder’ı her DNS sunucusunda ayrı ayrı mı tanımlamalıyım?

Gerekmez. Conditional forwarder Active Directory’de saklanacak şekilde oluşturulursa seçtiğiniz replikasyon kapsamındaki tüm DNS sunucularına otomatik dağılır. Normal forwarder ise sunucu düzeyinde bir ayardır ve her sunucuda ayrı yapılandırılır.

Statik kayıtlar scavenging ile silinir mi?

Elle oluşturulan kayıtların zaman damgası sıfırdır ve scavenging onları silmez. Dinamik oluşmuş kayıtlar ise zaman damgası taşır ve silinebilir; kritik sunucu kayıtlarını statik hale getirin.