DNS aging and scavenging simplified

Introduced in Windows 2000, Dynamic DNS brought a process with it called DNS scavenging where it would not be needed in a perfect world -- but who lives in a perfect world?

Introduced in Windows 2000, Dynamic DNS brought a process with it called DNS scavenging where it would not be needed

in a perfect world -- but who lives in a perfect world? So before you spend time reading the rest of the article, let's see if it applies to you.

Have you ever pinged a machine by name, got a reply, but when you attempted to connect to it, you connected to a different machine name or could not connect at all? If you nodded your head in agreement or mumbled something about this happening to you, then this article may shed some light.

Still reading? Good. First, let me establish my bias in saying that all this information pertains to Active Directory Integrated Zones. That being said, let's establish some definitions before we continue.

* A -- This record maps the name of the machine (Host) to the IP address.

* PTR -- This record maps the IP address to the Host name.

Why scavenge? (I'm a pack rat!)
There are two parts of DDNS that we need to understand before we answer the question: DNS and DHCP.

  • DHCP process
    (Wait a second! I thought we were talking about DNS?) Before we go on about DNS, we first have to understand how DDNS works and why DHCP is important in this process. Dynamic DNS registration happens at two places, either the DHCP client or the DHCP server. It all depends on configuration and client type. For the most part, Windows 2000 clients and above handle their own host name registrations, while the DHCP server handles the PTR registration, except in the case of statically assigned IP addresses, in which case the client will handle both the host name and PTR registrations. In other configurations, the DHCP server can be made to handle the host and PTR registrations. Other clients (NT4, 9x, among others), which are down-level clients, do not interact with the DDNS registration process. However, the DHCP server can be set to handle registration for these clients as well. Okay, now we have an idea of how these records are getting in DDNS. Unfortunately, the way records go in is a lot more efficient than the way they come out. By the way, read Larry Duncan's excellent article, "DNS for Active Directory -- A 10 Minute Primer," to understand what clients like to refresh their records.
  • DDNS process
    There's nothing to stop two records from holding the same IP address or the same host name. A common scenario where this is problematic is image-based workstation/laptop deployments. During a portion of the image process, the client will register as WIN2KIMAGE in DNS, for example, before having the machine name changed later down the process. Another image is started and WIN2KIMAGE is added again with a different IP address. Sooner or later, you end up with 50 PTR records pointing to the same name, WIN2KIMAGE. This same process happens under different situations where a machine will establish a different dynamic IP address, but for some reason, the old reverse-lookup record is not removed. Generally, the DHCP client and server helps clean up these records and, in some configurations, the DHCP server does it all. However, real world experience might tell you that this is not getting done effectively. When this clean up process does not occur properly, stale records reside in DNS.

This is where scavenging comes in. Scavenging will take stale records and delete them if they're beyond a set age. All records have an age. However, the age of a record is not considered until scavenging is turned on. Once scavenging is turned on, DNS does not calculate how old the record was prior to scavenging being enabled. (For more information on various triggers of the StartScavenging time frame, refer to the Microsoft DNS whitepaper.)

How do I use this scavenging stuff?
There are three different intervals that you need to understand before setting this up. These definitions come directly from the DNS GUI. Now that you're thoroughly confused, let's move on.

  • Scavenging period: No definition in GUI.
  • No-refresh interval: The time between the most recent refresh of a record timestamp and the moment when the timestamp may be refreshed again.
  • Refresh interval: The time between the earliest moment when a record timestamp can be refreshed and the earliest moment when the record can be scavenged. The refresh interval must be longer than the maximum record refresh period.

Did the italics help? If you're like me, your brain is twitching from all the circular circle wording words. To understand this a little better (without needing the mental capacity to solve a Rubik's Cube in two minutes), let's break down what the definitions really mean.

  • Scavenging period: This is easy enough to understand. This interval simply tells your DNS server how often to go out and check the zones for stale records. You can only get as granular as telling DNS to check every x number of hours or x number of days. By the way, this setting applies only to the DNS server, not the zones.
  • No-refresh interval: This a mechanism by which DDNS suppresses re-registration attempts. This helps keep replication of record information to a minimum. For example, using a default of seven days -- after DNSClient registers with DDNS -- means that all attempts to re-register for a period of seven days will be ignored. In other words, how long do you suspect records are validated and don't need to be refreshed?
  • Refresh interval: This definition took a while to grasp. It basically means from the point that the No-refresh Interval expires, the number of days DDNS will wait for the client to refresh its record before it becomes stale. Again, by default, this setting is also seven days. In other words, how long do you want to give clients a chance to register their record before it gets deleted?

