Active Directory-Integrated Zones
The most dramatic change in Windows 2000’s
DNS implementation was the concept of directory-integrated DNS zones,
known as AD-integrated zones. These zones were stored in Active
Directory, as opposed to a text file as in standard DNS. When the
Active Directory was replicated, the DNS zone was replicated as well.
This also allowed for secure updates, using Kerberos authentication, as
well as the concept of multimaster DNS, in which no one server is the
master server and all DNS servers contain a writable copy of the zone.
Windows Server 2012, like Windows
Server 2008, utilizes AD-integrated zones, but with one major change to
the design: Instead of storing the zone information directly in the naming
contexts of Active Directory, it is stored in the application partition
to reduce replication overhead. You can find more information about
this concept in the following sections.
Dynamic Updates
As previously mentioned, dynamic
updates, using Dynamic DNS (DDNS), allow clients to automatically
register, update, and unregister their own host records as they are
connected to the network. This concept was a new feature introduced
with Windows 2000 DNS and is carried over to Windows Server 2012.
Unicode Character Support
Introduced in Windows 2000 and supported in
Windows Server 2012, Unicode support of extended character sets enables
DNS to store records written in Unicode, or essentially multiple
character sets from many different languages. This functionality
essentially allows the DNS server to utilize and perform lookups on
records that are written with nonstandard characters, such as
underscores, foreign letters, and so on.
Note
Although Microsoft DNS supports Unicode
characters, it is a best practice that you make any DNS implementation
compliant with the standard DNS character set so that you can support
zone transfers to and from non-Unicode-compliant DNS implementations,
such as UNIX BIND servers. This character set includes a–z, A–Z, 0–9,
and the hyphen (-) character.
Application Partition
Perhaps the most significant feature in
Windows Server 2012 DNS implementation, Active Directory-integrated
zones are stored in the application partition of the AD. For every
domain in a forest, a separate application partition is created and is
used to store all records that exist in each AD-integrated zone.
Because the application partition is not included as part of the Global
Catalog, DNS entries are no longer included as part of global catalog
replication.
With the
application partition concept, replication loads are now reduced while
important zone information is delegated to areas of the network where
they are needed.
Automatic Creation of DNS Zones
The Configure a DNS Server Wizard, allows for the automatic creation of a DNS zone through a
step-by-step wizard. This feature greatly eases the process of creating
a zone, especially for Active Directory. The wizard can be invoked by
right-clicking the server name in the DNS Manager and choosing
Configure a DNS Server.
Fix to the “Island” Problem
Earlier versions of the Microsoft DNS had a
well-documented issue that was known as the “island” problem, which was
manifested by a DNS server that pointed to itself as a DNS server. If
the IP address of that server changed, the DNS server updated its own
entry in DNS, but then other DNS servers within the domain were unable
to successfully retrieve updates from the original server because they
were requesting from the old IP address. This effectively left the
original DNS server in an island by itself, hence the term.
Microsoft DNS fixed this problem in
Windows Server 2003 and above. Windows Server 2012 DNS first changes
its host records on a sufficient number of other authoritative servers
within DNS so that the IP changes made will be successfully replicated,
thus eliminating this island problem. As a result, it is no longer
necessary to point a root DNS server to another DNS server for updates,
as was previously recommended as a method of resolving this issue.
Forest Root Zone for _msdcs
In Active Directory, all client logons and
lookups are directed to local domain controllers and Global Catalog
servers through references to the SRV records in DNS. These SRV records
were stored in a subdomain to an Active Directory domain that is known
as the _msdcs subdomain.
In Windows Server 2012, _msdcs is a separate zone in DNS, as shown in Figure 1.
This zone, stored in the application partition, is replicated to every
domain controller that is a DNS server. This listing of SRV records was
moved mainly to satisfy the requirements of remote sites. In Windows
2000, these remote sites had to replicate the entire DNS database
locally to access the _msdcs records, which led to increased
replication time and reduced responsiveness. If you delegate the SRV
records to their own zone, only this specific zone can be designated
for replication to remote site DNS servers, saving replication
throughput and increasing the response time for clients.
Figure 1. _msdcs zone.
