Active Directory Insights (Part 1): Configuring DNS on domain controllers

By /

If you would like to read the other parts in this article series please go to:

Introduction

There are various ways you can trip yourself up when you set up and configure Active Directory for your organization. Misconfigured settings, inadequate maintenance procedures, and other mistakes can result in consequences that can range from poor performance to unsupportablility. My goal in this series of articles is to highlight some of the more common mistakes made in configuring, managing and maintaining Active Directory environments running supported versions of Windows Server. Many of the insights and recommendations that I’ll be sharing in these articles have been gathered from communications with various colleagues who are IT administrators or consultants working in the field. Some of the suggestions were also contributed by various experts I know who work at Microsoft Corporation.

However, it’s important that you understand that I’m only offering my own personal suggestions in these articles here on WindowsNetworking.com and am not providing any “official” guidance on the issues being discussed. For official recommendations you should always consult Microsoft TechNet or articles in the Microsoft Knowledge Base or some other Microsoft collateral. So please take everything in these articles “as is” with no warranties or guarantees.

Using the loopback address on domain controllers running Windows Server 2008 and Windows Server 2008 R2

The first issue we will examine is whether it’s a good idea or not for a domain controller to have the loopback address configured in its DNS client settings. Specifically, is it OK for a domain controller that also has the DNS Server role installed on it to have the address 127.0.0.1 in its TCP/IP settings for either the preferred (primary) or alternate (secondary) DNS server? Or should you use the actual IP address assigned to the network adapter on the domain controller instead? 

If you search TechNet for some official guidance on this matter, you may feel a bit confused afterwards. For example, in this post made in 2010 to the Ask The Directory Services Team blog the following questions are asked:

“What is Microsoft’s best practice for where and how many DNS servers exist? What about for configuring DNS client settings on DC’s and members?”

The immediate answer given is this:

“It depends on who you ask. 🙂 We in MS have been arguing this amongst ourselves for 11 years now.”

The poster then goes on however to state the following:

“When referencing a DNS server on itself, a DNS client should always use a loopback address and not a real IP address.”

So if you read the above you may feel that Microsoft is saying you should always use the loopback address instead of the actual address assigned to the network adapter when you configure the DNS client settings on a domain controller. But if you read the comments made to this post you’ll find a clarification from the poster that the key thing is to not use the loopback address as the preferred (primary) DNS server and only use it for alternate (secondary) DNS servers. The reasons for this are to avoid race conditions that might slow down the boot process for the domain controller and to make sure you don’t end up with DNS “islands” that can’t communicate with each other within your Active Directory environment.

Using the loopback address on domain controllers running Windows Server 2012 and Windows Server 2012 R2

Note however that the blog post referenced above was made during the Windows Server 2008 R2 timeframe, so the question naturally arises as to whether this guidance has changed with Windows Server 2012 and Windows Server 2012 R2. Specifically, while it’s clear that the loopback address should not be the first IP address in the list of DNS servers configured for the domain controller, the question remains: Is it better to use the domain controller’s actual IP address or the loopback address when referring the DNS client to the DNS server role on the domain controller itself?

The answer for this can basically be inferred from two TechNet articles describing the Best Practices Analyzer for Domain Name System. The first article is called DNS: DNS servers on <adapter name> should include their own IP addresses on their interface lists of DNS servers, and the relevant statements on this page are these:

“The inclusion of its own IP address in the list of DNS servers improves performance and increases availability of DNS servers.”

The second article is called DNS servers on <adapter name> should include the loopback address, but not as the first entry, and the relevant information here is:

“The loopback address should be configured only as a secondary or tertiary DNS server on a domain controller. If the loopback IP address is the first entry in the list of DNS servers, Active Directory might be unable to find its replication partners.”

Error when running the dcdiag /test:dns command

From the above TechNet articles, it sounds as if it’s quite OK to use the loopback address instead of the domain controller’s actual IP address in the DNS Client configuration of the domain controller–as long as you don’t use the loopback address (or the actual IP address!) as the preferred (primary) DNS Server for the domain controller. Unless of course you only have one domain controller in your environment, which is not a good idea of course because it leaves you with a single point of failure for identity and access to your network.

However, I have heard a few reports from the IT community that have left me feeling a bit concerned about using the loopback address in the DNS Client configuration of a domain controller. For example, I’ve heard a few reports that use of the loopback address as a secondary or tertiary DNS Server address has sometimes resulted in failures when running the dcdiag /test:dns command (see “DNS Test Syntax” on for details of this command). Specifically, one colleague reported the following error in this scenario:

Error details: 10054 (Type: Win32 – Description: An existing connection was forcibly closed by the remote host.)

The colleague reported that when the loopback address was replaced with the actual IP address for the domain controller, the dcdiag /test:dns command completed successfully without errors. However, when I asked some experts at Microsoft concerning this, one of them said that the problem was actually with the dcdiag command and not with the DNS configuration on the domain controller. Specifically, this error may happen when you run dcdiag remotely but it doesn’t occur when you run the command locally on the domain controller that hosts the DNS zone. So the error seems to be with the troubleshooting tool (dcdiag) and not with the DNS configuration of the domain controller that you’re trying to troubleshoot.

DNS configuration for domain controllers in central site vs branch sites

An interesting question arises however with configuring the DNS settings on domain controllers in large “hub and spoke” Active Directory environments where you have a large central site and a number of smaller branch office sites. I’ve been advised by one colleague who is very experienced with large AD environments that the proper way of doing this is as follows:

Central (hub) site:

  • Primary DNS – another DNS server in the central (hub) site
  • Secondary DNS – another DNS server (a different one than above) in the central (hub) site
  • Tertiary DNS – the local server (using either loopback or actual address)

Branch sites:

  • Primary DNS – a DNS server in the central (hub) site
  • Secondary DNS – another DNS server in the same branch site (or a DNS server in a different branch site)
  • Tertiary DNS – the local server (using either loopback or actual address)

On the other hand, another colleague who also has similar long-time experience with large AD deployments tells me that the correct way of doing it is to configure the DNS on ALL of the domain controllers (i.e. in both the central site and the branch offices) like this:

  • Primary DNS – a DNS server in the central (hub) site (but not the local DNS server)
  • Secondary DNS – a different DNS server in the central (hub) site (but again not the local DNS server)
  • Tertiary DNS – a different DNS server in the central (hub) site (but again not the local DNS server)
  • Quaternary DNS for local server in central (hub) site – a different DNS server in the central (hub) site (but again not the local DNS server)
  • Quaternary DNS for local server in branch site – a different DNS server in the same branch site
  • Quinary DNS – the local server (using either loopback or actual address)

Regardless of which of these schemes you decide to follow, you might have to vary them depending upon the connectivity, bandwidth and latency between the different sites involved. Remember also that you may be able to mitigate latency issues that can affect DNS resolution by deploying caching-only name servers and utilizing conditional forwarding.

Testing possible failure scenarios

Finally, whichever scheme you use for configuring DNS Server settings on domain controllers in your Active Directory environment, you may want to also conduct a test to see what happens if all of the domain controllers in a site are suddenly shut down, either gracefully or by an abrupt power failure. I’ve actually heard a report of an organization that had two domain controllers in their central site where each domain controller pointed to the other as its preferred DNS server and to itself as its alternate DNS server, and when both domain controllers were restarted at the same time after having patches applied, the Active Directory services of neither of them were able to restart afterwards. I’m not sure why this would happen, but I’m told it did. So the moral of the story is, however you configure the DNS Client on your domain controllers, be sure to test your setup thoroughly!

If you would like to read the other parts in this article series please go to:

About The Author

Mitch Tulloch is Senior Editor of both WServerNews and FitITproNews and is a widely recognized expert on Windows Server and cloud technologies. He has written more than a thousand articles and has authored or been series editor for over 50 books for Microsoft Press and other publishers. Mitch has also been a twelve-time recipient of the Microsoft Most Valuable Professional (MVP) award in the technical category of Cloud and Datacenter Management. He currently runs an IT content development business in Winnipeg, Canada.

Read Next

Static vs Dynamic IP Address

Static vs Dynamic IP Address

Most people are familiar with Internet Protocol (IP) Addresses, but many people don’t know you have 2 types. In this article, you’ll learn about static…

Read More »

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top