7.5 Aging and Scavenging

Now let's shift gears a bit and discuss one other aspect of maintenance that may be applicable to some of your servers. If you have any zones with dynamic update enabled, they are prone to stale records. (See Chapter 11 for a description of dynamic update.) Stale records are A or PTR records that were dynamically added but were not properly removed when no longer necessary. Most DHCP clients—including Windows clients—don't release their addresses on shutdown, which means they don't send the corresponding dynamic update message to remove their A records (nor does the DHCP server send a dynamic update message to remove the PTR record). Imagine a transient host, such as a laptop, that receives but never releases an address, leaving A and PTR records in DNS. Microsoft refers to these records as stale, and the DNS server in Windows Server 2003 can track their age and remove, or scavenge, them when they are no longer necessary.

The DNS server knows a record is not stale when it receives a dynamic update request for it. A Windows 2000 or Windows XP host sends a dynamic update message for its A record (and PTR record, if configured with a static address) every 24 hours by default. These same Windows hosts also send dynamic updates on lease renewal. An update of an existing record is called a refresh. (Before sending the update to make any changes, clients actually probe for a record's existence by sending a dynamic update message with only a prerequisite section. The DNS server counts such a message as a refresh, too.) A refresh is the signal to the server that a particular client is still alive and using its records.

The idea behind aging and scavenging is to remove records that haven't been refreshed within a certain interval. The primary master server stores a timestamp for each resource record in zones with aging and scavenging enabled. Every time a record is created, modified, or refreshed, the server updates the timestamp with the current time. If the primary master is Active Directory-integrated, it replicates these timestamps to the other servers (since all primary masters may need to perform aging and scavenging). A large number of dynamic updates means a large number of refresh events and corresponding timestamp updates, which means a lot of replication traffic if the zone is Active Directory-integrated.

To reduce the replication burden of this algorithm, Microsoft introduced the concept of a "no-refresh" interval. After a record is refreshed and its timestamp is updated, the server will not process additional refresh events (nor update the record's timestamp) for the length of the no-refresh interval. Note that each record has its own refresh or no-refresh timer ticking away. The record can still be changed, though, which does cause its timestamp to be updated. Remember, a refresh is just a dynamic update that doesn't cause any changes^[3] because the records specified in the update are already present in the zone. The no-refresh interval is like a cooling-off period that cuts down on replication: since refresh events aren't recorded during this interval, a record's timestamp isn't updated and therefore doesn't have to be replicated.

^[3] Or the prerequisite check we described.

The DNS server's default refresh and no-refresh interval are both seven days. Aging and scavenging is enabled on a zone-by-zone basis. At a configurable interval, the server makes a scavenging pass to remove any stale records in zones enabled for aging and scavenging. Stale records have a timestamp older than the current time minus the no-refresh interval minus the refresh interval. Figure 7-5 shows the phases of a record from creation through refreshing to scavenging. Since this record was never refreshed, it's eligible for scavenging. Figure 7-6 corresponds to another record from a live client that is sending periodic dynamic updates to keep its A record refreshed. This record won't be scavenged.

Figure 7-5. Nonrefreshed record

Figure 7-6. Periodically refreshed record

7.5.1 Configuring Aging and Scavenging

Aging and scavenging is disabled by default since its improper use is dangerous. If you set the refresh and no-refresh intervals too low, records that aren't stale can be inadvertently removed. A global setting controls aging and scavenging for the entire DNS server. It's located on the Advanced tab of the server properties window, which is shown in Figure 7-7. The Scavenging period setting controls how often the server makes a scavenging pass through all authoritative zones.

Figure 7-7. Enabling aging and scavenging for an entire server

Once aging and scavenging has been enabled on a given server, you must still enable it for a particular zone. From the General tab of a zone's properties window, click the Aging button to produce a window like the one shown in Figure 7-8. Click Scavenge stale resource records to enable aging and scavenging for this zone. The refresh and no-refresh intervals are set on a per-zone basis.

Figure 7-8. Enabling aging and scavenging for a particular zone

In addition, a DNS server may be configured to apply the zone's values to all the existing and future zones.

7.5.2 When Scavenging Occurs

The server stores a parameter called StartScavenging for each primary zone, which is the time after which the zone is eligible for scavenging. A DNS server performs a zone-scavenging pass only if the current time is greater than StartScavenging. (In addition, scavenging must be enabled for the server and the zone, and dynamic update must be enabled for the zone.) The StartScavenging parameter is set to the current time plus the refresh interval of the zone when the following events happen:

• When scavenging is enabled for the zone

• When dynamic update is enabled for the zone

• When the zone is loaded

• When the zone is resumed

7.5.3 Other Notes on Aging and Scavenging

Static records (i.e., those added with the DNS console) are considered "permanent." They have a creation/refresh timestamp of zero and are ignored during a scavenging pass.

The DNS server needs to retain each record's creation/refresh timestamp across server restarts, which means writing this information to disk. For Active Directory-integrated zones, this information goes in—surprise!—Active Directory. For standard zones, the server has to store the information in the zone datafile. Thus, for standard zones with aging and scavenging enabled, the zone datafile format includes an extra field that is compatible only with name servers running on Windows 2000 or Windows Server 2003. An outbound zone transfer of a zone with aging and scavenging enabled is not affected, so you can still have other name servers as secondaries. But if aging and scavenging is enabled for a zone, you can't take the actual zone file from a Windows Server 2003 name server and load it on, say, a BIND name server.