DNS Scavenging Deleted Valid Records: Recovery and Prevention

When dns scavenging deleted records from your Windows Server DNS zone, the first priority is identifying exactly what was removed – not adjusting aging intervals or re-enabling scavenging. Export the current zone immediately, then check DNS Server Audit Event ID 521 to get a per-record list of what was scavenged. Dynamic client and domain-controller records can often be re-registered within minutes. Static records – servers, appliances, manually maintained aliases – need to be rebuilt from an export or restored from backup. This article covers each recovery path in order of urgency and complexity, then the root-cause corrections that prevent a repeat incident.

Before You Do Anything Else

Two actions before touching DNS configuration or running any registration commands. Whether dns scavenging deleted records from one zone or wiped dozens of entries across multiple zones, the sequence is the same.

Export the current zone state. This preserves what exists now as your baseline and gives you a comparison point to verify recovery completeness later.

The export file lands in %SystemRoot%\System32\dns\. Copy it off the DNS server immediately. For AD-integrated zones this export captures the DNS record data, not the underlying AD object structure – but it is the fastest usable inventory you have.

Do not run dnscmd /ageallrecords. This command assigns aging timestamps to every record in the zone, including records that were intentionally static and had no timestamp. Once timestamps are applied to those records they become eligible for scavenging. There is no bulk undo. Individual records can be returned to static by recreating them or clearing the stale-record flag in DNS Manager, but that requires knowing which records were affected – work you want to avoid adding to an active incident.

Confirm DNS Scavenging Deleted Records

Before investing time in recovery, confirm that scavenging is actually the cause. DNS records can disappear from replication failures, DHCP reconfiguration, and accidental deletion – each has a different fix.

Check the DNS Server Audit log first. Event ID 521 in the Microsoft-Windows-DNSServer/Audit channel records each individual scavenged record. This is the most direct evidence.

Each Event 521 entry shows the record name, type, and data that was removed. If you see a cluster of 521 events at a specific time, that is your scavenging run. Note the timestamp – you will cross-reference it with zone export comparisons and DHCP lease data. Microsoft’s Troubleshoot DNS scavenging issues documents the full audit event structure for each scavenging cycle event.

Related events in the same audit channel:

Event 2501 tells you scavenging ran and deleted something. Event 521 tells you exactly what. If you have 2501 without 521 events, check whether DNS debug audit logging was enabled before the incident – without it, per-record detail is unavailable and you will need to compare the current zone against a backup or export. For the full DNS Server event ID reference, see Windows Server DNS Event IDs Explained.

Verify scavenging is configured on this server and zone.

Scavenging requires both server-level enablement and zone-level aging enablement. If both are on, and you see 521 or 2501 events, scavenging is the cause.

Identify Which Records Are Missing

Not all DNS records recover the same way. When dns scavenging deleted records from a zone, the recovery path depends entirely on how each record was originally created. Classifying missing records before starting recovery saves time and avoids re-registration attempts that cannot succeed.

Compare the current zone state against the zone export you just captured, or against a pre-incident backup:

Cross-reference against the zone export or previous CSV. The difference is your recovery list. Classify each missing record:

Recover Records by Type

The recovery sequence below assumes dns scavenging deleted records that were previously valid – not records lost to replication failure or accidental deletion. Work through the categories in order: dynamic records first (fastest), static records last (manual work required).

Dynamic Client Records (Workstations and Member Servers)

These are the fastest to recover. Run on each affected client:

This triggers the client to submit a DNS dynamic update for its configured interfaces. In a standard domain environment with working dynamic update permissions, the forward A record returns within seconds. Check Event Viewer on the DNS server for dynamic update events to confirm.

PTR record recovery depends on who owns reverse registration. In environments where the client owns its own reverse registration, ipconfig /registerdns handles both. Where DHCP owns reverse registration (the more common configuration in DHCP-heavy environments), PTR records return when the DHCP server processes the next lease renewal or update – not from the client command alone.

If ipconfig /registerdns succeeds but the record does not appear in DNS, check:

Domain Controller Locator Records (SRV, CNAME, A)

DC locator records in _msdcs and the main zone are registered by Netlogon. Run on each affected domain controller:

This triggers Netlogon to re-register all DC locator records for the domain. Validate immediately after:

If nltest /dsregdns does not restore the records, restarting Netlogon forces re-registration as well – but it is a more disruptive action. Try the nltest command first.

DC SRV record loss causes authentication and LDAP lookup failures across the domain. This recovery step should happen before or alongside client re-registration when DC records are confirmed missing.

DHCP-Owned Records

