DNS Aging and Scavenging

What Is DNS Aging and Scavenging?

Dynamic update lets a computer register its own DNS record the moment it boots. Nothing on the other side of that transaction removes the record when the computer disappears — a laptop that loses power mid-shutdown, a VM that’s deleted without ever running an OS-level deregistration, a server that’s decommissioned and just switched off. Left alone, DNS keeps answering queries for a host that no longer exists.

Think of aging as a sell-by date stamped on a record, and scavenging as the periodic check that throws out anything past its date. Neither one does anything on its own: aging just tracks the timestamp, and scavenging just deletes whatever aging has marked as expired. You have to enable both, and this feature covers Windows DNS Server going back to Windows 2000 — the intervals and event IDs below are unchanged through Windows Server 2022 and 2025.

This applies specifically to standard primary and Active Directory-integrated zones. Secondary and stub zones don’t support aging or scavenging at all — a secondary zone’s data is a read-only copy of whatever its primary sends it, so there’s nothing local to age. This post assumes the DNS Server role is already installed and zones already exist; for the role itself, zone types, and dynamic update, see Windows DNS Server.

How the Intervals Actually Work

Every dynamically-created record gets two clocks. The no-refresh interval starts the moment a record’s timestamp is set, and during that window the server ignores refresh attempts for that record entirely — it acknowledges them as successful without writing anything, purely to cut down on replication traffic from clients that re-register far more often than necessary. Once the no-refresh interval closes, the refresh interval opens, and only now can a client’s refresh actually update the timestamp. If nothing refreshes the record before the refresh interval also closes, the record is stale.

All four conditions have to be true before a record is actually removed. Miss any one — scavenging off, aging off on that specific zone, a record that was never dynamic, or the math not yet past the threshold — and the record stays untouched no matter how old it looks.

On an Active Directory-integrated zone, deletion isn’t instant either. AD DS stores every record for a name — A, AAAA, and so on — as values inside a single dnsNode object. When scavenging removes the last record for that name, the DNS Server service sets the node’s dnsTombstoned attribute to TRUE rather than deleting it outright, replicates that logical deletion to every other DNS server hosting the zone, and only then does normal AD directory cleanup remove the object permanently. This is the same tombstone lifecycle mechanism AD uses for deleted objects generally — it’s what lets replication catch up before the record is gone everywhere.

Why This Is Off by Default

Microsoft’s own guidance on this is unusually direct: enable aging and scavenging only after you understand every interval, because a misconfiguration deletes records that are still in use and leaves users unable to resolve them. The most common way this actually happens in practice is setting the refresh interval shorter than the DHCP lease duration — a client that only re-registers once a day gets scavenged out from under itself if the combined no-refresh-plus-refresh window is, say, four hours.

For what it actually looks like when this goes wrong in the other direction — scavenging never enabled at all, and a decommissioned host’s record lingering indefinitely — see Stale DNS Records After a Domain Controller Decommission.

Enabling Aging and Scavenging

Both the GUI and PowerShell paths configure the same two layers — aging on the zone, scavenging on the server — and neither is complete without the other.

In DNS Manager (dnsmgmt.msc), enable aging on a single zone by right-clicking it, choosing Properties, then the Aging tab, and selecting Scavenge stale resource records with the No-refresh and Refresh interval values you want. To apply aging to every zone at once — including zones that already exist — right-click the server name instead and choose Set Aging/Scavenging for All Zones, then check Apply these settings to the existing Active Directory-integrated zones on the confirmation dialog; without that box checked, the new settings only apply to zones created afterward. Server-level scavenging itself lives one level up: right-click the server, Properties, the Advanced tab, then Enable automatic scavenging of stale records with a scavenging period (7 days by default, 1 hour minimum).

# Enable scavenging on the DNS server: 7-day interval, applied to every existing zone
Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 -ApplyOnAllZones

# Enable aging on one zone with the default 7-day intervals
Set-DnsServerZoneAging -Name "corp.example.com" -Aging $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00

# Restrict which DNS server is allowed to scavenge this zone
# (Microsoft recommends exactly one scavenging server per zone)
Set-DnsServerZoneAging -Name "corp.example.com" -Aging $true -ScavengeServers 10.10.0.10

# Review current settings before or after changing anything
Get-DnsServerScavenging
Get-DnsServerZoneAging -Name "corp.example.com"

# Trigger an immediate scavenging pass instead of waiting for the next cycle,
# and see exactly what gets deleted
Start-DnsServerScavenging -Verbose

Protecting Records That Should Never Be Scavenged

Manually created records already get a zero timestamp and are exempt by default — that’s what makes a record “static” rather than “dynamic” from scavenging’s point of view. The exemption isn’t permanent for every record, though: if a record was created manually but later receives an authorized dynamic update, the server can assign it a nonzero timestamp during that update, which makes it eligible again.

For anything that must never be scavenged regardless — a domain controller’s own records, a load balancer VIP, a print server — open the record’s properties in DNS Manager and confirm Delete this record when it becomes stale is cleared. Clearing it forces the timestamp back to zero.

Monitoring Scavenging with the Event Log

Every scavenging cycle writes one event to the DNS Server event log, whether or not it actually deleted anything — that event is the fastest way to confirm scavenging is running at all, rather than inferring it from records slowly disappearing.

To work out when the next cycle runs, take the timestamp of the most recent 2501 or 2502 event and add the configured scavenging period. For AD-integrated zones specifically, cross-check replication health rather than assuming a record’s disappearance (or stubborn persistence) is a scavenging problem — repadmin /replsummary and repadmin /showrepl confirm whether the tombstone has actually propagated to every DNS server hosting the zone.

Aging and Scavenging Cheat Sheet

Common Mistakes and Fixes

Final Thoughts

Aging and scavenging are two of the few DNS settings that do nothing at all until you deliberately turn them on, and that’s by design — the failure mode of getting the intervals wrong is a name silently going unresolvable, which is a worse outage than the stale record you were trying to clean up. Test the intervals in a lab, back up zone data before the first production run, and watch event ID 2501 for the first few cycles before trusting it to run unattended.

Once it’s tuned to the environment’s real DHCP lease and client refresh behaviour, scavenging becomes the kind of maintenance that never needs attention again — which is exactly the point.