Active Directory ortamlarında DNS, Client'ların ve sunucuların kendi kayıtlarını Dynamic Update ile oluşturmasına izin verecek şekilde çalışır. Bir bilgisayar Domain'e katıldığında, IP adresi değiştiğinde veya DHCP üzerinden yeni bir adres aldığında ilgili A ve PTR kayıtları otomatik olarak oluşturulur ya da güncellenir. Bu mekanizma kayıtların oluşmasını otomatik hale getirir, ancak artık var olmayan cihazlara ait kayıtların silinmesi için ayrıca bir yapılandırma gerekir.
Domain'den çıkarılan bilgisayarlar, Network değiştiren dizüstü bilgisayarlar, yeniden kurulan sunucular, kaldırılan Domain Controller'lar ve kapatılan sanal makineler zamanla Zone içinde sahipsiz kayıtlar bırakır. Bu kayıtlar artık başka bir cihaza verilmiş bir IP adresini işaret ettiğinde isim çözümleme yanlış hedefe gider, yönetim araçları hatalı cihaza bağlanır ve sorun giderme süreci gereksiz yere uzar. Aynı IP adresi için birden fazla PTR kaydının bulunması da Reverse Lookup sonuçlarını güvenilmez hale getirir.
Windows Server DNS bu sorunu Aging ve Scavenging mekanizmasıyla çözer. Aging, dinamik olarak oluşturulan her kaydın üzerinde bir Timestamp tutar ve bu Timestamp'in ne zaman yenilenebileceğini belirler. Scavenging ise belirlenen süre boyunca yenilenmemiş kayıtları Stale kabul eder ve Zone'dan kaldırır.
Bu makalede önce mekanizmanın arkasındaki zaman hesabı açıklanacak, ardından kayıt Timestamp'lerinin incelenmesi, Zone ve sunucu seviyesindeki yapılandırma, PowerShell ile doğrulama, Scavenging yapacak sunucunun sınırlandırılması, silinecek kayıtların önceden tespiti ve Event Log üzerinden doğrulama adım adım ele alınacak. Örneklerde Windows Server 2022 üzerinde çalışan ABCISTSRVDC01 isimli Domain Controller ve abc.local Zone'u kullanılmıştır, komutlar kendi ortamınızın değerleriyle uyarlanmalıdır.
Aging ve Scavenging Nasıl Çalışır
Dynamic Update ile oluşturulan her kayıt, oluşturulduğu veya son yenilendiği anı gösteren bir Timestamp değeri taşır. Elle oluşturulan Static kayıtların Timestamp değeri sıfırdır ve bu kayıtlar varsayılan olarak Scavenging kapsamına girmez. Client'lar kayıtlarını düzenli olarak yeniler. Windows DNS Client servisi bu yenilemeyi varsayılan olarak 24 saatte bir yapar, Domain Controller'larda SRV kayıtları da Netlogon servisi tarafından aynı aralıkla yeniden kaydedilir.
Burada iki farklı işlemi ayırt etmek gerekir. Kaydın verisinin değişmesi, örneğin IP adresinin farklılaşması bir Update'tir. Verinin aynı kalıp yalnızca Timestamp'in tazelenmesi ise bir Refresh'tir. Aging mekanizması bu ikisine farklı davranır ve zaman hesabı iki Interval üzerine kuruludur.
Aging Interval Değerleri
Aşağıdaki tablo, kaydın yaşam döngüsünü belirleyen iki Interval değerini, sunucu seviyesindeki Scavenging döngüsünü ve varsayılan sürelerini gösterir.
|
Ayar |
Varsayılan |
Davranış |
|
No-Refresh Interval |
7 gün |
Timestamp yenilendikten sonra başlar. Bu süre içinde gelen Refresh istekleri kabul edilmez ve Timestamp değişmez. Veri değişikliği içeren Update istekleri kabul edilir. |
|
Refresh Interval |
7 gün |
No-Refresh Interval bittikten sonra başlar. Bu süre içinde gelen Refresh kabul edilir ve Timestamp güncellenir. Süre dolana kadar Refresh gelmezse kayıt Stale kabul edilir. |
|
Scavenging Period |
7 gün |
Sunucu seviyesindeki ayardır. Otomatik Scavenging döngüsünün ne sıklıkla çalışacağını belirler. |
No-Refresh Interval'ın var olma sebebi Replication yüküdür. AD-integrated Zone'larda her Timestamp değişikliği bir Active Directory yazma işlemi anlamına gelir ve bu değişiklik DNS rolü bulunan tüm Domain Controller'lara replike edilir. Her gün kaydını yenileyen binlerce Client'ın her Refresh'i kabul edilseydi gereksiz Replication trafiği oluşurdu. No-Refresh Interval bu yazmaları belirli bir aralığa indirir.
Bir kaydın silinebilir hale gelmesi için Timestamp üzerine iki Interval'ın toplamı kadar sürenin geçmesi gerekir. Varsayılan değerlerle bu süre 14 gündür. Aşağıdaki akış, tek bir kaydın zaman çizelgesini gösterir.
T0 T0 + 7 gün T0 + 14 gün
|----------------------|------------------------|------------------>
| No-Refresh Interval | Refresh Interval | Stale
| Refresh reddedilir | Refresh kabul edilir | Scavenging ile
| Update kabul edilir | Timestamp yenilenir | silinebilir
Refresh Interval içinde Refresh gelirse -> T0 yeni Timestamp olur, döngü baştan başlar
Refresh Interval içinde Refresh gelmezse -> Kayıt bir sonraki Scavenging döngüsünde silinir
Kaydın Stale olması tek başına silinmesi için yeterli değildir. Kaydın bulunduğu Zone'da Aging etkin olmalı, Zone için belirlenen Scavenging başlangıç zamanı geçmiş olmalı ve en az bir DNS sunucusunda otomatik ya da manuel Scavenging çalışmalıdır. Bu koşullardan biri eksik olduğunda kayıt Stale olsa bile Zone'da kalmaya devam eder. Makalenin sonundaki Event Log doğrulamasında bu koşullardan birinin henüz sağlanmadığı bir durum da görülecek.
DNS Manager'da Aging ve Scavenging ile ilgili üç farklı ayar bulunur ve bu ayarların hepsinin yapılması gerekmez. Aşağıdaki şema hangi ayarın ne işe yaradığını ve hangisinin zorunlu olduğunu gösterir.
Ayar Konum Gereklilik
------------------------------------ ----------------------------- --------------------------------
1. Zone Aging Zone Properties > Aging Zorunlu, her Zone için ayrı
2. Set Aging/Scavenging for All Zones Sunucu adı > sağ tık menüsü İsteğe bağlı, 1. ayarın kısayolu
3. Enable automatic scavenging Server Properties > Advanced Zorunlu, tek sunucuda yeterli
1 veya 2 -> Hangi Zone'daki kayıtların silinebileceğini belirler
3 -> Silme işlemini fiilen çalıştırır
Makalede üç ayar da sırayla gösterilmiştir. Zone'lar tek tek yapılandırılacaksa ikinci ayar atlanabilir, tüm AD-integrated Zone'lar aynı değerleri alacaksa birinci ayar yerine ikinci ayar kullanılabilir. Üçüncü ayar her iki yöntemde de gereklidir.
Kayıt Timestamp Bilgisinin İncelenmesi
Yapılandırmaya geçmeden önce mevcut kayıtların durumunu görmek gerekir. DNS Manager, varsayılan görünümde Timestamp bilgisini göstermez. View menüsünden Advanced seçeneği işaretlendiğinde abc.local Zone'undaki kayıtların listesinde Timestamp sütunu görünür hale gelir ve kayıt özelliklerinde ilgili alanlar açılır.
Aşağıdaki ekranda Timestamp sütununda iki farklı değer tipi görülür. SOA, NS kayıtları ve ABCISTSRVDC01 sunucusunun kendi A kaydı static olarak görünür, bu kayıtlar Scavenging kapsamı dışındadır. ABCISTSRVFS01 gibi düzenli çalışan sunucuların kayıtlarında ise yakın tarihli bir Timestamp yer alır. Timestamp değerlerinin tamamının tam saat olarak görünmesi tesadüf değildir, DNS sunucusu bu değeri saat hassasiyetinde tutar.
ABCISTWKS01 kaydının Properties penceresinde IP address alanında 10.10.10.88 görünür. Delete this record when it becomes stale seçeneği işaretlidir ve Record time stamp alanında 9/26/2026 2:00:00 PM değeri yer alır. Bu değer, kaydın dynamic olarak oluşturulduğunu ve Scavenging kapsamında olduğunu gösterir. Elle oluşturulmuş bir kayıtta ise bu seçenek boştur ve Timestamp sütununda static ifadesi yer alır.

