DNS Scavenging internals (or what is the dnsTombstoned attribute) for AD Integrated zones

 

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!

dnsTombstoned attribute

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,

-Michael.

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  Nice article.

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  March 07, 2011
  The comment has been removed

• Anonymous
  March 25, 2011
  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 :)

• Anonymous
  May 09, 2011
  absolutely very well written off and expalined in details. thanks,

• Anonymous
  July 22, 2011
  The comment has been removed

• Anonymous
  June 26, 2013
  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?

• Anonymous
  September 19, 2015
  you can try try this free online unix timestamp creator(http://www.online-code.net/unix-timestamp.html), you can get the current time stamp.
  

• Anonymous
  December 06, 2015
  Thanks, Michael!
  From your article all at once it becomes clear.