DNS Scavenging and AD

DNS Scavenging and AD

  • Comments 2
  • Likes

 

Recently I wrote a post about how, in an uncommon scenario, Active Directory integrated DNS could lose an entry regarding a domain controller in a global SRV record.   Here’s another aspect of AD integrated DNS which you can run into, particularly if you are spending energy tweaking your environment at all.

 

So let’s talk about DNS scavenging a bit.  DNS scavenging can be useful with respect to domain controllers because you do not want a domain controller that is no longer around (or perhaps has been moved, or maybe no longer covers that additional site using autositecoverage) to continue to have SRV records advertising that it is still available.  This would lead clients to try getting services to it when they no longer could or should.   That could lead to errors or latency at best on the client side as you might end up seeing a client in Chicago get authentication, for example, from a domain controller in New York.    Scavenging can help remove that record if it should no longer be there, based on the last time the DC that record represents tried to register it.  In other words, if it’s old it will be removed.

 

There are times, especially when you are troubleshooting a problem, when you may turn your DNS scavenging off for a particular DNS zone when you had it running previously in order to see if DNS scavenging is part of the problem.  In itself that is not a bad thing but there is something to keep in mind about how scavenging works before you disable scavenging.

 

As a little refresher, DNS scavenging refers to a time stamp on the record which was dynamically updated in order to decide whether that record should be removed or not.  Basically whether that record is “stale”.    Greater detail can be found here on Technet.

 

The most pertinent part of the above Technet article to this blog post is…

 

The server sets the time value to start scavenging on a per-zone basis whenever one of the following events occurs:

·         Dynamic updates are enabled for the zone.

·         A change in the state of the Scavenge stale resource records check box is applied. You can use the DNS console to modify this setting at either an applicable DNS server or one of its primary zones.

·         The DNS server loads a primary zone enabled to use scavenging.

·         This can occur when the server computer is started or when the DNS Server service is started.

·         When a zone resumes service after having been paused.

 

What am I getting at here?  Well, if you have been using scavenging for your DNS and then disable scavenging for some reason you are left with a zone full of records which do have time stamps. The DNS scavenging routine can look to these timestamps in order to decide whether they are stale or not.  During this period while scavenging is disabled, however, new registrations will not include the time stamp information since that is only done for DNS registrations which take place while scavenging is enabled on the zone.

 

So picture in your mind that you just turned scavenging off for a zone and that you leave it off for a certain number of days.  When you re-enable scavenging (and when scavenging runs next for that zone) those records which existed prior to disabling scavenging may be removed en masse if they match the re-enable scavenging criteria.  This could result in an effective outage if not taken into account as you plan to configure your DNS settings.

 

How do you plan for this?  Well, the DNS scavenging formula to keep in mind is

 

Record time stamp + No-refresh interval for zone + Refresh interval for zone

 

If the above sum of time is greater than the current DNS server’s time then the record will be kept, but if the amount of time we’ve had DNS scavenging disabled is greater than the current servers time then the records would be removed.    

 

How can you deal with this if you must enable scavenging immediately in this situation rather than planning in advance?  Following re-enabling the zone scavenging setting, simply restart the Netlogon services on the respective domain controllers which are in danger of having their records removed.  This will cause the DCs to register their records dynamically with the updated timestamp.

 

Finally, I’ve gotten a good amount of email from folks recently via the blog.  I anticipate following up with everyone in the near future-I just wanted to let you all know that I’ve heard you but I’m not ignoring you!

 

 

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