Govern Windows DNS scavenging as a deletion change, not routine cleanup

Source facts: scavenging is an automated delete decision

Microsoft’s Windows DNS aging and scavenging guidance describes aging as the timestamp-based process used to identify records that can become stale and scavenging as the process that removes eligible stale records. Stale records can consume storage, lengthen zone transfers, degrade DNS performance, and return outdated answers. The cleanup mechanism is disabled by default because an unsafe configuration can delete records that clients still need.

Aging and scavenging must be enabled at both the DNS server and the zone. Records also need an eligible timestamp. Dynamically registered records normally receive timestamps, while records created manually or loaded from a text zone file receive a timestamp of zero and are not scavenged unless an administrator changes that behavior. Microsoft warns that using dnscmd /ageallrecords can timestamp all records in a zone, including static records that should not be removed.

The no-refresh interval suppresses timestamp-only refresh writes while still allowing a substantive update, such as an address change. After that interval, the refresh interval allows a client or another service to renew the timestamp. Microsoft documents seven days as the default for each interval. A record becomes eligible for deletion only after its timestamp plus the zone’s no-refresh and refresh intervals is earlier than current server time and a scavenging cycle examines it.

Automatic scavenging also has a server period, seven days by default, with a documented minimum of one hour. Administrators can restrict an Active Directory-integrated zone to designated scavenging servers. The zone’s start-scavenging time is recalculated after events such as enabling dynamic updates, changing the scavenging setting, loading the zone when the DNS service starts, or resuming a paused zone, so deletion timing is not simply the interval displayed in one console field.

DSE recommendation: prove every registration path before enabling deletion

Treat the first scavenging deployment as a controlled service change. DNS is a shared dependency; a small record set can represent domain controllers, clusters, applications, security devices, or externally configured systems whose refresh behavior differs from ordinary Windows clients.

1. Inventory zones and records. Export each zone’s type, replication scope, dynamic-update mode, aging settings, scavenging servers, timestamps, static records, delegations, critical service records, record owner, and the system expected to register or remove it.
2. Map the writers. Identify records maintained by Windows clients, DHCP, clusters, domain controllers, appliances, scripts, IP-address-management tools, and administrators. Confirm credentials and ownership for DHCP dynamic updates and distinguish a valid long-lived record from an abandoned record.
3. Calculate from observed behavior. Compare DHCP lease duration, client DNS registration frequency, offline and roaming periods, remote-access patterns, maintenance windows, and appliance refresh behavior with the combined no-refresh and refresh intervals. Do not shorten defaults merely to make a cleanup test finish quickly.
4. Protect static intent. Review zero-timestamp records and document why each is static. Do not bulk-age an established production zone until every resulting deletion candidate has an accountable owner and an approved recovery path.
5. Pilot with containment. Select a low-risk zone or representative controlled record set, designate the intended scavenging server, capture the start-scavenging time, monitor registrations and timestamps through a complete interval, and review the expected candidate list before automatic deletion.
6. Monitor and recover. Review DNS Server events, deletion counts, resolution tests, AD replication where applicable, unexpected re-registration, and service incidents. Keep current zone and directory recovery procedures, escalation ownership, and a rapid way to restore an incorrectly deleted critical record.

Measure stale-record reduction alongside mistaken deletions, failed refreshes, duplicate registrations, unresolved owners, and DNS incidents. Reassess after DHCP changes, site or VPN redesign, cluster migrations, new appliances, directory changes, or altered lease durations. The safe outcome is not the smallest zone; it is a zone whose dynamic records age predictably while intentional records remain available and owned.

Official references

• Microsoft Learn, DNS aging and scavenging, March 24, 2025.
• Microsoft Learn, DNS scavenging setup.
• Microsoft Learn, Troubleshoot DNS scavenging issues, February 12, 2026.