DNS Scavenging and Aging on Windows Server

DNS scavenging Windows Server settings get enabled once, usually during a cleanup project, and then mostly forgotten until either nothing is ever removed (the zone keeps accumulating dead records for years) or something gets removed that shouldn’t have been (a service stops resolving on a Monday morning with no obvious cause). Both outcomes trace back to the same root: scavenging looks like a single checkbox, but it’s actually three settings that have to align, against a timing window that has to stay longer than how often your clients and DHCP leases actually refresh.

Microsoft’s own DNS aging and scavenging documentation calls scavenging “the most common culprit when DNS records go missing from DNS zones.” That’s not a hedge. Static-looking Windows machines still re-register every 24 hours by default, and if the combined aging window is shorter than that, valid records get deleted on schedule – not by accident.

How DNS Aging and Scavenging Actually Work

Two intervals control aging, both 7 days by default:

No-refresh interval – the window right after a record’s timestamp is set, during which the DNS server refuses to accept a refresh from the owning client. This exists purely to cut down on AD replication traffic; without it, every client re-registering every 24 hours would generate constant directory writes.

Refresh interval – opens once the No-refresh window closes. During this window the owning client is expected to re-register and reset the timestamp. A record only becomes eligible for scavenging after both windows pass – 14 days at default settings.

The scavenging period (also 7 days by default) is a separate timer on top of that. Eligibility doesn’t mean immediate deletion; deletion happens on the next scavenging cycle. Worst case at default settings, a stale DNS record can survive roughly three weeks before it’s actually removed.

Why operators get this wrong: the console makes scavenging look like one feature with one toggle. In practice it’s three separate switches that all have to be set correctly for anything to happen at all, and the interval math is what determines whether what gets removed is garbage or production.

DNS Scavenging Windows Server Settings: Record, Zone, and Server

DNS scavenging on Windows Server requires alignment at three levels, and Microsoft’s own setup documentation is explicit that all three matter:

1. Record level – the record must have a non-zero timestamp. Dynamically registered records get one automatically. Manually created static records have timestamp 0 and are permanently excluded, unless something later converts them (see the static-record trap below).
2. Zone level – aging must be enabled on the specific zone. This setting replicates with AD-integrated zone data, so it propagates to all DCs holding that zone.
3. Server level – at least one DNS server must have automatic scavenging of stale records turned on under the server’s Advanced properties. Unlike zone aging, this setting is per-server and does not replicate.

The most common beginner mistake, documented directly in Microsoft’s setup guidance, is enabling the server-level checkbox and assuming that’s sufficient, or enabling zone aging without ever turning on server-level scavenging. Either gap means nothing is scavenged, with no error and no indication anything is wrong – just a zone that quietly never cleans up.

LastScavengeTime (returned by Get-DnsServerScavenging) matters more than ScavengingState here. A server can report scavenging enabled while having never actually run a cycle, which is the first thing to check when “scavenging is on but nothing’s getting cleaned up.”

How to Enable DNS Scavenging on Windows Server

Via DNS Manager:

DNS Manager > right-click server > Properties > Advanced > Enable automatic scavenging of stale records. Then, per zone: right-click the zone > Properties > General > Aging, and check Scavenge stale resource records, setting the No-refresh and Refresh intervals.

Via PowerShell, the equivalent sequence:

That’s the mechanical sequence. The order that actually matters operationally – audit, then enable, then verify – is covered next.

Static Records and the Timestamp Trap

A record with timestamp 0 is permanently safe from scavenging. That covers anything created manually through the DNS console or PowerShell without dynamic registration: domain controllers, DNS servers themselves, DHCP servers, printers, load-balanced VIPs, and KMS host records (_vlmcs).

The trap is that this protection is not permanent by nature – it’s permanent only until something gives the record a timestamp. Two specific actions do this:

• dnscmd /ageallrecords stamps every record in the zone with a current timestamp, including records that were deliberately created static. There is no selective version; it’s all or nothing per zone, and the change is irreversible without deleting and recreating the affected records as static again.
• Deleting and recreating a record dynamically to “fix” something turns a previously static record into a dynamically timestamped one, silently moving it into scavenging eligibility.

Practical takeaway: before enabling scavenging on a zone for the first time, audit for records carrying a DNS record timestamp that shouldn’t have one.

Anything in that list that’s actually infrastructure (not a workstation or DHCP-leased host) should be converted back to static before scavenging goes live.

DHCP Lease Duration: The Number That Actually Matters

This is where most DNS scavenging Windows Server misconfigurations originate. Microsoft’s documented rule: Refresh interval + No-refresh interval must be greater than or equal to the longest DHCP lease in the environment.

The reasoning is direct. If the combined aging window is shorter than the lease, a record can age out and get deleted while the IP it points to is still actively leased to the same client, because the client hasn’t been due to refresh yet. Microsoft’s DNS troubleshooting guidance documents this exact scenario: a Refresh and No-refresh interval set against a server that only re-registers every 24 hours, weekly scavenging deletes the record, and the symptom is resolution failure overnight until the next working day’s traffic happens to trigger a re-registration.

Static-IP Windows machines re-register every 24 hours by default even without DHCP involved. That means the practical floor for the combined aging interval, regardless of DHCP, is 24 hours. Anything under that and you are scavenging machines that haven’t done anything wrong.

In practice: don’t tighten intervals below the default 7+7 unless you’ve specifically measured your environment’s shortest lease and confirmed the aging sum stays at or above it. Tighter intervals mean faster cleanup of genuinely dead records, but every hour shaved off the window is an hour closer to catching a slow-to-refresh client in the wrong place.

Check current Refresh/No-refresh values against your DHCP scope lease duration before any change.

Safe Rollout Sequence for DNS Scavenging

Enabling DNS scavenging on Windows Server for a zone that’s never had it before is not a single action – it’s a sequence, and skipping steps is how valid-record deletion incidents happen.

Why one server, not every DC: AD-integrated zone data replicates regardless of which server scavenges, so a single designated scavenger is sufficient. Running scavenging on multiple DCs at slightly different times creates a documented last-writer-wins conflict on the multi-valued record attribute, where a record deleted on one DC reappears because another DC’s copy hadn’t synced the deletion yet. The practical symptom operators report: deleted SRV records that “come back” days later with no obvious cause.

Confirming Scavenging Actually Ran

A server reporting scavenging enabled does not confirm anything was processed. Two DNS Server event log entries do:

• Event ID 2501 – a scavenging cycle completed and one or more records were deleted (the event includes the count)
• Event ID 2502 – a scavenging cycle completed and nothing was deleted

If audit/analytic logging is enabled, more granular events are available: Event ID 521 logs individual record deletions by scavenging, 552 and 554 mark the start and end of a cycle, and 567 logs which servers are designated as scavengers.

Practical takeaway: after enabling scavenging for the first time, check for 2501/2502 on the expected schedule (roughly No-refresh + Refresh + one scavenging period out). An unexpectedly high deletion count on a 2501 event is the signal to stop and check intervals against DHCP lease duration before the next cycle runs.

What Breaks When DNS Scavenging Is Misconfigured

Beyond the two failure modes already covered in depth (aging shorter than lease, static-record re-timestamping), a few additional patterns are worth knowing before they show up as a ticket:

Failed dynamic update on a DC, then scavenged SRV records. When a domain controller’s DDNS update to its own locator records fails for some reason, the scavenging process treats the unreached records as aged and removes them on schedule – which is the documented chain behind missing _msdcs SRV records and Netlogon 577x errors on affected clients. Microsoft also documents a related pattern around duplicate records sharing the same IP when scavenging intervals lag behind DHCP lease expiry.

Azure and cloud VMs with extreme lease durations. Azure-assigned DHCP leases default to 136 years. Half the lease renewal interval – the point at which a client is supposed to refresh – lands fifty years out, meaning Azure VMs functionally never refresh their own timestamp through normal lease behavior. Without a separate registration refresh policy, their records age out and get scavenged regardless of how the zone’s intervals are set. The fix is the Registration Refresh Interval Group Policy (Computer Configuration > Administrative Templates > Network > DNS Client > Registration Refresh Interval), set to roughly 24 hours, not left to lease-driven defaults.

Decommissioned-but-still-referenced records. A host taken offline stops refreshing and eventually scavenges out on schedule, which is correct behavior for a genuinely retired machine but a problem if something else (a script, a monitoring tool, a hardcoded config) still references that name.

Recovery: The Short Version

Full recovery procedures, including AD tombstone reanimation for records past simple re-registration, are covered in a dedicated article: DNS Scavenging Deleted Valid Records: Recovery and Prevention. The immediate options for a record that’s been scavenged in error:

