Clean Up Stale AD DNS Records: Scavenging Without Deleting Live Ones

Direct answer: In an Active Directory–integrated zone, stale dynamic records are only removed when aging and scavenging are both configured. Aging is a zone setting that replicates with the zone. Scavenging is a server setting that does not replicate and covers every eligible zone on that server; enable it on one DNS server per zone, after reviewing every zone it can reach. A record is deleted only when all of these are true:

• Its timestamp is not zero.
• Aging is on for its zone.
• The server is allowed to scavenge that zone.
• Timestamp + no-refresh interval + refresh interval is earlier than the current server time.

Static records have a zero timestamp and are never scavenged; they need an owner's review. Before enabling anything, list records of every type by timestamp and explain every old one. Then enable aging, wait out the protection period and turn on scavenging on a single server. Confirm with events 2501 and 2502, a test record you watch disappear, and direct queries to each authoritative server showing approved deletions gone and must-retain records present.

Why it matters

Clients and servers add their own records through dynamic update, and only an administrator or aging and scavenging removes them; AD replication never cleans them up. Over years of moves, re-addressing, DHCP churn and decommissioning, a zone builds up records for machines that no longer exist and old addresses for machines that do.

The visible symptoms are:

• A name resolves to an address that now belongs to a different machine.
• Authentication fails in odd ways.
• Monitoring tools report hosts that were retired long ago.

In Microsoft's example, client A's lease expires and its address goes to client B while client A's record remains, so two names point at one address. A connection to client A reaches client B with a Kerberos ticket meant for client A, and fails.

The opposite mistake is just as real. Microsoft warns that misconfigured scavenging deletes legitimate records, and users can then no longer resolve those names. The aim is to remove the dead records while keeping every live one.

This article is about steady-state hygiene in AD-integrated zones. Planned cutovers, where TTLs and resolver caches keep users on the old address for a while, are a different problem, covered in DNS Changed but Users Still Reach the Old Application.

How it works

Timestamps decide eligibility

Every record has a timestamp, rounded to the hour.

• Dynamic records get a non-zero timestamp when they are created by dynamic update. The timestamp records the last update or permitted refresh.
• Static records, added by hand in DNS Manager or loaded from a zone file, have a timestamp of zero and are never scavenged. Such a record can still accept a dynamic update to its data, such as a new IP address, but its timestamp stays zero.
• In DNS Manager (View > Advanced), the record property Delete this record when it becomes stale shows or sets aging; clearing it sets the timestamp to zero.

A trap: a dynamically registered record later made static can still be deleted by a dynamic update from its owner. If a "static" record keeps vanishing, check who has delete permission on it.

Two intervals and a scavenging period

With the defaults, a record that nobody refreshes becomes stale after 14 days. It is deleted at the next scavenging pass, so in the worst case it remains for about 21 days. Windows clients refresh their own records periodically. Microsoft's scavenging setup article says every 24 hours, and the troubleshooting article says statically addressed Windows machines register every 24 hours.

Protection built into the process

When aging is first enabled on a zone, or its aging settings change, the zone gets an available for scavenging time (shown in DNS Manager as "The zone can be scavenged after"). It is calculated as the current server time, rounded down to the hour, plus the refresh interval. This is a deliberate grace period. While aging was off, timestamps were not being replicated, so clients get one full refresh interval to refresh before anything can be deleted. The time is reset when:

• dynamic updates are enabled on the zone,
• the scavenge checkbox changes,
• the DNS service starts and loads the zone, or
• a paused zone resumes.

A scavenging pass also skips a zone in each of these cases:

• The server is not an authorised scavenging server for the zone.
• Aging is off on the zone.
• The available-for-scavenging time has not yet passed.
• The zone is paused, a cache zone or an offline-signed zone.
• The zone's directory partition has not replicated since the DNS service started.

The last condition prevents a domain controller that was offline for a long time from deleting records that look old to it but were refreshed elsewhere. A manual scavenge (Start-DnsServerScavenging, or Scavenge Stale Resource Records in DNS Manager) skips the schedule but none of these checks.

Where each setting lives in an AD-integrated zone

• Zone aging is set once and replicates with the zone to every DNS server that hosts it.
• Server scavenging does not replicate. It is set on each server, and Microsoft recommends exactly one scavenging server per zone. That gives one schedule and one set of logs, so deletions are predictable and traceable.
• Scavenge servers is an optional zone parameter (-ScavengeServers, or dnscmd /zoneresetscavengeservers) that limits which server IP addresses may scavenge the zone. If none are set, any authoritative primary server that has scavenging enabled can scavenge it.

When the last record at a name is scavenged, the DNS server marks the AD object (dnsNode) as tombstoned. Directory replication carries the deletion to the other servers.

Read-only checks

None of these was run for this article. All of them read configuration or records; none changes the zone. Querying needs rights to read the DNS server. Microsoft lists membership of DnsAdmins or local Administrators for managing a server, and Domain Admins for configuration changes to AD-integrated zones. Run the checks from a management host with the DnsServer module, using -ComputerName for the target server.

1. Current server and zone settings

# Read-only.
Get-DnsServerScavenging -ComputerName DNS01
Get-DnsServerZoneAging  -ComputerName DNS01 -Name 'corp.example.com'

Record these values:

• Server: the scavenging state and interval.
• Zone: whether aging is enabled, both intervals, the scavenge servers and the available-for-scavenging time.

Repeat Get-DnsServerScavenging against every DNS server that hosts the zone. Server scavenging does not replicate, so a forgotten server may already be scavenging on its own schedule. Also run Get-DnsServerZoneAging -Name 'corp.example.com' against each of those servers and confirm they all show the same aging state, intervals and scavenge servers. A zone change is written once and replicated, so a setting you just wrote is not proof that every server has it yet.

Server scavenging is not per zone. Once enabled, a server's passes cover every zone on it where aging is on, the server is allowed to scavenge and the available-for-scavenging time has passed, whether or not you used -ApplyOnAllZones. Inventory the aging settings of every zone on the server you intend to use:

# Read-only. Aging settings of every primary zone on DNS01.
Get-DnsServerZone -ComputerName DNS01 |
    Where-Object { $_.ZoneType -eq 'Primary' -and -not $_.IsAutoCreated } |
    ForEach-Object { Get-DnsServerZoneAging -ComputerName DNS01 -Name $_.ZoneName }

Every zone with aging on and no scavenge-server list that excludes DNS01 is in scope of DNS01's first pass. Write these results down: they are the prior state you restore on rollback.

2. Is anything already scavenging?

In the DNS Server event log on each server, look for:

• Event 2501: a pass ran and deleted records.
• Event 2502: a pass ran and deleted nothing.

The newest of these events plus the scavenging period gives an estimate of that server's next pass; the event is logged when a pass completes, not when it starts. If DNS Server audit logging is available, Microsoft documents events for:

• 521: a record deleted by scavenging.
• 552: start of a scavenging cycle.
• 554: end of a scavenging cycle.
• 567: the scavenge servers.

Any 2501 on a server you did not expect to be scavenging is the first thing to explain.

3. List records by age

Get-DnsServerResourceRecord returns a Timestamp for each record. Static records show an empty or zero timestamp. A scavenging pass examines every record with a non-zero timestamp in each eligible zone, whatever its type, so the review list must cover all types: A, AAAA, PTR, SRV, CNAME and any others. This read-only sketch lists every timestamped record older than a chosen age, keeping the type and full record data so an owner can review it and you could re-create it:

# Read-only. Lists every timestamped record older than 21 days, all types,
# with type, TTL and full record data, and saves it for review.
$zone   = 'corp.example.com'
$cutoff = (Get-Date).AddDays(-21)
Get-DnsServerResourceRecord -ComputerName DNS01 -ZoneName $zone |
    Where-Object { $_.Timestamp -and $_.Timestamp -lt $cutoff } |
    Sort-Object Timestamp |
    Select-Object HostName, RecordType, Timestamp, TimeToLive,
        @{n='Data';e={($_.RecordData.CimInstanceProperties |
            ForEach-Object { "$($_.Name)=$($_.Value)" }) -join '; '}} |
    Export-Csv -Path ".\aged-$zone.csv" -NoTypeInformation

