SON SON
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!
AUTHOR
Casper Manes