We'll put all this together in an example that makes sense. In this scenario, the DNSClient does not re-register during the Refresh Interval period. Keep in mind, we are using a default of seven days.

  1. DNSClient registers with DDNS.
  2. No-refresh Interval starts (seven days).
  3. DDNS server will not accept re-registration attempts from this client for seven days.
  4. No-refresh Interval expires.
  5. Refresh Interval starts (seven days).
  6. DNSClient has seven days to refresh its records before the record is considered stale.
  7. Refresh Interval expires.
  8. Scavenging process removes record.

If a client re-registers a record, then the No-refresh Interval would start all over again. In the scenario above, with the default settings of seven days, a record would have to be greater than 14 days old before DDNS would scavenge it. This might work if your DHCP lease times are eight days (default). Otherwise, you may need to set the intervals closer to your DHCP lease times. Also, keep in mind the Scavenging Period only runs on the interval specified, which is also by default of seven days.

Scavenging jobs will use processor time. However, the scavenging process is a low-priority thread of the DNS service. This is great in making sure that scavenging does not utilize all the processing capacity, but it is horrible if your DNS servers are heavily utilized. As a low-priority thread, on a highly utilized DNS server, there's a probability that the scavenging thread may never run. Also, if it attempts to run the scavenging process during a time when the DNS server is highly utilized, it will miss the scheduled interval. It will not attempt to start running over and over, but instead will wait until the next scheduled interval (remember the default is seven days). As of writing this article, I haven't found a setting that can be adjusted to change what hour the scavenging process starts.

For the advanced pack rat
As I alluded to earlier, the Scavenging Period setting only applies to an individual DNS server. Unlike the other settings, which are replicated by AD, this setting is specific to the DNS server in question. With this in mind, not enabling this setting means that no servers are scavenging records. Aging of records is taking place (No-refresh, Refresh), but nothing else is going on. This is good for a variety of reasons. First of all, you don't necessarily want ALL your DNS servers to scavenge. You only need one to do it. It'll replicate the record deletions to the other DNS servers. This also allows for some other configuration options.

  • Small environment: Turn Scavenging Period on. This should be ample for you.
  • Larger environment: Here's another method you can use. Leave the Scavenging Period setting off. In other words, you don't want DNS servers scavenging records for you. Instead, use the DNSCMD.exe (Support Tools) with the /StartScavenging option and schedule it on a recurring basis, at the time frame you're looking for. It's probably reasonable to suggest night-time hours to have very little DNS registrations or queries going on.
  • Enterprise environment: Designate a DNS server to handle all scavenging and nothing else. This can be established by placing the DNS server in its own site so that clients do not refer to it for lookups or any AD functions. If that sounds like too much work, the SRV records for this DNS server can be stripped from DNS achieving the same effect.

This article first appeared in myITforum, the premier online destination for IT professionals responsible for managing their corporations' Microsoft Windows systems. The centerpiece of myITforum.com is a collection of member forums where IT professionals actively exchange technical tips, share their expertise, and download utilities that help them better manage their Windows environments, specifically Microsoft Systems Management Server (SMS). It is part of the TechTarget network of Web sites. To register for the site and sign up for the myITforum daily newsletter, click here.

This was first published in June 2004

Dig deeper on Domain Name System (DNS)

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

1 comment

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close