Can DNS Scavenging Delete Static Records? Recovery Guide

Does DNS scavenging delete static records? Only if the record was carrying an aging timestamp. A record created manually with no timestamp is not eligible for scavenging under normal Windows Server DNS behavior, and a device having a static IP address does not by itself make its DNS record static. Before changing scavenging intervals or disabling anything, confirm two things: whether the missing record actually had a timestamp, and whether DNS Server Audit Event ID 521 shows it being scavenged. This article covers that confirmation, recovery by record type, and the root cause that made a supposedly static record eligible in the first place.

Does DNS Scavenging Delete Static Records?

A DNS record’s eligibility for scavenging comes down to one property: whether it carries an aging timestamp, not whether an administrator thinks of it as static. Four things get conflated during an incident, and separating them is the first diagnostic step:

• A static IP address is a network-layer setting on the device, unrelated to how its DNS record was created.
• A manually created static DNS record is added directly in DNS Manager, dnscmd, or PowerShell, and carries a timestamp of zero.
• A dynamically registered record is created through DNS dynamic update, on behalf of a client or by DHCP, and carries a nonzero aging timestamp.
• Timestamp zero means the record is treated as static for scavenging purposes. Any nonzero timestamp makes the record eligible for aging once it goes stale under the zone’s configured intervals.

Microsoft’s aging and scavenging documentation for Windows Server states that manually added records with no timestamp are not scavenged under normal operation. Aging and scavenging documentation does not describe a mechanism where a zero-timestamp record simply becomes “old enough” on its own.

So does DNS scavenging delete static records administrators genuinely intended to be permanent? Only if something gave the record a timestamp. The common ways this happens are covered in the root-cause section below. DNS scavenging does not check what a record was meant to be. It checks the timestamp.

What Does “Delete This Record When It Becomes Stale” Mean?

The checkbox lives on a record’s Properties tab in DNS Manager, under the General tab. Enabling it assigns the record an aging timestamp – the same mechanism a dynamic update uses. Once checked, the record becomes part of the normal aging and scavenging cycle after the zone’s no-refresh and refresh intervals elapse without a fresh registration.

Checking the box is not equivalent to an immediate deletion. The record still has to pass the zone and server-level scavenging conditions, and both aging intervals still have to elapse before the record becomes eligible for removal.

dnscmd /ageallrecords can assign current timestamps to records that previously had no timestamp, including manually created static records. Applied with /tree, as above, child nodes are included as well. Microsoft excludes record types such as NS, SOA, and WINS from this aging operation – it is not literally every record in the zone. There is no bulk undo. Individual records can be returned to static only by recreating them or manually clearing their aging state in DNS Manager. Do not use ageallrecords as an incident-response step.

DNS Scavenging Event IDs: How to Confirm a Record Was Deleted

Records also disappear from replication failures, DHCP reconfiguration, and accidental deletion, each with a different fix. Confirm scavenging is the actual cause before recovering anything.

Check the DNS Server Audit log first. Event ID 521 in the Microsoft-Windows-DNSServer/Audit channel records each individual scavenged record – the strongest built-in per-record evidence available, though not the only source. Backups, exports, and other change-monitoring data can also establish what changed.

Each 521 entry shows the record name, type, and data that was removed. A cluster of 521 events at one timestamp likely marks the scavenging run; note that time and cross-reference it against zone exports and DHCP lease data. Microsoft’s guidance on troubleshooting DNS scavenging issues documents the full audit event structure for each cycle.

Event 2501 confirms a cycle ran and deleted something. Event 521 confirms exactly what. If you have 2501 without any 521 events, the DNS Server Audit log likely was not enabled before the incident – per-record detail is unavailable, and comparing the current zone against a backup or export becomes the working method. For the full event ID reference, see Windows Server DNS Event IDs Explained.

Verify scavenging is actually configured on this server and zone:

Scavenging requires both server-level enablement and zone-level aging. If both are enabled, Event ID 521 confirms that the specific record was scavenged. Event ID 2501 confirms that the scavenging cycle removed records, but by itself does not prove that a particular missing record was among them.

Preserve the Current State Before You Recover Anything

One step before touching DNS configuration or running any registration commands: export the current zone.

The export lands in %SystemRoot%\System32\dns\. Copy it off the server immediately. For AD-integrated zones this captures record data, not the AD object structure, but it provides a practical baseline for verifying recovery completeness later.

Do not run dnscmd /ageallrecords as an incident-response step – it ages records that were never eligible for scavenging, turning recovery into a bigger cleanup problem.

Identify What Type of DNS Record Was Deleted

Recovery depends on how a record was originally created. Classify missing records first – it saves re-registration attempts that cannot succeed.

Use Event ID 521, or a known-good pre-incident inventory, to build the missing-record list. The export captured in the previous step is a post-incident baseline, not a source for discovering records that were already deleted – it is useful for tracking what changes during recovery and confirming restored records were added correctly.

How to Recover Deleted DNS Records After Scavenging

Recover dynamic records first, then work through records that require manual reconstruction.

Dynamic Client and Member-Server Records

Run on each affected client:

This triggers a dynamic update for the client’s configured interfaces. With working permissions, the forward A record should be recreated through dynamic update. PTR recovery depends on ownership: where the client owns reverse registration, this command can handle both records; where DHCP owns it, PTR registration occurs through the DHCP update path instead.

Domain Controller Locator Records

SRV, CNAME, and A records in _msdcs and the main zone are registered by Netlogon. Run on each affected domain controller:

Validate immediately after:

If nltest /dsregdns does not restore the records, restarting Netlogon forces re-registration too but is more disruptive – try nltest first. Loss of DC locator SRV records can disrupt DC discovery, authentication, LDAP lookups, and other AD-dependent services, so restore and validate these records early when they are affected.

DHCP-Owned Records

Where DHCP registers DNS on behalf of clients, work through the DHCP server, not the clients. Confirm DHCP is configured to update DNS and that the credentials are valid:

Trigger lease renewals on affected clients; DHCP submits fresh DNS updates as part of the lease acknowledgment. DHCP Reconcile Scopes repairs the lease database, not DNS records – it is not a DNS recovery step.

Manually Created Static DNS Records

Static records – created manually with no aging timestamp – have no self-registration mechanism. Recovery normally requires recreation from the zone export, a pre-incident backup, or documented inventory. There is no automatic path.

Records created this way are static by default: no aging timestamp, not eligible for scavenging. After recreation, verify the record’s properties show no timestamp if it is meant to stay permanent.

Why a “Static” DNS Record Was Actually Scavenged

Recovering the record stops the outage. Finding the cause below prevents the next one.

Static IP, dynamic DNS record, or the stale checkbox was enabled. Either one gives the record a timestamp – see the distinctions above.

dnscmd /ageallrecords was run against the zone at some point. This may have happened well before the current incident and timestamped records administrators expected to stay static.

Aging intervals and DHCP leases do not align. Microsoft’s documented relationship is refresh interval plus no-refresh interval greater than or equal to the maximum DHCP lease duration in the environment. If leases are longer than that combined window, or devices do not refresh reliably, valid records can age out before they re-register.

Microsoft’s guidance on setting up DNS scavenging safely recommends auditing lease durations against aging intervals before enabling scavenging, not after an incident.

Dynamic update ownership and ACL problems. DnsUpdateProxy changes the ownership and security behavior of records created on behalf of DHCP clients: records created by group members are intentionally left in a state that lets another updater take ownership. Microsoft recommends configuring DHCP with dedicated DNS update credentials in secure dynamic-update environments, so multiple DHCP servers use a consistent security principal. If records disappear without Event ID 521 evidence, inspect ownership, ACLs, DHCP credentials, and dynamic-update events before blaming scavenging.

Active Directory replication health. AD replication problems can make zone data inconsistent across authoritative DNS servers and complicate scavenging diagnosis. Windows DNS includes replication-related safety checks before scavenging an AD-integrated zone, so verify replication health whenever records differ between DNS servers:

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

AD-Integrated DNS: What Happens to a Scavenged Record?

In an AD-integrated zone, a scavenged record is not immediately purged. The DNS node object transitions to a tombstoned state and is retained for a period controlled by the DNS server’s DsTombstoneInterval setting, which Microsoft’s DNS protocol specification documents as defaulting to 14 days. DsTombstoneInterval property reference

During that window the DNS node remains represented in AD in a tombstoned state, but this is not a supported undo mechanism, not AD Recycle Bin, and not an operator-facing restore window. There is no supported operation to reverse a tombstone, and manually editing the dNSTombstoned attribute is unsupported and should not be attempted in production. The window exists to let replication propagate the deletion, not to give operators a recovery grace period. Normal recovery should still use re-registration or record recreation as appropriate; after retention expires, cleanup removes the object permanently and re-registration creates a new one from scratch.

When to Use AD Recycle Bin or Backup Recovery

AD Recycle Bin is not the standard recovery method for a normally scavenged record, since scavenging tombstones the DNS node rather than deleting the AD object outright. It matters more when an entire zone or subtree was deleted from AD directly – check whether it is enabled, and if the objects were actually deleted rather than tombstoned, recover them with Get-ADObject and Restore-ADObject.

Backup or authoritative restore should remain an escalation path for major damage, not a routine recovery step.

AD-integrated DNS zones live in application partitions with distinguished names in this form. Verify the actual partition before any restore attempt:

Prevent the Incident From Happening Again

Full scavenging configuration guidance, including aging interval selection and a safe rollout sequence, is in DNS Scavenging Windows Server: Aging and Safe Rollout Guide.

Verification Checklist

FAQ

Does DNS scavenging delete static records?

Not the ones with a zero aging timestamp. Records created manually with no timestamp are not eligible for scavenging under normal configuration. Records that were dynamically registered, had “delete this record when it becomes stale” enabled, or were touched by dnscmd /ageallrecords carry a timestamp and can be scavenged once they go stale. A static IP address does not by itself make a DNS record static.

What does “Delete this record when it becomes stale” do?

It assigns the record an aging timestamp, the same one dynamic updates use, and enrolls it in the normal aging and scavenging cycle. It does not delete the record immediately – the zone’s aging intervals still have to elapse first.

How do I see which DNS records were scavenged?

Check Event ID 521 in the DNS Server Audit log first for per-record detail. If that log was not enabled before the incident, Event 2501 in the DNS Server system log confirms a cycle removed records, but gives a count only.

How do I recover deleted DNS records after scavenging?

By record type. Dynamic client records: ipconfig /registerdns. DC locator records: nltest /dsregdns. DHCP-owned records: trigger lease renewal. Static records: recreate from a zone export, backup, or inventory – there is no automatic path.

Does ipconfig /registerdns restore domain controller SRV records?

No. It re-registers the computer’s own A and, in some configurations, PTR records. SRV records for domain controllers are registered by Netlogon, not the standard DNS client. Use nltest /dsregdns on the affected domain controller instead.

Can AD Recycle Bin restore a scavenged DNS record?

Rarely, for a routine scavenging incident. Scavenging tombstones the DNS node object rather than deleting it outright, and AD Recycle Bin protects against deleted objects. It is more useful when an entire zone or subtree was deleted from Active Directory directly.