لطفا منتظر باشید ...
9.1 How Many Name Servers?
Chapter 4. Two servers are as few as
you'll ever want to run and, depending on the size
of your network, you may need to run many more. It is not uncommon to
run four or more name servers, with one of them off-site. How many
name servers are enough? You'll have to decide that
based on your network. Here are some guidelines to help out:
Run at least one name server on each network or subnet you have. This
removes routers as a point of failure. Make the most of any
multihomed hosts you may have since they are (by definition) attached
to more than one network.
If you have a file server and some diskless nodes, run a name server
on the file server to serve this group of machines.
Run name servers near, but not necessarily on, large multiuser
computers. The users and their processes probably generate a lot of
queries and, as administrators, you will work harder to keep a
multiuser host up. But balance their needs against the risk of
running a name servera security-critical serveron a
system to which lots of people have access.
Run one
name server off-site. This makes your data available when your
network isn't. You might argue that
it's useless to look up an address when you
can't reach the host. Then again, the off-site name
server may be available if your network is reachable but your other
name servers are down. If you have a close relationship with an
organization on the Internetsay another university or a
business partnerthey may be willing to run a secondary for
you.
Figure 9-1 shows a sample topology to illustrate
how this might work.
Figure 9-1. Sample network topology
Notice that, if you follow our guidelines, you still have a number of
hosts on which you could choose to run a name server. Host
d, the file server for hosts
a, b,
c, and e, could run a name
server. Host g, a big, multiuser host, is
another good candidate. But probably the best choice is host
f, the smaller host with interfaces on both
networks. You'll need to run only one name server,
instead of two, and it will run on a closely watched host. If you
want more than one name server on either network, you can also run
one on d or g.
9.1.1 Where Do I Put My Name Servers?
In addition to giving you a rough idea
of how many name servers you'll need, these criteria
should help you decide where to run name servers
(e.g., on file servers and multihomed hosts). But there are other
important considerations when choosing the right host.
Other factors to keep in mind are the host's
connectivity, the software it runs (for example, the Microsoft DNS
Server or BIND), the security of your host, and maintaining the
homogeneity of your name servers:
Connectivity
It's important that
name servers be well connected. Running a name server on the fastest,
most reliable host on your network won't do you any
good if the host is mired in some backwater subnet of your network
behind a slow, flaky serial line. Try to find a host close to your
link to the Internet (if you have one) or find a well-connected
Internet host to act as a secondary for your zone. On your own
network, try to run name servers near the network's
topological hubs.
It's doubly important that your primary master name
server be well connected. For reliable zone transfers, the primary
needs good connectivity to all the secondaries that update from it.
And, like any name server, it will benefit from fast, reliable
networking.
Software
Another factor to consider in choosing
a host for a name server is the software the host runs. If you bought
this book, we'll assume it's
because you want to run the Microsoft DNS Server. Keep in mind that
you'll be able to manage remote name servers with
the DNS console only if they're running the Windows
2000 or Windows Server 2003 versions of the Microsoft DNS Server.
If managing servers with the DNS console isn't
important to you (maybe you like the DNS console front-end for
managing zone data, but you're comfortable editing
BIND configuration files by hand), you might consider running some
BIND name servers on your network. Newer BIND name servers are fast
and robust and can interoperate with the Microsoft DNS Server. If you
do decide to implement some BIND name servers, it would be a good
idea to run the most recent version of BIND, BIND 9. BIND 9 servers
can use a more efficient zone transfer protocol with Microsoft DNS
Servers. (See Chapter 11 and Chapter 12 for more information on interoperability
between the Microsoft DNS Server and BIND.)
Security
Since you would undoubtedly prefer
that hackers not commandeer your name server to assist them in
attacking your own hosts or other networks across the Internet,
it's important to run your name server on a secure
host. Don't run a name server on a big, multiuser
system if you can't trust its users. Computers that
are dedicated to hosting network services but don't
permit general logins are good candidates for running name servers.
If you have only one or a few really secure hosts, consider running
the primary master name server on one of those, since its compromise
would be more significant than the compromise of the secondaries.
Homogeneity
One
last thing to take into account is the homogeneity of your name
servers. Hopping between Windows and different versions of Unix can
be frustrating and confusing. Avoid running name servers on lots of
different platforms and even on different service packs if you can.
You can waste a lot of time porting your scripts (or ours!) from one
operating system to another or looking for the location of
nslookup on three different operating systems.
Though these are really secondary
considerationsit's more important to have a
name server on a given subnet than to have it running on the perfect
hostdo keep these criteria in mind when deciding where to run
your name servers.
9.1.2 Capacity Planning
If you have heavily populated<
networks or users who do a lot of name server-intensive work, you may
find you need more name servers than we've
recommended to handle the load. Likewise, our recommendations may be
fine for a little while, but as people add hosts to your networks or
install new name server-intensive programs, you may find your name
servers bogged down by queries.
Just which tasks are "name
server-intensive"? Surfing the Web can be, as can
sending electronic mail, especially to large mailing lists. Programs
that make lots of remote procedure calls to different hosts can also
be name server-intensive. Even running certain graphical user
environments can tax your name server. The astute (and precocious)
among you may be asking, "But how do I know when my
name servers are overloaded? What do I look for?" An
excellent question!
Memory utilization is
probably the most important aspect of a name
server's operation to monitor.
dns.exe, the name server process,
can get very large on a name server that is authoritative
for many zones. If dns.exe's
size, plus the size of the other processes you run, exceeds the size
of your host's real memory, your host may swap
furiously ("thrash") and not get
anything done. Another criterion you can use to measure the load on
your name server is the load the name server process places on the
host's CPU. Correctly configured name servers
don't use much CPU time, so high CPU usage is often
symptomatic of a configuration error. The Performance Monitor
(perfmon) tool can help you
characterize your name server's average CPU
utilization. To see the name server's CPU
utilization, start the Performance tool (Start
Administrative Tools Performance) and select System Monitor in the left pane. Click on the
add icon (shaped like a plus sign) in the right pane. In the
resulting window, choose Process
under Performance object, then
choose % Processor Time in the left
list and dns in the right list, as
in Figure 9-2. Click on the Add button, then the Close button. A chart now shows the percentage
of processor time the name server is using.
Figure 9-2. Adding counters to monitor DNS server CPU utilization
Unfortunately, there are no absolute rules when it comes to
acceptable CPU utilization. We offer a rough rule of thumb, though:
5% average CPU utilization is probably acceptable; 10% is a bit high,
unless the host is dedicated to providing name
service.
Another statistic to
look at is the number of queries the name server receives per minute
(or second, if you have a busy name server). Again, there are no
absolutes here: a multiprocessor server with oodles of RAM running
Windows Server 2003 can handle thousands of queries per second
without breaking into a sweat, while a less powerful PC might have
problems with more than a few hundred queries per second.
To check the volume of queries your name server is receiving, use the
Performance tool again. This time, select DNS under Performance
object. You'll see there are several
counters to choose from: you can monitor many different aspects of
the name server's behavior. To see how busy your
server is, pay particular attention to these counters: Total Query Received, Total Query Received/sec, Total Response Sent, and Total Response Sent/sec. More information
about using the Performance tool to monitor name server performance
can be found in "Understanding Name Server
Statistics" in Chapter 7.
You
should pay special attention to peak periods. For example, Monday
morning is often busy because many people like to respond to mail
they've received over the weekend first thing on
Mondays.
You might also want to take a sample starting just after lunch, when
people are returning to their desks and getting back to
workall at about the same time. Of course, if your
organization is spread across several time zones,
you'll have to use your judgment to determine a busy
time.
Even
if your host is fast enough to handle the volume of queries it
receives, you should make sure the DNS traffic isn't
placing undue load on your network. On most LANs, DNS traffic will be
too small a proportion of the network's bandwidth to
worry about. Over slow leased lines or dial-up connections, though,
DNS traffic could consume enough bandwidth to merit
concern.
To get a rough estimate of the volume of DNS traffic on your LAN,
multiply the number of queries received plus the number of answers
sent in an hour by 800 bits (100 bytes, a rough average size for a
DNS message), and divide by 3,600 (seconds per hour) to find the
bandwidth utilized. This should give you a feeling for how much of
your network's bandwidth is being consumed by DNS
traffic.
To
give you an idea of what's normal, the last NSFNET
traffic report (in April 1995) showed that DNS traffic constituted
just over 5% of the total traffic volume (in bytes) on its backbone.
The NSFNET's figures were based upon actual traffic
sampling, not calculations like ours using the name
server's statistics.[1] If you want to get a more accurate idea of
the traffic your name server is receiving, you can always do your own
traffic sampling with a LAN protocol analyzer.
[1] We're not sure how representative of the
current state of the Internet these numbers are, because
it's extremely difficult to wheedle equivalent
numbers out of the commercial backbone providers that succeeded the
NSFNET.
If you find that your name servers are overworked, what then? First,
it's a good idea to make sure that your name servers
aren't being bombarded with queries by a misbehaving
program. To do that, you'll need to find out the
sources of all the queries.
Fortunately, Microsoft introduced some slick logging capabilities in
Windows 2000 (the Windows NT version was woefully lacking in this
area). Logging is configured through the Debug Logging
tab of the server properties window (right-click on a name server in
the DNS console and choose Properties, then click on the Debug Logging
tab). Check the box labeled Log packets for
debugging to enable logging. Be sure to check at least
Queries/Transfers under Packet contents, which logs a record of every
query to the file
%SystemRoot%\system32\dns\dns.log. A sample
logging properties window is shown in Figure 9-3.
Figure 9-3. The Debug Logging tab of the properties window
When poring over the example, look for
hosts sending repeated queries, especially for the same or similar
information. That may indicate a misconfigured or buggy program
running on the host or a foreign name server pelting your name server
with queries.
If all the queries appear to be legitimate, add a new name server.
Don't put the name server just anywhere, though; use
the logging information to help you decide where
it's best to run one. If DNS traffic is gobbling up
your LAN, it won't help to choose a host at random
and create a name server there. You need to consider which hosts are
sending most of the queries, then figure out how to best provide them
name service. Here are some hints to help you decide:
Look for queries from resolvers on hosts that share the same file
server. You could run a name server on that file server.
Look for queries from resolvers on large, multiuser hosts. You could
run a name server there.
Look for queries from resolvers on another subnet. Those resolvers
should be configured to query a name server on their local subnet. If
there isn't one on that subnet, create one.
Look for queries from resolvers on the same bridged segment (if you
use bridging). If you run a name server on the bridged segment, the
traffic won't need to be bridged to the rest of the
network.
Look for queries from hosts connected to each other via another,
lightly loaded network. You could run a name server on the other network.
