How DNS Aging and Scavenging Actually Work

There’s a lot of conversation on the Internet about how DNS Aging and Scavenging within Windows Server work, but lots of it doesn’t make sense, and most of it is pretty convoluted. I’ll aim to clear that up below in plain English. Consider an environment with a bunch of Domain Controllers all holding the DNS server role, and a bunch of clients. Sound familiar? I hope so. Let’s assume you’ve followed best practice and have DNS aging/scavenging configured on all zones, and the scavenging process configured on a single DNS server (use this script to make sure, thanks @nickstugr).

Our server is called MELDC01, and our client is called COMPUTER1. This is the configuration of the DNS zone:

DNS Aging Scavenging Zone Config

…and this is the configuration on our server MELDC01:

serverconfig

Keeping the configuration settings above in mind, let’s dig a little into how the “conversation” goes between client and server. Client can be a PC, a server, or any other device that registers itself in DNS. First we enter the no-refresh interval. In this aptly-named stage, the record cannot be updated by the client.

T+0 Client: Hey, MELDC01! I’m COMPUTER1 and my IP address is 10.0.0.123 Server: Hey, COMPUTER1! Welcome aboard, I don’t see a record for you, so I’ll create one and stamp it with the current time

In the no-refresh interval of T+0 through T+7 days (or the configured no-refresh interval), the following occurs:

T+0 through T+7 days Client: Hey, MELDC01! I’m COMPUTER1 and my IP address is 10.0.0.123 Server: Hey, I don’t care, go away please

During the no-refresh interval, the record cannot be automatically updated. Once the no-refresh interval expires, we enter the refresh interval:

T+7 through T+14 days Client: Hey, MELDC1! I’m COMPUTER1 and my IP address is 10.0.0.123 Server: G’day, COMPUTER1! I have a record for you here, but it’s over 7 days old. Let me update that and restamp it with the current time. You now have another 7 days of no-refresh time to enjoy

At this point, we return to T+0 - the record is effectively brand new and we’re back in the no-refresh interval. If, however, the client does not communicate with the server during the refresh interval, we enter the scavenging period (T+refresh+no-refresh, or T+7+7 days). This is the point at which, when it runs, the server’s scavenging process will come along and delete the record. One common misconception is that this is an immediate action, however it’s anything but. That’s where the “Scavenging period” configured on the server comes into play.

This could perhaps, more aptly, be called the scavenging interval. This is how frequently the scavenging process runs on the designated DNS server. When the scavenging period is configured on a DNS server, the timer starts for 7 days (or whatever the configured value is). Once the timer expires, the scavenging process runs. It checks every zone on the server with Aging/Scavenging configured, and deletes any record that hasn’t been refreshed in T+refresh+no-refresh days. After the scavenging process runs, the timer again begins to count down the appropriate number of days. From this information, the astute reader will realise that a stale record can potentially exist significantly longer than just the 14 days we’ve got configured here. If the record happens to hit the end of its refresh interval just after the scavenging process runs, in this configuration, the record could exist for up to an additional 7 days, in a sort of “grace period”.

Here’s a graphical timeline of events:

timeline

Written on January 23, 2015