obsolate DC _SRV enties appear again after deletion inside root Domain DNS Zone

Question

We have a global AD Forest with one Root Domain and 3 Child Domains for each region.

DNS _SRV entries of demoted DCs in the root Domains DNS Zone reappear after deletion.

There are several DC entries from one of our Child Domains.

These DCs where demoted the correct way. All the recommended actions have been done .. metadata cleanup check, Nameserver Tab in the forward and reverse Zones, Sites and services, DNS Zone entries cleaned... aso.

btw: I´m AD Admin for more than 20 years and I´m familliar with DC promotion and demotion.

Inside this child domain you don´t find any entry inside the DNS for those obsolate and demoted DC´s.

Only in the root Domain DNS Zone under

_tcp (_GC Service Location (SRV) (0)(100)(3268) DC-FQDN -static) and

forestdnszones

_tcp (_ldap Service Location (SRV) (0)(100)(389) DC-FQDN - static)

entries of the same DCs.

These DNS entries are also present from DC´s that are demoted the correct way more than 2 Years ago !

Is there a way to get rid of these ?

We are replacing all 2012R2 DCs with Win2022 DCs since a few month and now the ammount of obsolate DC objects increase.

Only inside the DNS Zone of the Root Domain of our forest these enties come back again after manual deletion.

Answer 1

I could manage it on my own ..

using the NetTools LDAP Browser to translate the Hexadezimal code to the according obsolate Domaincontroller.

this hexadecimal entry can be delted via ADSIEdit ...

Then the obsolate DC entries are gone ..

Nevertheless, thank you very much for the suggestions and food for thought. This problem has caused me sleepless nights...

BR

Michael

Answer 2

Dear Haugg, Michael -Spark,

We understand that despite following all recommended steps—including metadata cleanup, DNS zone verification, and site/service checks—SRV entries for previously demoted DCs continue to reappear under _tcp and forestdnszones. This behavior can occur if stale replication data exists across DNS-integrated zones or if scavenging settings are misaligned across domain controllers.

To address this, we recommend verifying that DNS scavenging is properly configured and enabled on all DNS servers in the forest, including those in child domains. Additionally, ensure that the root domain’s DNS zone is not receiving replicated data from legacy DCs that may still hold outdated records in their local cache.

You may also consider using dnscmd or PowerShell to script the removal of these static SRV records and monitor whether they regenerate from a specific source. If the issue persists, enabling advanced DNS logging may help identify which DC is reintroducing the records.

We appreciate your expertise and the proactive steps you've taken. Please let us know if you'd like assistance reviewing scavenging policies or tracing replication sources.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

Best regards,

Harry Phan