Static bir kayıtta Delete this record when it becomes stale seçeneği işaretlenirse kayda Timestamp atanır ve kayıt Scavenging kapsamına girer. dnscmd /AgeAllRecords komutu Zone'daki tüm Static kayıtlar için aynı etkiyi yaratır. Sunucu, yazıcı ve uygulama kayıtları gibi kalıcı kayıtlarda bu iki yöntem kullanılmamalıdır.
Zone Seviyesinde Aging Yapılandırması
Aging, her Zone için ayrı ayrı etkinleştirilir. abc.local Zone'una sağ tıklanıp Properties açıldığında General sekmesinde Zone'un Active Directory-Integrated tipte olduğu, Replication kapsamının All DNS servers in this domain olarak tanımlandığı ve Dynamic updates ayarının Secure only olduğu görülür. Aging mekanizması, Dynamic Update ile oluşturulan kayıtlar üzerinde çalıştığı için bu ayarın açık olması gerekir. Aynı sekmenin alt kısmında Aging butonu yer alır.

Aging butonu, Zone Aging/Scavenging Properties penceresini açar. Bu pencerede Scavenge stale resource records seçeneği işaretlenir, No-refresh Interval ve Refresh Interval değerleri bu ortamda varsayılan 7 gün olarak bırakılır. Bu seçenek Zone için Aging'i etkinleştirir, ancak tek başına herhangi bir kaydı silmez. Silme işlemi sunucu seviyesindeki Scavenging çalıştığında gerçekleşir.
Pencerenin alt kısmındaki The zone can be scavenged after alanı, Zone'un hangi tarihten sonra temizlenebileceğini gösterir. Ekranda bu alanda 1/1/1601 2:00:00 AM değeri görünür. Bu bir tarih değil, henüz atanmamış bir değerdir. Seçenek yeni işaretlendiği ve ayar henüz kaydedilmediği için başlangıç zamanı hesaplanmamıştır.

