How to Enable and Configure DNS Scavenging in Active Directory

3.6K

Over time, a large number of outdated dynamic device records can accumulate in Active Directory-integrated DNS zones. This can cause name resolution issues in AD and increase zone replication traffic, especially in networks with large numbers of laptops and mobile clients. To automatically clear stale DNS records in Active Directory, you can use the following two built-in Windows Server options:

• DNS Aging — enables aging for DNS resource records.
• DNS Scavenging — feature to automatically purge DNS records that are older than a certain number of days.

Configure DNS Aging

By default, Windows Server domain controllers do not automatically clean up outdated DNS records. First, you need to configure DNS aging in the properties of your AD zone:

1. Run the DNS manager console and connect to the domain controller (dnsmgmt.msc)
2. Open your Forward Lookup DNS zone properties and click Aging in the General tab;

   

3. Check the option Scavenging stale resource records.
4. There are two parameters to configure:
   1) Non-Refresh Interval — period of time during which a DNS record cannot be updated. Any record update attempts during this time will be ignored. If this option is enabled, devices will not update the timestamp in their DNS records at each boot. This can significantly reduce the load on the DNS server and zone replication traffic. The default value is 7 days.
   2) Refresh Interval — the time interval during which a DNS record can be updated. The record cannot be deleted from the DNS database during this time. Its value must be greater than or equal to the Non-Refresh Interval.

When both of these values have expired, a DNS record is considered stale. The timestamp is updated every time a dynamic DNS record is updated.

With the default settings (7-day Non-Refresh Interval and 7-day Refresh Interval), you should note that a dynamically updated DNS record must remain inactive for at least 14 days before it becomes eligible for scavenging.

In practice, this means that DNS scavenging does not remove records immediately after a device disappears from the network. A record becomes a candidate for removal only after both intervals have fully expired.

You can also enable DNS aging on a zone using the following PowerShell command:

Set-DnsServerZoneAging -Name theitbros.com -Aging $true

Important note. DNS scavenging is not enabled at a single level only. In order for scavenging to work correctly in AD DNS, all three levels must be configured:

1. Zone level (DNS zone settings)
   – Aging and scavenging must be enabled on the DNS zone itself.
   – This defines whether records in the zone are eligible for aging.
2. Server level (DNS server settings)
   – Scavenging must be enabled on the DNS server.
   – The server performs the actual cleanup operation based on schedule.
3. Record level (DNS record timestamp)
   – Only dynamically created records with valid timestamps can be scavenged.
   – Static records are never scavenged.

In case you didn’t configure any of these three levels correctly, scavenging will not work even if other settings are enabled.

You can view the timestamp of any record in the DNS console or using the PowerShell command:

Get-DnsServerResourceRecord -Name wks11 -ZoneName theitbros.com

You can also check the aging settings configured on a DNS zone by using PowerShell command:

Get-DnsServerZoneAging -ZoneName theitbros.com

This command displays the zone-level aging config, including the Refresh and Non-Refresh intervals.

In real AD environments, DHCP servers often play a key role in DNS record management. When DHCP is used with Dynamic DNS updates enabled, the DHCP server can become responsible for updating DNS records on behalf of client devices.

This means that DNS record timestamps may be updated not by the client itself, but by the DHCP service during lease renewal.

Important. Note that this creates a potential interaction between DHCP lease renewal and DNS scavenging. Each DHCP lease renewal may refresh the DNS record timestamp, which effectively prevents the record from being considered stale. As a result, DNS scavenging may not remove records even if devices are no longer active, depending on DHCP renewal behavior and config.

The age of the DNS record is the time difference between the last timestamp and the current time.

By default, the Windows Server DNS does not remove stale DNS records. Open a PowerShell console and run the command:

Get-DnsServerScavenging

In this example, ScavengingState is disabled and LastScavengeTime is Never.

Run cleanup manually from DNS Manager console

An administrator can run the cleanup manually from the DNS Manager console.

1. Right click on the DNS server > All tasks > Scavenge Stale Resource Records.
2. Confirm removal.
   

Allow the DNS server to automatically remove outdated resource records

1. Open the DNS server properties.
2. Navigate to the Advanced tab.
3. Check the Enable automatic scavenging of stale records option. Select after how many days outdated DNS records should be removed (default is 7 days).

You can apply the same config using PowerShell command:

Set-DnsServerScavenging `
-ScavengingState $true `
-ScavengingInterval 7.00:00:00

DNS cleanup runs once a day. To delete old records immediately, run the command:

Start-DnsServerScavenging

Here is a common issue in production environments: even in case scavenging is enabled on the server, it will not function unless the zone-level aging config is also enabled.

Similarly, in case you enabled zone aging, alone it won’t trigger cleanup unless scavenging is enabled at the DNS server level.

In Active Directory-integrated DNS zones, scavenging is tightly coupled with AD replication.

DNS records are stored in AD and replicated between domain controllers. This means that any changes caused by scavenging must also be replicated across all DNS servers hosting the zone.

Important. Note that replication latency can affect scavenging behavior in multi-DC environments.

In case scavenging is triggered on one DC, the deletion of stale records must replicate to other DCs. During replication delays, different DNS servers may temporarily show inconsistent data.

Here is a common production scenario: in multi-DC environments, one DNS server may already have scavenged (deleted) stale records, while another DC still holds those records until replication completes.

This can lead to temporary DNS resolution inconsistencies depending on which DNS server a client queries.

This behavior is especially important in environments with:

• Multiple geographically distributed DCs
• High replication latency links (WAN sites)
• Load-balanced DNS queries across multiple DCs

Without proper replication planning, scavenging results may appear inconsistent across the infrastructure.

Make a specific DNS record static

DNS Scavenging will only clean the zones where DNS Aging is enabled. Scavenging never deletes records with a ‘static’ value in the timestamp. If you want to make a specific DNS record static, open its properties and uncheck the Delete this record when it becomes stale option.

Here is a common production issue: admins often assume that DNS scavenging alone will clean up stale records. However, in case DHCP is actively updating DNS records during lease renewals, those records may never age out as expected.

Note that this is especially common in environments with:

• Long DHCP lease times
• Always-connected clients (VPN/Wi-Fi/laptops)
• Misconfigured dynamic DNS update settings

Here are best practice notes:

• You should prefer secure dynamic updates
• Ensure only one system (DHCP or clients) owns DNS updates
• Align DHCP lease time with scavenging intervals