It Takes Two–DNS scavenging

It Takes Two–DNS scavenging

  • Comments 2
  • Likes

 

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

image

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

 

 

 

 

 

 

image

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

 

image

 

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
  • What are the consequences of enabling scavenging on more than one DNS server (e.g., multiple domain controllers that are in the same site, or in different sites)?

  • I do look here occasionally for comments - Looks I missed you for a long time. I am more active on http://blogs.TechNet.com/askpfeplat

    Answer to your question is that more than one can result in issue with multi-valued DNS records. SRV records are multi-valued. You are safe having 2 scavenging servers but should not have more. The issue with multi-valued objects is the last writer wins. So in theory, a multi value DNS record could be updated on two DNS servers and when they replicate the last writer will win and the other update will be lost. This is usually self healing since DCs refresh at frequent intervals. Here is a blog post from AskPFEplat that may help: http://blogs.technet.com/b/askpfeplat/archive/2012/07/09/the-case-of-the-missing-srv-records.aspx

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