Will No-Refresh Intervals on a DNS server apply if scavenging is not enabled

domain-name-systeminternal-dnswindows-server-2008-r2

I recently inherited a rather messy network. In DNS I've noticed that hundreds of systems have A records older than a year. And after running a script to ping all of them, over half of them are still online. We are not (currently) using DHCP and at least according to this link, by default a Windows workstation (that isn't getting its IP from DHCP) should attempt to register DNS once every 24 hours: https://social.technet.microsoft.com/Forums/sharepoint/en-US/e84228ca-95ff-4b22-b478-a8cb60c87c2d/how-often-dns-clients-come-to-dns-server-to-update-their-records-timemtaps-?forum=winserverNIS

These are our current scavenging and refresh settings on the zone:

Scavenge Settings

Now I intend to change these settings to 7 days each once I turn on scavenging and I plan on scheduling the first scavenge a few weeks out to give all systems a chance to refresh their A records, but before I do that I want to make sure that there isn't an issue keeping those workstations from updating their A records, lest I accidentally delete 500+ A records that belong to systems that are still active on the network. So is it normal that A record time stamps shouldn't be updating when scavenging is off? Or is there something wrong on those workstations keeping them from updating?

EDIT: So an update for anyone who comes googling for this later. Setting the refresh interval to be longer got my records to start refreshing, even without turning scavenging on. Even then, there were still a bunch of records that were not refreshing but that I could successfully ping, the reason behind the vast majority of these not updating was that they were a duplicate record. At some point in the past someone added a workstation to the domain with the hostname computer1. Eventually it was retired and a different computer was added to the domain using the same IP that computer1 had used at some point, let's say 192.168.1.1. Let's say it was named computer2. So computer1 and computer2 are both valid A records that both resolve to 192.168.1.1, but the actual Windows name of the machine is computer2. Once I get scavenging up and running all of the old duplicate records (different name but same IP) should get wiped out.

Best Answer

First, understand that an update and a refresh are not the same thing. An update is an actual update of the record, such as a host getting a new ip address and updating it's DNS record with the new ip address. A refresh is a refresh of the timestamp of the record with no other change to the record itself. Updates are always accepted regardless of the No-refresh interval. The No-refresh interval is meant to tamp replication traffic in the case that a record is not updated but the client is merely attempting to refresh the timestamp of the record. There's no need to replicate every refresh of the timestamp, especially considering that Windows clients attempt to refresh their timestamp every 24 hours by default.

Second, you can enable aging on the zone without enabling scavenging on the server so that the DNS zone has time to "shake off the dust", meaning the timestamps of the records for real, honest to goodness clients can be refreshed. You can then see which records are being refreshed and which are truly stale. I'd recommend setting the No-refresh and the Refresh intervals to the default of 7 days each. This should have the effect of allowing all records with timestamps older than 7 days to be refreshed. Then wait 14 days (the No-refresh interval + the Refresh interval) and enable scavenging on the server (I recommend the default scavenging interval of 7 days). Then wait 7 more days to see which records have been scavenged (this will be records that haven't been refreshed in 14 days + 7 days (the No-Refresh interval + the Refresh interval + the scavenging interval).

Third, before enabling aging on the zone and scavenging on the server make sure to export the zone so that it can be restored in the event that something goes wrong.