If you are running DNS services on a Windows server, then you’ve probably got Active Directory running, your DNS servers are also your domain controllers, and you have your clients configured to use their nearest DC for DNS. That’s a good start, but there are several misconfigurations in DNS that come up again and again. Let’s review nine mistakes that can cause problems with any network environment when DNS server is not configured correctly.
1. Setting up the lonely island
When you set up your first domain controller in a forest, you really have no choice but to point the server to itself for DNS. However, don’t leave it that way, or do that for any other server. As soon as your second domain controller is up and running, reconfigure the first to use the second for DNS, and the second to use the first. Once you build a third, add that one into the mix so no DC must rely upon itself for DNS (using its local ip.addr or 127.0.0.1.). When domain controllers use themselves for DNS, especially when DNS is AD integrated, they can become islands and start to fail replication. When they use other DCs for DNS, you will find fewer overall issues with AD replication.
2. DNS servers too far away from clients
Keep DNS response times fast for your clients. I strive for under 25ms, but under 50ms is good enough. To do that, you need to have a DNS server local to your clients. If you don’t have domain controllers in every site, you should at least deploy a caching-only DNS server on some system in the location, such as the File and Print server. With DNS close by, all other apps will perform better because name resolution happens locally.
3. Not storing AD zones in AD
AD integrated zones are stored and replicated with Active Directory, and can be configured to replicate to all DNS servers in the domain or the forest. That provides high availability, fault tolerance, and easy setup when running DNS on domain controllers. It’s the best way to go for your internal DNS.
4. Requiring secure updates
This may cause some comments, but bear with me for a moment. When you run AD integrated DNS, you have the option to permit dynamic updates and require that they be secure … meaning authenticated by domain members. All your servers and workstations (that are domain-joined and running Windows) can automatically register themselves into DNS. That’s great if you are a pure Windows shop, but if you have Linux or Mac clients and servers out there, it leaves them in the cold. Allow dynamic updates, or if your non-domain-joined systems are all workstations, compromise and allow DHCP to register DNS records for clients. The more systems you have registered in DNS, the easier it is for you to find, and manage, them.
5. Not setting up the PTRs
Reverse DNS records, called PTR records, resolve ip.addrs to names, making it much easier to run down a system when you know what IP it has, but not what it is. Far too often, admins opt to skip out on setting up the in-addr.arpa zones that hold the PTR records, breaking this often critical functionality. Don’t be that guy!
6. Forwarding far, far away
Just as you want to keep DNS servers close to clients, you want your DNS servers to resolve as close to themselves as possible. More and more services on the Internet today are taking advantage of CDNs and multiple instances that leverage GeoDNS or other site aware approaches to provide local responses to globally distributed clients. If your domain controller in the Tokyo office is set to forward to the domain controller in Dallas for resolution, you’re going to find things on the Internet are unnecessarily slow for your users in Japan, both because that’s a long way to go to resolve a name, and the name resolved won’t be local to the users more often than not.
7. Setting up a forwarding loop
Want to take down a WAN connection in two easy steps? Configure the DNS server in location A to forward to the server in location B. Configure the DNS server in location B to forward to the server in location A. Query one of them for a name. It doesn’t matter what name, as long as it is in a domain for which neither is authoritative. Query A, but A won’t know, so it will query B. B won’t know, so it will query A. It doesn’t matter that A asked it, it will still query A. And A won’t care that it just asked B the same question … it got a query, it won’t know the answer, so it will query B. DNS queries are stateless. There’s no TTL or origin marker or anything else. The two servers will loop the query to one another ad infinitum until you kill one of them or the network goes down. Sure, that’s fun for stress testing the network, but not so much for getting work done.
8. Not setting up aging and scavenging
Just as your clients and your DHCP servers both should be allowed to dynamically register DNS records, those records should be maintained. Windows DNS offers aging and scavenging, which looks at records older than X days, and removes them from DNS. However, this is off by default, which can lead to old or out-of-date data in DNS, including registrations for systems that you shut down ages ago. Keeping DNS clean makes it easier to find resources and troubleshoot issues. Aging and scavenging ensures DNS is kept clean automatically.
9. Allowing zone transfers externally, and not allowing them internally
Zone transfers enable a DNS server to provide the entire set of records for a namespace in response to a single query. When one DNS server in an authoritative zone needs to update its full zone file, or when an admin needs to check on things, that makes it easy to see the entire zone. But on the outside, allowing zone transfers makes it far too easy for an attacker to do reconnaissance. Zone transfers internally should be allowed to help admins do their jobs. Externally, you should not allow zone transfers other than to the other DNS servers you control, so that someone scoping you out at least must work for it!
Remember the old saying, “If DNS ain’t happy, ain’t nobody happy.” Getting DNS set up correctly and ensuring it remains that way is key to making sure your network, your applications, and your users all have the best experiences. Avoiding these nine pitfalls helps to make sure that happens.
#1 Is TERRIBLY WRONG — awful advice.
The correct method is “Self First” (As Preferred DNS), then other DCS as alternates.
Otherwise you lose DNS resolution when “other DC” goes down.
On RARE occasions (e.g., failed/restored DCs) you will need to “cross point” one or more temporarily to get DNS/AD replication working again..
what if you have DNS A primary DNS set to DNS B, but A’s alternative server set to itself? Then shouldnt DNS resolution still occur even if B goes down?
I’ve had a few people say what Herb Martin has said above.
I’ve got email evidence from Microsoft Partner advisory and from partner support that DC1 looks at DC2 for primary and itself for secondary. ALso the best practice will place it this way too.
1.You should never put the loopback address as primary
2. It’s best that DC’s look at each other rather then themselves.
I always set DNS to itself, as Herb Martin says. To the best of my knowledge, DNS replication partners are not defined as the primary DNS server.
Herb and Lewis, check Microsoft’s best practices. Self should NOT be primary DNS.
A small addition to #9 as DNS seems to be broken since server 2012 and microsoft can’t be bothered to fix it: https://support.microsoft.com/en-ca/help/4041821/secondary-dns-server-does-not-work-reliably-in-windows-server-2012
I know this is very old, but Herb’s advice is not best practice according to Microsoft. By default when dcpromo-ing a new domain controller, it will use whatever resolvers were previously set as the primary (ies), and the loopback as the last resolver.
From Microsoft:
“The inclusion of its own IP address in the list of DNS servers improves performance and increases availability of DNS servers. However, if the DNS server is also a domain controller and it points only to itself for name resolution, it can become an island and fail to replicate with other domain controllers. For this reason, use caution when configuring the loopback address on an adapter if the server is also a domain controller. The loopback address should be configured only as a secondary or tertiary DNS server on a domain controller.”
There’s no small amount of debate about this, and this “self-last” setup may not make sense if you have multiple sites connected by a slow WAN link. See: https://social.technet.microsoft.com/Forums/ie/en-US/fe204b88-0a50-43d0-bde5-ab22477f1ea5/best-practices-for-dns-order-on-domain-controllers?forum=winserverNIS
The #1 advice 1 is an old advice, it’s obsolete. It refears to this KB:
https://support.microsoft.com/en-us/help/275278/dns-server-becomes-an-island-when-a-domain-controller-points-to-itself
That KB applies to Windows 2000; as you can see, on Windows Server 2003 the island effect was mitigated and the MS recomendation is to set loopback as first resolver:
https://blogs.technet.microsoft.com/notesfromthefield/2008/03/25/dns-client-configuration-for-windows-dns-servers/
So, why when you run the BPA on a 2016 DNS server, does it tell you that you are not following best practices if you have the servers IP as the first DNS entry?
Fernando, the article you posted is from 2008. Here is one from 2013 where Microsoft again says do not use loopback as first address. It seems MS can’t even figure out what the correct configuration should be.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff807362(v=ws.10)?redirectedfrom=MSDN