DNS Dynamic Update Through Secondary Read Only DNS Servers. You must unlearn what you have learned.

I’m writing this article to describe how Dynamic DNS update operates on Windows in regards to which DNS server it chooses to send its update to, as I commonly hear the same response from people when discussing how this feature works. As Yoda would say, you must unlearn what you have learned.

I’ll probably end up with a lot of DNS articles – I don’t know why, but it’s always been a fascination.

DNS resolution is a system wide problem not an interface wide problem. Yet Windows still has DNS configuration per interface which is extremely misleading as to how the resolver works. I’ve heard many people indicate that they can configure different DNS servers per interface, and that the system will choose the correct one. In fact, Windows more or less combines the DNS server list from each interface, and then hits them all up for a response (there’s a little more to it than that, but not much).

It is often assumed that DNS dynamic registration on Windows will attempt to register the interface IP and system fully qualified domain name (FQDN) with the DNS server configured on a particular interface. What actually happens though is the system determines what its FQDN is, and then attempts to locate a writable DNS server for that domain.

In traditional DNS configurations, there is only one writable DNS server per domain (the master). The DNS Start Of Authority (SOA) record identifies the writable master DNS server for a domain, where as the Name Server NS records identify all DNS servers for a domain (including the read-only slave servers).

Microsoft Active Directory integrated DNS however does not typically rely on DNS master/slave zone transfers to replicate zone information. Instead, it uses the multi-master Active Directory replication service to replicate DNS zones. As such, there are typically multiple writable DNS servers for an Active Directory integrated domain.

Back to the question though. How does Dynamic Registration on Windows work…. The DNS Client will determine its FQDN and then use the configured DNS servers to locate the writable DNS server for that domain. An SOA query is sent for the client’s domain, it returns the name of the writable DNS server and then the DNS client then sends the registration update directly to this server – not the locally configured DNS servers.

In a Microsoft world, any Domain Controller/DNS server hosting an integrated zone will reply to an SOA query with its own host name as the master server,  as it contains a writable copy.

So where is this useful? In a largely Microsoft environment, typically the locally configured DNS server will be Active Directory integrated and thus able to accept DNS registration requests. In a more complex enterprise however, the DNS client may need to track down a different DNS server to process its DNS registration request. Either way, the DNS Client service works it all out.

Understanding this process creates more flexibility in DNS enterprise designs.

~ Mike

Leave a comment