Windows DNS Server Operations: Zone Replication, Dynamic Records, and Scavenging

Windows DNS problems are often misdiagnosed as “the DNS server is stale” when the real issue is which server is authoritative, how a zone reaches that server, whether a record is dynamic, or when scavenging is allowed to delete it. In Active Directory environments, zone data can replicate through AD DS, while cleanup depends on separate DNS aging and scavenging settings. A healthy client query against one resolver does not prove that every authoritative server has converged.

This article focuses on the server-side lifecycle of records in Windows DNS. It covers file-backed and AD-integrated zones, AD replication scope, dynamic updates, timestamps, stale-record eligibility, safe scavenging operations, and verification from each authoritative server. It deliberately separates DNS client resolver troubleshooting from zone administration.

Know where the zone data lives

A DNS zone is an authoritative portion of a namespace hosted by a DNS server. A standard primary zone is writable on its primary server and is commonly stored in a text file. Secondary zones contain read-only copies transferred from a primary. An Active Directory-integrated zone stores zone data in AD DS and is available on domain controllers that run the DNS Server role. The zone’s replication scope determines which directory replicas receive that data.

An AD-integrated zone is not a conventional primary-plus-secondary arrangement for its AD-aware replicas. Changes are written to AD DS and replicated through the directory to the DNS servers hosting that zone. A standard secondary server still uses DNS zone transfers from an authoritative source. These are separate replication paths with separate health checks. Do not troubleshoot a missing record by inspecting only one server or only AD replication without first confirming the zone type and the server’s role.

For an AD-integrated zone, replication scope can include DNS servers on domain controllers in the domain or forest, or a configured application directory partition. A wider scope can improve where records are available but increases the set of directory replicas and sites involved. Design scope intentionally, especially for large forests or sites with limited connectivity. The DNS console and Get-DnsServerZone help inventory the zone; Active Directory Sites and Services and directory replication tools explain how its directory partition replicates.

Before editing zone data, record:

The zone name, type, authoritative servers, and whether the zone is AD-integrated.
The AD replication scope or, for file-backed secondary zones, the primary and transfer configuration.
The record owner, record type, current data, and timestamp where applicable.
The DNS server and AD DS event evidence at the time the issue began.
The expected client subnet/site and which authoritative server should answer it.

Do not make identical manual edits on several AD-integrated DNS servers to “force convergence.” Make an approved update through one authoritative path, then verify directory replication and query each server directly. Multiple writers can create confusing evidence or preserve different answers in caches.

Dynamic updates and the record timestamp

Dynamic DNS update allows a client or DHCP service to add or change resource records automatically. In an AD-integrated zone, Windows DNS defaults to secure dynamic updates, while file-backed zones have different default behavior. Dynamic update and scavenging are related but distinct: accepting a dynamic update does not itself mean that stale records will later be deleted.

The record timestamp is the signal used by aging and scavenging. A nonzero timestamp makes a record eligible for the age calculation. Manually created static records normally have timestamp zero, which protects them from scavenging. An administrator can assign timestamps, but doing so broadly can make intended static records eligible for deletion. Inspect record data and ownership before changing timestamp state.

Aging suppresses timestamp refreshes during a no-refresh interval, then allows refreshes during a refresh interval. This reduces unnecessary replication updates. A record is considered stale only after its timestamp plus both intervals is earlier than the DNS server’s current time. With the common seven-day plus seven-day intervals, a record that is not refreshed becomes eligible after 14 days; it is not necessarily deleted at that instant because deletion waits for an eligible scavenging pass.

Clock correctness matters because the comparisons use server time. Before shortening intervals or enabling scavenging, compare time synchronization across the DNS servers and domain controllers. A skewed server can make an otherwise healthy record appear older or newer than expected. Also account for DHCP lease duration, device sleep or travel patterns, static addressing, and how clients register A and PTR records. If a client is offline longer than the chosen aging window, the record may be removed even though the device still exists.

Scavenging is a four-part gate

Scavenging can remove a record only when server-level scavenging is enabled, zone-level aging is enabled, and the record has a nonzero timestamp old enough to exceed both intervals. Aging by itself tracks timestamps; it does not delete records. A scavenging pass can run and delete nothing, which is a normal outcome when all records remain current or protected.

Server-level scavenging settings are local to each DNS server and do not replicate. Zone-level aging settings on an AD-integrated zone replicate with the zone data, while each server still needs its own server-level scavenging configuration if it is to run a pass. Microsoft recommends one scavenging server per zone as the usual operational model. Multiple scavengers increase the difficulty of explaining which server deleted a record and when; if redundancy is needed, configure it intentionally and monitor each server’s state.

Secondary and stub zones do not support this aging/scavenging lifecycle. For AD-integrated zones, a deleted final record can be tombstoned in AD DS and the logical deletion then replicates to other DNS servers hosting the zone. Scavenging a stale A record is not the same operation as deleting an entire dnsNode, and observing a record disappear on one DNS server does not prove every directory replica has converged yet.

Inspect first, then configure narrowly

Use targeted queries to collect current state before changing anything:

$server = "DNS01.contoso.com"
$zone = "contoso.com"

Get-DnsServerZone -ComputerName $server |
  Where-Object ZoneName -eq $zone | Format-List *
Get-DnsServerScavenging -ComputerName $server | Format-List *
Get-DnsServerZoneAging -ComputerName $server -Name $zone | Format-List *
Get-DnsServerResourceRecord -ComputerName $server -ZoneName $zone |
  Select-Object HostName, RecordType, Timestamp, RecordData

The commands above are read-only. Review a representative sample of static records, dynamically registered endpoints, domain controllers, printers, appliances, and service aliases. Confirm that records expected to remain static have zero timestamps and that dynamically registered clients can refresh their records. Back up DNS server configuration and zone data before making changes.

When enabling aging on a single AD-integrated zone, use a deliberate interval and restrict the scavenging server if that matches the topology:

Set-DnsServerZoneAging -ComputerName $server -Name $zone `
  -Aging $true `
  -NoRefreshInterval 7.00:00:00 `
  -RefreshInterval 7.00:00:00 `
  -ScavengeServers 192.0.2.10

# Enable the scheduled scavenging process on the chosen server.
Set-DnsServerScavenging -ComputerName $server `
  -ScavengingState $true `
  -ScavengingInterval 7.00:00:00

Use documentation matching the installed Windows Server version and DNS Server PowerShell module. The example assumes 192.0.2.10 is the chosen DNS server address and the interval fits the real re-registration window; it is not a universal default to paste into every domain. When applying settings to many existing zones, -ApplyOnAllZones has broad scope. Inventory what it will affect and preserve exceptions before using it.

Do not run Start-DnsServerScavenging as a cleanup shortcut before proving the interval, record timestamps, and zone scope are correct. An immediate pass can delete records that are genuinely stale according to current settings. First test in a lab or a low-risk zone, monitor the DNS Server events, and inspect the candidate records. Use the verbose output only when the deletion list is understood and the change is authorized.

Distinguish replication delay from stale client cache

When servers return different answers, query each authoritative DNS server directly. This bypasses a recursive resolver’s cached answer and shows whether the zone data itself differs:

Resolve-DnsName app01.contoso.com -Server 10.0.0.10 -DnsOnly
Resolve-DnsName app01.contoso.com -Server 10.0.1.10 -DnsOnly

repadmin /replsummary
repadmin /showrepl DNS01

If the authoritative responses differ for an AD-integrated zone, examine the DNS Server and Directory Service event logs, AD replication health, zone loading, and the zone’s replication scope. If authoritative responses match but clients differ, investigate the recursive resolver and client cache path rather than editing the authoritative zone again. DNS cache TTL and AD replication convergence are separate timelines.

For a file-backed primary and secondary, verify that the primary contains the intended record and inspect secondary zone-transfer success and serial state. Do not assume an AD replication check will explain a conventional AXFR or IXFR problem. Conversely, do not use repeated zone transfers as a substitute for checking AD DS replication for an integrated zone.

For AD-integrated zones, events 4013, 4515, and 4521 can help identify directory initialization or zone-load problems. Events 2501 and 2502 report completed scavenging passes: one indicates records were scavenged, and the other that none were removed. Use event details and timestamps to correlate a deletion with a server and pass, then validate the record’s timestamp and lifecycle rather than recreating it immediately on multiple servers.

Production rollout and acceptance checks

Treat enabling scavenging as a data lifecycle change, not as a harmless housekeeping toggle. Export zone data or take an approved backup. Inventory static and dynamic records, review the no-refresh and refresh intervals against device and DHCP behavior, confirm system time and AD replication, and identify exactly which servers will scavenge the zone. When aging is first enabled or its settings change, the zone receives one refresh interval of protection before it can participate in scavenging; that delay is expected and is not a reason to shorten intervals just to force an earlier pass.

Use a pilot zone or a representative test record to prove registration, timestamp refresh, replication, and eventual eligibility. Then enable one production zone at a time. After the first scheduled pass, review the event log, enumerate removed records, and confirm expected clients can dynamically register again. Keep a restore path for records removed incorrectly, including ownership and dynamic-update behavior; simply re-adding an A record as static may change how later client updates work.

Acceptance evidence should show: the authoritative servers and zone type are known; the intended replication scope is healthy; the scavenging server is configured; records have expected timestamps; static records are protected; only intended stale records are removed; and client resolution is correct from each relevant site. Record the change owner, exclusions, interval rationale, and rollback procedure. Revisit the settings after DHCP lease changes, client lifecycle changes, new AD sites, DNS role migrations, or Windows Server upgrades.

Related:

Sources: