The
Windows Server 2008 R2 improvements on the basic BIND version of DNS
help to further establish DNS as a reliable, robust name-resolution
strategy for Microsoft and non-Microsoft environments. An overall
knowledge of the increased functionality and the structural changes will
help you to further understand the capabilities of DNS in Windows
Server 2008 R2.
Application Partition
Perhaps the most
significant feature in Windows Server 2008 R2 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 on the server name in the DNS MMC 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 2008 R2 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 2008 R2, _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.
