The Impact of DNS on AD DS
Problems with DNS can spell disaster for an Active Directory environment. Because all servers and clients are constantly performing lookups on one another, a break in name-resolution service can severely affect Active Directory functionality.
For this and other reasons, installing a redundant DNS infrastructure in any AD DS implementation is strongly recommended. Even smaller environments should consider duplication of the primary DNS zone, and nearly as much emphasis as is put into protecting the Global Catalog AD index should be put into protecting DNS.
Security considerations for the DNS database should not be taken for granted. Secure updates to AD-integrated zones are highly recommended, and keeping DHCP servers off a domain controller can also help to secure DNS . In addition, limiting administrative access to DNS will help to mitigate problems with unauthorized “monkeying around” with DNS.
AD DS in Non-Microsoft DNS Implementations
AD DS was specifically written to be able to coexist and, in fact, utilize a non-Microsoft DNS implementation as long as that implementation supports dynamic updates and SRV records. For example, AD functions in all versions of UNIX BIND 8.1.2 or higher. With this point in mind, however, it is still recommended that an organization with a significant investment in Microsoft technologies consider hosting Active Directory DNS on Windows Server 2012 systems because functionality and security enhancements provide for the best fit in these situations.
For environments that use older versions of DNS or are not able (or willing) to host Active Directory clients directly in their databases, Active Directory DNS can simply be delegated to a separate zone in which it can be authoritative. The Windows Server 2012 systems can simply set up forwarders to the foreign DNS implementations to provide for resolution of resources in the original zone.
Using Secondary Zones in an AD DS Environment
Certain situations in Active Directory require the use of secondary zones to handle specific name resolution. For example, in peer-root domain models, where two separate trees form different namespaces within the same forest, secondaries of each DNS root were required in Windows 2000 to maintain proper forestwide synchronization.
Because each tree in a peer-root model is composed of independent domains that might not have security privileges in the other domains, a mechanism will need to be in place to allow for lookups to occur between the two trees. The creation of secondary zones in each DNS environment will provide a solution to this scenario, as illustrated in Figure 1. Windows Server 2012 now has the option of replicating these separate trees to all DNS servers in the forest, reducing the need for secondary zones. Replicating secondary zones outside of a forest is still sometimes necessary, however. Conditional forwarding and stub zones can also be used in certain cases to achieve a similar result without the need for data replication.
Figure 1. Peer-root domain DNS secondary zones.
SRV Records and Site Resolution
All AD DS clients use DNS for any type of domain-based lookups. Logons, for example, require lookups into the Active Directory for specific SRV records that indicate the location of domain controllers and Global Catalog servers. Windows Server 2012, as previously mentioned, divides the location of the SRV records into a separate zone, which is replicated to all domain controllers that have DNS installed on them.
Subdomains for each site are created in this zone; they indicate which resource is available in those specific sites, as shown in Figure 2. In a nutshell, if an SRV record in the specific site subdomain is incorrect, or another server from a different site is listed, all clients in that site are forced to authenticate in other sites. This concept is important because a common problem is that when Active Directory sites are created before they are populated with servers, an SRV record from the hub location is added to that site subdomain in DNS. When a new server is added to those sites, their SRV records join the other SRV records that were placed there when the site was created. These records are not automatically deleted, and they consequently direct clients to servers across slow wide-area network (WAN) links, often making logon times very slow.
7.2.12
Figure 2. Site-level SRV records.
In addition to the site containers, the root of these containers contains a list of all domain controllers in a specific domain. These lists are used for name resolution when a particular site server does not respond. If a site domain controller is down, clients randomly choose a domain controller in this site.
GlobalNames Zone
In some cases, using a fully qualified domain name (FQDN) is not convenient for the end users. This is especially true for novice users or in the case of very long domain names. A user entering the uniform resource locator (URL) http://intranet.convergentcomputing.com is quite likely to make a mistake in the typing. The WINS name resolution provides relief from this, in that single-label names can be used instead. This allows the user to type the URL http://intranet and still reach the desired resource.
However, with the advent of IPv6, WINS will no longer be supported as the new addressing is deployed throughout the organization. There are also many advantages of DNS over WINS, including reducing administrative overhead, single name-resolution repository, security, and open standards.
Windows Server 2012 provides a feature that was introduced in Windows Server 2008 to address this problem, specifically the GlobalNames zone (GNZ). This zone provides single-label name resolution via a DNS zone, similar to WINS. The zone is a normal forward lookup zone, albeit with a special name (GlobalNames), and is used by the DNS server in a special way. If the DNS server is unable to resolve an address in its local zones, it will then resolve the single-label address against the GNZ.
The GNZ holds out the promise of finally doing away with WINS and NetBIOS naming.
To configure the GNZ, follow these steps:
1. Launch Server Manager from a Windows 2012 server with a full GUI.
2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.
3. Right-click the DNS server to configure and select DNS Manager.
4. Select the DNS server name to configure.
5. Select the Forward Lookup Zones node.
6. Select Action, New Zone.
7. Click Next on the Welcome page.
8. Select Primary Zone and make sure that the Store the Zone in Active Directory check box is checked. Click Next.
9. Select To All DNS Servers in This Forest, and then click Next.
10. Enter the Zone name GlobalNames and click Next.
11. Leave the default Dynamic Update setting and click Next.
12. Click Finish to create the zone.
13. Open a PowerShell command prompt and enter the command Set-DnsServerGlobalNameZone -Enable $true. This command must be run on each DNS server that is expected to resolve global names, regardless of if the zone is replicated to them already.
Now the GNZ is ready to respond to queries. For any server that needs to respond to single-label queries, enter a CNAME record in the GNZ with the appropriate FQDN for the resource. The DNS server will try the GNZ after trying other local zones.
Note
The global name-resolution status of a Windows Server 2012 server can be checked with the PowerShell command Get-DnsServerGlobalNameZone. If GNZ is enabled, the Enable will show as True.
