DNS on the Client: An Apology and a Learning Lesson
Posted by Reprinted Article on 04 June 2013 10:58 AM
Well, as mentioned on the final line in our previous post here:
“It is our job as IT “Professionals” to know the “WHY” things work so that we can set things up properly.”
And, thanks to my fellow MVP Dave Shackleford taking the time to make things a bit clearer in the comments of the blog post, I now have a clearer picture of DNS on the client side.
My mistake was pulling the server round-robin structures into client.
In the case of the client, it will _always_ poll the primary DNS (DNS0 on the NIC/DHCP) server for its resolution needs. If for any reason something happens to the primary to cause it to not answer the client will move to the secondary DNS (DNS1 on the NIC/DHCP) and poll that server for about an hour.
So, my apologies for the misleading information. Lesson learned.
And, as Dave points out, and is our experience, if something causes a break between the primary DNS server and the client moves to the router or an Internet based DNS server that client will not move back in-house for a period of time.
What this means is that we still stand by our original premise on how the on-premises network should be configured to only poll DNS servers internally.
In a pinch the edge device can be set to deliver DHCP and DNS to clients if the only DC/DNS server goes down or a secondary DC can have the DHCP Role enabled but not online for backup purposes.
Thanks again for reading! :)
Chef de partie in the SMBKitchen