Active Directory DNS Yapılandırması: Forwarder ve Zone

Çok lokasyonlu bir kurumda çalıştığım dönemde satın alma portalına erişilemiyor diye şikâyet geldi. O gün evden çalışıyordum ve kendi bağlantımdan baktığımda site açılıyordu. Israr ettiler, kurum ağına VPN ile bağlandım ve gerçekten açılmıyordu. Aynı kampüste yer alan komşu kurumun kablosuz ağına geçtim, site açıldı. Kendi kurum ağına döndüm, açılmadı. Sorunun iç ağdan kaynaklandığı belliydi.

Kısa bir araştırmanın sonunda buldum: yıllar önce, web sunucuları dışarıya taşınmadan önce, eski bir sistemci iç DNS’e o alt alan adı için bir A kaydı eklemişti. Yazılım hizmet sağlayıcısı sonradan IP adresini değiştirmişti, ama kayıt iç DNS’te kalmaya devam etmişti. İç ağdan gelen sorgular DC’ye gidiyor, DC kendi zone’unda eski adresi buluyor ve kullanıcıyı oraya gönderiyordu. Dışarıdan bağlananlar internetteki DNS’i kullandığı için güncel adrese ulaşıyordu. Kurumun kıdemli sistemcileri suçu hizmet sağlayıcısına yıktı, ben ise sorunun iç DNS’te olduğunu biliyordum.

Active Directory DNS yapılandırması, domain controller’ın iç zone’larını, dış adları nereye soracağını (forwarder), IP’den ada dönüşü (reverse lookup zone), belirli domain’leri nereye yönlendireceğini (conditional forwarder) ve eskiyen kayıtları nasıl temizleyeceğini (scavenging) belirler. Bu yazıda hepsini lab domain’imiz ad.sistemkusu.com’un ilk DC’si dc01 üzerinde, Windows Server 2025’te kurdum ve ölçtüm. Yukarıdaki arızayı da lab’da yeniden ürettim: split-brain bölümünde.

Serinin benzetmesiyle Active Directory bir otelin kart sistemidir ve DNS otelin dahili telefon rehberidir. Rehber otelin kendi masalarını ve odalarını kusursuz bilir, ama şehirdeki bir restoranın numarasını bilmez. O numarayı otelin santrali dış hattan sorar. Bu yazı rehberin nasıl tutulduğunu ve santralin nereye bağlandığını anlatıyor.

Yazı Active Directory kurulumu yazımızın devamıdır ve DNS rolünün kurulu olduğunu varsayar. Protokolün kendisini, bir sorgunun kökten nasıl çözüldüğünü ve kayıt türlerini DNS nedir yazımızda anlattık.

Active Directory DNS’in İki Yüzü

Active Directory kurulurken DNS Server rolü de kurulur ve iki zone oluşur: ad.sistemkusu.com ve domain controller’ları bulmaya yarayan SRV kayıtlarını taşıyan _msdcs.ad.sistemkusu.com. İkisi de Active Directory-Integrated zone’dur: kayıtlar AD veritabanında durur ve DC’ler arasında AD replikasyonuyla kopyalanır.

DNS Manager’ı Win+R ile dnsmgmt.msc yazarak ya da Server Manager → Tools → DNS yoluyla açın. Sol ağaçta sunucu adının altında dört düğüm vardır: Forward Lookup Zones, Reverse Lookup Zones, Trust Points ve Conditional Forwarders. Kurulumdan sonra dc01’de şöyle görünüyordu:

Komut karşılığı zone listesini sunucunun kendi tuttuğu üç küçük reverse zone’la birlikte verir:

Get-DnsServerZone | Format-Table ZoneName, ZoneType, IsDsIntegrated, IsReverseLookupZone, DynamicUpdate -AutoSize

ZoneName                ZoneType IsDsIntegrated IsReverseLookupZone DynamicUpdate
--------                -------- -------------- ------------------- -------------
_msdcs.ad.sistemkusu.com Primary           True               False Secure
0.in-addr.arpa           Primary          False                True None
127.in-addr.arpa         Primary          False                True None
255.in-addr.arpa         Primary          False                True None
ad.sistemkusu.com        Primary           True               False Secure
TrustAnchors             Primary           True               False None