OK butonuna tıklayarak ayar kaydedildiğinde DNS sunucusu bu alanı, Aging'in etkinleştirildiği andan itibaren Refresh Interval kadar ileri bir zamana ayarlar. Bu bekleme süresi, Aging kapalıyken Timestamp'leri güncellenmemiş Client'ların kayıtlarını yenileyebilmesi için tanımlanmıştır ve Zone ilk etkinleştirildiğinde toplu silme yaşanmasını engeller. Hesaplanan değer, ilerleyen bölümde PowerShell çıktısında görülecek.
Aynı ayarın Reverse Lookup Zone'larda da yapılması gerekir. Forward Zone'da Aging etkin olup Reverse Zone'da etkin olmadığında A kayıtları temizlenirken eski PTR kayıtları yerinde kalır ve Reverse Lookup sonuçları hatalı olmaya devam eder.
Sunucu Seviyesinde Scavenging Yapılandırması
Sunucu seviyesinde iki farklı ayar bulunur ve bunlar sıklıkla birbirine karıştırılır. İlki DNS Manager'da ABCISTSRVDC01 sunucu adına sağ tıklandığında görünen Set Aging/Scavenging for All Zones seçeneğidir.

Açılan Server Aging/Scavenging Properties penceresi, Zone seviyesindeki pencereyle aynı alanları içerir. Burada belirlenen değerler sunucuda yeni oluşturulacak AD-integrated Zone'lar için varsayılan Aging ayarları olarak kullanılır. Bu ortamda Scavenge stale resource records seçeneği işaretlenir ve Interval değerleri 7 gün olarak bırakılır.

