8.2 Storing Zones in Active Directory

One of Microsoft's innovative uses of Active Directory is for storing (and replicating) DNS zone data. A traditional name server stores copies of the zones it supports in files on a local disk. In this model, you have a primary master name server that replicates the zone data to secondary name servers. A secondary can process updates to a zone from its master name server in two different ways. The original method supported by DNS is zone transfer, which allows secondary name servers to request a full copy of a zone. A newer method, which is an improvement on the zone transfer process, is incremental zone transfer. With incremental zone transfer, a secondary name server can request just the updates to the zone that occurred since its last transfer.

Active Directory provides another method for replicating zone content, albeit only for name servers running on domain controllers. You can make a zone AD-integrated, which means that instead of storing zone content in text files, it is stored in the Active Directory database. This makes a lot of sense because you take advantage of Active Directory's multimaster replication scheme, which means that any domain controller that is also a primary name server for the AD-integrated zone can update it directly, like a primary name server. With AD-integrated zones, replication is handled automatically, so you don't need to develop your own zone transfer replication topology.

One other note about Active Directory-integrated zones: strictly speaking, you don't have to make every domain controller into a name server for a zone that's AD-integrated within that domain. Since all authoritative servers can be configured to allow zone transfers, a server that loads a zone from Active Directory happily responds to allowed zone transfer requests. So you could conceivably make only a zone's primary master name server AD-integrated and have the secondaries continue to load from the primary, provided those secondaries are not domain controllers of the domain. However, this defeats one of the purposes of Active Directory integration—letting Active Directory handle zone replication. The other huge advantage of Active Directory integration is secure dynamic updates, which we'll cover in detail shortly.

8.2.1 The Impact on Replication

While AD-integrated zones have many advantages, the one potential drawback is how zone data gets replicated in Active Directory. Under Windows 2000, AD-integrated zones are stored in the System container in a domain. That means that every domain controller in that domain replicates that zone data regardless of whether the domain controller is a name server or not. For domain controllers that are not name servers, there is no benefit to replicating the data, which results in needless replication traffic. This can be a serious issue for those that have large zones with many domain controllers that are not name servers. Fortunately, a new feature in Windows Server 2003 called application partitions provides a better alternative.

Another issue with Windows 2000 AD-integrated zones is that domain controllers in subdomains could not replicate the forest root zone resource records through AD replication. You would have to configure the subdomain domain controller as a secondary and enable zone transfer. The requirement to replicate forest root records is common in branch office deployments where a certain amount of autonomy is needed due to potential network outages. Application partitions also help with this requirement.

8.2.2 Using Application Partitions

Active Directory segregates data into one of three partitions: schema, configuration, or domain. Partitions are used to organize and replicate data with a similar scope (i.e., forestwide or domainwide) among domain controllers. Conceptually, partitions are similar to zones. Zones are also used to segregate and replicate data (using zone transfer) among name servers.

In Windows Server 2003, Microsoft added a new type of partition called an application partition. Whereas the default partitions have a predefined replication scope, application partitions can be configured to replicate with any domain controller in a forest. Domain controllers that are configured to contain replicas of an application partition become the only servers that replicate the data contained within the partition. Application partitions are not limited by domain boundaries. You can configure domain controllers in completely different domains to replicate an application partition. For these reasons, application partitions make a lot of sense for storing AD-integrated zones. You no longer have to store zone data within the domain partition and replicate it to every domain controller in the domain, even if only a few are name servers. With application partitions, you can configure Active Directory to replicate DNS data only between the domain controllers running the DNS server in any domain of the forest. To help facilitate the transition from domain-based storage of zones to application partitions, Microsoft provides a couple of default DNS application partitions: one default DNS application partition for each domain in a forest and one for the forest itself. During the installation of a new Windows Server 2003 Active Directory forest, these partitions are created automatically and AD-integrated zones are stored there. If you upgrade from Windows 2000, the default DNS application partitions are still created automatically, but existing AD-integrated zones are not moved into them. You have to do that manually.

You are not required to use the default DNS application partitions. You can create your own or continue to use the System container in the domain partition, which is the only option under Windows 2000. The storage options are summarized in Table 8-1.

Table 8-1. Storage options for AD-integrated zones

Location	Replication scope
cn=System,DomainDN Example:cn=System,dc=movie,dc=edu	All domain controllers in the domain, regardless of whether they are a name server. This is the only storage method available under Windows 2000.
dc=DomainDnsZones,DomainDN Example:dc=DomainDnsZones,dc=fx, dc=movie,dc=edu	Domain controllers in the domain that are name servers.
dc=ForestDnsZones,ForestDN Example:dc=ForestDnsZones,dc=movie,dc=edu	Domain controllers in the forest that are name servers.
AppPartitionDN Example:dc=DnsData,dc=movie,dc=edu	Domain controllers that have been configured to replicate the custom application partition.

Application partitions are treated just like Active Directory domains by DNS. Each application partition has a corresponding DNS domain, which contains records that are used to locate domain controllers that replicate the partition. For the movie.edu forest root domain, the ForestDnsZones and DomainDnsZones default DNS application partitions would translate into domaindnszones.movie.edu and forestdnszones.movie.edu DNS domains. For the fx.movie.edu domain, there would be a domaindnszones.fx.movie.edu DNS domain.

8.2.3 Securing Dynamic Updates

Another huge advantage of storing zones in Active Directory is that you can enable secure dynamic updates. For zones that are not AD-integrated, you have two options for dynamic updates: allow anyone to make dynamic updates or don't allow dynamic updates at all. Allowing anyone has obvious drawbacks. A malicious client can easily hijack resource records in this mode.

However, when a zone is AD-integrated, you have the option to select Secure only for the Dynamic Updates configuration, found on the General tab for the zone properties in the DNS console. Figure 8-2 shows this window and the three dynamic update options.

Figure 8-2. Dynamic update options

Microsoft uses access control lists (ACLs) on objects in Active Directory to secure zone data and provide secure dynamic update capability. A Security tab is available in the DNS console for AD-integrated zones, which allows you to configure whether a user, group, or computer can create and delete objects (i.e., resource records). By default, authenticated computers in a forest can create new records in a zone, and only the client that created a record is allowed to modify it.