Listedeki küçük reverse zone’lar (0, 127 ve 255) sunucunun kendi yerel adresleri içindir ve konsolda görünmez. İki iç zone yalnız güvenli güncellemeye açık: kendi kayıtlarını yalnız domain’e katılmış makineler yazabilir.

İç Zone: Rehberin Kendi Sayfaları

dc01, ad.sistemkusu.com için authoritative DNS sunucusudur: bu zone’daki A, AAAA, SRV ve CNAME kayıtlarının asıl kaynağıdır ve soruları başka yere sormadan cevaplar. Örnekteki otelde bu, dahili rehberin kendi sayfalarıdır: ön büronun, kat şeflerinin ve odaların numarası oradadır. Rehberin dışındaki bir numara sorulduğunda ise rehber susar.

DNS Forwarder: Bilinmeyen Sorguyu Dışarıya Yönlendirmek

DC google.com sorusunu aldığında önce kendi zone’larına bakar ve bulamaz. Forwarder tanımlıysa soruyu ona iletir ve gelen cevabı istemciye döner. Forwarder yoksa ya da cevap vermiyorsa iki yol kalır: root hints ile internetteki root server’lara kendisi sorar ya da soruyu cevapsız bırakır. Örnekteki otelde forwarder santraldir: rehberde olmayan numarayı dış hattan şehir santraline sorar.

Root hints çoğu ağda çalışır, ama firewall yalnız belli DNS sunucularına izin veriyorsa DC’nin root server’lara gidişi kesilir ve kullanıcılar dış adları çözemez. Belirti kafa karıştırıcıdır: DC’ye ping atılır, domain’e giriş yapılır, iç uygulamalar açılır, yalnız internet “gitmiştir”.

Active Directory DNS Nasıl Olmalı?

Microsoft’un önerileri ve lab ölçümleri birlikte şu düzeni tarif ediyor:

1. DC’nin ağ kartında yalnız iç DNS sunucuları yazılır. Microsoft’a göre DC’nin DNS istemcisi ISP’nin DNS sunucusunu gösterirse Netlogon AD’nin doğru kayıtlarını yazamaz. Her DC önce öbür DC’yi, sonra kendini gösterir.
   Microsoft Learn, Recommendations for DNS client settings.
2. Dış adlar DNS sunucusunda çözülür: forwarder ya da root hints ile. Microsoft örnek olarak ISP’nin DNS sunucularını forwarder eklemeyi verir. En az iki forwarder yazılır.
3. Reverse lookup zone AD’de saklanır ve yalnız güvenli güncellemeye açılır. Böylece PTR kayıtları DC’ler arasında kopyalanır ve yalnız domain üyeleri kayıt yazabilir.
4. Conditional forwarder AD’de saklanır. Saklanmazsa yalnız tanımlandığı DC’de çalışır.
5. Aging ve scavenging bilinçli açılır. Microsoft’a göre ikisi de fabrika ayarında kapalıdır, iki aralığın önerilen değeri 7 gündür ve zone’u tek bir DNS sunucusu temizler. Elle eklenen kayıtlar hiç silinmez.
   Microsoft Learn, Configure DNS aging and scavenging, Eylül 2026.

DNS Forwarder Yapılandırması

Kurulumdan sonra ilk bakılacak yer forwarder listesidir, çünkü onu kurulumun kendisi doldurur ve neyle doldurduğunu çoğu zaman kimse kontrol etmez.

Kurulum Forwarder’ı Kendisi Yazdı

DNS Manager’da sunucu adına (DC01) sağ tıklayıp Properties açın ve Forwarders sekmesine geçin. dc01’de liste boş değildi:

Get-DnsServerForwarder | Format-List IPAddress, UseRootHint, Timeout

IPAddress   : {192.168.1.1, <önek>::1}
UseRootHint : True
Timeout     : 3

Lab hattının genel IPv6 öneki bu yazının çıktılarında ve ekranlarında <önek> diye maskelendi. Çıktıdan üç şey okunur:

1. İki forwarder da modem. DC promotion, ağ kartında o an yazılı olan DNS adreslerini forwarder yapar. Modemin IPv6 DNS adresi de modemin IPv6 duyurusundan gelip listeye girmiş.
2. Root hints açık. Forwarder’lar cevap vermezse DC root server’lara kendisi sorar.
3. Zaman aşımı 3 saniye. DC bir forwarder’dan bu kadar cevap bekler, sonra sıradakine geçer.

Dış adların bir ev modeminden çözülmesi lab’da çalışır, kurumda ise iki sorun yaratır: modem kendisi bir çözümleyici değildir, soruyu başka bir yere iletir ve hangi kayıtların nerede tutulduğu belirsizleşir. Forwarder’ı bilinçli seçin.

Forwarder Ekleme

Aynı sekmede Edit düğmesine basın. Edit Forwarders penceresinde eski satırları seçip Delete ile silin, sonra Click here to add an IP Address or DNS Name satırına yeni adresi yazıp Enter’a basın. Pencere her adresi o an sınar ve sonucu Validated sütununa yazar. Lab’da şu iki adresi yazdım:

1. 1.1.1.1: Server FQDN one.one.one.one, Validated OK.
2. 8.8.8.8: Server FQDN dns.google, Validated OK.

Pencereyi ve Properties’i OK ile kapattım. Komut karşılığı:

Set-DnsServerForwarder -IPAddress 1.1.1.1, 8.8.8.8

Lab’da Public DNS sunucularını seçtim, çünkü lab hattı bir ev modemi. Çalıştığım kurumlarda ise buraya ISP’nin DNS sunucu adreslerini yazdım: 5651 sayılı Kanun kapsamında DNS çözümleme kayıtlarının ISP’de tutulmasını daha sağlıklı buldum. İnternete erişim sağlayan kurumların bu kanundaki yükümlülüklerini 5651 Sayılı Kanun ve log yönetimi yazımızda anlattık.

Forwarder Doğrulama: PowerShell ile Test

Değişikliğin işe yaradığını DC’nin kendisine sorarak görün:

Get-DnsServerForwarder | Format-List IPAddress
Resolve-DnsName google.com -Server 192.168.1.10 -Type A -DnsOnly

IPAddress : {1.1.1.1, 8.8.8.8}

Name       Type TTL  Section IPAddress
----       ---- ---  ------- ---------
google.com A    296  Answer  192.178.24.46

Forwarder listesi yeni adresleri gösteriyor ve google.com DC üzerinden çözüldü. DNS servisini yeniden başlatmak gerekmedi. -DnsOnly parametresi soruyu yalnız DNS’e sorar, NetBIOS ve yerel dosyalar devreye girmez. -Server ile soruyu doğrudan DC’ye yönelttiğiniz için istemcinin kendi DNS ayarı sonucu değiştirmez.

İstemcilerin önbelleğinde eski cevaplar bir süre daha kalabilir. Hangi önbelleğin hangi komutla temizlendiğini DNS önbelleği temizleme yazımızda ölçümleriyle anlattık. Bir switch gibi ağ cihazının bu DNS’e nasıl sorduğunu da switch DNS server ayarı yazımızda ölçtük.

Reverse Lookup Zone ve PTR Kayıtları

Forward zone addan IP’ye gider, reverse lookup zone ise IP’den ada döner. Örnekteki otelde bu, rehberin ters dizinidir: “dahili 304’ü kim arıyor?” sorusunun cevabı. Kurulum reverse zone açmaz, dc01’de Reverse Lookup Zones düğümü boştu.

Reverse Lookup Neden Gerekli?

Reverse zone olmadan AD çalışır, ama iki yerde eksikliği hissedilir:

1. Log ve güvenlik incelemesi: SIEM araçları ve firewall logları IP’yi ada çevirerek raporlar. PTR kaydı yoksa log yalnız IP taşır ve “bu IP hangi makineydi?” sorusu bir olay sırasında cevapsız kalır.
2. Araçların okunabilirliği: nslookup çıktısındaki Server: UnKnown satırı, istemcinin DNS sunucusunun PTR kaydını bulamadığı anlamına gelir.

Reverse Lookup Zone Oluşturma

Reverse Lookup Zones düğümüne sağ tıklayıp New Zone seçin. Sihirbazın sayfaları ve lab’daki değerler:

1. Zone Type: Primary zone ve Store the zone in Active Directory işaretli. İkisi de fabrika ayarında seçili gelir.
2. Active Directory Zone Replication Scope: To all DNS servers running on domain controllers in this domain: ad.sistemkusu.com. Bu da fabrika ayarıdır.
3. Reverse Lookup Zone Name: IPv4 Reverse Lookup Zone.
4. Network ID: 192.168.1. Sihirbaz zone adını kendisi 1.168.192.in-addr.arpa olarak yazar.
5. Dynamic Update: Allow only secure dynamic updates, fabrika ayarında seçili.

Komut karşılığı tek satırdır:

Add-DnsServerPrimaryZone -NetworkId "192.168.1.0/24" -ReplicationScope Domain -DynamicUpdate Secure

Zone oluştuktan sonra DC’nin kendi PTR kaydını yazması için dc01’de ipconfig /registerdns çalıştırdım. İki dakika sonra kayıt zone’daydı ve ters sorgu cevap verdi:

Resolve-DnsName 192.168.1.10 -Server 192.168.1.10 -DnsOnly

Name                      Type TTL  Section NameHost
----                      ---- ---  ------- --------
10.1.168.192.in-addr.arpa PTR  1200 Answer  dc01.ad.sistemkusu.com

Kayıt kendiliğinden geldiği için zaman damgası taşıyor. Bu ayrıntı aşağıdaki scavenging bölümünde önem kazanıyor: zaman damgası olan kayıt eskiyebilir, olmayan eskimez.

Zone kurulmadan önce açılmış makinelerin PTR kayıtları kendiliğinden oluşmaz. Domain üyeleri bir sonraki kayıt döngüsünde (en geç 24 saatte) ya da ipconfig /registerdns ile yazar. Domain dışı cihazlar için kayıt elle eklenir. Zone’a sağ tıklayıp New Pointer (PTR) seçilir ya da yeni A kaydı açılırken Create associated pointer (PTR) record kutusu işaretlenir.

Active Directory Conditional Forwarder Yapılandırması

Tek domain’li bir yapıda conditional forwarder’a genelde ihtiyaç yoktur. Şu durumlarda gerekir:

1. İki ayrı forest: şirket birleşmesinde ya da bir iş ortağıyla entegrasyonda iki AD’nin birbirinin adlarını çözmesi gerekir.
2. VPN ile bağlı ayrı bir ağ: karşı tarafın iç DNS adlarını yalnız karşı tarafın DNS sunucusu bilir.

Standart forwarder bilinmeyen bütün soruları aynı yere gönderir. Conditional forwarder ise yalnız belirli bir domain’in sorularını belirli bir sunucuya yollar. Örnekteki otelde bu, bir iş ortağı otelin numaraları sorulduğunda şehir santrali yerine doğrudan o otelin santraline bağlamaktır.

Conditional Forwarders düğümüne sağ tıklayıp New Conditional Forwarder seçin. Pencerede üç alan var:

1. DNS Domain: yönlendirilecek domain, örnekte iş ortağının ad.isortagi.com’u.
2. IP addresses of the master servers: o domain’i çözen DNS sunucusu, örnekte 10.20.0.10.
3. Store this conditional forwarder in Active Directory, and replicate it as follows: işaretli, liste All DNS servers in this domain. Fabrika ayarında liste forest’i gösterir.

Bu kareyi kaydetmeden kapattım, çünkü lab’da 10.20.0.10’da bir DNS sunucusu yok. Pencere bunu kendisi gösterdi: Validated sütununda kırmızı çarpı ve “A timeout occurred during validation.” Gerçek bir yapılandırmada bu satır OK olmadan kaydetmeyin, aksi hâlde o domain’in bütün soruları her seferinde 5 saniyelik zaman aşımını bekler. Komut karşılığı:

Add-DnsServerConditionalForwarderZone -Name "ad.isortagi.com" -MasterServers 10.20.0.10 -ReplicationScope Domain

Split-Brain DNS Yapılandırması