OK butonuna basıldığında Server Aging/Scavenging Confirmation penceresi açılır. Üst kısımda yeni AD-integrated Zone'lar için uygulanacak varsayılan ayar özetlenir. Altındaki Apply these settings to the existing Active Directory-integrated zones seçeneği işaretlendiğinde aynı değerler mevcut AD-integrated Zone'lara da uygulanır.
Bu ortamda seçenek işaretlenmiştir. Böylece _msdcs.abc.local Zone'u ve varsa AD-integrated Reverse Lookup Zone'lar da aynı Aging ayarlarını alır. abc.local önceki adımda aynı değerlerle yapılandırıldığı için bu Zone'da bir değişiklik olmaz. Zone'ları farklı Interval değerleriyle yapılandırmak istenen ortamlarda bu seçenek boş bırakılmalıdır, aksi halde Zone bazında yapılmış ayarların üzerine yazılır.

İkinci ayar ise Scavenging işleminin kendisini çalıştıran ayardır. ABCISTSRVDC01 Properties penceresinde Advanced sekmesindeki Enable automatic scavenging of stale records seçeneği işaretlendiğinde sunucu, Scavenging period alanında belirtilen aralıkla Aging etkin olan Zone'ları tarar ve Stale kayıtları siler. Bu ortamda Scavenging period değeri 7 gün olarak bırakılmıştır.

Zone seviyesindeki Aging ayarı AD-integrated Zone'larda Active Directory içinde tutulur ve Replication ile tüm DNS sunucularına taşınır. Automatic Scavenging ise her DNS sunucusunun kendi yerel ayarıdır. Bu yüzden Scavenging'in tüm Domain Controller'larda açılması gerekmez. Tek bir sunucuda çalışması, temizlenen kayıtların Replication ile diğer sunuculara yansıması için yeterlidir.
AD-integrated Zone'larda Scavenging ile kaldırılan kayıt hemen silinmez. Önce Tombstone olarak işaretlenir ve bu durum Replication ile diğer Domain Controller'lara taşınır.
Yapılandırmanın PowerShell ile Doğrulanması
Yapılandırma tamamlandıktan sonra hem sunucu hem Zone seviyesindeki değerlerin beklenen şekilde uygulandığı kontrol edilmelidir. Get-DnsServerScavenging komutu sunucunun Scavenging durumunu, Interval değerlerini ve son Scavenging zamanını gösterir. Get-DnsServerZoneAging komutu ise Zone'un Aging durumunu, Interval değerlerini, ScavengeServers listesini ve Zone'un hangi tarihten sonra temizlenebileceğini döndürür.
Get-DnsServerScavenging -ComputerName "ABCISTSRVDC01"
Get-DnsServerZoneAging -Name "abc.local" -ComputerName "ABCISTSRVDC01"
İlk çıktıda ScavengingState değerinin True olduğu ve NoRefreshInterval, RefreshInterval ile ScavengingInterval değerlerinin 7 gün olarak uygulandığı görülür. LastScavengeTime alanı boştur, çünkü sunucu bu yapılandırmadan sonra henüz bir Scavenging döngüsü tamamlamamıştır.
İkinci çıktıda AgingEnabled değeri True olarak görünür. Daha önce grafik arayüzde 1/1/1601 olarak görünen alan artık AvailForScavengeTime değeri olarak 10/19/2026 1:00:00 PM gösterir. Aging 12 Ekim 2026'da etkinleştirildiği için bu tarih tam olarak 7 günlük Refresh Interval sonrasına denk gelir. Bu tarihten önce Zone üzerinde hiçbir kayıt silinmez.
ScavengeServers alanının boş olması ise Zone üzerinde Scavenging yetkisinin herhangi bir sunucuyla sınırlandırılmadığını gösterir.

