Chapter 8. Integrating with Active Directory
With the release of Windows 2000, Microsoft
In fact, using DNS for name resolution is one of the major improvements of Active Directory over Windows NT, which relied on the Windows Internet Naming Service (WINS). Microsoft made the decision to develop WINS in the early days of Windows NT because, at the time, DNS did not support dynamic update capability, which Microsoft needed for its
Even with the opportunity to get rid of WINS, migrating to Active Directory hasn't always resulted in a harmonious union between AD and DNS administrators. While Windows NT had virtually no DNS requirement, Active Directory is at the
This chapter explores many of the key DNS-
8.1 Active Directory Domains
One of the first issues you have to consider when implementing an Active Directory infrastructure is how many domains you need and what to
The number of domains you create in your forest is largely dependent on your administrative and replication requirements. A domain is mastered by one or more domain controllers, which are servers that have
8.1.1 Domains, Domain Trees, and Forests
Domain trees and forests are two important Active Directory concepts. A
is simply a collection of one or more domains that share a common namespace. The
domains would be
A forest is a collection of one or more domain trees. The domains in the movie.edu domain tree and the example.com domain tree could be part of the same forest. A domain tree is based on a common namespace, but a forest is not.
A forest is named after the first domain created in the forest. If
was the first domain we created, the forest is automatically named
. We can then create additional domains for
All domains within a forest, regardless of which domain tree they are part of, are trusted by each other from an authentication and authorization perspective. For this reason, the forest is considered the primary security boundary in Active Directory. By making the example.com domain part of the movie.edu forest, users in example.com , by default, have read access to much of the information in the movie.edu domains, and vice versa. Also, users in example.com can have control delegated to them over objects in the movie.edu domains and vice versa. If example.com is created in a separate forest, the users in that domain do not have access to the movie.edu forest, and they cannot have access delegated to it (unless a special cross-forest trust is created between the two forests). 
8.1.2 Domain Models
Two Active Directory domain models are commonly used. Your choice of domain model is important because it dictates DNS requirements, as we discuss later. One model consists of an empty root domain with geographic or organizational subdomains. We recommend that you do not create organizational-based subdomains if you can help it since they are very likely to change at some point. 
Some of the benefits of the multidomain model include the ability to delegate administration for management of portions of a forest, greater control over how data is replicated within the forest, and decreased exposure to problems that can impact a single domain. For example, if an application went out of control and mistakenly started creating tons of objects in a domain, at some point the hard disk on the domain controllers in that domain would fill up. The domain would then enter an unstable and possibly unusable state. However, the domain controllers in other domains would continue to function without much impact. This example is admittedly contrived, but it shows you the benefits of autonomy in the multidomain model.
The downsides of this model include the increased support costs of setting up additional domain controllers—remember that each domain must have its own set of domain controllers—and additional domain configuration (configuring security,
The other common domain model is simply a single domain. Over time, many organizations have come to recognize the increased support costs associated with supporting additional domains and have found that their initial reasons for needing multiple domains may no longer be valid. With a single domain, you typically need fewer domain controllers, which results in decreased costs. Also, the global catalog does not play as big a role because you do not need to search across multiple domains.
The downside to the single domain model is decreased flexibility in replicating data. Since all of your objects are in a single domain, wherever you need to deploy a domain controller, you have to replicate all of the objects in the domain to it. This type of model does not lend itself well to branch office deployments where you have a lot of domain controllers, many of which may have slow WAN connections.
There are variations to these models, but this should give you the general idea. A good rule of thumb is the fewer domains the better. And if you can get by with a single domain, that's great.
8.1.3 Three Options for the Root Domain Name
Once you've decided on a domain model, you need to choose a name for your root domain, also known as the forest root domain. The root domain name is very important because it determines which name servers can be authoritative for the corresponding DNS namespace. You have three basic options for naming your root domain: use the same name as an existing DNS domain, create a new subdomain from an existing domain, or use a name that doesn't
126.96.36.199 Same name as an existing DNS domain
Consider Movie University. The apex (or top) of Movie U.'s DNS namespace is movie.edu , with subdomains named fx.movie.edu , classics.movie.edu , and comedies.movie.edu . This namespace is represented in Figure 8-1.
Figure 8-1. Movie University's namespace
We could root Active Directory's namespace at the root of Movie U's DNS namespace. That would result in
being the forest root domain. If we decide that the special effects lab needs a dedicated Active Directory domain, we can create the
domain as a child domain in the
forest. Everyone else at Movie U. can be part of the
Active Directory domain, even though individual
If your authoritative name servers are not domain controllers and you want to use AD-integrated zones (more on this later), or you want some other name servers to be authoritative for the zone that contains the Active Directory resource records, you have to create delegations. All of the required Active Directory-specific resource records are stored in subdomains of the DNS domain whose name corresponds to the AD domain. These subdomains are named
. The forest root domain will also have a
To delegate the Active Directory DNS responsibilities when the Active Directory domains are named after an existing DNS domain, you need to delegate those subdomains. In
188.8.131.52 Subdomain of an existing DNS domain
Now let's say that Movie U. wanted to completely separate its AD namespace from its DNS namespace. Another common approach is to create a subdomain of an existing domain, such as the top-level domain for the organization. For example, we could name the forest root domain ad.movie.edu or corp.movie.edu . If we still needed to create a subdomain for the special effects lab, it could be named fx.ad.movie.edu .
This model is the
184.108.40.206 Disjoint or private name
The last major option for naming your forest root domain is not to base it on any of your top-level domain names and use a disjoint or private name. The most common suffix that is used in this scenario is
). This model is typically
In nonproduction forests, we recommend following the guidelines in RFC 2606 and using
, which are suffixes reserved for testing purposes. If you need to create a lab or test environment that your general community does not need to access, this is a good model to use. In fact, you can create a forest without requiring any delegations at all from your main forward-mapping zone,
In order for clients to resolve DNS names outside of the forest, you would need to point the