4.7 Running a Primary Master Name Server

Now that you've created your zone data 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 that the syslog daemon is running. If the name server reads the configuration file and zone data files and sees an error, it logs a message to the syslog daemon. If the error is bad enough, the name server exits.

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 installed. Check the named manual page to find the directory the name server executable 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 to /usr/sbin. Other places to look for named are /usr/etc/in.named and /usr/sbin/in.named. The following descriptions assume that the name server is in /usr/sbin.

To start up the name server, you must become root. The name server listens for queries on a reserved port, so it requires root privileges. The first time you run it, start the name server from the command line 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. We ran it on the host terminator.movie.edu:

# /usr/sbin/named

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

# /usr/sbin/named -c 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 with facility daemon under the name named. You might be able to find out where syslog messages are logged by looking for the daemon facility 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 saves only the ones that are at severity LOG_NOTICE or higher. Some useful messages are sent at severity 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 said 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 zone data files or configuration file. For example, if you forget 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 24: Unknown type:
                192.249.249.2
Jan 10 20:48:32 terminator named[3221]: db.movie.edu Line 24:
                Database error near (192.249.249.2)
Jan 10 20:48:32 terminator named[3221]: master zone "movie.edu" (IN) rejected due 
to errors (serial 1)

Or, if you misspell 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]: /etc/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
Jul 24 20:56:26 terminator named[1496]: db.movie.edu:33: owner name error
Jul 24 20:56:26 terminator named[1496]: db.movie.edu:33: Database error near (A)
Jul 24 20:56:26 terminator named[1496]: master zone "movie.edu" (IN) rejected due 
to errors (serial 1)

If you have a syntax error, check the line numbers mentioned in the syslog error message to see if you can figure out the problem. You've seen what the zone data 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, to see the gory syntactic details of all the resource records. If you can fix the syntax error, do so and then reload the name server with ndc, the name daemon controller:

# ndc reload

so that it rereads the zone data files.^[4] You'll see more information in Chapter 7 on using ndc to control the name server.

^[4] For a BIND 9 name server, you'd need to use rndc, but we haven't shown you how to configure that yet. Skip ahead to Chapter 7 if you'd like to see how that's done. ndc works without much configuration, though.

4.7.3 Testing Your Setup with nslookup

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

4.7.3.1 Set the local domain name

Before running nslookup, you need to set the host's local domain name. With this configured, you can look up a name like carrie instead of having to spell out carrie.movie.edu—the system adds the domain name movie.edu for you.

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

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

domain movie.edu

Or, set hostname(1) to 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 domain 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 first name server specified in resolv.conf. (Without a name specified in resolv.conf, the resolver defaults to querying the local name server.) To look up a host's address with nslookup, run nslookup with the host's domain name as the only argument. A lookup of a local domain 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 domain name works, your local name server has been configured properly for your forward-mapping zone. 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 zone data—check your zone data file—or you didn't set your local domain name in hostname(1), or some name server error occurred (though 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 (reverse-mapping) zones. If the lookup fails, you'll see the same error messages as when you looked up a domain name.

4.7.3.4 Look up a remote domain name

The next step is to try using the local name server to look up a remote domain name, like ftp.uu.net, or another system you know of 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 how to contact them to find information about domain names in zones other than your own. If it fails, either you forgot to configure the root hints 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 zone. 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're testing, though, run one more test. Try having a remote name server look up a domain name in one of your zones. This will work only if your parent zone's name servers have already delegated your zones to the name server you just set up. If your parent required you to have your two name servers running before delegating your zones, skip ahead to the next section.

To make nslookup use a remote name server to look up a local domain name, give the local host's domain name as the first argument and the remote server's domain 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. Here, for instance, gatekeeper.dec.com looks up carrie.movie.edu:

% 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 zones may not be registered with your parent name servers. That's not a problem, at first, because systems within your zones can look up the domain names of other systems both within and outside of your zones. You'll be able to send email and to FTP to local and remote systems, though some systems won't allow FTP connections if they can't map your hosts' addresses back to domain names. But not being registered will shortly become a problem. Hosts outside your zones can't look up domain names in your zones—you can send email to friends in remote zones but you won't get their responses. To fix this problem, contact the administrators of your parent zones and have them check the delegation of your zones.

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 configure it to start 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 or /etc/named.boot 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.d/*/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