3

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.

ChickenOverlord
  • 133
  • 1
  • 5

2 Answers2

2

The no refresh interval means between its last refresh and its next it has to wait at least 360 days to update regardless of what the client is doing.

Separate from that if you were to tick the scavenge stale resource records it would only remove those records which are over 365 days and 1 hour old so with current settings its not giving it much time to refresh before its considered stale.

Its really two functions in the same dialogue box.

I usually go for 4 days no refresh interval and 5 days refresh interval totalling 9 so that what we do have on dhcp (8 day lease) is gone before the scavenge, I hope that helps.

Rebus
  • 86
  • 8
  • But even if the Refresh Interval has elapsed/the record has been marked stale shouldn't it still be able to refresh until it has been scavenged? Or is something else going on here? In any case I've increased the refresh interval significantly now. – ChickenOverlord Nov 28 '17 at 22:11
2

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.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • I've changed the no-Refresh and refresh intervals to 7 days each. I'm going to try to refresh my own workstation in 7 days, I'll give you an update on whether or not it works. Thank you for the advice – ChickenOverlord Nov 28 '17 at 22:18
  • If you want to verify that dynamic DNS registration is working on your workstation and that the zone is accepting refreshes you can change the No-refresh interval to anything less than the current timestamp on the record and run ipconfig/registerdns from an elevated command prompt on your workstation and then check the timestamp of the record. So for instance, if the current timestamp of the record is 11/24/2017 @ 5:00 PM then change the No-refresh interval to anything less than 4 days and attempt to refresh the record from your workstation. – joeqwerty Nov 28 '17 at 22:32
  • Just tried it and it updated, thank you so much for the help. One last question, will a record with a timestamp older than the no-refresh and refresh intervals get updated even if it has already been marked stale if I run ipconfig /registerdns on it? – ChickenOverlord Nov 28 '17 at 22:40
  • Yes. Any record is a candidate for refresh so long as scavenging hasn't run on the zone. The "staleness" of a record isn't a technical attribute. Any record older than the No-refresh + Refresh intervals is considered stale, but can be updated at any time. The only concern is if scavenging runs and deletes the record before the client has an opportunity to refresh the timestamp. – joeqwerty Nov 28 '17 at 22:46
  • Then I'm wondering why none of the older records have ever updated despite the refresh interval only being an hour (though the non-refresh interval was 360 days), I'm guessing it is in fact something going wrong on those systems then that's keeping them from trying to refresh? :/ – ChickenOverlord Nov 28 '17 at 22:48