Repeat After Me: DHCP and DNS Belong on a DC
Posted by admin on 21 May 2013 03:01 PM
When configuring any network one needs to have an understanding of just how DNS works.
If DNS is not set up correctly there are so many things that break it is not funny.
Unlike mail routing (MX records) that offer a priority system for directing mail to the final destination where the system compensates for an offline mail server DNS operates in a round robin fashion.
So, if DHCP is set up on a router and delivers the following IPs for the client’s DNS queries:
Guess how many times the client’s on-premises resource DNS queries, in general, will fail.
If you guessed “67%” then you would be right.
It seems that folks are missing the reason for “Domain” in “Domain Naming System” or DNS for short.
The primary excuse we’ve heard so far to set the above DNS server IP settings on clients and even Remote Desktop Services servers and other servers is:
There is, however, a fatal flaw in that line of reason . . . the missing “Domain” in DNS.
Or, to be blunt: A lack of understanding how DNS works on-premises and on the Internet and why the two are separate from each other.
Let’s have a look at this very crude drawing:
The left hand box is the on-premises Domain network. On that network MYDC is authoritative for that domain. Everything inside the box boundary for the network belongs to that DC and its on-premises DNS setup.
MYDC is the Start of Authority (SOA) for that domain (DOMAIN.LOCAL).
Being that our MYDC has the SOA means that no other DNS server _anywhere on the planet_ will be an authority for that domain. At least, for _that_ particular domain name in that particular location.
Not to mention the Top Level Domain (TLD) .LOCAL is not to be found anywhere on the Internet either.
What that means is that any client that queries DNS where MYSQL is will get the correct IP address from the DC that hosts the on-premises _domain’s_ DNS because that server is _authoritative_ for that domain.
Now, what happens on the client if they query DNS for MYSQL.DOMAIN.LOCAL and Google/OpenDNS server IPs are on the client’s DNS “where to query” server list and they respond?
That query goes OUTSIDE of the domain network to Google or OpenDNS and the response back is, “I have no clue who, what, or where the chicken DOMAIN.LOCAL is. Check ROOT SERVERS.” And of course, they answer same.
So, we have 67% of our on-premises queries failing DNS resolution.
Let’s think about that for a moment.
. . .
67% of our DNS queries are FAILING.
That means poor network performance, network print problems, LoBs that depend on database/SQL connections losing their connections, improper RDP routing, and so much more.
The _proper_ way to configure a domain’s DNS is as follows:
DHCP belongs on the server. Period. Full-stop.
If DHCP is on the router with DNS pointers to Google/OpenDNS or ISP DNS servers served to the on-premises DHCP clients then changes need to be made to put DHCP back where it belongs. . . on the DC.
If there is a concern about the only DC going down and leaving the clients helpless then make sure the backups are good.
If a need for redundancy is there then install an HP MicroServer with a Standard license and DCPromo that box into the domain. Make sure replication and AD integrated DNS are functioning between the now two DCs on the domain (we’ve seen situations where the second DC or RODC had no SYSVOL due to broken replication).
Or install an online cold backup device but make sure that the primary server has Software Assurance as Cold Backup is an SA only option.
For Small Business Server networks there _is_ a caveat to having another DC on the domain when in a disaster recovery situation.
In the end, a good chunk of the problems on a network such as connectivity, Line of Business application problems, performance, and more can have their source in an improperly configured DNS structure.
It is our job as IT “Professionals” to know the “WHY” things work so that we can set things up properly.
Chef de partie in the SMBKitchen