Split-brain DNS, aynı alan adının iç ağda ve internette farklı adreslere çözülmesidir. İç ağdaki DC, şirketin genel alan adı için de bir zone tutar ve içeriden gelen sorulara iç adresi verir. Dışarıdan gelen sorulara ise internetteki DNS cevap verir. Örnekteki otelde bu, otelin kendi restoranının numarasını dahili rehbere iç hat olarak yazmaktır: misafir içeriden aradığında dış hatta çıkmadan restorana bağlanır.

Gerekçesi yönlendirme ile ilgilidir. İç ağdaki kullanıcı genel adı internetteki adrese çözerse paket firewall’a çıkıp aynı ağa geri döner. Buna hairpin NAT denir: bazı cihazlar desteklemez, destekleyenler de gereksiz yük taşır. İç zone bu dolaşmayı ortadan kaldırır.

İç Zone Açmak ve Kayıt Eklemek

Lab’da sitemizin kendi alan adı sistemkusu.com için dc01’de bir iç zone açtım. Önce dışarıdaki cevabı kaydettim:

Name                      Type TTL  Section IPAddress
----                      ---- ---  ------- ---------
sistemkusu.com            A    1800 Answer  216.150.1.1
sistemkusu.com            A    1800 Answer  216.150.1.193
www.sistemkusu.com        A    1800 Answer  216.150.16.65
www.sistemkusu.com        A    1800 Answer  216.150.1.129

Forward Lookup Zones → New Zone sihirbazında reverse zone’daki değerlerin aynısını seçtim (Primary, Store in AD, domain kapsamı). İki sayfa farklıydı:

1. Zone Name: sistemkusu.com. İç AD domain’i değil, genel alan adı.
2. Dynamic Update: Do not allow dynamic updates. Bu zone’a domain makineleri kendiliğinden kayıt yazmamalı, yalnız bilerek eklenen kayıtlar durmalı.

Zone’a sağ tıklayıp New Host (A or AAAA) ile kaydı ekledim:

Komut karşılığı:

Add-DnsServerPrimaryZone -Name "sistemkusu.com" -ReplicationScope Domain -DynamicUpdate None
Add-DnsServerResourceRecordA -ZoneName "sistemkusu.com" -Name "www" -IPv4Address 192.168.1.100 -CreatePtr

Aynı adı iç DC’ye ve dışarıya sorduğumda iki farklı cevap geldi. Önce -Server 192.168.1.10, sonra -Server 1.1.1.1:

Name               Type TTL  Section IPAddress
----               ---- ---  ------- ---------
www.sistemkusu.com A    3600 Answer  192.168.1.100

Name               Type TTL  Section IPAddress
----               ---- ---  ------- ---------
www.sistemkusu.com A    1651 Answer  216.150.16.65
www.sistemkusu.com A    1651 Answer  216.150.1.129

Split-brain çalışıyor: içeride iç adres, dışarıda genel adres.

İçeriden Açılmayan Site

Asıl ders bir sonraki soruda çıktı. Aynı iç DC’ye sitenin çıplak adını, yani sistemkusu.com’u sordum:

Resolve-DnsName sistemkusu.com -Server 192.168.1.10 -DnsOnly

Name           Type TTL  Section   PrimaryServer          NameAdministrator            SerialNumber
----           ---- ---  -------   -------------          -----------------            ------------
sistemkusu.com SOA  3600 Authority dc01.ad.sistemkusu.com hostmaster.ad.sistemkusu.com 2

Cevapta hiçbir adres yok. İnternette sistemkusu.com iki adrese çözülüyordu, ama iç zone’a yalnız www kaydını eklemiştim. DC artık bu zone’un sahibi olduğu için soruyu dışarıya sormadı. Kendi zone’unda kayıt bulamayınca yalnız zone’un SOA kaydını döndürdü. Sonuç, girişteki portal arızasının aynısı: site dışarıdan açılıyor, içeriden açılmıyor.

Kural buradan çıkıyor: iç zone, genel zone’daki bütün adların sorumluluğunu alır. Public DNS’e eklenen her kayıt iç zone’a da eklenir. Eklenmezse o ad içeriden hiç çözülmez ve iç zone’daki eski bir kayıt da girişteki vakada olduğu gibi kullanıcıyı yanlış adrese gönderir. Ölçümden sonra lab’daki sistemkusu.com zone’unu ve 192.168.1.100’ün PTR kaydını sildim, çünkü lab makinelerinin gerçek siteye ulaşması gerekiyor.

