Scavenging Stale DNS Records

How Win2K DDNS keeps its database clean

Because dynamic DNS (DDNS) and WINS are in many ways similar (both name-resolution systems maintain a database that lets the system find a machine's IP address, given the machine's name), I have a subliminal tendency to assume that all I need to do to plan for DDNS is dust off my Windows NT 4.0 knowledge about WINS servers and replace all mention of WINS with DDNS and all references to NT with Windows 2000. Although that bit of cognitive laziness isn't entirely incorrect, neither is it completely accurate. In "Win2K DNS," March 2001, I highlighted some of the differences between how WINS and DDNS add new records to their machine-name-to-IP-address databases. In this issue, I look at how DDNS lets you get rid of old records—stale records is the Win2K term—in its database.

Before you continue, however, you should know that DDNS offers two ways to store that database. The more traditional—and compatible with non-Win2K DNS servers—method is zone files, and the newer method is known as Active Directory­integrated zones. I limit this column to discussing traditional zone files.

A Time to Live
By default, when a machine registers its name and IP address in a DDNS database (i.e., the set of zone files that the DNS server stores), DDNS remembers that information forever. DDNS stores the information as a host record, also known as an A record. If a machine named mypc with an IP address of 100.100.20.17 is in a DDNS domain named acme.com, mypc's name record in the acme.com zone file would look like

mypc 1200 IN A 100.100.20.17

Translated, this record says that the machine named mypc.acme.com has an IP address of 100.100.20.17. The term IN stands for Internet and represents the class of the DNS record, and the A means that the record is a simple name-to-address record (DNS has many types of records).

The number 1200 in the name record is the Time to Live (TTL) value. The TTL value tells other DNS servers how long they can expect the address to remain valid. For example, mypc's TTL value of 1200 tells another DNS server that it can expect mypc.acme.com to still have the same address 1200 seconds (i.e., 20 minutes) from the time the DNS server reads the record. So, the other server doesn't need to recheck the address if the server needs the same information again within 20 minutes. However, the server shouldn't assume that the address information will remain correct beyond that time.

The DDNS server doesn't assign the TTL value; rather, the client computer (e.g., mypc) specifies the TTL value when the client computer registers its name with the DDNS server. Note that the TTL value doesn't tell the DDNS server to delete the A record after the TTL expires—the TTL is simply an instruction to other DNS servers advising them not to cache the A record for longer than the specified time.

And a Time to Scavenge
Let's assume that we boot mypc, which registers its A record with the primary DDNS server for the acme.com zone. Then, we shut down mypc and never turn it on again. A year later, that A record for mypc will still exist in the acme.com zone file because, by default, Win2K DDNS doesn't eliminate old records. But you can configure scavenging to change that behavior and direct Win2K's DDNS server to eliminate stale records of all types—not only A records.

To activate scavenging, you need to turn it on in several places. First, open the Microsoft Management Console (MMC) DNS snap-in and right-click the icon in the left-hand pane that represents your DNS server. Choose Set Aging/Scavenging for all zones, and select the Scavenge stale resource records check box in the Server Aging/Scavenging Properties dialog box. You'll see No-refresh interval and Refresh interval controls. I'll discuss these intervals later; for now, simply use the defaults. Click OK to clear the dialog box, then click OK again in the Server Aging/Scavenging Confirmation dialog box. Repeat these steps for each zone.

Assuming your DNS server is the primary DNS server for the acme.com domain, double-click the icon that represents the DNS server to see the Forward Lookup Zones folder. In that folder, you'll see another folder that represents the acme.com domain. Right-click the domain folder, choose Properties, and click Aging on the General tab. Again, select the Scavenge stale resource records check box and click OK, then click OK again.

Finally, right-click the icon that represents your DNS server, choose Properties, and click the Advanced tab on the resulting properties page. Select the Enable automatic scavenging of stale records check box, and you're finished.

