Friday 12 March 2010

DNS Scavenging Revealed

I thought I'd write up how scavenging works in DNS in conjunction with DHCP. There are places that describe the process well, but not everywhere, and nowhere that I've seen has it quite right in terms of timings.

DNS has 2 intervals relating to aging: the no refresh interval and the refresh interval:

No refresh interval - during this time, no refreshes may be made to the timestamp of a DNS record (more about refreshes in a moment), but updates are ok. This is done to prevent unnecessary frequent replication of DNS record changes.

Refresh interval - during this time, the timestamp of the record may be refreshed, at which point the no refresh interval kicks in again.

After the refresh interval has passed, if there has been no refresh (or update) of that record then it is available to be scavenged.

How to set up scavenging:
On the properties of the DNS zone, click on "Aging". Set whatever no refresh and refresh intervals you want. Ensure that you also tick the box to "scavenge stale resource records".
You then also need to tell the server to actually scavenge periodically. I am in favour of a single DC doing the scavenging.
In the properties of the DNS server, on the Advanced tab, check the box to "enable automatic scavenging of stale records", and set the scavenging period. Don't make this too frequent as scavenging hits the server.
Note that if you right click on the DNS server, there is a "set aging/scavenging for all zones..." option. This will, if you wish, allow you to set consistent scavenging options across all hosted zones. I don't use it personally.

That's the easy bit and what you can find on any website.

DNS record Refresh vs Update
A refresh is defined as when the record tries to update its timestamp but its IP address hasn't changed.
An update is when the IP address changes. This kind of operation can always occur as the no refresh interval does not impact on it.

So, let's see the processes in action:
Firstly, DNS refreshes being prevented by the no refresh interval:
The scenario here is that we have a DHCP server, with DHCP lease times set to 10 mins.
This means that DHCP half-life (T1) will occur every 5 mins.
Scavenging is enabled and scheduled every hour, with no refresh interval set to 1 hour, and refresh interval set to 2 hours:
  1. Scavenging is occurring at 25 past each hour.
  2. Client powers on at 09:44.
  3. The timestamp for the record is set to 09:00:00 because all timestamps are rounded down to the nearest hour.
  4. At 09:49, it attempts to refresh its timestamp in DNS. It is not allowed to do so due to it being in the no refresh interval.
  5. This goes on every 5 minutes. At 10:04, it tries again. Now, logic dictates that it should be able to refresh its timestamp this time because the no refresh interval is only 1 hour. However (and this is what I've never seen written anywhere else), it can't. This is because, all DNS registrations that occur from 09:00 to 09:59 will have a timestamp of 09:00:00. Therefore, counting only commences at 10:00, so the no refresh interval is officially from 10:00 - 11:00 (and any time before 10:00). Therefore the record timestamp will be refreshed on the first attempt after 11:00 and will be set to 11:00:00.

Now, let's see scavenging in action in the same scenario:

  1. Scavenging still occurs at 25 past the hour.
  2. Client is powered on at 13:38. DNS timestamp is set to 13:00:00.
  3. It tries to refresh its timestamp every 5 mins but is unable to.
  4. At 14:16 it is powered down.
  5. At 15:00, its DNS record enters the refresh interval. However, the client is powered down so does not refresh it.
  6. At 17:00 (2 hour refresh interval), the refresh interval expires and the record becomes eligible for scavenging.
  7. At 17:25, scavenging runs and the record is deleted.

Matching DHCP and DNS scavenging periods correctly is vital.

Here's an example where they aren't matched. DCs re-register their records every 24 hours by default, or whenever Netlogon is restarted. All clients automatically attempt to refresh their DNS records every 24 hours too.

In this scenario, we have the same scavenging settings as above, but this time, DHCP lease times are set to 4 days.

  1. Scavenging occurs at 25 past the hour again.
  2. Client powers on at 08:12 and receives an IP address from DHCP. DNS timestamp is set to 08:00:00. Since the lease time is 4 days, the client will not attempt to refresh its record for 2 days if left up and running.
  3. Therefore, by the end of the refresh interval at 12:00, the client has not refreshed its record and consequently at 12:25 the record is scavenged, despite the client being up and running and in use all that time.

Therefore, take care with over-zealous scavenging. Know your DHCP lease times!

What are the best settings?

I've heard talk that with a default DHCP lease time of 7 days, no refresh of 3 days and 4 days refresh intervals are good (the idea being that T1 is 3.5 days in, when the refresh interval is in place - again be careful its not the other way round with a no refresh of 4 days as T1 will always fail, though T2 at 87.5% of the way through the lease should succeed).

However, I'm not convinced. If the person goes on holiday for a week, the record will be scavenged - is that good? It might be depending on your point of view. However, by leaving it there it's not necessarily a bad thing. If the client is turned off for a few days and the lease expires, then as soon as it comes back on line and picks up a new IP address, the record is immediately updated anyway so it will always show the latest IP address.

Using DNSCMD to see record timestamps:

I don't like the DNS console much. It's slow to update so I can never trust the information it is giving me is up to date. DNSCMD often will show me that a timestamp is updated well before the console ever does.

If you want to see the timestamps for records in the console, you need to turn on advanced features. If you want to see them using DNSCMD, it's:

dnscmd servername /EnumRecords DNSZoneName @ /Type A

This will show you all A RRs, with timestamps.

No comments:

Post a Comment