8.1 How Many Name Servers?

Team-Fly    

 
DNS on Windows 2000, 2nd Edition
By Matt Larson, Cricket Liu
Table of Contents
Chapter 8.  Growing Your Domain

8.1 How Many Name Servers?

We set up two name servers in 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 from five to seven 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 slave for you.

Figure 8-1 shows a sample topology and a brief analysis to show you how this might work.

Figure 8-1. Sample network topology
figs/dnsw_0801.gif

Notice that if you follow our guidelines, there are still a number of places 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 .

8.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 slave for your zone. On your own network, try to run name servers near the hubs.

It's doubly important that your primary master name server be well connected. The primary needs good connectivity to all the slaves that update from it, for reliable zone transfers. 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 version of the Microsoft DNS Server.

If managing servers with the DNS console isn't important to you (maybe you like the DNS console frontend 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 Microsoft's 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 10 and Chapter 13 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 slaves.

Homogeneity

One last thing to take into account is the homogeneity of your name servers. Hopping between Windows 2000 and different versions of Unix can be frustrating and confusing. Avoid running name servers on lots of different platforms, 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.

8.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. Windows 2000's Performance toolcan help you characterize your name server's average CPU utilization. To see the name server's CPU utilization, start the Performance tool ( Start Programs figs/u2192.gif Administrative Tools figs/u2192.gif 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 8-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 8-2. Adding counters to monitor DNS server CPU utilization
figs/dnsw_0802.gif

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 2000 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 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 DNS 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 DNS server performance can be found in Section 7.4.5 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 their 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 added some slick logging capabilities to the Windows 2000 DNS Server (the Windows NT DNS Server was woefully lacking in this area). Logging is configured through the Logging tab of the server properties window (right-click on a server in the DNS console and choose Properties , then click on the Logging tab). You'll want to enable the Query category, which logs a record of every query to the file %SystemRoot%\system32\dns\dns.log . A sample logging properties window is shown in Figure 8-3.

Figure 8-3. The Logging tab of the properties window
figs/dnsw_0803.gif

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.


Team-Fly    
Top


DNS on Windows 2000
DNS on Windows 2000
ISBN: 0596002300
EAN: 2147483647
Year: 2001
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net