Run it for every zone the change can affect: the forward zone, the reverse lookup zones (in-addr.arpa, ip6.arpa) whose PTR records the same clients register, and every other aging zone on the scavenging server (see Stage 3). Adding -RRType A gives a smaller diagnostic view, but it is not the review list. Pick a cut-off longer than the intended no-refresh plus refresh. The output is a review list, not a deletion list.

4. List the static records

# Read-only. Records with no timestamp are static and will never be scavenged.
Get-DnsServerResourceRecord -ComputerName DNS01 -ZoneName 'corp.example.com' |
    Where-Object { -not $_.Timestamp } |
    Select-Object HostName, RecordType, @{n='Data';e={$_.RecordData | Out-String}}

Expect the zone apex records (SOA, NS) and records created on purpose for appliances, aliases and services. Each needs an owner who can say whether it is still right; scavenging never removes them.

5. Explain the oldest dynamic records

For each record in Check 3, use the questions from Microsoft's own setup procedure:

• Does the machine still exist?
• Can it register itself? Microsoft suggests testing with ipconfig /registerdns on the client. That command does change the record, so run it only on machines you manage.
• Who owns the record? See the record's Security tab.
• Was the record created by hand and later set to age?
• Is AD replication healthy?

Microsoft's rule is not to continue until every old record is explained, because the next phase deletes them.

6. Check DHCP lease length against the intervals

On the DHCP servers, read the lease duration of each scope that registers into this zone. For example, Get-DhcpServerv4Scope shows LeaseDuration; it is read-only.

Microsoft's own pages disagree on the direction. The troubleshooting article says refresh plus no-refresh should be greater than or equal to the maximum DHCP lease. The configuration article says the combined interval should be equal to or less than the lease. Neither inequality alone is a safety guarantee, because they guard against two different failures:

• Sum longer than the lease. An address can be leased to a new client while the old client's record is not yet stale. Microsoft's duplicate-address example uses an eight-day lease and the 7 + 7 day defaults: the address is reused on day eight and the old record cannot be scavenged for another six days, plus the wait for the next pass.
• Sum shorter than a live client's real refresh gap. A record whose owner is still alive but has not refreshed in time is deleted. Clients that are off for longer than the sum, or that refresh less often than you assume, are the ones at risk.

The duplicate-address article gives two ways to bring lease and intervals into line, lengthen the lease (14 days in its example) or shorten both intervals (4 days each), and recommends a one-to-three-day scavenging period with either. Both have costs, set out under Decision guidance. Choose from how your clients and DHCP actually refresh and who owns each record (by default the client, so DHCP cannot delete it), and test the design.

7. Look for machines with very long leases

Microsoft notes that Azure virtual machines have a lease of about 136 years. They renew their lease so rarely that their DNS timestamps can go stale and be scavenged. If your zone includes such machines, or any machine whose registration does not follow its lease, note it. The documented fix is the DNS client's Registration Refresh Interval policy.

Interpreting the results

Decision guidance

The following staged procedure follows the order in Microsoft's "Don't be afraid of DNS scavenging" article. With the defaults, it takes about four to five weeks. That time is deliberate: it is what lets you see what will be deleted before anything is. Microsoft's configuration article asks you to test the configuration in a lab and back up zone data before enabling scavenging in production; for an AD-integrated zone, the backup is your normal domain controller and DNS backup. Before Stage 1:

• Rehearse the stages on an isolated test zone.
• Confirm AD replication is healthy (repadmin /replsummary, repadmin /showrepl, both read-only).
• Record the prior server and zone settings from Checks 1 and 2 for every server and zone involved.
• Get the change approved for every zone the chosen server will scavenge, not only the one you are cleaning, or first restrict those zones' scavenge servers so the chosen server is excluded.

Stage 1: Set up (no deletions while server scavenging is off everywhere)

This stage deletes nothing only if Checks 1 and 2 showed server scavenging off on every server that hosts the zone. If any server already scavenges, its passes continue to apply to this zone once aging is on and the protection period ends.

1. Make sure only one server could ever scavenge the zone. Set the zone's scavenge servers to one chosen DNS server, and confirm that server-level scavenging is still off on that server.

powershell # Changes the zone setting. Domain Admins for AD-integrated zones. Set-DnsServerZoneAging -ComputerName DNS01 -Name 'corp.example.com' -ScavengeServers 192.0.2.10

2. Enable aging on the zone with the intervals you have chosen. Microsoft's configuration article says the 7-day defaults suit most environments, but align them with your DHCP leases (Check 6). The setup article suggests that a shorter no-refresh interval, with the refresh interval left at its default, scavenges more effectively. A shorter interval increases replication, because clients refresh more often.

powershell # Changes the zone setting; starts the protection period. Set-DnsServerZoneAging -ComputerName DNS01 -Name 'corp.example.com' -Aging $true ` -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00

3. Note the date. Today plus both intervals is when the review phase can start.

• Verification: Get-DnsServerZoneAging, run against every server hosting the zone after replication, shows aging enabled, the intended intervals, a single scavenge server and an available-for-scavenging time one refresh interval ahead. No server is scavenging, which Check 1 on every server confirms.
• Rollback: Restore the zone's recorded prior aging state, intervals and scavenge servers with Set-DnsServerZoneAging. If server scavenging was off everywhere, nothing has been deleted.

Do not use dnscmd /ageallrecords or Set-DnsServerResourceRecordAging -Recurse to stamp existing records. Microsoft warns that /ageallrecords puts a timestamp on every record in the zone, including the static ones you want to keep.

Stage 2: Review (the most important step)

After the intervals have passed, repeat Check 3 using the chosen interval sum as the cut-off. By now every live machine should have refreshed its record. Every record still older than the cut-off would be deleted by the first pass. Explain each one using Check 5. Fix registration for machines that are alive, and make records static on purpose where a timestamp should not apply. Keep two lists from this review:

• Approved to delete: every record still older than the cut-off, each with an owner's sign-off. Do not go on until every old record is either on this list or fixed.
• Must retain: the names that must survive, such as domain controller SRV records, critical servers and applications, and any record you just fixed or made static.

Making a dynamic record static is not a simple switch: no cmdlet clears an existing timestamp. Clear Delete this record when it becomes stale in DNS Manager, or remove the record and add it again without -AgeRecord, which briefly removes the name and changes its owner and permissions.

Stage 3: Enable scavenging on one server

Enable server scavenging only on the server named in the zone's scavenge servers, and only after the zone inventory from Check 1 shows that every other zone it may scavenge is approved or excluded:

# Changes the server setting on DNS01 only. Do not use -ApplyOnAllZones here
# unless you mean to change aging on every zone on the server.
Set-DnsServerScavenging -ComputerName DNS01 -ScavengingState $true -ScavengingInterval 7.00:00:00

Be careful with -ApplyOnAllZones and the DNS Manager option Apply these settings to the existing Active Directory-integrated zones. Both push aging settings to every existing AD-integrated zone on the server, not only the one you reviewed. Also note that -ScavengingState controls the default for newly created zones; a non-zero -ScavengingInterval is what enables scavenging on the server. Microsoft's own example sets both, as above.

Microsoft's setup procedure also suggests creating a test record set to age. Work out when it should disappear: its timestamp, plus both intervals, plus the time until the next pass. Event 2501 or 2502 and the scavenging period give only an estimate of the next pass, so treat the result as an observation window and check during and after it rather than at one exact time.

• Verification:
• Event 2501 lists deletions, or 2502 says nothing needed deleting.
• With audit logging, event 521 names each deleted record; compare them with the approved-to-delete list.
• The test record disappears within the observation window.
• After AD replication has completed (repadmin /replsummary), query each authoritative DNS server directly: records on the approved list are gone and every must-retain record is present. For example, Get-DnsServerResourceRecord -ComputerName DNS02 -ZoneName 'corp.example.com' -Name 'app01' or Resolve-DnsName app01.corp.example.com -Server DNS02 -DnsOnly, both read-only.
• A lookup through a client or caching resolver can return a cached answer until its TTL expires, so it is not evidence of what the zone holds.
• Rollback: 1. Restore the server's recorded prior scavenging interval; -ScavengingInterval 0 disables scavenging if it was off before. This stops further passes for every zone the server scavenges, not only this one, so agree it with the owners of those zones. Leave other zones' aging settings and schedules as they were. 2. Restore records that were wrongly deleted. A machine that is up can register again with ipconfig /registerdns. A record that should be static must be re-created by hand from your review list. 3. Restore from your DNS or AD backup only through your normal recovery process. Restoring an AD-integrated zone is not a single-record operation.

When to shorten the scavenging period

Microsoft's duplicate-address article suggests lowering the scavenging period to between one and three days, so that stale records do not wait up to a week once they become eligible. A shorter period means more frequent passes. Microsoft cautions that very frequent scavenging of large zones costs server performance.

DHCP registering on behalf of clients

DHCP can also register and remove records itself, so a record goes when its lease expires. This needs a dedicated DHCP service account; the alternative, the DnsUpdateProxy group, Microsoft calls less secure. Treat it as a separate design change, not part of enabling scavenging.

What not to do

• Do not enable scavenging on every DNS server "for redundancy". One server per zone keeps deletions predictable and auditable.
• Do not enable scavenging without first reviewing old records. That review is where Microsoft says the real work happens.
• Do not run dnscmd /ageallrecords. It ages static records you meant to keep.
• Do not set refresh plus no-refresh below 24 hours, or change it relative to your DHCP lease, without working through both failures in Check 6.
• Do not run a manual scavenge expecting it to skip the protections. It skips the schedule only.
• Do not delete static records in bulk on the strength of the age list. Static records have no age, and each needs an owner's decision.
• Do not use -ApplyOnAllZones when you meant to change one zone.

Limitations

• This covers Windows Server DNS with AD-integrated primary zones. Standard primary zones keep aging settings on the primary server. Secondary and stub zones do not support aging and scavenging.
• The Set-DnsServerScavenging reference gives the maximum no-refresh and refresh value as "8760 hours (seven days)". 8760 hours is 365 days, so the parenthesis appears to be wrong. Set-DnsServerZoneAging gives 8760 hours without it. This article does not rely on either maximum.
• Microsoft's guidance gives the refresh frequency of Windows clients as every 24 hours. Your clients may differ because of policy, so trust the age list over that assumption.
• The PowerShell age list is a review aid. On very large zones, consider the load of enumerating records against a busy server, and run the list at a quiet time.
• No timings in this article come from measurements. The four-to-five-week figure is Microsoft's estimate for the default intervals.
• Records registered by non-Windows systems, appliances or DHCP depend on those systems' own refresh behaviour. Check them individually.

Acceptance checklist

• [ ] Get-DnsServerScavenging and zone aging recorded for every DNS server hosting the zone; any unexpected scavenging explained.
• [ ] Every zone the chosen server may scavenge inventoried and approved or excluded; prior settings recorded.
• [ ] Rehearsed on an isolated test zone; AD replication healthy.
• [ ] Events 2501/2502 checked on every server.
• [ ] Static records listed and reviewed with owners.
• [ ] DHCP lease durations compared with refresh plus no-refresh; both failure modes considered.
• [ ] Zone scavenge servers restricted to one server.
• [ ] Aging enabled with recorded intervals; protection period date noted.
• [ ] Age list (all record types, forward and reverse zones) reviewed; approved-to-delete and must-retain lists signed off.
• [ ] Server scavenging enabled on the one designated server only.
• [ ] Test record removal predicted and observed; 2501/2502 (and 521 if audited) reviewed.
• [ ] Both lists checked on each authoritative server after replication; prior-settings rollback documented.

