Udostępnij za pośrednictwem

Dns Issue on Multi Valued Records

  • Artykuł

In a large scale environment there is a known issue which has been experienced by several customers of SRV Domain Controller records disappearing from the DNS Zone File. This is caused by the following issue;

As DNS is AD Integrated, the DNS data is stored in AD as separate objects for each record.  One of the attributes of each record object is called “dnsRecord” which basically holds the information for every DC which registers that DNS record – so, this is a mulitvalued attribute with one value per DC – so, for the site-specific records, there are only a few values – dependant on the number of DC’s in the site (in most cases only 1).  However, the other records will have a value in the dnsRecord attribute for every DC – so potentially this could be a large number of records in a large enterprise environment.  The dnsRecord attribute contains information on the server name and the timestamp for the record (amongst other things).  The timestamp is what is used to determine if this particular value within the record is stale (and hence can be scavenged as part of the DNS scavenging process) – e.g. if a DC is removed, we’d want the SRV record information to be removed from DNS accordingly.

The update of these values in AD is controlled by the Netlogon service on each DC which, by default, attempts to refresh the record data every 24 hours – however, once a record is refreshed (and the timestamp changed), the record cannot be refreshed again until the DNS NoRefresh interval has passed (7 days by default) – this is effectively to reduce replication traffic.

However, the issue we have been seeing reported from customers, is that because there are a high number of values in the dnsRecord attribute, and each DC only attempts an update every 24 hours, we have sometimes seen an issue where one DC updates the record with its own data, but before replication has completed to all other DC’s in the Domain, another DC also updates the record with its own data – and because the first change hasn’t replicated to the second DC, the dnsRecord attribute is superseded by the later one (last update wins).  Because AD replication is at the attribute level, this is standard behaviour.

The recommended “fix” to alleviate this situation and which has helped several customers is the following;

  •  Recommendation to effectively set DnsRefreshInterval to 1 hour (back to Windows 2000 default) rather than 24 hours
  •  GPO: “Computer Configuration > Administrative Templates > System > Net Logon > DC Locator DNS Records” - - - “Refresh Interval of the DC Locator DNS Records” to 3600 (in seconds – i.e. 1 hour).

This recommendation may appear in a KB article in the future  however, time of publishing is not know at this time.

Comments