Scavenging Yapacak Sunucunun Sınırlandırılması
ScavengeServers listesi boş olduğunda Automatic Scavenging açık olan her DNS sunucusu Zone'u temizleyebilir. Birden fazla DNS sunucusunda bu ayar açık olduğunda hangi sunucunun hangi kaydı ne zaman sildiğini takip etmek zorlaşır ve sorun giderme sırasında tüm sunucuların Event Log'larını taramak gerekir. Bu karmaşayı önlemek için Zone seviyesinde ScavengeServers listesi tanımlanabilir.
Bu liste tanımlandığında Zone üzerinde yalnızca listedeki IP adreslerine sahip DNS sunucuları Scavenging yapabilir. Diğer sunucularda Automatic Scavenging açık kalsa bile bu Zone'a dokunmazlar. Ayar grafik arayüzde bulunmaz ve PowerShell üzerinden yapılır. Komutlar DnsServer modülü yüklü bir sunucuda, Zone üzerinde yetkili bir hesapla çalıştırılmalıdır.
# abc.local Zone'unda Scavenging yetkisini yalnızca 10.10.10.100 adresli ABCISTSRVDC01 sunucusuna bırakır
Set-DnsServerZoneAging -Name "abc.local" -ScavengeServers 10.10.10.100 -ComputerName "ABCISTSRVDC01"
# Reverse Zone için aynı yapılandırma
Set-DnsServerZoneAging -Name "10.10.10.in-addr.arpa" -ScavengeServers 10.10.10.100 -ComputerName "ABCISTSRVDC01"
# Sonucun kontrolü
Get-DnsServerZoneAging -Name "abc.local" -ComputerName "ABCISTSRVDC01"
ScavengeServers listesine yazılan IP adresi Automatic Scavenging açık bir DNS sunucusuna ait değilse Zone hiç temizlenmez. Liste, Scavenging'in çalıştığı sunucuyla eşleşmelidir.
Silinecek Kayıtların Önceden Tespiti
Scavenging geri alınması zahmetli bir işlemdir. Silinen bir kaydın geri gelmesi için ilgili cihazın kaydını yeniden yapması gerekir ve bu cihaz kapalıysa ya da Dynamic Update yapamıyorsa kaydın elle oluşturulması gerekir. Bu yüzden Zone'un Scavenging başlangıç zamanı gelmeden önce hangi kayıtların silineceğini görmek doğru yaklaşımdır.
Aşağıdaki komut, Timestamp değeri No-Refresh ve Refresh Interval toplamından daha eski olan kayıtları listeler. Static kayıtların Timestamp değeri boş döndüğü için bu kayıtlar filtre dışında kalır.
# No-Refresh + Refresh toplamı varsayılan değerlerle 14 gündür
$Esik = (Get-Date).AddDays(-14)
Get-DnsServerResourceRecord -ZoneName "abc.local" -ComputerName "ABCISTSRVDC01" |
Where-Object { $_.Timestamp -and $_.Timestamp -lt $Esik } |
Select-Object HostName, RecordType, Timestamp |
Sort-Object Timestamp
Bu ortamda çıktı oldukça uzundur. Listenin büyük bölümü, Timestamp değeri 1/31/2026 10:00:00 AM olan SRV, A ve AAAA kayıtlarından oluşur. Bu kayıtlar _ldap, _kerberos ve _gc servislerine ait Site bazlı kayıtlar ile DomainDnsZones ve ForestDnsZones isimlerine ait adres kayıtlarıdır ve Antalya-Site, Izmir-Site, London-Site, Mumbai-Site, Ankara-Site ile HQ-Head-Office gibi Site'lara uzanır.



Bu kayıtlar Domain Controller'lar üzerinde Netlogon servisi tarafından kaydedilir. Çalışan bir Domain Controller bu kayıtları 24 saatte bir yenilediği için Timestamp değerleri hiçbir zaman 14 günden eski olmaz. Aylar önceki bir Timestamp, kaydı oluşturan Domain Controller'ın veya o kayıttaki IPv6 adresinin artık kullanılmadığına işaret eder. Yine de Domain Controller SRV kayıtları DC Locator sürecinin doğrudan parçası olduğu için Scavenging başlamadan önce bu kayıtların gerçekten kaldırılmış Domain Controller'lara ait olduğu doğrulanmalıdır.
Listenin son kısmında ise sunucu ve Client kayıtları görülür. ABCISTSYNCSRV01, ABCISTWKS02 ve ABCISTWKS03 kayıtlarının Timestamp değeri Ağustos 2026'dır. İlk adımda incelenen ABCISTWKS01 kaydı da 9/26/2026 2:00:00 PM değeriyle listededir. Bu cihazlar o tarihten beri kaydını yenilememiştir. Kalıcı olarak kapatılmışlarsa kayıtlarının silinmesi beklenen davranıştır.

