DNS Replication or Zone Transfer
Copying the DNS
database from one server to another is accomplished through a process
known as a zone transfer. Zone transfers are required for any zone that
has more than one name server responsible for the contents of that zone.
The mechanism for zone transfer varies, however, depending on the
version of DNS and whether the zone is Active Directory–integrated.
Primary-Secondary (Master-Slave) (RW-RO)
The primary name server
holds the authoritative copy of the zone. For redundancy and load
sharing, a secondary or slave name server should be set up. The DNS name
resolution does not care if it is dealing with a primary or secondary
server.
The main
difference between the primary and secondary server is where the data
comes from. Primary servers read it from a text file, and the secondary
server loads it from another name server over the network via the zone
transfer process. A slave name server is not limited to loading its data
from a primary master name server; a slave server can load a zone from
another slave server.
A big advantage of using a
secondary name server is that only one set of DNS databases needs to be
maintained because all secondary name servers are read-only (RO)
databases. All updates to the zone file have to be done at the server
holding the primary zone file.
AD-Integrated Replication
One of the most
significant changes from Windows Server 2000 to Windows Server 2008 is
the location where the zone file is stored in Active Directory. Windows
Server 2008 Active Directory–integrated zones are stored in the
application partition, whereas in Windows 2000 Server, the zones were
part of the global catalog (GC). This change in the location of the zone
file reduces cross-forest replication traffic because the application
partition is unique to each domain.
DNS Resource Records
In the DNS hierarchy,
objects are identified through the use of resource records (RRs). These
records are used for basic lookups of users and resources within the
specified domain and are unique for the domain in which they are
located. Because DNS is not a flat namespace, multiple identical RRs can
exist at different levels in a DNS hierarchy.
Start of Authority Record
The Start of
Authority (SOA) record indicates that this name server is the best
source for information within the zone. An SOA record is required for
each zone. The server referenced by the SOA record maintains and updates
the zone file.
The
SOA record also contains other useful information, such as the latest
serial number for the zone file, the email address of the responsible
person for the zone, and Time to Live (TTL).
Host Records
A host (A) record is the
most common form of DNS records; its data is an Internet address in a
dotted decimal form (for example, 10.32.1.132). There should be only one A record for each address of a host.
Name Server Records
Name server (NS)
records indicate which servers are available for name resolution for
that zone. All DNS servers are listed as NS records within a particular
zone. When slave servers are configured for the zone, they will have an
NS record as well.
Mail Exchange Record
A mail exchange (MX)
specifies a mail forwarder or delivery server for SMTP servers. MX
records are the cornerstone of a successful Internet mail routing
strategy.
One of the advantages
of a DNS over HOSTS files is its support for advanced mail routing.
LMHOST files allowed only attempts to deliver mail to the host’s IP
address. If that failed, they could either defer the delivery of the
message and try again later or bounce the message back to the sender.
DNS offers a solution to this problem, by allowing the setup of backup
mail server records.
Mail server records are also MX records, but with a higher-priority number as the primary MX record for the domain. In Figure 2, microsoft.com has a single mail server, with the priority of 10.
The preference
value associated with an MX record determines the order in which a
mailer uses a record. The preference value of an MX record is important
only in relation to the other servers for the same domain. Mail servers
attempt to use the MX record with the lower number first; if that server
is not available, they try to contact the server with a higher number,
and so on.
MX record preferences can
also be used for load sharing. When several mail hosts have the same
preference number associated with them, a sender can choose which mail
server to contact first.
Mail routing
based on preference numbers sounds simple enough, but there are major
caveats that mail administrators have to understand. When
troubleshooting mail routing problems, administrators use the following
concepts to pinpoint the problem.
Mail routing
algorithms based on preference numbers can create routing loops in some
situations. The logic in mail servers helps circumvent this problem:
Companyabc.com IN MX 10 m1.companyabc.com
Companyabc.com IN MX 20 m2.companyabc.com
Companyabc.com IN MX 30 m3.companyabc.com
Using this example, if a message is sent from a client to Bob@companyabc.com from an email address outside of companyabc.com, the sending mail server looks up the receiving mail server for companyabc.com based on the MX records set up for that domain. If the first mail server with the lowest priority is down (m1.companyabc.com), the mail server attempts to contact the second server (m2.companyabc.com). m2 tries to forward the message to m1.companyabc.com because that server is on the top of the list based on preferences. When m2 notices that m1 is down, it tries to contact the second server on the list, (itself), creating a routing loop. If m2 tries to send the message to m3, m3 tries to contact m1, then m2,
and then itself, creating a routing loop. To prevent these loops from
happening, mail servers discard certain addresses from the list before
they decide where to send a message. A mailer sorts the available mail
host based on preference number first, and then checks the canonical
name of the domain name on which it’s running. If the local host appears
as a mail exchange, the mailer discards that MX record and all MX
records with the same or higher preference value. In this example, m2 does not try to send mail to m1 and m3 for final delivery.
The second
common mistake administrators have to look out for with an MX record is
the alias name. Most mailers do not check for alias names; they check
for canonical names. Unless an administrator uses canonical names for MX
records, there is no guarantee that the mailer will find itself, which
could result in a mail loop.
Hosts listed as
mail exchangers must have A records listed in the zone so that mailers
can find address records for each MX record and attempt mail delivery.
Another common mistake
when configuring mail hosts is the configuration of the hosted domain
local to the server. Internet service providers (ISPs) and organizations
commonly host mail for several domains on the same mail server. As
mergers and acquisitions happen, this situation becomes more common. The
following MX record illustrates that the mail server for companyabc.com is really the server mail.companyisp.com:
companyabc.com IN MX 10 mail.companyisp.com
Unless mail.companyisp.com is set up to recognize companyabc.com
as a local domain, it tries to relay the message to itself, creating a
routing loop and resulting in the following error message:
554 MX list for companyabc.com points back to mail.companyisp.com
In this situation, if mail.companyisp.com was configured not to relay messages to unknown domains, it would refuse delivery of the mail.
Service (SRV) Record
Service (SRV)
records are RRs that indicate which resources perform a particular
service. Domain controllers in Active Directory are referenced by SRV
records that define specific services, such as the global catalog, LDAP,
and Kerberos. SRV records are relatively new additions to DNS and did
not exist in the original implementation of the standard. Each SRV
record contains information about a particular functionality that a
resource provides. For example, an LDAP server can add an SRV record
indicating that it can handle LDAP requests for a particular zone. SRV
records can be very useful for Active Directory because domain
controllers can advertise that they can handle GC requests.
Note
Because SRV records are a
relatively new addition to DNS, they are not supported by several
down-level DNS implementations, such as UNIX BIND 4.1 and NT 4.0 DNS. It
is, therefore, critical that the DNS environment that is used for
Windows Server 2008 Active Directory has the capability to create SRV
records. For UNIX BIND servers, version 8.1.2 or higher is required.
Canonical Name Record
A canonical name
(CNAME) record represents a server alias or allows any one of the member
servers to be referred to by multiple names in DNS. The record
redirects queries made to the A record for the particular host. CNAME
records are useful when migrating servers, and for situations in which
friendly names, such as mail.companyabc.com, are required to point to more complex, server-naming conventions, such as sfoexch01.companyabc.com.
Caution
Though DNS entries
for MX records can be pointed to canonical (CNAME) host records, doing
so is not advised, and is not a Microsoft recommended best practice.
Increased administrative overhead and the possibility of misrouted
messages can result. Microsoft recommends that mail/DNS administrators
always link MX records to fully qualified principal names or domain
literals. For further details, see Microsoft Knowledge Base Article
#153001 at http://support.microsoft.com/kb/153001/.
Other Records
Other,
less common forms of records that might exist in DNS have specific
purposes, and there might be cause to create them. The following is a
sample list, but it is by no means exhaustive:
AAAA— Maps a standard IP address into a 128-bit IPv6 address. This type of record becomes more prevalent as IPv6 is adopted.
ISDN— Maps a specific DNS name to an ISDN telephone number.
KEY— Stores a public key used for encryption for a particular domain.
RP— Specifies the responsible person for a domain.
WKS— Designates a particular well-known service.
MB— Indicates which host contains a specific mailbox.
Multihomed DNS Servers
For multihomed DNS
servers, an administrator can configure the DNS service to selectively
enable and bind only to IP addresses that are specified using the DNS
console. By default, however, the DNS service binds to all IP interfaces
configured for the computer.
This can include the following:
Any additional IP addresses configured for a single network connection.
Individual
IP addresses configured for each separate connection where more than
one network connection is installed on the server computer.
For
multihomed DNS servers, an administrator can restrict DNS service for
selected IP addresses. When this feature is used, the DNS service
listens for and answers only DNS requests that are sent to the IP
addresses specified on the Interface tab in the Server properties.
By default, the DNS
service listens on all IP addresses and accepts all client requests sent
to its default service port (UDP 53 or TCP 53 for zone transfer
requests). Some DNS resolvers require that the source address of a DNS
response be the same as the destination address that was used in the
query. If these addresses differ, clients could reject the response. To
accommodate these resolvers, you can specify the list of allowed
interfaces for the DNS server. When a list is set, the DNS service binds
sockets only to allowed IP addresses used on the computer.
In addition to
providing support for clients that require explicit bindings to be used,
specifying interfaces can be useful for other reasons:
If an administrator does not want to use some of the IP addresses or interfaces on a multihomed server computer.
If
the server computer is configured to use a large number of IP addresses
and the administrator does not want the added expense of binding to all
of them.
When
configuring additional IP addresses and enabling them for use with the
Windows Server 2008 DNS server, consider the following additional system
resources that are consumed at the server computer:
DNS server performance overhead increases slightly, which can affect DNS query reception for the server.
Although
Windows Server 2008 provides the means to configure multiple IP
addresses for use with any of the installed network adapters, there is
no performance benefit for doing so.
Even
if the DNS server is handling multiple zones registered for Internet
use, it is not necessary or required by the Internet registration
process to have different IP addresses registered for each zone.
Each
additional address might only slightly increase server performance. In
instances when a large overall number of IP addresses are enabled for
use, server performance can be degraded noticeably.
In
general, when adding network adapter hardware to the server computer,
assign only a single primary IP address for each network connection.
Whenever possible, remove nonessential IP addresses from existing server TCP/IP configurations.