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 to Office 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:

proper-dns-setup-01

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):

proper-dns-setup-02

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!

Share →

14 Responses to Best Practices for Windows Server DNS And How to Avoid the Common Pitfalls

  1. Phillip Croxford says:

    Thank you for such a good write up, I have been in the IT industry since the age of windows server 2003, and only ever setup 1 DNS server for my small workplace.
    and to be honest you opened my eyes up abit as i really dabble with DNS, it just works as i put it,
    but if i should ever run into any problems i sure will be taking advise from here!

    Thanks! 🙂

  2. Graeme says:

    Sometimes you stumble across something on the internet that makes your day…. this is todays. Thank you, thank you, thank you.

    I too had been left a terrible mess, and this has helped sort it out. I have also learnt something today about DNS.

    A (slightly) happier techie.

  3. MikeTR says:

    I’m a one-man IT department with no formal IT training.

    This is a very helpful article. I feel like my DNS knowledge has increased exponentially.

    Thanks so much for this!

  4. jay says:

    agreed with the above comments. This was really thorough, clearly broken down, and well advised. Thanks!

  5. Kevin Maire says:

    Thank you for the clear and concise information. I do have a question though – If you have two domain controllers on the same physical LAN and subnet and both have DNS, should they both be primary, or should one be secondary?

  6. dwlodarz says:

    In a case like that Kevin, you would do as such:
    Server 1: Primary DNS should be itself; secondary the other server
    Server 2: Primary DNS should be itself; secondary the other server

    This way, each considers itself a primary, and the other box as its backup. This adds resiliency to your setup and ensures little downtime in case of server maintenance or outages. Hope this helps!

  7. Kevin Maire says:

    dwloadarz – Thank you. I’m sorry I wasn’t clear. I’m speaking of the DNS Manager on the server. In the forward lookup zones, right-click the zone and click Properties, Type, Primary zone or secondary zone? By default when I add the second DC including DNS, the DNS server on the second DC says it’s a Active Directory-Integrated and primary too.

    Thank you.

  8. dwlodarz says:

    Hey Kevin,

    That behavior is normal and actually ideal in an AD environment! Per Microsoft:

    You may want to add additional DNS servers so there is no single point of failure. Instead of adding standard secondary DNS servers, you can convert the server from a primary DNS server to an Active Directory Integrated Primary server and configure another domain controller to be a DNS server. With integrated primary servers, all the servers are primary servers, so when a zone change is made at one server, it is replicated to the others, eliminating the requirement for a zone transfer.

    Your setup is following “best practices” so no need to change anything.

    Source: https://support.microsoft.com/en-us/kb/816101

  9. musccounty says:

    First, great article that we found informative and direct.

    We have 4 subnets, each with at least 1 domain controller that acts as the DNS server and the DHCP server. Currently we have our PDC emulator set as the “primary” DNS server and its forwarders set to our local ISP, but none of the other DNS servers have forwarders set. If the PDC is offline for any reason, users lose access to the web, but internal server access is unaffected.

    A consultant that we we work with at times when we run into issues that we are unable to resolve, says that we should not be using any forwarders and rely on root hints.

    Should we set each of our DNS servers to use forwarders?

    When we originally migrated from NT to 2000, we had each of the DNS servers set to use forwarders, but this became cumbersome to maintain as servers were added and retired and the consultant recommended not using them. Of course not using forwarders has caused its own set of issues.

  10. emy says:

    can you help me please to do my project ?! 🙁

  11. emy says:

    The project is about WIFI INFRASTRUCTURE – connecting with DC/DNS

  12. emy says:

    pleeeeeeeeeeeeeeeeeeeeeaz 🙁 :(( 🙁

  13. Hi dwlodarz,

    I have a question about best practices and which DNS servers should clients use in two offices:

    Headquarters and branch office are connected with a site-to-site vpn and headquarters are hosting the Exchange services. Each site has its own DNS Server(HQ DNS and REMOTE DNS) in the same domain and replicating over the VPN Tunnel

    1)clients in the remote office have a primary DNS server = REMOTE DNS (so their closest server), secondary server ISP DNS
    2) or scenario 2, clients in the remote office have a primary DNS server = HQ DNS, secondary server ISP DNS

    As long as the VPN Tunnel is up and running, then no issues and Scenario 1 will be preferable. When VPN Tunnel is down, then remote clients cannot access public-facing resources like Exchange because they are resolving IPs on the other side of the vpn tunnel, which is not available.

    Would it make sense to keep scenario2 and have a secondary server on remote office clients to be a ISP DNS, so when VPN tunnel is down, they can reach public-facing resources with the public DNS resolution ?

  14. Zak says:

    I feel like crying! Wish I’d read this earlier. Just came off a nightmare day with our company network down all day.

    Had DNS running on an old 2003 server. Installed a new 2012 DC with DNS, and pointed clients to new 2012 box. Had old domain as .local, which was used purely for RDP, no clients joined to domain. I made the new 2012 box as .co.za thinking there’ll be no clashing.

    In an attempt to not reconfigure clients with static DNS settings, I gave the new server a 2nd IP (matching the old box) and changed the IP of the old server.

    Got to work this morning, and not sure what you place. Looks like some replication occurred. Huge screw up to put things mildly. Well we learn every day

Leave a Reply

Your email address will not be published.