ABCISTSYNCSRV01 gibi bir sunucunun bu listede yer alması ayrıca değerlendirilmelidir. Sunucu yalnızca bir süreliğine kapalıysa ve yeniden açılacaksa, Scavenging başlamadan önce kaydın Properties penceresinden Delete this record when it becomes stale seçeneği kaldırılarak Static hale getirilmesi gerekir. Cluster adı, yük dengeleyici veya uygulama kayıtları da bu kontrolde aynı şekilde ele alınmalıdır.
Manuel Scavenging ve Event Log Doğrulaması
Automatic Scavenging, Scavenging Period dolduğunda kendiliğinden çalışır. Döngünün sonucunu beklemeden görmek veya temizliği planlı bir bakım penceresinde yapmak için Scavenging elle tetiklenebilir. DNS Manager'da ABCISTSRVDC01 sunucu adına sağ tıklanıp Scavenge Stale Resource Records seçildiğinde döngü başlatılır.

Seçimden sonra sunucu üzerindeki tüm Stale kayıtların temizlenip temizlenmeyeceğini soran bir onay penceresi açılır. Yes butonuna basarak onay verildiğinde sunucu, Scavenging yetkisi bulunan tüm Zone'larda döngüyü hemen çalıştırır.

Aynı işlem PowerShell ile de yapılabilir.
Start-DnsServerScavenging -ComputerName "ABCISTSRVDC01" -Force
Manuel Scavenging, Zone'un Scavenging başlangıç zamanı geçmişse Stale kayıtları hemen siler. Döngü tetiklenmeden önce bir önceki adımdaki listenin kontrol edilmiş olması gerekir.
Döngünün sonucu DNS Server Event Log'una yazılır. Event Viewer'da Applications and Services Logs altındaki DNS Server log'u açıldığında bu ortamda 10/12/2026 2:02:53 PM zamanlı bir Event ID 2502 kaydı görülür. Mesajda DNS sunucusunun Scavenging döngüsünü tamamladığı, ancak hiçbir Node'u ziyaret etmediği belirtilir.

