Hello everybody, this is Michael again.
This time I would like to discuss the internal processing of DNS Scavenging.
As you know, setting up aging and scavenging for DNS Zones and Servers is something usually recommended in order to delete “old” records from the DNS and maintain it up to date. While the whole process is explained in several locations I have noted that the actual internals of what’s happening when the record is being scavenged isn’t explained anywhere… good thing I’m here :-).
Our records story begins with configuring Refresh/No-refresh settings on the zone and enabled scavenging.
The Refresh/No-Refresh settings explained
The default settings of Refresh/No-Refresh intervals are 7 days each, but the setting on the zone is disabled by default:
After you enable all subsequent DNS dynamic updates are registered in the DNS server with a timestamp on the record. (More information about dynamic updates can be found here - http://support.microsoft.com/kb/932464).
Now that we have the timestamp on the record we begin counting. First we count off the no-refresh interval, during which any update to the timestamp of the DNS record is discarded (please note: it’s only timestamp updates – if the client changes it’s IP address it IS updated). The reason for discarding the timestamp updates is to avoid unnecessary replication, just imaging if we have an Active Directory integrated zone with 40,000 machines and each updates it’s timestamp every 24 hours. There will be a lot replication just to cover the timestamp updates…
After we have finished counting the No-refresh interval (7 days by default) we begin counting the refresh interval. During the refresh interval we expect the client to update it’s timestamp, which if does happen we just go back to the beginning of counting the no-refresh time. If that doesn’t happen then we go for scavenging.
The following figure illustrates the No-refresh and Refresh intervals:
The Scavenging process
Now that are record wasn’t updated for Refresh + No-Refresh intervals it is called a stale record. When the scavenging process runs (which also happens at specific intervals) it scans all records in all zones hosted on the DC and checks whether the current time is later than the Timestamp + No-Refresh + Refresh Intervals.
In order to enable the scavenging process this is done on the server properties in the DNS console
Now the interesting part begins!
When the DNS server looks at the record and determines it can be scavenged (or when you delete a record from the DNS MMC manually) it doesn’t actually get’s deleted from the AD Integrated Zone but instead the dnsTombstoned attribute is changed to TRUE and it is deleted from the DNS server in-memory cache.
So in order to demonstrate the whole process we have a test record:
Our test record is a record called W2K8R2CL02, which has a timestamp which already elapsed it’s Refresh and No-Refresh intervals and is ready for scavenging. In order to track our record we have a look at it in adsiedit.msc to note it’s GUID.. here it is:
The GUID is ba0f16d4-c40d-49ad-aa24-efb9795f6ae.
The next thing that happens is the scavenging process. When the Scavenging process is run the record is deleted from the DNS in-memory cache, from the MMC snap-in and is not loaded by DNS again. But…. It’s still in the Directory..
Now we have the record not in the DNS server, but still in the directory, so how is it cleaned?
dnsTombstoned Records clean-up
The clean-up of these records is performed by the DNS server process well.
Everyday at 2AM (non-configurable) the DNS server scans all DNS integrated zones in AD and determines whether the tombstoned record is ready to be deleted. The default retention time of the tombstoned records is 7 days. This value can be changed by the DsTombStoneinterval value (dnscmd w2k8r2dc01 /config /DsTombstoneInterval value) or by editing the registry under HKLM\CCS\Services\DNS\Parameters Value Name:DsTombstoneInterval Value Type: DWORD). The value is in seconds.
At that point the DNS deletes the record.
Updates while the record is dnsTombstoned
If the client performs an update to a record, even though the record has already been scavenged, but is still in the Directory and wasn’t deleted completely the update is accepted and the dnsTombstoned record is changed back to not set, meaning the record will retain the same GUID and will be loaded by DNS.
Updates while the record is dnsTombstoned but the SID of the machine has changed
Think of the following scenario. The machine has crashed and was re-installed after 3 weeks. During those 3 weeks the record was already scavenged, but wasn’t still deleted from the AD Integrated zone. Now, if you use secured dynamic updates the permissions on the record are set explicitly for the specific machine (machine’s SID) which has registered it:
That means the machine that is currently trying to register the record doesn’t have permissions for the old record.
In that case, the DNS server automatically deletes the old record and creates a new record.
Here’s our record found by ldp in the deleted objects container:
That’s our record: objectGUID is ba0f16d4-c40d-49ad-aa24-efb9795f6ae.
And here’s the new record (note the GUID has changes):
That’s the story of a DNS scavenged record and several update scenarios.
Note: The default behavior for Windows 2008 R2 was modified and will be acting as if the SID of the machine has changed regardless of whether it's true or not. Meaning when a record update is sent to a DNS server hosted on a Windows 2008 R2 Domain Controller and the record's dnsTombstone=True the record is deleted regardless of the permissions issue described earlier. This was to fix the issue described in http://support.microsoft.com/kb/952087.
In certain cases (with many updates and low No-Refresh interval) this can cause issues. The resolution can be found in http://support.microsoft.com/kb/2548145/en-us.
Hope that makes some stuff a bit more simple and understandable.
Some references that can be useful:
DNS Aging and scavenging process explained - http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx
How to configure DNS Dynamic updates in Windows 2003 - http://support.microsoft.com/kb/816592
DNS Dynamic updates - http://technet.microsoft.com/en-us/library/cc784052(WS.10).aspx
dnscmd reference - http://technet.microsoft.com/en-us/library/cc756116(WS.10).aspx
Understanding aging and scavenging on technet - http://technet.microsoft.com/en-us/library/cc759204(WS.10).aspx
Auditing DNS records and deletions - http://blogs.msdn.com/b/anthonw/archive/2006/08/23/715983.aspx
Good luck with configuring aging and scavenging,
"After you enable all subsequent DNS dynamic updates are registered in the DNS server with a timestamp on the record."
Does this mean that before enabling the scavenging a timestamp is not registered to the dynamicaly registered records?
Although I had GuyTe explain the scavanging process to me, It's really nice to have it all written down and cleared up.
Tnx Michael :)
absolutely very well written off and expalined in details.
Thanks for this detailed explanation.
I've got a question regarding the process that starts a 2:00 AM to delelete dnsTombstoned older that 7 days from Active directory.
Does this process run on all DNS servers ? I would except that it's not the case otherwise it would produce a lot of useless replication activity. i.e deletion of same records being originated for every DC/DNS.
You are absolutely right. Having this process running on many DNS servers may cause a lot of replication and conflicts.
The process does run on every DNS server which has the scavenging process enabled.This is why it is recommended to enable this only on two DNS servers in the environment.
If more servers are enabled for scavenging (for various reasons) you can control which servers are allowed to scavenge a specific zone by using the dnscmd.exe /ZoneResetScavengeServers and specifying which servers can scavenge a zone.
Does anyone have any information about the correct minimal ACLs to expect on DNS records? I inherited an old DNS install and the ACLs are all over the place due to changes to the zone ACLs, etc., that no one knows why anymore. How do we backpedal?
what is the reason to just mark the RR with DnsTombstoned = TRUE instead of deleting the record immediately? I can imagine some reasons, such as decreasing replication traffic, decreasing number of lost-out DNTs etc. or USNs. But is the real reason?