DNS Scavenging: Eskiyen Kayıtları Temizlemek

Makineler kendi kayıtlarını DNS’e yazar, ama emekli olduklarında silmez. Yıllar içinde zone’da yüzlerce eski kayıt birikir ve bu kayıtlar yeni bir makineye verilmiş IP’yi eski bir adla eşleştirir. Örnekteki otelde bu, check-out yapmış misafirlerin rehberde kalan numaralarıdır. Scavenging bu kayıtları düzenli olarak rehberden düşer.

Aging ve Scavenging Nedir?

İki terim aynı işin iki yarısıdır, biri kaydın yaşını izler, öbürü eskiyeni siler:

1. Aging (yaşlandırma): DNS sunucusunun, kendiliğinden yazılan her kaydın yaşını bir zaman damgasıyla izlemesidir. Kaydın sahibi makine onu tazeledikçe damga yenilenir. Aging tek başına hiçbir kaydı silmez, yalnız hangisinin eskidiğini bilir. Ayarı zone’dadır.
2. Scavenging (temizleme): bayat sayılan kayıtları belirli aralıklarla silen iştir. İngilizcede scavenger artıkları toplayan demektir. Ayarı sunucudadır: hangi DNS sunucusunun, kaç günde bir temizleyeceği.

İkisi birbirine bağlıdır. Aging açık değilse scavenging silecek bayat kayıt bulamaz, scavenging açık değilse aging yalnız işaret koyar. Microsoft ikisini birlikte açmayı tarif eder ve ikisi de fabrika ayarında kapalıdır.

Ne işe yaradıkları emekli olan makinede görünür. Makine ağdan çıkar ama DNS’teki kaydı kalır. Aynı IP sonradan başka bir makineye verilince eski ad yeni makineyi gösterir, log okuyan ve ping atan yanlış makineye bakar. Girişteki portal vakası ise scavenging’in çözemeyeceği türdendi: o A kaydı elle eklenmişti ve elle eklenen kaydı scavenging hiç silmez.

Aging ve Scavenging Nasıl Çalışır?

Kendiliğinden yazılan her kaydın bir zaman damgası vardır. İki aralık bu damgaya göre işler:

1. No-refresh interval: kayıt yeni yazıldıktan sonra bu süre boyunca zaman damgası yenilenmez. Amaç gereksiz replikasyonu önlemektir.
2. Refresh interval: ardından gelen bu sürede makine kaydını yenilerse damga güncellenir.

İki süre de geçtiği hâlde kayıt yenilenmemişse kayıt bayat sayılır ve sunucunun bir sonraki temizlik turunda silinir. Fabrika ayarındaki 7+7 günle bir kayıt 14 gün yenilenmezse bayatlar. Elle eklenen kayıtların zaman damgası sıfırdır ve scavenging onları hiç silmez: yukarıdaki PTR kaydının damgası vardı, split-brain zone’una elle eklenen www kaydının yoktu.

Scavenging’i Açmak

Ayar iki yerde yapılır ve ikisi de gerekir. Biri zone’ların aging ayarı, öbürü sunucunun temizlik turu.

Zone’lar için: sunucu adına sağ tıklayıp Set Aging/Scavenging for All Zones açın. dc01’de Scavenge stale resource records işaretsizdi, iki aralık zaten 7 gündü. Kutuyu işaretledim:

OK’e basınca ikinci bir pencere ayarın yalnız bundan sonra açılacak zone’lara mı, mevcut zone’lara da mı uygulanacağını sordu. Apply these settings to the existing Active Directory-integrated zones kutusu işaretsiz geliyordu, işaretledim:

Sunucu için: sunucunun Properties penceresinde Advanced sekmesine geçin ve Enable automatic scavenging of stale records kutusunu işaretleyin. Kutu işaretsizken Scavenging period 0 gündü, işaretleyince kendiliğinden 7 gün oldu:

Microsoft zone’u tek bir sunucunun temizlemesini önerir, bu yüzden aynı kutuyu dc02’de işaretlemedim. Komut karşılığı:

Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 -ApplyOnAllZones

