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:
192.168.99.5 (local DC)
192.168.99.1 (router)
8.8.8.8 (Google DNS server)
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:
I want my clients to be able to browse the Internet if the DC and DNS goes offline.
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:
On the only DC on the network
AD and DNS are properly integrated
DHCP on the server
Name Protection Set (Ticks on 2003):
Admin credentials set to update DNS with IP:
The DC NIC properties:
IP: 192.168.33.5
SN: 255.255.255.0
GW: 192.168.33.1
DNS0: 192.168.33.5 (SELF ONLY)
AD integrated DNS takes care of delivering IPs for other DC with DNS on the network. There is NO reason to put any other IP in DNS1.
DHCP configuration:
Scope Options:
003 Router: 192.168.33.1
006 DNS Servers: 192.168.33.5 (and other AD integrated DC/DNS server IPs)
015 DNS Domain Name: DOMAIN.LOCAL
That’s it. Google/OpenDNS server IPs DO NOT belong here.
DNS Server service
Forwarders Tab
OpenDNS IPs or ISP’s DNS server IPs (at least two).
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.
MPECS Inc. Blog: SBS Disaster Recovery – Secondary DC SBS Restore Caveats
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.
Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book
Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/
Windows Live Writer
Subscribe in a reader