This article is intended as an extension of a blog on Aging and Scavenging by the MS Enterprise Networking Team.
In brief, Scavenging is used as follows:
Each record in a zone which has been dynamically registered with an MS DNS Server will have a Time Stamp. The Time Stamp is used in conjunction with the Aging Intervals to determine when a record is Stale. When a record is Refreshed the Time Stamp is updated. The Scavenging process will remove any Stale records it encounters within a zone.
If a system changes IP Address an Update is sent to DNS. An Update will ignore any No-Refresh Interval and update the record data as well as the Time Stamp.
Manually created records are not removed by the Scavenging Process, they have no Time Stamp value and therefore cannot be considered stale.
SOA and NS records tend not to be involved in the Scavenging Process as they are created by a different mechanism; they are not dynamically registered by default, instead they are automatically created.
There are several different systems or services involved with dynamic registration of DNS Records.
By default Microsoft DHCP updates DNS on behalf of each client. When DHCP is performing updates the clients will not register record directly with the DNS server (while using a lease from that DHCP server). If DHCP does not update on behalf of each client then the client will register directly (if capable, Windows 2000 or higher).
The DHCP server will attempt to register a record when a lease is granted. It will also Refresh the record when lease Renewal occurs. Renewal occurs half way through a lease, the client attempts to renew and extend its lease with the server.
For example, if the DHCP Lease is 10 days the DHCP Server will Refresh the record in DNS every 5 days and the client lease will extend every 5 days.
If more than one DHCP server is used each should be configured with specific credentials (DHCP Server Properties, Advanced, Credentials) so all DHCP servers can update all records created by all DHCP services. This prevents creation of duplicate records or failure to update existing records.
Using the DNSUpdateProxy group is a less secure alternative to setting fixed credentials. It should only be used as a last resort and ideally never if DHCP runs on a Domain Controller. Records added by members of the DNSUpdateProxy group allow Authenticated Users Full Control. This means that any user or system on the domain can update any record regardless of whether or not it belongs to them.
If a member of the DNSUpdateProxy group registers a record, and a client system later updates that record the security will be rewritten with the Client as the record owner. The DHCP server will no longer be able to modify the record.
DHCP Client Service
The DHCP Client service is responsible for performing updates in DNS for every client that is not updating via a DHCP Server. Clients with static IP addresses use this service to update Host (A) and Pointer (PTR) records in DNS. It is important that the service remains enabled regardless of how the IP Address is to be set.
The DHCP Client service will send a Refresh Request for both Host (A) and Pointer (PTR) records once every 24 hours.
A Refresh or Update request can be forced in two ways:
- Restart the DHCP Client Service
- Run "ipconfig /registerdns"
Rebooting the system will also force registration as doing so restarts the DHCP Client service.
The NetLogon service is used to update certain DNS Records for Domain Controllers. As with the DHCP Client service records are Refreshed once every hour.
A Refresh or Update request can be forced by restarting the NetLogon service.
The following records are updated by the NetLogon service:
- Service Locator Records (SRV)
- The CNAME record linking the GUID to the server name found under _msdcs.
- Host (A) records for DomainDNSZones and ForestDNSZones if the server hosts those partitions
- The Host (A) record for Global Catalogs found in gc._msdcs.
The records added by the NetLogon Service are stored in two files, netlogon.dns and netlogon.dnb. These are found under %SystemRoot%\System32\Config
(although only the .dns version can be opened). Modification of the contents of these files is not recommended.
It is possible to modify settings for the NetLogon Service, changing which records it registers. This can include preventing the service registering generic service records (prevents clients in remote sites finding the DC), and making a DC available to multiple sites.
Summary of Client Refresh Intervals
- Clustering: 24 Hours
- DHCP Client: 24 Hours
- DHCP Server: 50% of Lease
- NetLogon: 1 Hour
Working with Aging and Scavenging Intervals
The minimum value that should generally be considered for the Refresh Interval is 24 Hours (based on the refresh interval for systems with static IP addressing). Ideally allow a longer interval so each system has more than one chance to refresh a record.
The maximum lifetime of a dynamic record registered by a transient client is given by:
No-Refresh Interval + Refresh Interval + Scavenging Period
It is more difficult to establish the maximum possible lifetime for any DNS record. It can, perhaps, be described as follows:
No-Refresh Interval + n * (No-Refresh Interval + x) + Scavenging Period
Where "n" is the number of times a record is refreshed and x represents how much of the Refresh Interval was used before the client registered. If the client has a static IP and is always online x may range from 1 second to 24 hours. Otherwise the x is anything from 1 second to the maximum value of the Refresh Interval.
For low turnover networks reducing the number of changes in DNS may be desirable. Normally a combination of a longer DHCP Lease and a longer No-Refresh Interval is appropriate.
For high turn-over networks a shorter lease with a lower aging Intervals is more appropriate. Be mindful of the 24 hour minimum limit if the DNS zone is shared with clients using static addressing.
Scavenging occurs on a fixed cycle based on the Scavenging Period; the maximum will not always apply. A Record can be Scavenged at any time between the end of the two Aging Intervals and the maximum lifetime.
For small to medium networks the Scavenging process can be run once a day. the process will only ever clear out Stale records according to the Aging Intervals.
Automatic scavenging should be configured on a small number of servers (one or two perhaps) to ensure the use of the process can be effectively monitored.