Zone Aging Enabled Without Server Scavenging Silently Preserves Stale AD DNS Records

Symptom

Name resolution intermittently returns IP addresses belonging to decommissioned or reassigned hosts inside an Active Directory-integrated DNS zone. Client machines that were rebuilt, renumbered or removed from the domain months earlier still resolve under their old names. DNS Manager shows “Aging” enabled on the zone properties, dynamic updates are configured as secure-only, and administrators report that scavenging “is on”, yet no stale records are ever removed from the zone.

False Assumption

The operator assumes that enabling the Aging checkbox in the zone’s Aging/Scavenging properties dialog is sufficient to activate scavenging for that zone. In the Windows DNS Server aging model this checkbox only marks records with a timestamp and sets the zone’s no-refresh and refresh interval values; it does not by itself trigger deletion. Scavenging is a separate server-level process that must be explicitly enabled on at least one authoritative DNS server for the zone, and that server must also be reachable and running when the scavenging interval elapses.

Root Cause

Windows DNS Server scavenging requires two independent settings to be true at the same time: zone aging (per-zone, controls whether records get a timestamp and how the refresh/no-refresh windows behave) and server-level scavenging (a per-server setting, plus a configured scavenging period, that determines whether the automatic cleanup task actually runs and against which zones). A zone can have aging enabled while every DNS server hosting that zone has server-level scavenging disabled, or has scavenging enabled but the scavenging period left at its default of 0 (disabled). In either case, records accumulate timestamps but are never evaluated for deletion. This is exactly the kind of unverified assumption UNI-023 requires making visible: the environment invisibly depends on a second toggle that many administrators never audit because the zone-level UI does not surface server-level scavenging state.

A second, related trap compounds this: if multiple DNS servers host the zone, only one server should run scavenging for it. If scavenging is enabled on more than one authoritative server without careful timing, or on none, results are inconsistent depending on which server last ran its scavenging cycle.

Impact

Stale records silently persist, so DNS continues resolving names to IP addresses that no longer correspond to the intended host. This creates duplicate-IP confusion when addresses are reassigned by DHCP, causes intermittent authentication and Kerberos SPN mismatches when decommissioned domain controllers or member servers still resolve, and can misdirect monitoring, backup or certificate-issuance systems that rely on DNS to reach the correct host. Because the failure is silent — no error is logged, no alert fires — it is typically discovered only when a name resolves to the wrong host during an incident, which is a debugging cost multiplier under time pressure.

Diagnosis

Confirm the two independent settings separately rather than trusting the zone properties dialog alone. First check zone aging state and the record timestamps; then check server-level scavenging state and the configured scavenging interval on each DNS server authoritative for the zone.

Correction

Enable server-level scavenging with a defined, non-zero scavenging period on exactly one authoritative DNS server for the zone, confirm the zone’s no-refresh and refresh intervals are appropriate for the environment’s actual dynamic-update cadence, and verify only a single server runs the automatic scavenging task to avoid inconsistent cleanup timing.

Validation

Validation succeeds when a deliberately aged stale test record is observed to be removed by the scavenging process within the configured scavenging interval, and when server-level scavenging state is confirmed consistent across all authoritative servers for the zone.

Rollback

If enabling scavenging removes records that are still required (for example static records lacking a refreshed timestamp), immediately disable server-level scavenging on the server where it was enabled, restore any deleted records from a DNS zone backup or AD-integrated zone replication from an unaffected domain controller, and re-enable scavenging only after confirming which records must be excluded or manually re-timestamped.

Prevention

Treat zone aging and server-level scavenging as two separate controls that must be audited together on every DNS-hosting server, document which single server is authorised to run scavenging for each zone, and require a stale-record test in an isolated environment before enabling scavenging on any production zone.