[Chapter 4] 4.7 Running a Primary Master Name Server

4.7 Running a Primary Master Name Server

Now that you've created your DNS database files, you are ready to start a couple of name servers. You'll need to set up two name servers: a primary master name server and a slave name server. Before you start a name server, though, make sure the syslog daemon is running. If the name server sees an error, it logs a message to the syslog daemon. If the error is bad enough, the name server will exit.

4.7.1 Starting Up the Name Server

At this point, we assume the machine you are running on has the BIND name server and the support tool nslookup . Check the named manual page to find the directory the server is in and verify that the executable is on your system. On BSD systems, the name server started its life in /etc , but may have migrated elsewhere. Other places to look for named are /usr/etc/in.named and /usr/sbin/in.named . The descriptions below assume that the name server is still in /etc .

To start up the name server, you must become root. The name server operates on a reserved port requiring root privileges. The name server doesn't require root access for anything else. Start the name server from the command line the first time you run it, to test that it is operating correctly. Later, we'll show you how to start up the name server automatically when your system boots.

The following command starts the name server. In the movie.edu domain, we ran this command on the host terminator :

# 

/etc/named

This command assumes that your configuration file is /etc/named.boot (version 4) or /etc/named.conf (version 8). You can have your configuration file elsewhere, but you have to tell the name server where it is using the -b command-line option:

# 

/etc/named -b conf-file

4.7.2 Check for Syslog Errors

The first thing to do after starting your name server is to check the syslog file for error messages. If you are not familiar with syslog, look at the syslog.conf manual page for a description of the syslog configuration file, or the syslogd manual page for a description of the syslog daemon. The name server logs messages as daemon under the name named . You might be able to find out where syslog messages are logged by looking for daemon in /etc/syslog.conf :

% 

grep daemon /etc/syslog.conf


*.err;kern.debug;daemon,auth.notice /var/adm/messages

On this host, the name server syslog messages are logged to /var/adm/messages , and syslog only saves the ones that are LOG _ NOTICE or higher. Some useful messages are sent at LOG _ INFO - you might like to see some of these. You can decide if you want to change the log level after reading Chapter 7 , where we cover syslog messages in more detail.

When the name server starts, it logs a starting message:

% 

grep named /var/adm/messages


Jan 10 20:48:32 terminator named[3221]: starting.

