DNS aging and scavenging

Aging makes a record eligible; scavenging removes it

A nonzero record timestamp allows aging. The zone’s no-refresh and refresh intervals determine when an unrefreshed record becomes stale. A server’s scavenging schedule determines when an eligible record might actually be removed.

The record isn’t deleted the moment the refresh interval ends. Zone readiness and the next server pass also matter. See Microsoft’s scavenging explanation.

Read the configuration first

With the DnsServer PowerShell module and DNS administration access:

Get-DnsServerScavenging -ComputerName 'DC1.contoso.com'
Get-DnsServerZoneAging -ComputerName 'DC1.contoso.com' -Name 'contoso.com'
Get-DnsServerResourceRecord -ComputerName 'DC1.contoso.com' -ZoneName 'contoso.com' |
    Select-Object HostName, RecordType, Timestamp

Check the record data as well when investigating a particular record. Two records with similar names may have different record types, ownership, timestamps, and registration paths. The module has separate commands for zone aging and server scavenging.

Zero timestamps are deliberate

A static record with timestamp zero is not scavenged merely because its target has disappeared. Conversely, a server with a static IP address can still register a dynamic, timestamped DNS record. IP allocation and DNS-record aging are different properties.

Don’t use “age all records” for routine cleanup. It can make intentionally static records eligible for deletion. Before changing aging, check which records must stay static, which DHCP manages, which devices can’t register themselves, and which systems spend long periods offline.

Enable it in stages

Changes DNS configuration and can lead to deletions: review the zone, inventory its records, check backups, and understand how registrations are kept current. Enable aging on the zone first, give clients time to refresh, then enable scavenging on the chosen server. Check the zone’s “can be scavenged after” time and allow for the rollout interval. Don’t enable both ends and force a cleanup straight away.

The combined intervals need to accommodate the actual DHCP lease/renewal behavior and how long valid clients may be absent. A short refresh window can delete legitimate registrations. A long no-refresh interval reduces timestamp replication but also delays the next timestamp refresh. Microsoft’s DNS aging and scavenging guide covers the controls and monitoring.

Diagnose disappearance with evidence

Keep the authoritative server name, record type/data/timestamp, zone-aging settings, designated scavenging server, and time the record disappeared. Check DNS events 2501 and 2502 around that time. Compare authoritative answers before treating a cached response as a replication problem.

Records can also disappear after an ownership/update failure or an AD conflict affecting the zone. A missing record doesn’t automatically mean the scavenging interval is wrong. Microsoft’s missing DNS records guide covers these alternatives.

Keep the arithmetic visible

For a record that never refreshes, add the no-refresh and refresh intervals to its timestamp to find the earliest point it can become eligible. Deletion happens on a later scavenging pass, subject to the zone’s protections. The arithmetic won’t give you an exact deletion time.

Work a timing example without confusing it with TTL

Suppose a zone is configured with seven days no-refresh, seven days refresh, and the server scans every seven days. A timestamp-only refresh during the first seven days can be acknowledged without moving the timestamp. After that interval, an accepted refresh renews the timestamp and starts another no-refresh interval. If no refresh arrives, the record can become stale after fourteen days and wait for a later eligible pass.

The DNS record’s TTL controls how long query answers may remain cached. It does not control whether the authoritative record is scavenged. Lowering TTL will not rejuvenate a timestamp or shorten the no-refresh interval. The aging terminology reference separates those timers and the zone’s readiness gate.

Verify registration before switching on deletion

Choose some representative DHCP clients, static-address Windows servers, non-Windows systems, and devices that sleep or leave the network. Save their authoritative records and check that the intended registrar can refresh them during the allowed window. Investigate records that stay old before enabling cleanup.

An authentication/ownership failure that already prevents updates will turn into a name-resolution outage once scavenging starts deleting those records. Fix that registration path rather than shortening intervals to make the zone look clean. Where DHCP registers records, validate its configured DNS credentials and behavior after failover too. DNS dynamic updates explains the Windows/DHCP ownership relationship.

Restrict the cleanup owner deliberately

One DNS server can scavenge an AD-integrated zone because deletions replicate. A zone’s allowed scavenging-server list and that server’s automatic-scavenging setting are separate controls. If the designated server is retired, record which server takes over and verify the replacement’s logs and zone readiness.

Changes zone aging configuration: after reviewing the existing settings, this scopes scavenging eligibility to a chosen DNS server; it does not immediately delete records:

Set-DnsServerZoneAging -ComputerName 'DC1.contoso.com' -Name 'contoso.com' `
    -Aging $true -ScavengeServers '192.0.2.10' -WhatIf

Replace the address and check the preview. The zone-aging command reference documents the setting. Save the current intervals and server list before changing them; avoid -ApplyOnAllZones when you’re only changing one zone.

Separate a manual pass from changing eligibility

Start-DnsServerScavenging is a deletion-capable operation, not a report of what would be deleted. It requests a pass; the record and zone safety conditions still apply. A pass that removes nothing does not by itself prove scavenging is broken. Check zero timestamps, zone aging, allowed server, readiness time, and the record’s age first. The configuration guide documents the manual pass and server/zone controls.

Read the DNS event message to distinguish a completed pass from a zone-loading failure. Keep the before/after record exports, server name, and AD replication status together. Query the authoritative server after deletion, then allow for cached answers when checking what clients see.

Separate deletion from removal of the directory node

An AD-integrated DNS name can hold several records on one dnsNode. Removing one record need not remove the name. When its last record is removed, DNS can mark the node dNSTombstoned=TRUE, retain deletion metadata, and stop serving it while that state replicates. This is separate from an AD object carrying isDeleted=TRUE, and separate again from a cached positive answer surviving until TTL expiry. The attribute definition explains the DNS-specific state.

DNS’s DsTombstoneInterval controls later cleanup of these DNS tombstones; it is not the zone’s no-refresh/refresh period or AD’s tombstone lifetime. The current protocol specifies a 14-day default and a daily 02:00 local-time cleanup search; historical versions differed, so inspect the deployed setting instead of adopting an old seven-day statement. See DNS directory tombstone cleanup. Changing that interval is not a way to make active records refresh successfully.

For the server’s scavenging schedule, event 2501 records a pass that removed records and 2502 a pass that removed none. The next scheduled start is based on the previous pass’s start plus its interval, rather than simply adding the interval to a completion event. Record both times when diagnosing long passes. The configuration guide’s event-log section documents these events and timing.