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 over multiple primary name servers 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 2012 is the location where the zone file is stored in Active
Directory. Windows Server 2012 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 Records
The
SOA record indicates that this name server is the best source for
information within the zone. An SOA record is required for each zone.
In a non-Active Directory–integrated 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 the 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
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 Records
An
MX record 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. Hosts
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.
The MX record defines the email domain, that is, the part to the right of the @ symbol in the email address. In Figure 2, microsoft.com has a single mail server (mail.messaging.microsoft.com), with the priority of 10.
Note that the single DNS host name resolves to two different IP
addresses, which will be issued in a round-robin fashion for load
balancing and fault tolerance.
Figure 2. Microsoft.com mail server entry.
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.
