Name servers, or
DNS servers, are systems that store information about the domain
namespace. Name servers can have either the entire domain namespace or
just a portion of the namespace. When a name server only has a part of
the domain namespace, the portion of the namespace is called a zone.
DNS Zones
There is a subtle difference between zones and
domains. All top-level domains, and many domains at the second and lower
levels, are broken into zones—smaller, more manageable units by
delegation. A zone is the primary delegation mechanism in DNS over which
a particular server can resolve requests. Any server that hosts a zone
is said to be authoritative for that zone, with the exception of stub
zones.
A name server can have authority
over more than one zone. Different portions of the DNS namespace can be
divided into zones, each of which can be hosted on a DNS server or
group of servers.
Forward Lookup Zones
A forward lookup zone is created to do forward
lookups on the DNS database, resolving names to IP addresses and
resource information.
Reverse Lookup Zones
A reverse lookup zone performs the opposite
operation as the forward lookup zone. IP addresses are matched up with a
common name in a reverse lookup zone. This is similar to knowing the
phone number but not knowing the name associated with it. Reverse lookup
zones must be manually created, and do not exist in every
implementation. Reverse lookup zones are primarily populated with PTR
records, which serve to point the reverse lookup query to the
appropriate name.
Tip
It is good practice for the Simple Mail
Transfer Protocol (SMTP) mail server to have a record in the reverse
lookup zone. Spam control sites check for the existence of this record.
It is possible to be placed on a spammer list if the site does not have a
PTR record for the MX entry in the DNS reverse lookup zone.
Active Directory–Integrated Zones
A
Windows 2003 DNS server can store zone information in two distinct
formats: Active Directory–integrated or standard text file. An Active
Directory–integrated zone is an available option when the DNS server is
installed on an Active Directory domain controller. When a DNS zone is
installed as an Active Directory zone, the DNS information is
automatically updated on other server AD domain controllers with DNS by
using Active Directory’s multimaster update techniques. Zone information
stored in the Active Directory allows DNS zone transfers to be part of
the Active Directory replication process secured by Kerberos
authentication.
Primary Zones
In traditional (non–Active
Directory–integrated) DNS, a single server serves as the master DNS
server for a zone, and all changes made to that particular zone are done
on that particular server. A single DNS server can host multiple zones,
and can be primary for one and secondary for another. If a zone is
primary, however, all requested changes for that particular zone must be
done on the server that holds the master copy of the zone. As
illustrated in Figure 1, companyabc.com is set up on VMW-DC1 as an Active Directory-Integrated Primary zone. However, VMW-DC1 also holds a secondary zone copy of the HQ.COMPANYABC.COM zone.
Creating a new primary zone manually is a
fairly straightforward process. The following procedure outlines the
creation of a standard zone for the companyabc.com DNS namespace:
1. | Open the DNS MMC snap-in (Start, Administrative Tools, DNS).
|
2. | Navigate to DNS\<Servername>\Forward Lookup Zones.
|
3. | Right-click Forward Lookup Zones, and choose New Zone.
|
4. | Click Next on the welcome screen.
|
5. | Select
Primary Zone from the list of zone types available. Also, determine if
the zone will be stored in Active Directory. If not, uncheck the Store
the Zone in Active Directory check box. Click Next to continue.
|
6. | Type the name of the primary zone to be created, and click Next.
|
7. | Because
a new zone file will be created, as opposed to importing an existing
zone file, select Create a New File with This File Name, and click Next.
|
8. | Determine
whether dynamic updates will be allowed in this zone. By default, Do
Not Allow Dynamic Updates is selected. Click Next to continue.
|
9. | Click Finish on the Summary page to create the zone.
|
Secondary Zones
A secondary zone is established to provide
redundancy and load balancing for the primary zone. Secondary zones are
not necessary if the zone has been set up as the Active Directory
Integrated Zone because the zone will be replicated to all domain
controllers in the domain. With secondary zones, each copy of the DNS
zone database is read-only, however, because all recordkeeping is done
on the primary zone copy. A single DNS server can contain several zones
that are primary and several that are secondary. The zone creation
process is similar to the one outlined in the preceding section on
primary zones, but with the difference being that the zone is
transferred from an existing primary server.
Stub Zones (Delegated Zones)
A stub zone is a zone that contains no
information about the members in a domain but simply serves to forward
queries to a list of designated name servers for different domains. A
stub zone contains only NS, SOA, and glue records. Glue records are A
records that work in conjunction with a particular NS record to resolve
the IP address of a particular name server. A server that hosts a stub
zone for a namespace is not authoritative for that zone.
A stub zone effectively serves as a placeholder
for a zone that is authoritative on another server. It allows a server
to forward queries that are made to a specific zone to the list of name
servers in that zone.
DNS Queries
The primary function of DNS is to provide name
resolution for requesting clients, so the query mechanism is one of the
most important elements in the system. Two types of queries are commonly
made to a DNS database: recursive and iterative.
Recursive Queries
Recursive
queries are most often performed by resolvers, or clients that need to
have a specific name resolved by a DNS server. Recursive queries are
also accomplished by a DNS server if forwarders are configured to be
used on a particular name server. A recursive query asks whether a
particular record can be resolved by a particular name server. The
response to a recursive query is either negative or positive.
Iterative Queries
Iterative queries ask a DNS server to either
resolve the query or make a best-guess referral to a DNS server that
might contain more accurate information about where the query can be
resolved. Another iterative query is then performed to the referred
server and so on until a result, positive or negative, is obtained.
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 2003 is the location where the
zone file is stored in Active Directory. Windows Server 2003 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 three mail servers, all set with the same 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.
As shown in the example, 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 2003
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 2003 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 2003 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.
