"Well, in our country," said Alice, still panting a little, "you'd generally get to somewhere else - if you ran very fast for a long time as we've been doing."
"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
This chapter discusses a number of related topics pertaining to name server maintenance. We'll talk about sending signals to name servers, modifying the db files, and keeping db.cache up to date. We'll list common syslog error messages and explain the statistics BIND keeps.
This chapter doesn't cover troubleshooting problems. Maintenance involves keeping your data current and watching over your name servers as they operate. Troubleshooting involves putting out fires - those little DNS emergencies that flare up periodically. Firefighting is covered in Chapter 13, Troubleshooting DNS and BIND .
In day-to-day operation, the BIND name server, named , is manipulated with signals. We'll use them in this chapter and in other chapters. Here's a list of the signals you can send to a name server and a short description of the action each signal causes. Each of these signals will be discussed in more detail elsewhere in this book. (On some systems, the files listed below will be found in /var/tmp instead of /usr/tmp .)
The 4.9 and later distributions provide a handy shell script for sending these signals, called ndc . Check out the manpage for the command syntax or just run ndc without any options and it will display a usage message. Be careful not to use a BIND 4 version of ndc with a BIND 8 name server since the signal to send for statistics has changed. If you don't have ndc , you'll have to send the signals manually. Read on.
To send a name server a signal, you must first find the name server's process ID . The BIND name server leaves its process ID in a disk file, making it easier to chase the critter down - you don't have to use ps . The most common place for the process ID to be left is /etc/named.pid . On some systems, the process ID is in /var/run/named.pid . Check the named manual page to see which directory named.pid is in on your system. Since the name server process ID is in a file, sending a HUP signal can be as simple as:
On a SYS V-based system use:
However, you may find more than one name server running if you use ps , since name servers spawn children to perform zone transfers. During a zone transfer, the name server pulling the zone data starts a child process, and the name server providing the zone data may start a child process. We'll digress a little here and explain why child processes are used.
A slave name server starts a child process to perform a zone transfer. This allows the slave name server to keep answering queries while the zone data is being transferred from the master server to the local disk by the child process. Once the zone is on the local disk, the slave name server reads in the new data. Using a child process to do the zone transfer fixed a problem with pre-4.8.3 versions of BIND , in which slave name servers wouldn't answer queries during a zone transfer. This could be a real nuisance on name servers that loaded lots of zones or large zones: they'd go silent for long periods of time.
A version 8 primary master name server does not spawn a child process to provide a zone to a slave name server. Instead, the primary master server transfers the zone at the same time it is answering queries. If the primary master server loads a new copy of the zone from a disk file while a zone transfer is in progress, it will abort the zone transfer in progress and load the new zone from the disk file. The slave server will have to attempt the zone transfer again after the primary master has completed loading the new zone.
A version 4 primary master name server starts a child process to provide a zone to a slave name server. This creates extra load on the host running the primary master server, especially if the zones are very large or many zone transfers are active at one time.
If the ps output shows multiple name servers, you should be able to tell easily which name server process is the parent and which processes are children. A child name server started by a slave server to pull a copy of a zone is called named-xfer instead of named :
root 548 547 0 22:03:17 ? 0:00 named-xfer -z movie.edu -f /usr/tmp/NsTmp0 -s 0 -P 53 220.127.116.11
A child name server started by a master name server changes its command-line options to indicate which slave server it is providing the zone to:
root 1137 1122 6 22:03:18 ? 0:00 /etc/named -zone XFR to [18.104.22.168]
You may encounter a version of named that doesn't change its command line, but you can still figure out the relationship between multiple named processes by examining their process ID s and parent process ID s. All the child processes will have the parent name server's process ID as their parent process ID . This may seem like stating the obvious, but only send signals to the parent name server process. The child processes will go away after the zone transfers complete.