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

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

  • Comments 8
  • Likes

 

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:

image

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:

Cc961420.CNCF45(en-us,TechNet.10).gif

 

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

image

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:

Record - Before Scavenging

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:

ADSI Edit - DNS record GUID

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..

image

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:

image

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:

LDP Search for deleted objects ObjectResult

That’s our record: objectGUID is ba0f16d4-c40d-49ad-aa24-efb9795f6ae.

And here’s the new record (note the GUID has changes):

image

image

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
  • "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?

    Thnx

  • 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,

  • Hi Michael,

    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.

    Thanks

    Philippe.

  • Hi Philippe,

    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.

  • Nice article.

  • 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?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment