Active Directory DNS Kayıt Silinmelerinin Takibi

Active Directory ortamında bir DNS kaydının beklenmedik şekilde silinmesi, özellikle uygulamalar ve etki alanı hizmetleri için ciddi erişim sorunlarına neden olabilir. Asıl ihtiyaç yalnızca kaydın kaybolduğunu görmek değil; hangi işlemle, hangi sunucuda ve mümkünse hangi güvenlik bağlamında silindiğini belirlemektir. Bu makalede eski ADSI Edit laboratuvarını koruyarak Windows Server 2022/2025 üzerinde izlenebilecek denetim yöntemlerini birlikte inceleyeceğiz.

Ekim 2026 güncellemesi: Makalenin ilk sürümü 17 Aralık 2013 tarihlidir. Orijinal 17 ekran görüntüsü korunmuştur. Eski arayüzlerin anlattığı AD denetim yöntemi ile Windows DNS Server Audit olaylarını birbirinden ayrı değerlendirmek gerekiyor.

DNS kaydı neden silinir?

Kaydı bir yönetici DNS Manager üzerinden silebilir; bir istemci veya DHCP sunucusu dinamik güncelleme ile kaydı kaldırabilir; yanlış yapılandırılmış Aging/Scavenging ise zaman damgası süresi dolan kayıtları temizleyebilir. AD-integrated zone kullanıldığında DNS nesnesinin Active Directory tarafındaki değişiklikleri ayrıca izlenebilir. Bu üç mekanizmanın olay izleri aynı değildir.

Hangi olay günlüğüne bakmalıyız?

Kaynak / Event ID	Ne gösterir?	Pratik kullanım
DNS Server Audit / 516	DNS resource record silinmesi	Manuel veya DNS sunucusu işlemleriyle gerçekleşen kayıt silinmesini inceleme.
DNS Server Audit / 517, 518	RRSET veya node düzeyinde silme	Tek kayıttan daha kapsamlı silmeleri izleme.
DNS Server Audit / 520	Dinamik güncelleme ile kayıt silme	İstemci veya DHCP kaynaklı güncelleme; olayda istek gönderen IP bulunabilir.
DNS Server Audit / 521	Scavenging ile kayıt temizleme	Yaşlandırma ayarlarının etkisini analiz etme.
Security / 4662	Directory Service Access işlemi	SACL ve uygun denetim ilkesi gerekir; tek başına kesin silme kanıtı değildir.
Security / 5136	AD nesnesinde değişiklik	dnsNode nesnesindeki dnsRecord veya dNSTombstoned değişimlerini izleme.
Security / 5141	AD nesnesinin silinmesi	SACL yapılandırıldıysa gerçek AD nesne silmelerini izleme; her DNS Manager silmesinde çıkmaz.

Bu tabloyu değerlendirirken kaydı silen işlemi ve kişiyi aynı şey sanmamak önemli. Dinamik güncellemeyi DHCP hizmeti veya bir bilgisayar hesabı yapmış olabilir. Olay günlüğündeki hesap, DNS kaydını kaldırmaya neden olan son kullanıcıyı her zaman doğrudan göstermez.

1. DNS Server Audit günlüğü ile silinen kayıtları izleme

DNS rolünün yüklü olduğu sunucuda Event Viewer üzerinden Applications and Services Logs > Microsoft > Windows > DNS-Server > Audit yolunu kontrol edin. Bu günlük DNS işlemlerini Security günlüğündeki genel AD nesne olaylarına göre daha anlaşılır kategorilerde gösterebilir.

İlgili DNS sunucusunda PowerShell ile günlük varlığını ve durumunu inceleyebiliriz:

Get-WinEvent -ListLog "Microsoft-Windows-DNSServer/Audit" | Format-List LogName,IsEnabled,RecordCount,MaximumSizeInBytes

Günlük adı ve özelliği sürüme/kuruluma göre doğrulanmalıdır. Günlük mevcutsa ilgili silme olaylarını aşağıdaki gibi sorgulayabiliriz:

Get-WinEvent -FilterHashtable @{
  LogName = "Microsoft-Windows-DNSServer/Audit"
  Id = 516,517,518,520,521
  StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated,Id,MachineName,Message | Format-List

Kayıt silme olayı 516 ile, dinamik silme 520 ile, scavenging 521 ile izlenebilir. DNS Audit kayıtlarının tutulma süresini üretim ortamının olay hacmine göre planlayın; uzun süreli inceleme gerekiyorsa Windows Event Forwarding veya SIEM ile merkezi depolama kullanın.

2. AD-integrated DNS zone üzerindeki nesneleri bulma

Orijinal makalede anlattığım yöntem, AD-integrated zone altında bulunan dnsNode nesnelerini ADSI Edit aracılığıyla izlemeye dayanıyordu. Önce zone üzerinde replication scope bilgisini kontrol ediyoruz. Bu bilgiye göre DNS nesneleri farklı naming context alanlarında bulunur.

DC=DomainDnsZones,DC=cozumpark,DC=com
DC=ForestDnsZones,DC=cozumpark,DC=com
CN=MicrosoftDNS,CN=System,DC=cozumpark,DC=com

İlk iki satır naming context köklerini, üçüncü satır ise legacy domain partition içindeki klasik DNS container yolunu gösterir. ADSI Edit üzerinde domain/forest partition için CN=MicrosoftDNS altına ilerleyin. Gerçek domain DN bilgilerini kendi ortamınıza uyarlayın.

3. 2013 tarihli ADSI Edit ve Group Policy laboratuvarı

Aşağıdaki ekran görüntüleri ilk makaledeki sırasıyla korunmuştur. Windows Server 2008/2012 arayüzlerine aittir. Bu adımların güncel karşılığı için sonraki bölümde Advanced Audit Policy Configuration ve SACL ayarlarını ayrıca açıklıyorum.

Eski makalede klasik Audit Policy yapılandırılıyordu. Yeni ortamlarda bunun yerine Advanced Audit Policy alt kategorileriyle çalışmak daha kontrollü sonuç verir.

SACL girişlerini değiştirmek, DNS verilerini değil denetlenecek erişimleri etkiler; yine de kritik directory partition ACL/SACL yapılandırmalarını değiştirmeden önce mevcut ayarları dışa aktarın ve kontrollü bir pilotta doğrulayın.

Orijinal laboratuvardaki Everyone + Success/Failure + Write all properties/Delete/Delete subtree seçimi yüksek olay hacmi oluşturabilir. 2026 için tüm DNS zone üzerinde geniş kapsamlı denetimi varsayılan öneri olarak kullanmıyorum.

4. Güncel Active Directory denetim ilkeleri

Domain Controller bilgisayarlarına uygulanan hedefli GPO üzerinde Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access yolunu açın.

• Audit Directory Service Changes: AD nesnesi oluşturma, değiştirme ve silme gibi işlemler için Success denetimi. 5136, 5137, 5141 bu kategoridedir.
• Audit Directory Service Access: Nesneye yapılan erişim ve yetki tabanlı işlemler için uygun Success/Failure seçimi. 4662 bu kapsamdadır.
• SACL: Yalnızca ilgili DNS zone veya nesnelerinde, izlenmek istenen özellik ve işlemler için sınırlandırılmış denetim girişleri tanımlayın.

Audit Directory Service Changes ilkesi tek başına yeterli değildir. İlgili nesnenin SACL kapsamı değişiklikle eşleşmiyorsa beklenen 5136/5141 olayı üretilmeyebilir. Eski audit kategorileriyle Advanced Audit Policy çakışmalarını da kontrol etmek gerekir.

auditpol /get /subcategory:"Directory Service Changes"
auditpol /get /subcategory:"Directory Service Access"

Bu komutları domain controller üzerinde çalıştırarak etkin denetim ayarını kontrol edin; GPO ayarına yalnızca bakmak gerçek uygulanmış sonucu garanti etmez.

5. 5136 mı 5141 mi? DNS silmenin kritik ayrımı

DNS Manager veya DNS API üzerinden AD-integrated DNS kaydı silindiğinde AD içindeki dnsNode nesnesi bazen fiziksel olarak silinmez; dNSTombstoned özniteliği TRUE olur. Bu durumda silme hareketinin AD tarafındaki karşılığı 5136 değişiklik olayı olabilir. ADSI Edit üzerinden nesnenin doğrudan silinmesi ise uygun SACL ile 5141 üretebilir. Yalnızca 5141 aramak, DNS Manager üzerinden gerçekleşmiş silmeleri kaçırmamıza neden olabilir.

5136 olayında ObjectClass: dnsNode, AttributeLDAPDisplayName: dNSTombstoned ve yeni değeri kontrol edebiliriz. Bunun dışında dnsRecord özelliğindeki değişimler ve DNS Audit olayları da birlikte incelenmelidir.

Get-WinEvent -FilterHashtable @{
  LogName = "Security"
  Id = 4662,5136,5141
  StartTime = (Get-Date).AddDays(-3)
} | Where-Object { $_.Message -match "dnsNode|MicrosoftDNS|dNSTombstoned" } |
  Select-Object TimeCreated,Id,MachineName,Message | Format-List

Yukarıdaki filtre olay mesajı üzerinden çalışan bir ilk inceleme örneğidir. Olay metni sunucu diline ve olaya göre değişebilir; sağlam bir SIEM korelasyonu için olay XML alanlarını esas almak gerekir. Yoğun domain controller ortamında doğrudan tüm Security günlüğünü taramak maliyetli olabilir; dar zaman aralığı ve merkezi sorgu kullanın.

6. DNS kayıt kaybında uygulanacak kontrol sırası

• Kaydın son olarak hangi DNS sunucusunda görüldüğünü ve zone türünü belirleyin. AD-integrated zone mu, dosya tabanlı zone mu?
• DNS-Server Audit günlüğünde 516, 517, 518, 520 ve 521 olaylarını arayın; kaydın adı, türü, zaman bilgisi ve varsa dinamik güncelleme kaynak IP adresini not edin.
• Dinamik güncelleme bulursanız DHCP DNS update yetkileri, bilgisayar hesabı ve secure dynamic update mekanizmasını inceleyin.
• 521 görürseniz Aging/Scavenging, no-refresh/refresh aralıkları, kayıt timestamp değeri ve scavenging yapan sunucuyu kontrol edin.
• AD-integrated zone için ilgili DC Security olaylarından 5136, 5141 ve gerektiğinde 4662 kayıtlarını karşılaştırın; dnsNode/dNSTombstoned alanlarını arayın.
• Farklı DC’lerde kayıt sonucu değişiyorsa DNS zone replikasyon kapsamını ve AD replikasyon sağlığını kontrol edin.
• Olaylar merkezi log sisteminde tutulmuyorsa günlüğün üzerine yazılmadan önce kanıtları dışa aktarın.

7. Merkezi izleme neden önemli?

Orijinal yazıda Windows olay günlükleri ile üçüncü parti denetim araçlarının farkından bahsetmiştim. Bu yaklaşım güncelliğini koruyor: Windows kendi başına temel denetim kayıtlarını oluşturabilir, ancak merkezi depolama ve korelasyon için Windows Event Forwarding, Azure Monitor/SIEM ya da başka bir denetim ürünü kullanmak gerekebilir. Her üçüncü parti ürünün hangi kaynağı (Windows Event Log, AD değişiklikleri, DNS Audit) topladığı ve olay üretimi için hangi ilkelere bağımlı olduğu ayrıca doğrulanmalıdır.

Burada amaç yalnızca silme işlemini görmek değil, olaydan sonra hangi servisin etkilendiğini ve kaydın neden geri geldiğini veya yeniden silindiğini de açıklayabilmek. Bu nedenle DNS Audit, AD SACL ve merkezi olay korelasyonu birlikte değerlendirildiğinde daha güvenilir sonuç verir.