References

All accessed 2 November 2026.

• Microsoft Learn, "DNS aging and scavenging in Windows Server" (updated 23 September 2026): dynamic and static timestamps, four conditions for deletion, default intervals and scavenging period, 14 and 21 day examples, available-for-scavenging time and resets, zone skip conditions, tombstoning, one scavenging server per zone. https://learn.microsoft.com/en-us/windows-server/networking/dns/aging-scavenging
• Microsoft Learn, "Configure DNS aging and scavenging in Windows Server": permissions, prerequisites, non-replicating server setting, supported zone types, DNS Manager and PowerShell procedures, ApplyOnAllZones, protecting records, no cmdlet to clear a timestamp, events 2501, 2502, 4013, 4515 and 4521, combined interval ≤ lease, lab test and backup advice, direct queries to each authoritative server, event time as an estimate of the next pass. https://learn.microsoft.com/en-us/windows-server/networking/dns/configure-aging-scavenging
• Microsoft Learn, "Don't be afraid of DNS scavenging, just be patient": three places scavenging must be set, record timestamps, /ageallrecords caution, safety checks, staged setup with review phase, four-to-five-week estimate, prediction example. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-scavenging-setup
• Microsoft Learn, "Troubleshoot DNS scavenging issues": three-level configuration, static-converted records still deletable through DDNS, refresh + no-refresh ≥ maximum DHCP lease (the configuration article states the opposite inequality), audit events 521, 552, 554 and 567, under-24-hour scenario, replication skip, Azure lease and Registration Refresh Interval policy. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-scavenging-issues
• Microsoft Learn, "Troubleshoot multiple records being registered with the same IP address": DHCP lease versus scavenging scenario, Kerberos failure, three resolutions, suggestion of one-to-three-day scavenging period, DnsUpdateProxy caution. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-multiple-records-being-registered-with-the-same-ip-address
• Microsoft Learn, "Set-DnsServerScavenging": parameters, ScavengingInterval 0 disables, ApplyOnAllZones. https://learn.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserverscavenging
• Microsoft Learn, "Set-DnsServerZoneAging": Aging, intervals, ScavengeServers behaviour, primary zones only. https://learn.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserverzoneaging
• Microsoft Learn, "Get-DnsServerZoneAging". https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzoneaging
• Microsoft Learn, "Get-DnsServerResourceRecord": returned properties including Timestamp. https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresourcerecord
• Microsoft Learn, "Start-DnsServerScavenging": preconditions, Verbose lists deletions. https://learn.microsoft.com/en-us/powershell/module/dnsserver/start-dnsserverscavenging

Related articles

• DNS Changed but Users Still Reach the Old Application
• Static IP Lost After a VM Restore or Virtual NIC Change

• SQL Kerberos After Migration: Check SPNs and NTLM Use

• Duplicate IP or MAC Address After a VM Clone or Restore: Prove It, Contain It, Fix the Copy

• Windows DHCP Failover: Partner Down, Lease Conflicts and Recovery

Learning notes

1. A record is scavenged only if its timestamp is non-zero, aging is on for its zone, the server may scavenge that zone, and timestamp + no-refresh + refresh is in the past.
2. The defaults are 7 days, 7 days and a 7-day scavenging period, all disabled by default. A dead record becomes stale after 14 days and may remain for up to 21.
3. Zone aging replicates; server scavenging does not, and it covers every eligible zone on the server. Enable it on one server per zone, restrict the zone's scavenge servers to that server, and review every zone it can reach.
4. Static records have a zero timestamp and are never scavenged. Review them with their owners, and never run /ageallrecords.
5. Stage the change: enable aging, wait for both intervals, review every old record of every type into approved-to-delete and must-retain lists, then enable scavenging. Prove it with events 2501/2502, a test record and direct queries to each authoritative server.