It Takes Two–DNS scavenging

 

Scavenging works great on Microsoft Active Directory Integrated DNS. So why does it get blamed for DNS issues? The reason is pretty simple and can be summarized with two words: Patience and Misunderstanding.

First let’s understand how it works. It takes two. Yes there two configurations to set and they are both needed for the scavenging to be automated. 

• Server Scavenging Must Be Enabled
  • Settings Do not replicate
  • Restart of DNS restarts countdown
• Zone Aging Must Be Enabled
  • Refresh/No Refresh settings replicate
  • Time stamps replicate if aging is enabled

• • • • • • Server Scavenging
            • Managed on DNS server properties
            • Not replicated to other servers
            • Initiates event log entry (2502)

 

 

 

 

 

 

• • • • • • • Aging Enabled
              • Managed on each zone’s properties
              • Refresh/No Refresh
              • Settings replicate
              • Time stamps replicate

 

 

 

 

 

So let’s talk about those 2 settings: since it takes two..

Scavenging Setting

Server scavenging should be looked at as an event in time that occurs every X days. Which 7 is the default value. So if a server is configured to scavenge records it will do so every 7 days like a scheduled task. A problem with this, is that the time restarts when the DNS server or service restarts. Therefore, if you reboot or restart the DNS service on your scavenging server, it will be 7 days out before it scavenges.

If aging is not setup, the scavenging event will still occur, but have nothing to do. For the scavenging to actually delete records it takes two and thus far I am only talking about the scavenging setting on the server. Remember, this does not replicate, meaning if you retire the scavenging server and do not select another, you are no longer scavenging records if this was you only scavenging server.

Moving on the the 2nd of “it takes two.”

Aging

Aging is independent of scavenging. You do not have to setup scavenging for the aging to work. In-fact, I would recommend setting up aging before scavenging so you can see what a scavenging server is going to see.

By default aging is disabled and with aging disabled, time stamps on the DNS records are not replicated. This should explain why Scavenging has nothing to do if aging is disabled. If aging is disabled but scavenging is enabled, the scavenging event will occur and simply skip each zone and log event 2501 in the DNS log stating it did its job and did not delete any records. Enabling aging opens the gates of replication for the DNS records, so that all DNS servers hosting the zone have updated time stamps and are candidates to be a scavenging server.

Keeping with the “It takes two” theme - Aging has two key settings: NO refresh and Refresh Intervals.

When you turn on aging DNS record timestamps begin to replicate. The NO refresh interval is there to dampen/reduce replication traffic. There is no need to keep accepting refreshes if the IP is the same and some user or service is refreshing the record. Default is 7 days. This means once a record is created/refreshed it will not accept a refresh to the time stamp for 7 days.

The refresh interval is the time DNS will accept a refresh to the time stamp. And actually the interval is open ended and will accept a refresh on any day past the NO refresh as long as it exists in DNS. The interval is there to provide a calculation on what is stale. The scavenging event will delete any record that is older than NO refresh + Refresh. By default that would be older than 14 days.

Great stuff. But you say you have everything setup correctly but you see records as old as 20 days and some real close to 21. What gives? What happens is this. If a record was just under 14 days old when scavenging occurred and the next scheduled scavenging event is 7 days out, then that would put that record at almost 21 days old when it would actually get deleted. This graphic below will depict this much better than my words and you can see it gets deleted on day 15:

 

 

One last discussion. Common mistakes with setting up scavenging.

1. Refresh interval too short – results in lost DNS records because clients have insufficient time to refresh their records
2. Not patient. When I work with engineers that are tasked with setting up scavenging. For some reason they feel the need to speed up the 7 day/ 7 day /7 day settings. Just remember if it hasn’t been setup for years, why today, does it have to be done fast pace all of a sudden.
3. Aging is zone by zone by zone and it replicates with its partners. You must setup aging on each individual zone if you want that zone to be scavenged. Don’t forget the reverse lookup zones.
4. Make sure the DNS servers accept dynamic updates
5. Make sure the clients are configured for automatic updates.
6. TEST IN LAB before making any production changes.
7. BACKUP your DNS prior to making any changes.
8. Monitor for event ID 2501 – make sure it is happening and deleting records.

To close out my fun with it takes two here is a summary.

• Scavenging still occurs with aging disabled on all zones, but will just skip every zone and log that it succeeded.
• Aging without scavenging only increases replication traffic. Aging will never delete a record by itself.
• With both disabled: well I think you know that answer.

Comments

• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  November 05, 2013
  The comment has been removed
• Anonymous
  November 19, 2014
  The comment has been removed
• Anonymous
  July 29, 2015
  @Mohamed fekry
  In this post I am trying to explain exactly what you asked - It takes two - meaning both the server and the zone configurations must be setup for it to work.
• 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.