Scavenging Periods and Refresh Intervals
Now, let's go back and look at what we did. If you visited all the dialog boxes that I described above, you might have noticed three time intervals: Scavenging period, No-refresh interval, and Refresh interval. (The Server Aging/Scavenging Properties dialog box contained only the no-refresh interval and the refresh interval, but that dialog box seems to apply only to new zones. The No-refresh interval and Refresh interval controls that appear on the dialog you raised by clicking Aging on the zone's Properties page seem to be the intervals that count.) Let's examine how these three intervals interact.

The scavenging period simply tells your DDNS server how often to look in its zone files for records that are old or that are for computers that haven't reregistered in a long time. You might have records that have been stale for years, but the DNS server won't delete them until the scavenging feature runs.

As I mentioned, Win2K DDNS lets you store a DNS zone's information in Active Directory (AD). Because AD replication can consume a lot of bandwidth, Microsoft was concerned that DDNS clients that frequently reregistered with DDNS would set off a lot of AD replication. Consequently, Microsoft incorporated the no-refresh interval into Win2K DDNS. Suppose you set the no-refresh interval to 5 days. If mypc registers its name and address with a DDNS server, that DDNS server will ignore mypc's attempts to reregister within 5 days. For example, if mypc registers at 9:00 a.m. Monday, it won't be able to reregister until 9:00 a.m. Saturday.

You can think of the refresh interval as defining the end of the no-scavenge period. Recall that scavenging runs at a regular interval, which you can specify. When the scavenging routine runs, it examines each record in a DNS zone and determines whether the record is stale. If it is, the scavenging feature deletes the record.

But what criterion does scavenging use to determine at what age a record becomes stale? When a record is older than the sum of the no-refresh interval and the refresh interval, the scavenging feature considers the record stale and deletes it. So, when you set No-refresh interval to 3 days and Refresh interval to 5 days, scavenging will delete records that are more than 8 days old.

Setting Intervals
You can set the scavenging period to any value you want. However, keep in mind that scavenging burns up CPU time. Thus, on one hand, the smaller the value (i.e., the more frequently you run scavenging), the more scavenging will slow performance. On the other hand, a larger scavenging interval lets stale records remain in the database longer. I'd err on the side of a larger value—say, 2 weeks or so.

On a network that's fairly stable, I suggest setting the no-refresh interval to 1 week or 2 weeks to minimize the morning rush to reregister with the domain's primary DDNS server. Set the refresh interval so that the sum of the no-refresh and refresh intervals (which I think of as the "mandatory retirement age") gives your system a chance to reregister.

Remember that the client, not the server, initiates reregistration, and ask yourself how often your system will try to reregister. PCs reregister with DNS whenever their DHCP leases are renewed; when the PC's static IP address changes; when you reboot the system; every 24 hours, if you leave the PC running for that long; or when you run the Ipconfig /registerdns command. So, if you reboot your PC every day, your PC will attempt to reregister every day. If your system is always running, it will reregister once a day. If you were to leave your system running and wait for a DHCP renewal, reregistration would occur in 4 days (half the default of 8 days for a DHCP lease under Win2K). But wait; if you left the system up all the time, the system would reregister every 24 hours without waiting for the DHCP lease to expire. Thus, the longest time that mypc would ever wait to try to reregister would be 1 day.

Of course, you don't want the intervals to be too short. For example, if you set mypc's no-refresh interval and refresh interval both to 1 hour, DDNS records would expire after 2 hours, leaving 22 hours before mypc tried to reregister. Obviously, that mandatory retirement age wouldn't work. The bottom line is this: No matter what value you choose for the no-refresh interval, make sure that the sum of the refresh interval and the no-refresh interval exceeds 24 hours.

Do all these ins and outs make DDNS seem ugly? It isn't, by WINS standards: WINS has more complications for you to worry about, including four intervals and tombstoning. Win2K DDNS can also scavenge reverse lookup zones, causing stale PTR records to expire. Overall, I'd say that DDNS is a good thing compared with WINS.