Most of you reading this will already know what DNS Scavenging is. For those of you that don’t it is a feature of Windows DNS servers which allows you to automate the deletion (scavenge) of outdated DNS resource records. It sounds simple enough and it is once you decipher Microsoft’s cryptic descriptions, but to the uninitiated it is just plain confusing and often leads to unpredictable results. This article will attempt to simplify how DNS scavenging works.
Enabling DNS Scavenging on Zones
The first thing we need to do is enable Scavenging. This is done separately for each DNS zone. To enable scavenging on all zones see “Enable Scavenging on All Zones” below. To enable scavenging right click the DNS zone, select properties and then on the general tab select the “ageing” button.
Tick the box “Scavenge Stale resource Records” and leave the rest to their defaults.
Here is where the confusion starts. The No-Refresh and Refresh Intervals are not when resource records get scavenged. They are timers for when DNS records become eligible for scavenging. The actual scavenging process is done elsewhere.
Enable Scavenging on All Zones
To enable scavenging for all zones right click the DNS server name and select “Set Ageing/Scavenging for all DNS zones”
It is important to point out that this will only enable scavenging on NEW zones. To apply it to existing zones tick the box (on next pop-up) that says “Apply these settings to the existing AD zones”.
No-Refresh and Refresh Interval Settings
DNS clients by default update their DNS resource records every 24 hours. There are two ways to do this. If the client’s IP has changed since the last update it is considered an “update”. If the IP hasn’t changed then it is considered a “refresh”. In both cases a new timestamp is set.
The No-Refresh interval is the amount of time after the timestamp where the DNS server will not accept a “refresh” from the client. Apparently the point of this is to cut down on DNS replication if you have multiple DC’s; it makes sense, I mean what is the point of updating the record with a new timestamp and causing unnecessary replication traffic if nothing else has changed? By setting the No-refresh interval you prevent these refreshes from taking place causing less replication. Non refresh updates (where the IP changes) can update the record at any time.
The Refresh interval starts AFTER the no-refresh interval. In this window updates and refreshes are allowed. If a resource record hasn’t been updated by the time the no-refresh and refresh intervals have elapsed it becomes eligible for scavenging. The no-refresh and refresh intervals are cumulative (that is 14 days in the image above).
Let’s look at an example using the settings above. My PC has an IP address of 18.104.22.168 and registers this with my PC name on the DNS server. It will now contact the DNS server every day to update or refresh the DNS record depending on whether my IP changes or not. For the first 4 days my IP is the same which means each day it tries to “refresh” the DNS record. The DNS server does not allow this due to the No-Refresh interval of 7 days. On the fifth day my IP changes so my PC tries to “update” the DNS record. The server allows this as the no-refresh interval doesn’t apply to “updates”. The record is updated along with a new timestamp and the no-refresh period starts again. Now 7 days pass where my IP hasn’t changed. After 7 days the DNS server allows me to “refresh” the record setting a new timestamp and we enter the no-refresh interval again. If 14 days pass without the record being updated or refreshed the record becomes eligible for scavenging.
The above steps only enable DNS scavenging on the zone. To actually scavenge stale resource records you right click the server and select “Scavenge stale resource records”. The server will then delete records with timestamps older than the No-Refresh interval plus the Refresh interval. With the default settings this is 14 days. To enable automatic scavenging right click the server, select properties and then click the Advanced tab.
Tick the box that says “enable automatic scavenging for stale records” and set how often you’d like it to run. Each time the scavenge process runs whether you initiate it manually or automatic it is recorded in the Windows event log with ID 2501/2502. For Windows 2003 servers this is in the system event log, for 2008 it is in the DNS event log. This is important as it should be the first place you look if you suspect scavenging isn’t working; it ALWAYS logs this when scavenging takes place, if there is no entry then scavenging failed and you need to investigate why.
TIP: To work out when automatic DNS scavenging will run next find the most recent 2501/2502 event and add the scavenging period to it.
Other Reasons Why DNS Scavenging May Fail
If you already knew all the above it is likely you have been caught out by the following:
The server is not authorised to perform scavenging on this domain – This was the cause of my scavenging issues; a good indication of this is that there are no 2501/2502 events logged when you run scavenging. To my knowledge there is no way to determine which servers are authorised to scavenge but you can reset this if unsure. To reset it and allow DNS scavenging on only the servers you specify type “DNSCmd . /ZoneResetScavengeServers yourdomain [list of DNS server IP addresses]” at a command prompt. If I had two DNS servers I want to authorise scavenging for on mydomain.local with IP’s 192.168.0.1 and 192.168.0.2 I would type DNSCmd . /ZoneResetScavengeServers mydomain.local 192.168.0.1 192.168.0.2. You should now try scavenging again and this time you should see an event logged for it. Scavenging may still fail however for the next reason.
The no-refresh interval hasn’t yet elapsed since enabling the zone for scavenging – When you first enable a zone for scavenging ALL DNS records are protected until “The zone can be scavenged after” date has passed regardless of their timestamp.
This to allow ample time for DNS records and timestamps to be updated on all DNS servers. For those of you wondering how this calculated it is the date you enabled DNS scavenging plus the no-refresh interval. If you do not see this section close the window and refresh the zone. When you open it again it should be there. If it still isn’t there it maybe because you have an SBS server or single DNS server environment in which case no replication occurs so this setting is irrelevant and does not apply to you.
Putting It All Together
Here is one last example which takes into account everything discussed above.
- We enable DNS scavenging on 26/04/12.
- We set the no-refresh interval to 3 days and the refresh interval to 4 days.
- We configure the server to scavenge for stale records every 4 days.
- There are several DNS records with timestamps older than 01/04/12.
- We have a PC which creates a new DNS record on 28/04/12.
After we enable DNS scavenging on the zone we immediately run a manual scavenge but notice that the records with timestamps older than 01/04/12 haven’t been deleted. We check the DNS event log and see that no DNS scavenging events have been logged so we run the ZoneResetScavengeServers command to authorise our DNS server to scavenge this zone. We then run scavenging again but it still fails to delete any records. We note that this time events have been logged so we know a scavenge has taken place. We check the “This zone can be scavenged after” and note that the date is set to 29/04/12 which is exactly the current date plus the no-refresh interval. This means the zone is protected from scavenging until th 29th and no DNS records can be scavenged until then. We come back on the 29th and see that the records over a month old are still there. This is because although the zone can now be scavenged the next scavenge attempt will not occur until exactly 4 days after the last scavenge was run; since we ran one on 26/04/12 the next would be 30/04/12. We run a manual scavenge again and note that 01/04/12 and older records have now been deleted. On the same day (29th) we notice that the record our client created on the 28th still has a timestamp set as 28th, this is because it’s IP address hasn’t changed and attempts a refresh but the no-refresh settings prevent it from doing so for 3 days. On the 01/05/12 the PC is shut down and decommissioned. 01/05/12 is still in the no-refresh interval (for this record only) so it never refreshed it’s resource record and still has a timestamp of 28/04/12 (note: if the IP had changed it would have updated the record and timestamp). On 05/05/12 the client’s record is now eligible for scavenging as 3+4 days have elapsed since the timestamp. The record will be deleted if we run another manual scavenge or automatic scavenging runs on 07/05/12 which is exactly 4 days after the last scavenge ran.
Note: It is the 7th because the last automatic scavenge would have happened on 3rd (which I didn’t mention above) which is 4 days after our manual scavenge on 29th.