Sonuç iki sorguyla görünür:

Get-DnsServerScavenging | Format-List
Get-DnsServerZoneAging ad.sistemkusu.com | Format-List

NoRefreshInterval  : 7.00:00:00
RefreshInterval    : 7.00:00:00
ScavengingInterval : 7.00:00:00
ScavengingState    : True
LastScavengeTime   :

ZoneName              : ad.sistemkusu.com
AgingEnabled          : True
AvailForScavengeTime  : 16.10.2026 23:00:00
RefreshInterval       : 7.00:00:00
NoRefreshInterval     : 7.00:00:00
ScavengeServers       :

Son satırdan önceki değer önemli: AvailForScavengeTime bir hafta sonrasını gösteriyor. Microsoft’a göre aging ilk açıldığında zone bir refresh aralığı boyunca temizlenmez. Bu sürede makineler kayıtlarını yeniler, böylece aging kapalıyken damgası güncellenmemiş canlı kayıtlar silinmez. Reverse zone’da da aynı tarih yazıyordu.

Aralıklar DHCP Kira Süresinden Kısa Olmamalı

Aralıkları kısaltmak eski kayıtları daha çabuk siler, ama hâlâ kullanılan kayıtları da silebilir. Bir makine kaydını DHCP kirasını yenilerken tazeler. Toplam aralık kira süresinden kısaysa, kirası henüz dolmamış ve yenileme zamanı gelmemiş bir makinenin kaydı bayat sayılır. Microsoft’un sorun giderme sayfası bu yüzden No-refresh ve Refresh toplamının en uzun DHCP kirasına eşit ya da ondan uzun olmasını ister.

Microsoft’un yapılandırma sayfası ise aynı maddede toplamın kira süresine eşit ya da ondan kısa olmasını yazıyor. İki sayfa ters yönde kural veriyor. Yapılandırma sayfasının kendi gerekçesi (“refresh aralığı istemcinin yeniden kayıt süresinden kısaysa geçerli kayıtlar silinir”) ve sorun giderme sayfasının örnek vakası aynı mekanizmayı anlatıyor ve o mekanizma toplamın kiradan uzun olmasını gerektiriyor. Güvenli kural budur. Fabrika ayarındaki 14 gün, Windows Server DHCP’nin 8 günlük fabrika kirasını karşılar. Kira süresinin nerede ayarlandığını Windows Server DHCP kurulumu yazımızda anlattık.
Microsoft Learn, Troubleshoot DNS scavenging issues, Şubat 2026.

Active Directory DNS’de Sık Yapılan Hatalar

Sonuç: AD DNS’i Kurulum Değil, Bakım Belirler

Active Directory DNS’i kurulumla gelir ama kurulumun bıraktığı hâliyle kalmamalıdır. Lab’da beklenenden farklı çıkan şeyler:

1. Forwarder’ı kurulumun kendisi yazdı ve yazdığı iki adres de modemdi, biri IPv6.
2. PTR kaydı reverse zone açıldıktan iki dakika sonra geldi, zone açılmadan hiçbir makinenin PTR kaydı yoktu.
3. Split-brain zone’u açılınca sitenin çıplak adı içeriden çözülmez oldu. DC zone’un sahibi olduğu için soruyu dışarıya sormadı.
4. Microsoft’un iki sayfası scavenging aralıkları için ters kural veriyor. Güvenli olan, toplamın en uzun DHCP kirasından kısa olmamasıdır.

Girişteki benzetmeye dönersek: dahili telefon rehberi otelin kendi numaralarını kusursuz bilir, ama santralin hangi dış hatta bağlandığını, ters dizinin tutulup tutulmadığını ve check-out yapanların rehberden düşülüp düşülmediğini rehberin kendisi söylemez. Bunları biri kontrol etmezse misafir bir gün kendi otelinin restoranını içeriden arayamaz.

Sıradaki adım, kullanıcılar, gruplar ve bilgisayarlar açılmadan önce adlarını kararlaştırmak: Active Directory isimlendirme standardı. AD ortamının bütününü Active Directory rehberimizde anlattık.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn