Once you have determined your
network’s name resolution requirements and designed your DNS namespace,
it is time to actually implement the name resolution services by
installing and configuring servers. Toward this end, you must first
decide how many servers you need and where you are going to locate them,
and then determine how you are going to configure the servers.
How Many DNS Servers?
A Windows Server
2003 DNS server running on a computer with a 700 MHz Pentium III
processor can handle up to 10,000 name resolution queries per second, so
in most instances, private networks use multiple DNS servers for
reasons other than a heavy client load. Some other reasons for deploying
multiple DNS servers on your network are as follows:
Providing redundancy
For a network that relies heavily on DNS name resolution, having a
single DNS server means having a single point of failure. You should
plan to deploy a sufficient number of DNS servers so that at least two
copies of every zone are always online.
Improving performance
For a DNS client, the combination of a nearby DNS server and a reduced
traffic load on that server means improved name resolution performance.
Balancing traffic load
Even when a single server is capable of handling the name resolution
requests for your entire network, the network might not be up to the
task. Having all the network’s DNS traffic converge on a single subnet
can overload the LAN and slow down the name resolution process, as well
as interfere with the other computers sharing the network. Deploying
multiple servers on different subnets enables you to balance the DNS
traffic between them and avoid creating bottlenecks.
Reducing WAN traffic
When your network consists of LANs at multiple sites, connected by
multiple wide area network (WAN) links, it is usually best to have a DNS
server at each site. WAN links are relatively slow compared to LAN
connections, and their bandwidth can be quite expensive. Having a DNS
server at each site prevents name resolution traffic from monopolizing
the WAN connections. This practice also prevents router or WAN
connection failures from interrupting name resolution services.
Delegating authority In
a large organization, it might be impractical for a single
administrative team to maintain the DNS namespace for the entire
enterprise. It is often more efficient to split the namespace into
several domains and have the administrative staff in each department,
division, or office location maintain their own DNS resource records.
While it is not essential that you allocate a separate DNS server to
each domain, circumstances usually dictate this setup.
Supporting Active Directory
The Active Directory directory service relies heavily on DNS. Active
Directory clients use DNS to locate domain controllers and browse the
network. You should deploy enough DNS servers to support the needs of
Active Directory and its clients.
You should consider
all these factors when deciding how many DNS servers you need, and when
balancing them against factors such as hardware and software costs and
the administrative burden of running multiple servers.
Understanding DNS Server Types
You can deploy Windows
Server 2003 DNS servers in a number of different configurations,
depending on your infrastructure design and your users’ needs.
Using Caching-Only Servers
It is not essential for a
DNS server to be the authoritative source for a domain. In its default
configuration, a Windows Server 2003 DNS server can resolve Internet DNS
names for clients immediately after its installation. A DNS server that
contains no zones and is hosting no domains is called a caching-only server.
If you have Internet clients on your network but you do not have a
registered domain name and are not using Active Directory, you can
deploy caching-only servers that simply provide Internet name resolution
services for your clients.
In
some instances, you might want to use some caching-only servers on your
network, even if you are hosting domains. For example, if you want to
install a DNS server at a branch office for the purpose of Internet name
resolution, you are not required to host a part of your namespace
there. You can simply install a caching-only server in the remote
location and configure it to forward all name resolution requests for
your company domains to a DNS server at the home office, while the
caching-only server resolves all Internet DNS names itself.
Using Forwarders
A forwarder
is a DNS server that receives queries from other DNS servers that are
explicitly configured to send them. With Windows Server 2003 DNS
servers, the forwarder requires no special configuration. However, you
must configure the other DNS servers to send queries to the forwarder.
To do this, from the Action menu in the DNS console, click Properties to
display the server’s Properties dialog box, click the Forwarders tab,
and then supply the IP address of the DNS server that will act as a
forwarder. (See Figure 1.) You can also specify multiple forwarder IP addresses to provide fault tolerance.
You can use forwarders in
a variety of ways to regulate the flow of DNS traffic on your network.
As explained earlier, a DNS server that receives recursive queries from
clients frequently has to issue numerous iterative queries to other DNS
servers on the Internet to resolve names, generating a significant
amount of traffic on the network’s Internet connection.
There are several
scenarios in which you can use forwarders to redirect this Internet
traffic. For example, if a branch office is connected to your corporate
headquarters using a T-1 leased line and the branch office’s Internet
connection is a much slower shared dial-up modem, you can configure the
DNS server at the branch office to use the DNS server at headquarters as
a forwarder, as shown in Figure 2.
The recursive queries generated by the clients at the branch office
then travel over the T-1 to the forwarder at the headquarters, which
resolves the names in the usual manner and returns the results to the
branch office DNS server. The clients at the branch office can then use
the resolved names to connect to Internet servers directly, over the
dial-up connection. No DNS traffic passes over the branch office’s
Internet connection.
You can also use
forwarders to limit the number of servers that transmit name resolution
queries through the firewall to the Internet. If you have five DNS
servers on your network, all of which provide both internal and Internet
name resolution services, you have five points where your network is
vulnerable to attacks from the Internet. By configuring four of the DNS
servers to send all their Internet queries to the fifth server, you
create only one point of vulnerability.
Chaining Forwarders
One
DNS server that is functioning as a forwarder can also forward its
queries to another forwarder. To combine the two scenarios described in
the previous section, you can configure your branch office servers to
forward name resolution requests to various DNS servers at headquarters,
and then have the headquarters servers forward all Internet queries to
the one server that transmits through the firewall.
|
One of the new
features in Windows Server 2003 is the ability to configure the DNS
server to forward queries conditionally, based on the domain specified
in the name resolution request. By default, the forwarder addresses you
specify in the Forwarders tab in a DNS server’s Properties dialog box
apply to all other DNS domains. However, when you click New and specify a
different domain, you can supply different forwarder addresses so that
requests for names in that domain are sent to different servers.
As an example of
conditional forwarding, consider a network that uses a variety of
registered domain names, including contoso.com. When a client tries to
resolve a name in the contoso.com domain and sends a query to a DNS
server that is not an authoritative source for that domain, the server
normally must resolve the name in the usual manner, by first querying
one of the root name servers on the Internet. However, using conditional
forwarding, you can configure the client’s DNS server to forward all
queries for the contoso.com domain directly to the authoritative server
for that domain, which is on the company network. This configuration
keeps all the DNS traffic on the private network, speeding up name
resolution and conserving the company’s Internet bandwidth.
You can
also use conditional forwarding to minimize the network traffic that
internal name resolution generates by configuring each of your DNS
servers to forward queries directly to the authoritative servers for
their respective domains. This practice is an improvement even over
creating an internal root, because there is no need for the servers to
query the root name server to determine the addresses of the
authoritative servers for a particular domain.
Using conditional
forwarding extensively on a large enterprise network has two main
drawbacks: the amount of administrative effort needed to configure all
the DNS servers with forwarder addresses for all the domains in the
namespace, and the static nature of the forwarding configuration. If
your network is expanding rapidly and you are frequently adding or
moving DNS servers, the need to continually reconfigure the forwarder
addresses might be more trouble than the savings in network traffic are
worth.
|
Creating Zones
A zone
is an administrative entity you create on a DNS server to represent a
discrete portion of the namespace. Administrators typically divide the
DNS namespace into zones to store them on different servers and to
delegate their administration to different people. Zones always consist
of entire domains or subdomains. You can create a zone that contains
multiple domains, as long as those domains are contiguous in the DNS
namespace. For example, you can create a zone containing a parent domain
and its child because they are directly connected, but you cannot
create a zone containing two child domains without their common parent
because the two children are not directly connected. (See Figure 3.)
You can divide the DNS
namespace into multiple zones and host them on a single DNS server if
you want to, although there is usually no persuasive reason to do so.
The DNS server in Windows Server 2003 can support as many as 200,000
zones on a single server, although it is hard to imagine what scenario
would require this many. In most cases, an administrator creates
multiple zones on a server and then delegates most of them to other
servers, which then become responsible for hosting them.
Every zone consists of a
zone database, which contains the resource records for the domains in
that zone. The DNS server in Windows Server 2003 supports three zone
types (as shown in Figure 4), which specify where the server stores the zone database and what kind of information it contains.
The three zone types are as follows:
Primary zone
A primary zone contains the master copy of the zone database, where
administrators make all changes to the zone’s resource records. If the
Store The Zone In Active Directory (Available Only If DNS Server Is A
Domain Controller) check box is cleared, the server creates a primary
master zone database file on the local drive. This is a simple text file
that is compliant with most non-Windows DNS server implementations.
Secondary zone
A duplicate of a primary zone on another server, the secondary zone
contains a backup copy of the primary master zone database file, stored
as an identical text file on the server’s local drive. You cannot modify
the resource records in a secondary zone manually; you can only update
them by replicating the primary master zone database file, using a
process called a zone transfer. You should always create at least one
secondary zone for each primary zone in your namespace, both to provide
fault tolerance and to balance the DNS traffic load.
Stub zone
A copy of a primary zone that contains Start Of Authority (SOA) and
Name Server (NS) resource records, plus the Host (A) resource records
that identify the authoritative servers for the zone. The stub zone
forwards or refers requests. When you create a stub zone, you configure
it with the IP address of the server that hosts the zone from which you
created the stub. When the server hosting the stub zone receives a query
for a name in that zone, it either forwards the request to the host of
the zone or replies with a referral to that host, depending on whether
the query is recursive or iterative.
You
can use each of these zone types to create forward lookup zones or
reverse lookup zones. Forward lookup zones contain name-to-address
mappings and reverse lookup zones contain address-to-name mappings. If
you want a DNS server to perform name and address resolutions for a
particular domain, you must create both forward and reverse lookup zones
containing that domain.
Using File-Based Zones
When you create
primary and secondary zones, you must configure zone transfers from the
primary to the secondaries to keep them updated. In a zone transfer,
the server hosting the primary zone copies the primary master zone
database file to the secondary zone, so that their resource records are
identical. This enables the secondary zone to perform authoritative name
resolutions for the domains in the zone, just as the primary can. You
can configure zone transfers to occur when you modify the contents of
the primary master zone database file, or at regular intervals.
Originally,
the DNS standards defined the zone transfer process as a complete
replication of the entire zone database file. At specified times, the
DNS server hosting the primary zone transmits the file to all the
servers hosting secondary copies of that zone. File-based zone transfers
use a relatively simple technique in which the servers transmit the
zone database file in its native form, or sometimes with compression.
You must manually create secondary zones and configure the servers to
perform the zone transfers. A later DNS standard document (RFC 1995,
“Incremental Zone Transfer in DNS”) defines a new replication method
called incremental zone transfers.
An incremental zone transfer consists of only the data that has changed
since the last zone transfer. The Windows Server 2003 DNS server
supports incremental zone transfers, but reverts to full transfers when
one of the servers does not support the new standard.
Using Active Directory–Integrated Zones
When you are
running the DNS server service on a computer that is an Active Directory
domain controller and you select the Store The Zone In Active Directory
(Available Only If DNS Server Is A Domain Controller) check box while
creating a zone in the New Zone Wizard, the server does not create a
zone database file. Instead, the server stores the DNS resource records
for the zone in the Active Directory database. Storing the DNS database
in Active Directory provides a number of advantages, including ease of
administration, conservation of network bandwidth, and increased
security.
In Active
Directory–integrated zones, the zone database is replicated
automatically, along with all other Active Directory data. Active
Directory uses a multiple master replication system so that copies of
the database are updated on all domain controllers in the domain. You
don’t have to create secondary zones or manually configure zone
transfers because Active Directory performs the database replication
automatically.
By default, Windows
Server 2003 replicates the database for a primary zone stored in Active
Directory to all the other domain controllers running the DNS server in
the Active Directory domain where the primary is located. You can also
modify the scope of zone database replication to keep copies on all
domain controllers throughout the enterprise, or on all domain
controllers in the Active directory domain, whether or not they are
running the DNS server.
If all your domain
controllers are running Windows Server 2003, you can also create a
custom replication scope that copies the zone database to the domain
controllers you specify. To modify the replication scope for an Active
Directory–integrated zone, open the zone’s Properties dialog box in the
DNS console, and in the General tab, click the Change button with the
label Replication: All DNS Servers In the Active Directory Domain to
display the Change Zone Replication Scope dialog box.
Active Directory
conserves network bandwidth by replicating only the DNS data that has
changed since the last replication, and by encrypting the data before
transmitting it between servers. The zone replications also use the full
security capabilities of Active Directory, which are considerably more
robust than those of file-based zone transfers.
Because
Windows Server 2003 automatically replicates the Active Directory
database to other domain controllers, creating secondary zones is not a
prerequisite for replication. Indeed, you cannot create an Active
Directory–integrated secondary zone. However, you can create a
file-based secondary zone from an Active Directory–integrated primary
zone, and there are occasions when you might want to do this. For
example, if no other domain controllers are running DNS in the Active
Directory domain, there are no other domain controllers in the domain,
or your other DNS servers are not running Windows Server 2003, you might
have to create a standard secondary zone instead of relying on Active
Directory replication. If you do this, you must manually configure the
DNS servers to perform zone transfers in the normal manner.
