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.
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/
7 comments:
Hi Phil,
First, I'd like to thanks you for the amount of information available on your blog, it's really useful and easy to read (as opposed to some technet articles).
In case of DC down, (for really small SMB with only 1 server), to get them back on the internet (before we get on site), we usually logon to the main router and re-activate the DHCP (incl DNS). It may not be the best way but it can get our customers back "online" (internet + external emails only) rather quickly.
Once again thanks for all the informations.
Bertrandep,
Our position is specific to the production network setup online at any given time.
Yes, in the case of a failed DC one can fire up DHCP on the router and have the clients Release&&Renew to get their external resolution going.
We have in some cases had a backup DC in place where the main SBS went down. We would then fire up DHCP on that backup DC while things were being worked out with SBS. In that case, e-mail was in-house anyway (though ExchangeDefender has offline access for clients in the LiveArchive feature).
That is how we discovered the SBS second DC caveats. :)
As a short-term fall-back your method is indeed a good one.
Thanks,
Philip
Philip,
Good article. I totally agree everything works better when both DNS and DHCP are handled by the DC.
I set my DHCP server credentials to use a standard Domain User account. Administrator credentials aren't required for it, and besides the reduced security risks, as admin passwords are changed it is one less service to worry about updating.
This is a really in depth article on all things DNS and DHCP for Windows server environments that I have followed:
http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx
Also, Server 2012 apparently introduces more versatile DHCP where if a server goes down at one site (or on one server), another could take over. There is some info here: http://blogs.technet.com/b/teamdhcp/archive/2012/06/28/ensuring-high-availability-of-dhcp-using-windows-server-2012-dhcp-failover.aspx
Doug
Hi Philip,
I totally agree with the title and the message of the article. However, I am pretty sure that round robin is not used by DNS on the client side but on the server side to rotate between different A records. When I configure my network adapter with both a primary and a secondary DNS every lookup is resolved by the primary (I tested it with nslookup), except when the primary DNS server fails. So for this very reason I enter the ISP DNS as secondary like you descriped in your article.
I don't see a reason why you can't have DHCP on a router and still not have a proper working Domain environment. I've done this in my shop so that if the primary Domain Controller does need to be rebooted, clients still get an IP from the router. I have configured the router to provide my DNS suffix (domain.local) and the Primary and Secondary DC as the DNS IP addresses. This way if one DC/DNS server goes down, clients can still get an IP address from the router and rely on the other DC/DNS server for internet access. Also, because most windows clients should be setup to register themselves in DNS, their entries will be added/updated in the DNS server.
Huig, the problem with using an ISP's DNS server as the secondary is that if the primary fails to be available for even a single lookup, the client will then use the secondary DNS and not switch back for quite a while. It does not try the primary and then the secondary for each query--it actually stops trying the primary (removes it from it's temp cache of DNS servers and recreates a new list without it) if the primary is ever unavailable. So if you rebooted the switch that your server was connected to, that may cause the client to start using the ISP DNS server and AD-lookups and authentication would begin to fail on that workstation, even though the DC/DNS server was still available. Many other clients in the office would probably not have the issue, so it would be difficult to troubleshoot...but eventually rebooting that workstation would resolve it, and you'd blame it on a networking glitch that workstation was having.
And that's something I learned today, thanks Dave. Unfortunately, this doesn't make things easier. It makes me consider configuring a sec. DNS with the disadvantages Dave describes or enabling DHCP on the router and reboot which requires an manual action.
Post a Comment