Bu sonuç, önceki adımda çok sayıda Stale kayıt listelenmiş olmasına rağmen beklenen davranıştır. abc.local Zone'unun AvailForScavengeTime değeri 10/19/2026 1:00:00 PM olduğu için manuel tetiklenen döngü bu Zone'u atlamıştır. Makalenin başında belirtilen koşullardan biri, yani Zone'un Scavenging başlangıç zamanının geçmiş olması henüz sağlanmamıştır.
Bu tarih geçtikten sonra çalışan ilk döngüde Event ID 2501 kaydı oluşur. Bu kayıtta ziyaret edilen Zone ve Node sayıları ile silinen kayıt sayısı yer alır. Silinen kayıt sayısı, önceki adımda listelenen kayıt sayısıyla tutarlı olmalıdır. Event kayıtları PowerShell ile de sorgulanabilir.
Get-WinEvent -FilterHashtable @{ LogName = 'DNS Server'; Id = 2501, 2502 } -ComputerName "ABCISTSRVDC01" -MaxEvents 5 |
Format-List TimeCreated, Id, Message
İlk başarılı döngüden sonra Get-DnsServerScavenging çıktısındaki LastScavengeTime alanı da dolar. Silinen kayıt sayısında beklenmedik bir fark varsa Interval değerleri, Zone'un AvailForScavengeTime değeri ve ScavengeServers listesi yeniden kontrol edilmelidir.
Interval Değerlerinin Planlanması
Varsayılan 7 + 7 gün değerleri çoğu ortamda doğru çalışır, ancak her ortam için uygun değildir. Interval değerleri belirlenirken kayıtların hangi bileşen tarafından ve hangi sıklıkla yenilendiği esas alınmalıdır.
Refresh Interval, kaydın yenilenme sıklığından kısa olursa cihaz açık ve çalışır durumdayken kaydı silinebilir. DHCP sunucusunun Client'lar adına kayıt yaptığı ortamlarda kayıt Lease yenilemesiyle birlikte güncellenir. Bu durumda No-Refresh ve Refresh Interval toplamının DHCP Lease süresinin altında kalmaması gerekir. Kısa Lease süreleri ve daha uzun Interval değerleri birlikte kullanıldığında kısa süreli kapanmalarda kayıt kaybı yaşanmaz.
|
Senaryo |
Değerlendirme |
|
Client'lar kendi kayıtlarını yapıyor |
DNS Client servisi kaydı 24 saatte bir yeniler. Varsayılan 7 + 7 gün değerleri genellikle yeterlidir. |
|
DHCP, Client'lar adına kayıt yapıyor |
Kayıt Lease yenilemesiyle güncellenir. Interval toplamı Lease süresinin altında kalmamalıdır. |
|
Uzun süre kapalı kalan cihazlar |
Tatil dönemleri veya mevsimsel kullanılan sistemler için Interval değerleri bu süreyi kapsayacak şekilde artırılabilir ya da kayıtlar Static yapılabilir. |
|
Hızlı değişen VDI veya Lab ortamları |
Daha kısa Interval değerleri Zone'un daha temiz kalmasını sağlar. Kısaltma yapılırken Replication yükü de hesaba katılmalıdır. |
Aging ve Scavenging, yapılandırıldıktan sonra DNS Zone'larının kendiliğinden temiz kalmasını sağlayan bir mekanizmadır. Yapılandırmanın güvenli şekilde devreye alınması için Static kalması gereken kayıtların önceden belirlenmesi, Scavenging'in tek bir sunucuya bırakılması ve AvailForScavengeTime tarihine kadar geçen sürenin silinecek kayıtları gözden geçirmek için kullanılması yeterli bir çerçeve oluşturur. Bu adımlar uygulandığında Zone içinde yalnızca gerçekten var olan cihazların kayıtları kalır ve isim çözümleme kaynaklı sorun giderme süreleri belirgin şekilde kısalır.
Bu makalede, DNS Server üzerinde Aging ve Scavenging mekanizmasının eski ve sahipsiz kayıtları nasıl temizlediği, Timestamp hesabının nasıl işlediği ve yapılandırmanın Zone ile sunucu seviyesinde nasıl ayrıştığı teknik bir zeminde ele alındı. Dynamic Update ile oluşturulan kayıtların Timestamp taşıdığı, Static kayıtların ise varsayılan olarak bu sürecin dışında kaldığı açıklandı.
No-Refresh Interval ve Refresh Interval değerlerinin bir kaydın Stale kabul edilme zamanını birlikte belirlediği, No-Refresh Interval'ın AD-integrated Zone'larda gereksiz Replication trafiğini önlemek için var olduğu görüldü. Zone seviyesindeki Aging ayarının Active Directory ile replike edildiği, Automatic Scavenging ayarının ise her DNS sunucusunun yerel ayarı olduğu ve bu iki ayarın zorunlu, Set Aging/Scavenging for All Zones seçeneğinin ise isteğe bağlı bir kısayol olduğu üzerinde duruldu.
Aging etkinleştirildiğinde Zone için hesaplanan AvailForScavengeTime değerinin ilk Scavenging döngüsünü Refresh Interval kadar ertelediği, bu tarihten önce tetiklenen döngülerin Event ID 2502 ile sonuçlandığı ve başarılı döngülerin Event ID 2501 ile izlendiği gösterildi. ScavengeServers listesi ile temizlik yetkisinin tek bir DNS sunucusuna bırakılması ve Domain Controller SRV kayıtları dahil Stale kayıtların PowerShell ile önceden listelenmesi de ele alındı.
Planlama tarafında Interval değerlerinin Client yenileme sıklığı ve DHCP Lease süresiyle uyumlu seçilmesi gerektiği, Reverse Lookup Zone'ların da Aging kapsamına alınması gerektiği ve kalıcı kayıtların Static tutulmasının DNS Scavenging yapılandırmasının güvenli devreye alınmasındaki yeri vurgulandı.
Faydalı olması dileğiyle...
Makale ile ilgili düşüncelerinizi ve sorularınızı aşağıdaki yorum kısmında paylaşmaktan çekinmeyin. Her katkı, içeriğin daha fazla kişiye ulaşmasını ve daha faydalı bir tartışma ortamı oluşmasını sağlar.