5 expert tips to help DNS work better in your AD environment
When DNS name resolution stops working, your Microsoft Active Directory (AD) environment has problems. DNS is the bedrock of your environment, and without name resolution, operations may be interrupted or grind to a halt. Possibly a name resolution issue has built up over time due to a slow migration away from a sound DNS tree hierarchy design. This could have happened as a result of decisions made by segmented groups where an immediate functional need was required but enterprise DNS design consideration fell to the wayside. Here are some key tips and troubleshooting tools to help you avoid or resolve DNS problems.
Tip 1: The DNS namespace should reflect a contiguous tree hierarchy
The Internet DNS namespace has a tree hierarchy (by design), and administration of this is delegated to DNS administrators responsible for various branches of the DNS namespace (IETF RFC 1034, RFC 1032). Like their Internet counterparts, intranet DNS admins should follow hierarchical tree design. Whenever a non-contiguous or disjoint namespace is encountered in an intranet environment, complexity will ensue in the form of the addition of conditional forwarders, stub zones, and/or secondary zones.
Take the scenario of a company acquisition, where each company has two separate, independent namespaces that must be consolidated in functionality using Windows Server trusts. A suggested approach is to create a secure VPN between both company environments at the root of each separate, continuous namespace. Use conditional forwarders to direct name queries across the VPN to the namespace on the opposite side of the VPN tunnel, as Figure 1 shows.
Figure 1: Using conditional forwarding across separate DNS namespaces on an intranet
Any queries that do not meet conditional forwarder criteria would simply be forwarded up to the ISP's DNS servers. DNS servers configured for conditional forwarding located in the root level of one contiguous namespace will forward queries to a specific DNS server located in the other contiguous namespace. A cache of namespace information is amassed on this DNS server, and the need for recursion is decreased.
Instead of using conditional forwarders, some admins choose to implement stub zones on the DNS servers in top-level intranet domains such as domain1.local and domainA.local. Stub zones contain only enough record information to be able to determine the authoritative DNS servers for the subordinate zone and are more of a consideration when zones are not stored in AD. Stub zones are a consideration when a DNS server in a parent zone needs to be kept aware of the authoritative DNS servers in the child zone. Stub zones increase complexity because when a stub zone replies to a query for a name, all authoritative DNS servers in the domain are provided in the DNS response. The goal should be to have a DNS infrastructure design that is functional and straightforward to troubleshoot.