• Live clients and member servers – ipconfig /flushdns then ipconfig /registerdns forces immediate re-registration
• Domain controllers – nltest /dsregdns re-registers all DC-specific DNS records (SRV, locator, CNAME) without a Netlogon restart
• Decommissioned-but-needed records, or anything not self-healing – restore from a zone backup, or reanimate from the AD tombstone if still within the tombstone lifetime (180 days on most modern forests, but verify; some forests default to 60 days if the attribute was never explicitly set)

Fix the underlying interval problem before re-registering. Otherwise the next scavenging cycle deletes the same record again.

Windows Server 2025 Notes

Scavenging mechanics are unchanged on Windows Server 2025: same intervals, same Event IDs, same Get-DnsServerScavenging / Set-DnsServerZoneAging cmdlets. dnscmd.exe still ships and still works, carrying the same long-standing “may be removed in a future release, prefer the DNS PowerShell cmdlets” notice it’s carried for years. What has changed is the surrounding tooling: WMIC is disabled by default (available only as an on-demand feature), VBScript is deprecated, and Windows PowerShell 2.0 is removed outright as of the September 2025 update. None of that touches DNS scavenging directly, but it breaks older audit scripts built around WMIC or VBScript wrappers for DNS data collection. Anything still relying on those should move to the DnsServer PowerShell module.

FAQ

Why isn’t DNS scavenging removing anything even though I enabled it?

Check all three levels: record timestamp, zone aging, and server-level scavenging. Most “scavenging does nothing” cases are a missing zone-level or server-level setting, not a deeper problem. Get-DnsServerScavenging and its LastScavengeTime field confirm whether a cycle has actually run.

How long does a stale DNS record actually survive before deletion?

At default 7-day Refresh, 7-day No-refresh, and 7-day scavenging period, a record can survive roughly two to three weeks past its last legitimate refresh before it’s removed. Eligibility and actual deletion are two different points in time.

Should every DC run DNS scavenging, or just one?

Just one. AD-integrated zone data replicates regardless of which server scavenges, and running it on multiple DCs causes documented deletion conflicts where records get removed on one DC and reappear because another DC’s copy hadn’t replicated the change yet.

Does DNS scavenging replicate through Active Directory?

Zone-level aging settings replicate with AD-integrated zone data, so every DC sees the same aging configuration. Server-level scavenging does not replicate – it’s a per-server setting, which is exactly why only one DC should have it enabled.

Can DNS scavenging delete static records?

Not directly. A record with timestamp 0 is never scavenged. It becomes vulnerable only if something gives it a timestamp first – running dnscmd /ageallrecords on the zone, or deleting and recreating the record through dynamic registration instead of as static.

How often should DNS scavenging run?

The scavenging interval defaults to 7 days and that’s a reasonable starting point for most SMB environments. Shortening it (to 1-3 days) speeds up cleanup of genuinely dead records once you trust the configuration, but it doesn’t change the underlying No-refresh/Refresh eligibility window – it only affects how soon an already-eligible record gets removed.

Is it safe to run dnscmd /ageallrecords?

Generally no, not on a zone with intentionally static infrastructure records. It timestamps everything in the zone, including records you created static on purpose, and that conversion is irreversible without manually deleting and recreating the affected records.

My Azure VM’s DNS record keeps disappearing. Why?

Azure VMs default to an extremely long DHCP lease, long enough that normal refresh behavior never triggers. Without a Registration Refresh Interval Group Policy forcing roughly daily re-registration, those records age out and get scavenged on a normal schedule even though the VM is still very much in use.

Final Thoughts

DNS scavenging on Windows Server is safe in the abstract and risky only in the specific: the mechanism itself is well documented and predictable, but it depends entirely on numbers – DHCP lease, client refresh behavior, zone aging settings – lining up correctly for a given environment. Get the alignment right and it quietly removes genuinely dead records for years without anyone thinking about it again. Get the interval math wrong, even by a few hours relative to a lease duration, and it removes records that are very much still in use, usually on a schedule nobody’s watching for.

For most SMB and homelab environments, the practical sequence is: audit first, enable with default or longer intervals on a single designated server, confirm a clean cycle before trusting it, and only then consider tightening. Treat the audit step as mandatory, not optional, regardless of how confident the zone looks.