Thursday, June 2, 2011

DNS in an Active Directory Domain Services Environment

DNS is inseparable from Active Directory. In fact, the two are often confused for one another because of the similarities in their logical structures.

Active Directory uses a hierarchical X.500-based structure that was designed to map into the DNS hierarchy, hence the similarities. In addition, Active Directory utilizes DNS for all internal lookups, from client logons to global catalog lookups. Subsequently, strong consideration into how DNS integrates with Active Directory is required for those considering deploying or upgrading AD.


The Impact of DNS on Active Directory Domain Services
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 Active Directory Domain Services 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.


Active Directory Domain Services in Non-Microsoft DNS Implementations
Active Directory Domain Services 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 will function 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 2008 R2 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 2008 R2 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. Windows Server 2008 R2 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.


SRV Records and Site Resolution
All Active Directory Domain Services 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 2008 R2, 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. 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.

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 2008 R2 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 GlobalNames zone. The GNZ holds out the promise of finally doing away with WINS and NetBIOS naming.

To configure the GlobalNames zone, execute the following steps:
1. Launch Server Manager.

2. Expand the Roles, DNS Server, and DNS nodes, and then select the server name.

3. Select the Forward Lookup Zones node.

4. Select Action, New Zone.

5. Click Next on the Welcome page.

6. Select Primary Zone and make sure that the Store the Zone in Active Directory check box is checked. Click Next.

7. Select To All DNS Servers in This Forest, and click Next.

8. Enter the Zone name GlobalNames and click Next.

9. Leave the default Dynamic Update setting and click Next.

10. Click Finish to create the zone.

11. Open a command prompt and enter the command dnscmd /config
/EnableGlobalNamesSupport 1. The message “Registry property
EnableGlobalNamesSupport successfully reset” should be returned. This command
must be run on each DNS server that is expected to resolve GlobalNames, regardless
of if the zone is replicated to them already.

Now the GlobalNames zone is ready to respond to queries. For any server that needs to respond to single-label queries, enter a CNAME record in the GlobalNames zone with the appropriate FQDN for the resource. The DNS server will try the GlobalNames zone after trying other local zones.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

No comments: