Article Summary: This article provides best-practice recommendations for configuring DNS in an Active Directory domain.
For Active Directory to function as intended, proper configuration of DNS is essential. Improperly configured DNS can cause a variety of issues, including logon failures, Group Policy processing problems, and replication issues. The following list of best practices is not all-inclusive but will help ensure proper name resolution within an Active Directory domain.
- In a small environment, at least one domain controller (DC) should be a DNS server. It is possible to install DNS on servers which are not DCs, including non-Windows servers, but installing DNS on DCs allows the use of AD-integrated lookup zones (see below), which improve security and simplify zone replication.
- In a larger environment, at least two domain controllers at each physical site should be DNS servers. This provides redundancy in the event that one DC goes offline unexpectedly. Note that domain-joined machines must be configured to use multiple DNS servers in order to take advantage of this.
- If multiple DCs are configured as DNS servers, they should be configured to use each other for resolution first and themselves second. Each DC's list of DNS servers should include its own address, but not as the first server in the list. If a DC uses only itself for resolution, it may stop replicating with other DCs. This is obviously not an issue in a domain with only one DC.
- All domain-joined computers must use only internal DNS servers. If a domain-joined computer is configured to use an external server as an alternate DNS server, a temporary lack of connectivity to an internal DNS server will cause that machine to begin using the external server for resolution. That external server will be unable to resolve queries for anything inside the AD domain, and the client machine will not automatically revert to the internal DNS server when connectivity is restored. This generally manifests itself as an inability to access resources in the domain from the affected machine. Be advised that if you are using a small-office/home-office (SOHO) router to assign DHCP addresses to client machines, it will likely also assign external DNS servers to those clients unless it has been manually configured to do otherwise.
- In a multi-site environment, domain members should be configured to use the DNS servers at their local site before those at a different site. This minimizes the amount of DNS traffic crossing slower WAN links.
- Use Active Directory-integrated DNS zones to improve security and simplify DNS replication. AD-integrated DNS zones are stored in directory partitions within Active Directory. These directory partitions replicate along with the rest of AD; therefore, no extra configuration (i.e., zone transfer setup) is required for DNS replication. Further, AD-integrated zones allow the use of secure dynamic updates. This prevents updates to DNS records from machines which are unable to authenticate with the domain.
- Unless there is a compelling reason to do otherwise, DNS zones should allow only secure dynamic updates. Allowing unsecure dynamic updates can enable machines which aren't part of the domain to modify records on the domain's DNS servers, which is a security risk. Disabling dynamic updates altogether, on the other hand, secures the DNS records but makes management of the domain more difficult.
- Configure forwarders or root hints for external name resolution in an Internet-connected environment. Forwarders can provide a faster response to external queries, but they are less redundant than the 374 widely distributed root DNS servers that exist as of this writing. Root hints are present by default on Windows servers, but forwarders must be configured manually.
- DNS servers within a domain should not use each other as forwarders. Forwarders are servers to which a DNS server will send queries that it can't answer (i.e., queries for records in zones that it doesn't host). DNS servers within a domain will typically all host the same zones, so if one of them is unable to answer a given query, they all will be unable to do so, and forwarding that query from one server to another will simply cause delays.
- Configure aging and scavenging to avoid stale DNS records. Properly configuring aging and scavenging ensures that stale records (those older than a certain age, which is configurable) will be purged from DNS automatically.
- Use the DNS Best Practice Analyzer. The DNS BPA checks for more items than are documented here and provides guidelines for resolving any issues it finds. More information about the DNS BPA is available at Best Practices Analyzer for Domain Name System.
: For further and detailed information regarding DNS Best Practices, refer to Microsoft official documentation accordingly to your operating system version/edition.