11.3 Aging and Scavenging | DNS on Windows 2000


Team-Fly

	DNS on Windows 2000, 2nd Edition By Matt Larson, Cricket Liu
	Table of Contents

	Chapter 11. New DNS Features in Windows 2000

11.3 Aging and Scavenging

Zones with dynamic update enabled are prone to stale records; that is, A or PTR records that are dynamically added but not properly removed when no longer necessary. Most DHCP clientsincluding 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 2000 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 host sends a dynamic update message for its A record (and PTR record, if configured with a static address) every 24 hours by default. Windows 2000 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 ^[10] 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.

^[10] 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 11-7 shows the phases of a record from creation through refreshing to scavenging. Since this record was never refreshed, it's eligible for scavenging. Figure 11-8 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 11-7. Nonrefreshed record

Figure 11-8. Periodically refreshed record

11.3.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 11-9. The Scavenging period setting controls how often the server makes a scavenging pass through all authoritative zones.

Figure 11-9. 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 11-10. 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 11-10. Enabling aging and scavenging for a particular zone

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

11.3.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

11.3.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 insurprise!Active Directory. For standard zones, the server has to store the information in the zone data file. Thus, for standard zones with aging and scavenging enabled, the zone data file format includes an extra field that is incompatible with non-Windows 2000 name servers. An outbound zone transfer of a zone with aging and scavenging enabled is not affected, so you can still have non-Windows 2000 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 2000 name server and load it on, say, a BIND name server.


Team-Fly

Top