The starting message is not an error message, but there might be other messages with it that are error messages. (If your server used restarted instead of starting , that's okay too. The message changed at BIND 4.9.3.) The most common errors are syntax errors in the db files or configuration file. For example, if you forgot the resource record type in an address record:

robocop  IN  192.249.249.2

you'll see the following syslog error messages:

Jan 10 20:48:32 terminator named[3221]: Line 13: Unknown type:
                192.249.249.2
Jan 10 20:48:32 terminator named[3221]: db.movie Line 13:
                database format error (192.249.249.2)

Or, if you misspelled the word "zone" in /etc/named.conf :

zne "movie.edu" in {

you'll see the following syslog error message:

Mar 22 20:14:21 terminator named[1477]: named.conf:10:
                syntax error near `zne'

If BIND version 4.9.4 or later finds a name that doesn't conform to RFC 952, you'll see the following syslog error message:

Jul 24 20:56:26 terminator named[1496]: owner name "
ID
_4.movie.edu 
IN
"
                                     (primary) is invalid - rejecting

If you have a syntax error, check the line mentioned in the syslog error message to see if you can figure out the problem. You've seen what the db files are supposed to look like; that should be enough to figure out most simple syntax errors. Otherwise, you'll have to go through Appendix A, DNS Message Format and Resource Records , to see the gory syntax details of all the resource records. If you can fix the syntax error, do so and then send the name server a HUP signal:

# 

kill -HUP <pid>

so that it rereads the data files. You'll see more information in Chapter 7 on sending signals to the name server.

4.7.3 Testing Your Setup with nslookup

If you have correctly set up your local domain, and your connection to the Internet is up, you should be able to look up a local and a remote name. We'll step you through the lookups below with nslookup . There is a whole chapter in this book on nslookup ( Chapter 11, nslookup ), but we will cover nslookup in enough detail here to do basic name server testing.

4.7.3.1 Initialize the default domain name

Before running nslookup , you need to initialize the default domain name. With this in place, you can look up a name like carrie instead of spelling out carrie.movie.edu - the system adds the domain for you.

There are two ways to initialize the default domain: hostname (1) or /etc/resolv.conf . Some people say that, in practice, more sites initialize the default domain in /etc/resolv.conf . You can use either. Throughout the book, we assume the default domain comes from hostname (1).

Create a file called /etc/resolv.conf with the following line starting in column one (substitute your domain name for movie.edu ):

domain movie.edu

Or, set hostname (1) to be a domain name. On the host terminator , we set hostname (1) to terminator.movie.edu . Don't add a trailing dot to the name.

4.7.3.2 Look up a local name

nslookup can be used to look up any type of resource record, and it can be directed to query any name server. By default, it looks up A (address) records using the name server on the local system. To look up a host's address with nslookup , run nslookup with the host's name as the only argument. A lookup of a local name should return almost instantly.

We ran nslookup to look up carrie :

% 

nslookup carrie


Server: terminator.movie.edu
Address: 192.249.249.3

Name:    carrie.movie.edu
Address: 192.253.253.4

If looking up a local name works, your local name server has been configured properly for your domain. If the lookup fails, you'll see something like this:

*** terminator.movie.edu can't find carrie: Non-existent domain

This means that either carrie is not in your data - check your db file - or you didn't set your default domain in hostname (1), or some name server error occurred (but you should have caught the error when you checked the syslog messages).

4.7.3.3 Look up a local address

When nslookup is given an address to look up, it knows to make a PTR query instead of an address query. We ran nslookup to look up carrie 's address:

% 

nslookup 192.253.253.4


Server: terminator.movie.edu
Address: 192.249.249.3

Name:    carrie.movie.edu
Address: 192.253.253.4

If looking up an address works, your local name server has been configured properly for your in-addr.arpa domain. If the lookup fails, you'll see the same error messages as when you looked up a name.

4.7.3.4 Look up a remote name

The next step is to try using the local name server to look up a remote name, like ftp.uu.net , or another system you know on the Internet. This command may not return as quickly as the last one. If nslookup fails to get a response from your name server, it will wait a little longer than a minute before giving up:

% 

nslookup ftp.uu.net.


Server: terminator.movie.edu
Address: 192.249.249.3

Name:      ftp.uu.net
Addresses: 192.48.96.9

If this works, your name server knows where the root name servers are and knows how to contact them to find information about domains other than your own. If it fails, either you forgot to initialize the cache file (and a syslog message will show up) or the network is broken somewhere and you can't reach the name servers for the remote domain. Try a different remote domain name.

If these first lookups succeeded, congratulations! You have a primary master name server up and running. At this point, you are ready to start configuring your slave name server.

4.7.3.5 One more test

While you are testing, though, run one more test. Try having a remote name server look up a name in your domain. This is only going to work if your parent name servers have already delegated your domain to the name server you just set up. If your parent required you to have your two name servers running before delegating your domain, skip ahead to the next section, Section 4.7.4, "Editing the Startup Files ."

To make nslookup use a remote name server to look up a local name, give the local host's name as the first argument, and the remote server's name as the second argument. Again, if this doesn't work, it may take a little longer than a minute before nslookup gives you an error message. For instance, to have gatekeeper.dec.com look up carrie :

% 

nslookup carrie gatekeeper.dec.com.


Server: gatekeeper.dec.com.
Address: 204.123.2.2

Name:    carrie.movie.edu
Address: 192.253.253.4

If the first two lookups worked, but using a remote name server to look up a local name failed, your domain may not be registered with your parent name server. That is not a problem, at first, because systems within your domain can look up the names of other systems within your domain and outside of your domain. You'll be able to send email and to ftp to local and remote systems. Some systems won't allow ftp connections if they can't map your address back to a name. But not being registered will shortly become a problem. Hosts outside of your domain cannot look up names within your domain. You will be able to send email to friends in remote domains, but you won't get their responses. To fix this problem, contact someone responsible for your parent domain and have them check the delegation of your domain.

4.7.4 Editing the Startup Files

Once you have confirmed that your name server is running properly and can be used from here on, you'll need to start it automatically and set hostname (1) to a domain name in your system's startup files. Check to see if your vendor has already set up the name server to start on bootup. You may have to remove comment characters from the startup lines, or the startup file may test to see if /etc/named.conf exists. To look for automatic startup lines, use:

% 

grep named /etc/*rc*

or, if you have System V style rc files, use:

% 

grep named /etc/rc*/S*

If you don't find anything, add lines like the following to the appropriate startup file somewhere after your interfaces are initialized by ifconfig :

if test -x /etc/named -a -f /etc/named.conf
then
        echo "Starting named"
        /etc/named
fi

You may want to wait to start the name server until after the default route is installed or your routing daemon (routed or gated ) is started, depending upon whether these services need the name server or can get by with /etc/hosts .

Find out which startup file initializes the host name. Change hostname (1) to a domain name. For example, we changed:

hostname terminator

to:

hostname terminator.movie.edu