"The zone can be scavenged after" keeps incrementing
What are you trying to do?
I'm trying to enable DNS scavenging on a DNS zone that has about a hundred stale DNS records.
What have you tried in order to make it happen?
I setup DNS Scavenging per everyone's favorite TechNet Blog post: Don't be afraid of DNS Scavenging. Just be patient.
I first disabled scavenging on all of our domain controllers:
DNSCmd . /ZoneResetScavengeServers contoso.com 192.168.1.1 192.168.1.2
I then enabled automatic scavenging on the DNS zone:
I then enabled DNS scavenging on one of the domain controllers:
I then found a few records that I expected to get delete with timstamps from a few years ago and ensured that that the Delete this record when it becomes stale and that time stamp was actually set:
Finally I reloaded the zone and waited 14 days (the sum of the Refresh + No-Refresh periods).
What results did you expect?
I expected to see a 2501 Event in the DNS server logs noting the deletion of a bunch of DNS records.
What actually happened?
Nothing happened. The Zone Aging/Scavenging Properties showed that the zone could be scavenged after 6/12/2014 10:00:00 AM last week. No 2501/2502 events were recorded. All of the records with "aged" time stamps are still present.
The date at which the zone can be scavenged after incremented another seven days to 6/18/2014 10:00:00 AM.
As I understand it until that date stays at least 14 days in the past nothing will ever even be eligible for scavenging let alone actually be scavenged.
The only 2501 events recorded in the event logs are ones that I have triggered by right clicking and selecting "Scavenge Stale Resource Records". They note that scavenging will try to run again in 168 hours which was this morning.
I have DNS scavenging enabled for a few months and have waited patiently for something to happen. I have reloaded the zone multiple times (which resets this timestamp).
What am I missing here?
Solution 1:
This is old, but I will throw out a few suggestions.
As I understand it until that date stays at least 14 days in the past nothing will ever even be eligible for scavenging let alone actually be scavenged.
I don't think so. The setup sounds correct and the records should be scavenged. Three things needed are scavenging is set for the zone, on a DNS server, and on resource records with a timestamp.
Obvious stuff first - check the security of the resource records. System and Enterprise Domain Controllers typically have Full Control. And no Deny entries.
I would check the version of dns.exe to ensure it is up-to-date. Both 2008 R1 and R2 have had bugs with how DNS records are tombstoned and scavenged.
Windows Server 2008 R1: 6.0.6002.23387
https://support.microsoft.com/en-us/kb/2962612
Windows Server 2008 R2: 6.1.7601.22893
https://support.microsoft.com/en-us/kb/3022780
I'm assuming the zone is AD-Integrated. If so, dnscmd.exe /zoneinfo zoneName reports a directory partition type of AD-Domain (or AD-Forest) 99.999% of the time. I've seen zones where the partition has been changed to something else, then changed back and something went wrong during that process, or was none of the expected values from the start due to how the domain controller was provisioned, or not all domain controllers reported the same partition type.
Check the fsmoRoleOwner attribute in ADSIEdit for the DC=DomainDNSZones,DC=domain,DC=com partition. DomainDNSZones and ForestDNSZones have the sixth/seventh fsmo role owners. If there was ever some damage in the past and a previous domain controller that owned the partition no longer exists, the fsmoRoleOwner attribute would contain 0ADel: and the guid of the previous domain controller. More information on correcting that is here:
http://blogs.technet.com/b/the_9z_by_chris_davis/archive/2011/12/20/forestdnszones-or-domaindnszones-fsmo-says-the-role-owner-attribute-could-not-be-read.aspx
Another situation that may interfere with normal operation is duplicate zones. Ace Fekay has an excellent writeup here:
http://blogs.msmvps.com/acefekay/2009/09/02/using-adsi-edit-to-resolve-conflicting-or-duplicate-ad-integrated-dns-zones/