Where the DHCP server registers DNS on behalf of clients (common in environments using DHCP option 81 or DHCP server-side update policies), recovery requires working through the DHCP server, not the clients directly.

First, confirm DHCP is configured to update DNS and that the credentials are valid:

Then trigger lease renewals on affected clients – the DHCP server will submit fresh DNS updates as part of the lease acknowledgment. For clients that cannot renew immediately, the DHCP server audit log at %SystemRoot%\System32\dhcp\ shows update attempts and failures.

DHCP Reconcile Scopes repairs inconsistencies in the DHCP lease database. It does not recreate deleted DNS records. Do not use it as a DNS recovery step.

Static Records (Manually Created)

Static records – those created manually in DNS Manager or via dnscmd with no aging timestamp – have no self-registration mechanism. When dns scavenging deleted records of this type, they must be rebuilt from your zone export, a pre-incident backup, or documentation. There is no automatic recovery path.

From the zone export file, identify each missing static record and re-add it. In DNS Manager: right-click the zone, New Host (A or AAAA), and leave “Create associated pointer (PTR) record” checked if needed. After creation, verify the record has no aging timestamp by checking its properties – the “Delete this record when it becomes stale” checkbox should be unchecked for intentionally static records.

Alternatively via PowerShell for A records:

Records added this way are static by default – they carry no aging timestamp and are not eligible for scavenging.

The AD-Integrated DNS Tombstone Window

For AD-integrated DNS zones, a scavenged record is not immediately purged from Active Directory. The DNS node object transitions to a tombstoned state and is retained for a period controlled by the DsTombstoneInterval registry value (default: 7 days, set in days on the DNS server). Microsoft documents this lifecycle in detail in the DNS logging and diagnostics reference.

During this window, the object exists in AD but is not visible in normal DNS administration views. A fresh dynamic update for the same record name can recreate the DNS data, potentially reusing the same AD object structure.

This is a useful forensic insight – it explains why re-registration often succeeds quickly in AD-integrated zones and why a zone export shows fewer records than AD actually holds at that moment. It is not a native undo feature. There is no supported DNS Manager or PowerShell operation to “untombstone” a DNS record. Manually editing the dNSTombstoned AD attribute is not a supported recovery method and should not be attempted in production. The tombstone window exists to allow AD replication to propagate the deletion – not to provide a recovery window after dns scavenging deleted records incorrectly.

After the tombstone retention period, the AD DNS object cleanup interval removes the object permanently. At that point, re-registration creates a completely new object.

Restore from Export or Backup

Zone Export Rebuild

If the zone export you captured at the start of the incident is insufficient (because the export ran after deletion), compare it against a scheduled export or backup copy. The DNS zone export format is a standard zone file – each record is readable and can be re-imported or used to manually reconstruct missing records.

For bulk reconstruction of static records, a tested PowerShell import script built from the zone export CSV is faster than manual DNS Manager entry. The CSV produced by Get-DnsServerResourceRecord | Export-Csv is an inventory reference, not a native restore format – you need a script to parse it and call Add-DnsServerResourceRecord* for each record type.

AD Recycle Bin

AD Recycle Bin preserves deleted AD objects when it was enabled before deletion. For DNS, it is most useful when entire zones or zone subtrees were deleted from Active Directory – not for individual records removed by normal scavenging cleanup (where the DNS node is tombstoned, not deleted). If dns scavenging deleted records through the normal aging process, Recycle Bin is not the right recovery tool – re-registration and manual rebuild are.

Check whether AD Recycle Bin is enabled:

If it is enabled and the relevant DNS AD objects were deleted (not just tombstoned by scavenging), recovery is possible via Get-ADObject and Restore-ADObject. In practice, scavenging creates tombstoned DNS nodes rather than fully deleted AD objects, so Recycle Bin is rarely the right tool for a standard scavenging incident.

System State Authoritative Restore (Last Resort)

When large portions of the DNS zone are unrecoverable through re-registration and no usable export exists, a System State authoritative restore of the DNS zone data from a domain controller backup is an option – but a disruptive one.

AD-integrated DNS zones live in application partitions with distinguished names in the form:

Verify the actual partition your zone uses before any restore attempt:

Find the Root Cause: Why DNS Scavenging Deleted Records

Recovering the records stops the immediate outage. Fixing the root cause prevents the next one. Understanding why dns scavenging deleted records that should have been safe is the difference between a one-time incident and a recurring problem.

Intervals too short for the environment. The total of no-refresh interval plus refresh interval (default 7+7 days) defines the minimum time a record must exist before becoming eligible for scavenging. If DHCP leases are longer than 14 days, or if devices do not refresh their DNS registration reliably, valid records age out before they can be re-registered. Microsoft’s guidance on safe DNS scavenging setup recommends auditing lease durations before enabling scavenging. Check lease durations against scavenging intervals:

The no-refresh interval should be at least as long as the longest DHCP lease duration.

Records without timestamps (static records that became eligible). Before scavenging was enabled, records created manually had no aging timestamp. When scavenging runs for the first time, treatment of timestamp-zero records depends on the scavenging server configuration – some configurations treat zero-timestamp records as immediately eligible. Audit before enabling scavenging:

DnsUpdateProxy group misuse. When a DHCP server is a member of the DnsUpdateProxy security group, all DNS records it registers on behalf of clients are created without owner ACLs – any authenticated user can update them. These records can be deleted by the next dynamic update from a different source. If DnsUpdateProxy is in use and records disappear without scavenging being involved, ACL issues are the more likely cause. The safer alternative is dedicated DHCP service credentials for DNS registration without DnsUpdateProxy.

AD replication failure. In a multi-DC environment, scavenging on one DC can delete records that have not yet replicated to other DCs. The result looks like a partial deletion – records present on some DCs, missing on others. Check replication health before assuming scavenging settings are the problem:

For the full AD replication diagnostic workflow, see Active Directory Replication Not Working.

Devices with static IPs but dynamic DNS registration. As noted in the field note above – a static IP address does not make a DNS record static. If the device’s operating system registers DNS dynamically, the record carries a timestamp. Verify each server-class record that should be permanent is actually created as a static DNS record with no aging timestamp.

Prevent Recurrence

Full scavenging configuration guidance is in DNS Scavenging Windows Server: Aging and Safe Rollout Guide. The short prevention checklist after an incident where dns scavenging deleted records unintentionally:

To enable DNS audit logging if it is not already on:

Verification Commands

FAQ

Can DNS scavenging delete static records?

Yes, under certain conditions – and this is often the root cause when dns scavenging deleted records that were supposed to be permanent. Records with no aging timestamp are not eligible for scavenging under normal configuration. Records created with aging enabled – or records that had dnscmd /ageallrecords applied to the zone – carry timestamps and can be scavenged. A device having a static IP address does not automatically mean its DNS record is static. If the device’s OS uses dynamic registration, the record carries a timestamp regardless of the IP configuration.

How do I see which DNS records were scavenged?

When dns scavenging deleted records, the evidence is in the DNS Server Audit log. Check Event ID 521 in Event Viewer under Applications and Services Logs – Microsoft – Windows – DNSServer – Audit. Each Event 521 records the specific hostname, record type, and data that was removed. If the audit log was not enabled before the incident, Event 2501 in the DNS Server log tells you scavenging ran and how many records were removed, but without per-record detail.

Does ipconfig /registerdns restore SRV records?

No. ipconfig /registerdns re-registers the computer’s A and optionally PTR records. SRV records for domain controllers are registered by Netlogon, not the standard DNS client. Use nltest /dsregdns on each affected domain controller to restore DC locator SRV, CNAME, and A records.

Can AD Recycle Bin restore a scavenged DNS record?

Rarely, for a standard scavenging incident. Scavenging creates tombstoned DNS node objects in Active Directory, not deleted objects. AD Recycle Bin protects against deleted objects. If the DNS zone or a zone subtree was deleted from AD directly, Recycle Bin can help. For records removed by routine scavenging, re-registration or manual recreation is the correct path.

Why did a server with a static IP address lose its DNS record?

A static IP address does not make a DNS record static. If the server’s operating system or DHCP client is configured for dynamic DNS registration, the record carries an aging timestamp and is eligible for scavenging when the timestamp ages out. Verify in DNS Manager that the record’s properties show no aging timestamp – the “Delete this record when it becomes stale” option should be unchecked for records that must be permanent.

How long before a scavenged AD-integrated DNS record is permanently removed?

Scavenged records in AD-integrated zones are tombstoned, not immediately deleted. The tombstone is retained for a period controlled by the DNS server’s DsTombstoneInterval setting (default 7 days). After that, the AD object cleanup process removes the tombstoned object permanently. During the retention window, a fresh DNS registration for the same record name can restore service quickly. After the window closes, re-registration creates a new object from scratch – functionally the same result.

Is the zone export from dnscmd sufficient for a full restore?

As an inventory and manual reconstruction reference, yes – and it is the fastest option when dns scavenging deleted records that were static and cannot self-register. As an automated restore source without additional tooling, no. The zone file produced by dnscmd /zoneexport is human-readable and contains all record data. To bulk-restore records from it, you need either a script that parses the file and calls Add-DnsServerResourceRecord for each record type, or manual DNS Manager recreation. It is not a one-command import format.