Enabling DNS Aging Without Server-Level Scavenging Never Removes Stale Active Directory Records

Symptom

Stale A and PTR records for decommissioned hosts keep appearing in an Active Directory-integrated DNS zone weeks or months after the hosts were retired. Clients occasionally resolve a hostname to an IP address that has since been reassigned to a different machine, causing intermittent authentication failures, misrouted traffic, or connections to the wrong endpoint. The DNS Manager console shows the zone’s Aging tab enabled, so the team assumes cleanup is already happening automatically.

False Assumption

The administrator who enabled aging on the zone believed that switching on the zone property was the complete configuration needed to remove outdated records over time. In Windows Server DNS, zone-level aging and server-level scavenging are two separate, independently controlled mechanisms. Zone aging only stamps dynamically registered records with a timestamp so they become eligible for later removal; it does not, by itself, trigger any deletion. A separate server-level scavenging process must be explicitly enabled and scheduled before those aged records are ever evaluated for removal.

Root Cause

The root cause is that Active Directory-integrated DNS treats aging eligibility and scavenging execution as two independent configuration surfaces that share no automatic dependency. Enabling the zone’s AgingEnabled property sets the NoRefresh and Refresh intervals that govern when a record becomes stale, but the DNS server’s own ScavengingState remains disabled by default and must be turned on separately, on a per-server basis, with its own scavenging interval. Because the DNS console groups aging options visually near scavenging-sounding language, administrators reasonably but incorrectly treat the zone checkbox as the whole feature.

Impact

The practical impact is that decommissioned or reassigned hosts keep resolvable DNS records indefinitely, even though the zone appears correctly configured for lifecycle management. If an IP address is later reassigned to a new device through DHCP, clients and applications that still cache or resolve the old hostname can silently connect to the wrong system. This creates authentication anomalies, name-resolution inconsistencies between domain controllers, and a governance gap where DNS no longer reflects the actual state of the environment, which undermines confidence in DNS-based inventory and security tooling.

Diagnosis

Confirm the actual state of both settings before assuming either is active, using read-only queries only.

• Get-DnsServerZoneAging -ZoneName "corp.example.com" -ComputerName DC01 — confirms whether zone-level aging is enabled and reports the configured NoRefreshInterval and RefreshInterval values.
• Get-DnsServerScavenging -ComputerName DC01 — confirms the server-level ScavengingState and the last recorded scavenging run time. Repeat this on every DNS server that hosts the zone.
• Get-DnsServerResourceRecord -ZoneName "corp.example.com" -ComputerName DC01 | Where-Object { $_.Timestamp } — lists records that have an aging timestamp (static records have a null Timestamp). Compare the Timestamp against the cutoff date (today minus NoRefreshInterval and RefreshInterval) to see how many entries are already stale.

A likely finding is AgingEnabled reporting True on the zone while ScavengingState on the server reports False, which would confirm the two settings were never linked. Check every DNS server that hosts the zone, as scavenging may be enabled on some servers and not others.

Correction

The correction is to explicitly enable server-level scavenging with an interval aligned to the zone’s aging intervals. Scavenging is a server-wide setting: once enabled, it runs on every zone on that server that has aging enabled. It only has to be enabled on one DNS server that hosts the zone, but that server must be running when the scavenging period elapses, so choose one that is always on. Before enabling it, list the aging status of all zones with Get-DnsServerZone -ComputerName DC01 | Get-DnsServerZoneAging, and use Set-DnsServerZoneAging to disable aging on any zone that should not be scavenged. Confirm that static records have no timestamp (see the Timestamp query above), since any record carrying a timestamp in an aging-enabled zone can be deleted.

Take the backup first, then apply the change, ideally on a single pilot server and zone before extending it further.

Set-DnsServerScavenging -ComputerName DC01 -ScavengingState $true -ScavengingInterval 7.00:00:00

This is a state-changing operation: it does not delete any record immediately, but it starts a recurring process that will remove records once they exceed the combined NoRefresh and Refresh window. Before applying it, record the current scavenging settings (Get-DnsServerScavenging -ComputerName DC01) and export the current record set for the zone, for example with Get-DnsServerResourceRecord -ZoneName "corp.example.com" -ComputerName DC01 | Export-Clixml -Path C:\Backup\corp.example.com-records.xml. Export-Clixml retains the Timestamp property. A zone file export with dnscmd DC01 /ZoneExport corp.example.com corp.example.com.bak.dns (written to the DNS server’s %SystemRoot%\System32\dns folder) can supplement it, but it may not work for AD-integrated zones and does not preserve aging timestamps, so do not rely on it alone. Verify the files exist, and retain them as your only practical recovery reference, since scavenging deletion is not natively reversible.

Validation

Validation confirms scavenging is genuinely running and is only removing records that are actually stale, not records still in active use.

1. Re-run Get-DnsServerScavenging after the change and confirm ScavengingState reports True with a LastScavengeTime that updates after one interval elapses.
2. Compare the pre-change record export against the zone contents after one full aging-plus-scavenging cycle; only records older than NoRefreshInterval plus RefreshInterval should disappear, and no actively used host should be missing.
3. Query a recently decommissioned hostname with Resolve-DnsName and confirm it now returns NXDOMAIN instead of resolving to a reused address.

Rollback

Rollback for this change means disabling scavenging before it removes anything unexpected, since there is no native undo for records it has already deleted.

If validation shows active hosts losing records, immediately run Set-DnsServerScavenging -ComputerName DC01 -ScavengingState $false to stop further deletions (or restore the previously recorded settings), then re-register the affected hosts with ipconfig /registerdns on the client or by forcing a DHCP lease renewal. The pre-change export taken during Correction is the only reliable recovery source for records already removed; restoring from a domain controller system-state or Active Directory database backup is a last-resort option that requires a full, carefully scoped DC recovery procedure and should not be attempted casually.

Prevention

Test the aging-and-scavenging pairing on a single non-production zone or lab domain controller first, and only extend it to production once both intervals are documented and understood, rather than relying on whatever defaults happen to be present in the console. Keep a standing export of DNS records before any scavenging-related change, align NoRefreshInterval, RefreshInterval and the server scavenging interval deliberately rather than leaving them at whatever value the console last showed, and identify statically configured or non-dynamic-update hosts up front so they can be explicitly excluded from scavenging rather than discovered after they disappear. Treat DNS aging and scavenging as a single governed control, reviewed alongside other identity and infrastructure hygiene controls rather than as an isolated zone checkbox.

Related reading

• Active Directory Kerberos Logons Fail Because a Member Server Clock Is Skewed
• Active Directory Domain Controller Replication Failure
• Active Directory Certificate Services
• Active Directory