The Domain Name System (DNS) is used to translate human-readable website names (google.com) to the IP addresses (216.58.192.228) used to route data packets to the proper destinations. Typical business networks also have DNS servers internally to handle access to resources using hostnames or aliases. The DNS server is an extremely important component to a stable and functional network.
DNS is the lynchpin making the Internet and Active Directory domain environments usable. Without DNS working correctly, a huge number of user-impacting problems can be experienced, from crazy high latency, to outright connection failure.
Public Forwarders
Forwarders should only point to public DNS servers. Use at least two, but a large list is unnecessary.
OpenDNS and Google are my go-to public name servers. Level 3 Communications (now CenturyLink, ugh) name servers are also a popular choice. CloudFlare also recently started running a public service intended to be privacy-focused and free from censorship or logging. I have high hopes for this service, but I did have some trouble when testing it out in the first few weeks after launch.
- OpenDNS – 208.67.222.222, 208.67.220.220
- Google – 8.8.8.8, 8.8.4.4
- Level 3 – 4.2.2.1, 4.2.2.2
- CloudFlare – 1.1.1.1, 1.0.0.1
Most Internet Service Providers (ISPs) also provide DNS service for customers, which may or may not be publicly accessible. My recommendation is to not use them. There are no guarantees to the reliability or load on these servers (not to mention privacy), where public servers are tried and true.
Do not set forwarders to other DCs. This defeats the purpose. DCs already synchronize DNS databases among themselves so there is no benefit forwarding a request through another DC.
Enable Root Hints. This allows name resolution if the DNS forwarders are somehow offline, though this will almost never happen.
Clean Up Root Records
Only DCs should be listed as root A records. Remove any others if they exist.
Root A records are returned when you try to access a domain without any prefix. For example, if you try to access “yatznet.com”, you will reach this website because the root record is pointed to the same place “www.yatznet.com” is going. However if I had more than one web server to host this site to serve all my honored visitors, I could add separate records for each web server. DNS would hand out the addresses in a round-robin fashion on each subsequent request.
Active Directory uses the root domain for serving core domain functions, such as the system-level file shares SYSVOL and NETLOGON. If old or stale records are still listed as root A records, the internal DNS server will dutifully hand these out in a round-robin fashion to internal users, which will fail and cause delays or timeouts.
The root record is the one with the name “(same as parent folder)”. All DCs should be listed, and nothing else should be included.
Single-Record Split-Brain DNS
Create a separate zone for each record needing to be overridden as a subdomain, with a single root A record.
This is an interesting one since I don’t see it many places, but in my opinion it makes a lot of sense. It’s something I’ve been doing for several years now and it works great. This is used when you need to override some of your public DNS zone for internally-hosted services, which is a common requirement.
If you create an authoritative zone for the full public domain, then anything not created locally will not resolve with public DNS; you effectively have to duplicate all public records internally. This can be avoided by creating separate authoritative subdomains for each overridden record, and have a single root A record serving the zone. This way, anything not explicitly overridden will recurse to the public servers.
Common uses for this are internal mail servers, firewall management, and security systems (DVRs with web interfaces).
Reverse Lookup Zones
I debated whether to include this section, but it seems to cause confusion so I figured I’d provide my thoughts.
Normal forward lookup zones are used to translate a domain name into an IP address. A reverse lookup zone does the opposite – it translates an IP address into a domain name.
In my experience, reverse lookup zones are almost never needed on an internal DNS server. They are useful on public DNS as a point of validation for spam filters, but internally they seem to just be overhead.