Dns On Windows Server 1002003 [Electronic resources] نسخه متنی

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
integrationletting 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.

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.