Best Practices for Windows Server DNS And How to Avoid the Common Pitfalls
We recently finished a big overhaul for a customer of ours that involved downsizing from three physical servers to a single unit. To make a long story short, they had one server hosting file shares; another box doing Exchange; and finally a third was the domain controller and DNS/DHCP host. What a mess! In the end, we moved them toOffice 365 so the Exchange server was gone by default. File shares and AD/DNS were moved onto a single physical Dell Poweredge, and we also happened to spin up a production Hyper-V server running Server 2012 for the purposes of Remote Desktop Services.
By the way, if you are curious, Hyper-V 2012 is working great for us. No need for VMWare here, folks.
So it was a Mission Accomplished on the server consolidation and virtualization front. The bigger issues we ran into was on the DNS front. Due to some mismanagement of DNS in the past, and not following best practices, we had to clean up a few snags that were left behind by the old IT company. Not fun, and it caused a bit of crazy downtime and head-banging issues. In the end, we figured them all out, but solving DNS related problems is frustrating because it brings a lot of core infrastructure to a halt when it doesn’t work.
Internet browsing and functionality relies on DNS. Email relies on DNS. Active Directory relies on DNS, as does Remote Desktop Services. There aren’t many items in a modern workplace that don’t rely on DNS in some way. Having a screwed up backbone when it comes to DNS service can be crippling, so I don’t want you to have to go through the same thing like we did.
Talk about a hellhole of issues we were running into. From clients being unable to login over Remote Desktop Services, to group policy failing to update, down to internet connectivity being spotty or non functional for some people. It was a true rat’s nest of issues! And the best part is that all of them stemmed from poor DNS configuration and planning.
Here are some best practices that I have garnered through research and first hand experience that can save you a ton of frustration if done right from the start.
Domain computers: Proper DNS setup
This tip applies to regular computers in your domain that are getting their DNS settings manually or more realistically, from a DHCP server like Windows Server or a small business router. Most of the time, my company likes to offload DHCP to the router in offices so that if a Windows Server has to be taken offline for a short period of time, we are not affecting address handout. Routers, once configured, rarely need to go down for service. We use the rock solid Cisco RV series of units for our customers and have had great results in terms of VPN connectivity, firewall configuration, and most other things a small business needs.
Back off my tangent. On any computers at a location with DNS that is handled on the Windows Server (read: pretty much ANY Windows domain network) you need to ensure that DHCP is handing out addresses with primary and secondary DNS settings that are kosher!
For networks that have a single Windows Server handling DNS: Your primary DNS should be the Windows Server, and the secondary should ideally be the router for that location. Why do we do this? Because if the Windows Server or DNS is down for a time, at least clients can browse the internet and have some of their functionality. We do this very often at business locations so that there is no such thing as being down 100% even if the server is flaking out.
For networks with two Windows Servers handling DNS: The closest server to the workstations in question should have that unit as their primary DNS, and the remote server as their secondary. This is common in situations with branch offices. Or you can opt to have the closest Windows server as primary, and the secondary be the local router for cases where server downtime happens. It’s up to you.
Don’t EVER use public DNS servers as the entries for workstations. Public DNS like Google DNS or OpenDNS have NO IDEA about your internal network and will not be able to route login requests, file share connections, etc. These DNS providers should only be used in the Forwarding Zone section of the Windows Server for doing public domain to address lookups. I will get to that in a bit.
How DNS should be configured on the DC (or DNS host server)
There are a few key things to remember when configuring a domain controller or another server to handle DNS for the network:
- Public DNS or router addresses should NEVER be used in the primary or secondary fields.
- The only entries that should exist are the static IP of the server itself, and potentially the address of a secondary true Windows DNS server on your network.
- NEVER use the loopback address (127.0.0.1) as an entry in the DNS settings. This was kosher back in the day, but modern Windows networks do not like to see this.
Here is a photo of how a simple network card configuration should look on a Windows Server 2012 box that does double duty as a domain controller and a DNS server:
You can see that the addresses were all set manually (as you should NEVER rely on DHCP for a server unless it is not in production) and that the preferred (primary) DNS address is that of itself! If you are hosting DNS on the same box, you merely place the same IP address into the settings so that the server can “look to itself” for any DNS lookups. Sounds silly, but even DNS servers need to know where to look for their requests.
If I had a secondary DNS server on the network (a Windows server; not a router) then I would merely place that remote IP into the alternate area of the configuration.
If you are fixing a bad DNS setup with the above tips, be sure you run the following commands on the box(es) prior to allow clients to continue functioning again:
- ipconfig /flushdns
- ipconfig /registerdns
- Restart the following Windows services (by going to RUN and typing “services.msc” and pressing ENTER): DNS and NETLOGON
These tips are valid for any Windows Server, down to 2000 all the way up to the latest Server 2012 R2. DNS best practices rarely if ever change!
Each DNS server should only have one private IP assigned
This is only applicable to DNS servers that may have dual or quad or more NICs. If you don’t know how to properly configure the server to handle NIC teaming for failover or bandwidth aggregation, you should only use a single NIC and DISABLE THE OTHERS. No questions asked here. If your server is broadcasting more than one address on the network, you are confusing client PCs and potentially corrupting information in your DNS store.
We happen to use NIC teaming on Server 2012 at some customer sites, but it works well because we configured it properly so that the network only sees dual or quad connections as a single logical connection and address. You can read up on Server 2012 NIC teaming from resources like this great TechNet post.
Setting up your Forwarders in Windows Server DNS settings
To put it simply, Forwarder entries in Windows Server are used for when the server itself doesn’t know where to look for a particular address/IP resolution. For example, a user in your internal network is the first one attempting to visit Microsoft.com and the server is not able resolve the request on its own unless it had a previous entry of where this domain points to. For these common situations, we look to using Forwarders in the DNS configuration area to point our requests externally.
I won’t go into depth for how you can get to these settings, as Microsoft does a good job on the steps here. Below I am going to show how the Forwarders are setup on a client server running Server 2012 (again, DNS settings have barely changed since the Server 2003 days):
As you can see from the above, even though some purists claim that using public DNS services is not kosher, I have not once run into a problem with it – unless a site you need is blocked by that DNS provider. I have run into this in one instance with a customer that was doing some grey-area activity which I will not describe here.
How did I find which DNS servers to use?
When it comes to picking DNS servers for your Forwarders, you want a mixture of speed and security. OpenDNS is one such host that is very popular, but their servers aren’t necessarily the fastest on response times, which is crucial to having a network that doesn’t browse the net at slug-like speeds. In order to find the best combination of 2-3 servers for this instance, I just downloaded and ran Steve Gibson’s awesome DNS Benchmark tool which is 100% free and allows you to check response times among a bevy of pre-configured DNS servers which the utility has.
My best practice used to be just to use OpenDNS and perhaps Google DNS but after checking out the DNS Benchmark tool, I found that a previously unknown provider called UltraDNS actually had faster results for their nameservers and they provide similar security to OpenDNS. So my new combination was finally found!
In practical terms, what does this setup mean?
User A tries to find Microsoft.com through the internal network using their Google Chrome browser. My internal DNS server (as configured above) will try to resolve the name first through UltraDNS; if that service is down, the second attempt will be through OpenDNS; and my third attempt will be through a secondary OpenDNS address. The likelihood of one being down happens from time to time, but two being down is a rarity. Three DNS providers all being down publicly is almost unheard of.
So there you go. You CAN use public DNS providers to filter out and provide security for your DNS server, but you have to ensure the settings are properly configured in the right place. NOT on the DNS settings of the NIC card of the server OR in the settings areas of the workstations. But in the Forwarders section on the DNS configuration tool for Windows Server, you should be A-OK. And if you find that a particular server (usually the primary, which is used for over 99% of requests anyway) is blocking a critical service, you can always adjust to one of the dozens of available providers.
As a last resort, you could just call up your ISP and use their DNS servers for your needs. But they are usually the slowest and most apt to being attacked, so I rarely use these in my production environments. OpenDNS, UltraDNS, and Google DNS do a far better job in all aspects.
What should I do with IPv6 settings?
IPv6 is still in its relative infancy, and is not being used as the primary stack for private and public facing servers yet. However, this will likely be changing in the next 5-10 years. Until that happens, most technologists including myself are recommending that you merely leave the IPv6 settings at their defaults on modern servers, which is to automatically cull settings through DHCP.
This allows the stack to stay active for any purposes that MAY traverse IPv6 internally, and doesn’t take a reliant technology out of commission completely on that server. Once IPv6 starts taking over for IPv4, we may be changing the way we handle this – but again, we can’t look that far ahead yet. Leave the setting at its default and don’t worry about it for now.
If you’re curious to hear what Microsoft says about this, you can read this TechNet blog post going over why you shouldn’t be disabling IPv6.
Hope this helps you prevent any catastrophes in your own environment, and don’t hesitate to reach out to us if you are running into a DNS or Active Directory nightmare of your own. We can lend a hand!
