Notes on Dynamic DNS updates, DNS Scavenging, etc.

Dynamic DNS updates can be set to one of these (per zone):

  • None => No dynamic updates are allowed for the zone on this server
  • Secure => Only secure updates are allowed.
    • Note: This is only applicable to AD integrated zones.
    • By default only domain members (domain joined computers & domain users) are allowed to update the zone for secure updates. This is controlled by the ACLs on the zone (which can be viewed via the Security tab of the zone – check out the ACE for “Authenticated Users“). See this link for more. 
  • Nonsecure and secure => Both secure and nonsecure updates are allowed.

Scavenging

Dynamic DNS updates result in records being added and deleted to DNS. But while records are correctly added, it is not always the case that the record is also correctly removed. For instance, a client could have got an IP address from DHCP and dynamically registered its A record. Maybe the client then crashed so it never removed the dynamically registered record. The address, however, is removed from DHCP after the lease expires and could later be assigned to another client – who also dynamically registers itself in DNS – resulting in two A records, both to the same IP address, but one of them incorrect. To prevent such issues DNS scavenging is required. This removes stale DNS records after a pre-defined period. 

  • Scavenging is set at 3 places on a Windows server and all three must coincide for a record to be scavenged. These places are:
    • an individual record; 
    • the zone; and
    • the server performing the scavenging. 
  • The scavenging setting on an individual record can be viewed only after selecting View > Advanced in the DNS MMC and then viewing the properties of a record. 
    • When a dynamic DNS record is created it has a timestamp (rounded down to the nearest hour when the record was created).
      • When a record is first created it is considered an “Update”.
      • When an existing record is updated with the same IP address it is considered a “Refresh”.
      • When an existing record is updated with a new IP address it is considered an “Update”.
    • Every 24 hours Windows clients will attempt to to dynamically update the DNS record. The update could be considered an update or a refresh depending on whether the IP changes as above.
    • If a record is enabled for scavenging its properties window will have a tick next to “Delete this record when it becomes stale”. 
      • Static records don’t have this ticked by default (because they are not meant to be scavenged). 
      • If this is manually ticked (for a static or dynamic record) then a timestamp will be set to when it was ticked (rounded down to the nearest hour). 
    • It is possible to set scavenging on a zone and all its records via the following command: dnscmd /ageallrecords
      • This is not recommended as it enables scavenging on all records – even static. Do not use this command on zones with static records. 
  • The scavenging setting for a zone can be viewed via the Aging button in the zone properties (by default the setting is off).
    • The aging values for a zone are replicated to all DNS servers hosting the zone.
    • Two intervals are in play here:
      • No-refresh interval: Once a record is refreshed, it is not refreshed again until this time period has passed. 
        • The purpose of this seems to be to reduce replication traffic. If a client refreshes its DNS record every 24 hours, those are ignored by the DNS server for the no-refresh interval, and not replicated to other DNS servers.  
      • Refresh interval: How much time to wait once a record is refreshed before it can be scavenged?
        • So this interval specifies how long the server should wait after a record has refreshed before it can considered it a candidate for scavenging.
        • The default value is 7 days. This means, if a record is refreshed today, the server will wait for 7 days to see if it’s refreshed again. If it is not, the server considers this record ready for scavenging. 
    • Both intervals must be passed for a record to be expired. By default both are 7 days, so what this means is:
      • If a record is created/ updated/ refreshed today, for the next 7 days the record is considered current – irrespective of whether any refreshes happen or not (because remember: during the no-refresh interval refreshes, if they happen, are ignored so the server considers the record as current for this period). 
      • After those 7 days have passed, the server checks if there are any refreshes.
        • If there are, the timestamp is accordingly updated and it goes back into waiting the no-refresh interval again. 
        • If there are no refreshes, the server now waits 7 days of refresh interval to see if any refreshes happen. If they do, the record goes back into the no-refresh interval; if there aren’t any, the record is ready for scavenging. 
    • As an aside, the default lease duration for Windows server DHCP leases is 8 days. Which is why the no-refresh interval is set to 7 days by default. During these 7 days the address won’t be allocated to any other client, nor will it change with the client, so chances of a refresh are minimal. 
      • DHCP leases and Dynamic DNS updates can conflict if clients are responsible for updating DNS with their addresses (which is usually the default).
      • Say a client got an IP address from DHCP (leased to it for 8 days, remember). The client will update that in DNS. For the next 7 days any refreshes from the client are ignored (no-fresh interval, expected). From the 7th day any refreshes/ updates will be considered.
      • Say our client went offline on the 3rd day. So on day 7 it doesn’t send a refresh – no problemo, DNS will not scavenge the record yet, it will simply wait for another 7 days.
      • On the 8th day, however, DHCP will release that IP address for others to use. Any new client that comes up will now get this address. This new client will send a Dynamic DNS update to the DNS server – creating a new A record to the same address, but with this new client’s name. Thus there are two DNS entries now to the same IP address!
      • Only after the refresh interval expires (7 days) can the old record be actually scavenged by the server (and even then there could be a delay based on the server setting – see below). 
      • For this reason it is recommended that the DHCP lease duration match the “no-refresh+refresh” interval of DNS scavenging. In the default case, either increase the DHCP lease to 14 days (7+7 days) or decrease the no-refresh and refresh intervals to 4 days (so the sum is 8 days, the DHCP lease).
        • Alternatively, allow the DHCP server to make updates on behalf of clients and disable (via GPO?) clients from registering updates with the DNS server.
          • Read this post on DHCP servers and Dynamic DNS updates.
          • Typical solution is to put all DHCP servers in a group called DnsUpdateProxy, but that’s not recommended – especially for DCs – because if a server is in this group the dynamic DNS records it creates have no security (so in the case of a DC this means the SRV records written by netlogon can be changed by anyone!)
          • It is better to create a low privilege AD user and get all DHCP users to use that account to register records. This way the dynamic DNS records are secured to that user.
          • Also note: if dynamic DNS records are written by a server in the DnsUpdateProxy group – i.e. with no security – if any other machine (even one not in this group) changes this record (because the records are open to all) the ACLs of that record will be changed to only grant that machine permissions to the record. Thus the original DHCP server will lose rights to that record. DnsUpdateProxy is not a good idea. 
        • It is important that clients be disabled from registering dynamic DNS updates in this case. Else the ACLs on the DNS record created by the client will prevent updates/ deletions from the DHCP server to the DNS server for those records.  
    • When scavenging is enabled for a zone, the “Date and time” the zone can be scavenged after value is set to the time the setting was enabled (rounded down to the nearest hour) plus the refresh interval period. 
    • It is also possible to right click a DNS server and set scavenging values for all zones on that server. These only apply to zones created after this setting was changed (unless the setting to modify existing zones is explicitly selected). 
  • The scavenging setting on the server can be enabled via the “Advanced” tab of the server properties in the DNS MMC (by default the setting is off).
    • When this setting is enabled, the scavenging period is set to a default of 7 days. The scavenging period defines how often the server will try to scavenge records. 
      • Does this mean every time the server starts scavenging all records are immediately deleted? No – because you have to also consider the no-refresh and refresh intervals of above. When a server runs its scavenging task, if a record to be scavenged has not crossed the refresh interval, it will not be removed. Similarly, if a record has crossed its refresh interval and is ready to be scavenged, if the server’s scavenging period isn’t due for a few more days nothing will happen. It’s only when the scavenging period is due that this record will be scavenged. 
    • When the server scavenges records it logs an event ID 2501 indicating how many records were scavenged. If no records were scavenged, an event ID 2502 will be logged. 
    • Note: You needn’t enable the scavenging setting on all servers hosting a zone. As long as any one server scavenges, the changes will propagate to others. In fact, it’s preferred to have only one server (or a set of servers) scavenge a zone as that will make it easier to troubleshoot. If all servers hosting a zone have scavenging on and the zone records are not being scavenged, we will have to check all these servers to see why scavenging isn’t happening. 
    • In practice, it is likely that all servers have scavenging turned on (because they are hosting multiple zones and could be responsible for scavenging one of those zones). But once a server has scavenging turned on it will scavenge any zones that has scavenging turned on. It is possible to restrict the servers that are allowed to scavenge a zone – even if the server and zone have scavenging turned on – via the dnscmd command. The syntax is as follows:

      The IP addresses are optional. If no address is given, all servers are allowed to scavenge it. Example:

      To see what servers have permissions to scavenge a zone the same command with a different switch can be used:

      Resetting this is simple – just don’t specify an IP addresses, that’s all:

The latter part of this blog post gives an example of how scavenging works with all the intervals above. In fact the whole blog post is worth a read.