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.
• Get-DnsServerResourceRecord -ZoneName "corp.example.com" -ComputerName DC01 | Where-Object { $_.Timestamp -ne 0 } — lists records that have an aging timestamp and are theoretically eligible for scavenging, so you can see how many stale entries already exist.

Typically this diagnosis shows AgingEnabled reporting True on the zone while ScavengingState on the server reports False, confirming the two settings were never linked.

Correction

The correction is to explicitly enable server-level scavenging with an interval aligned to the zone’s aging intervals, scoped to the zone already validated in diagnosis rather than applied blindly to every zone on the server.

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

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, export the current record set for the zone with Get-DnsServerResourceRecord and retain that export 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, 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.