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
Over a decade later here I am troubleshooting a registration issue and find that the behavior is no longer as described, or perhaps needs some clarification. If none of the DNS servers assigned to the interface are writeable (such as in a domain where AD integration is not enabled) then the DNS client does issue a query to those servers to get the SOA (writeable) server information. However, if the address of the SOA server isn’t in the list of DNS servers for the interface the DNS client just logs an error in the system log saying the update failed because of error (9002) which roughly translates to DNS server failure. That’s pretty misleading because the DNS client never tried to send an update to the server address returned as the SOA so it’s not a server side error, but a client side issue of some sort. Leaving this breadcrumb in case someone else runs across the same issue.