Running a Slave Name Server (DNS and BIND, 4th Edition)

4.8. Running a Slave Name Server

You need to set up another name server for robustness. You can (and probably will eventually) set up more than two authoritative name servers for your zones. Two name servers are the minimum -- if you have only one name server and it goes down, no one can look up domain names. A second name server splits the load with the first server or handles the whole load if the first server is down. You could set up another primary master name server, but we don't recommend it. Instead, set up a slave name server. You can always change a slave name server into a primary master name server later if you decide to expend the extra effort it takes to run multiple primary master name servers.

How does a server know if it's the primary master or a slave for a zone? The named.conf file tells the name server whether it is the primary master or a slave on a per-zone basis. The NS records don't tell us which server is the primary master for a zone and which servers are slaves -- they only say who the servers are. (Globally, DNS doesn't care; as far as the actual name resolution goes, slave servers are as good as primary master servers.)

What's the difference between a primary master name server and a slave name server? The crucial difference is where the server gets its data. A primary master name server reads its data from zone data files. A slave name server loads its data over the network from another name server. This process is called a zone transfer.

A slave name server is not limited to loading zones from a primary mastername server; it can also load from another slave server.

The big advantage of slave name servers is that you maintain only one set of zone data files for a zone, the ones on the primary master name server. You don't have to worry about synchronizing the files among name servers; the slaves do that for you. The caveat is that a slave does not resynchronize instantly -- it polls to see if its zone data is current. The polling interval is one of those numbers in the SOA record that we haven't explained yet. (BIND Versions 8 and 9 support a mechanism to speed up the distribution of zone data, which we'll describe later.)

A slave name server doesn't need to retrieve all its zone data over the network; the overhead files, db.cache and db.127.0.0, are the same as on a primary master, so keep a local copy on the slave. That means that a slave name server is a primary master for 0.0.127.in-addr.arpa. Well, you could make it a slave for 0.0.127.in-addr.arpa, but that zone's data never changes -- it may as well be a primary master.

4.8.1. Setup

To set up your slave name server, create a directory for the zone data files on the slave name server host (e.g., /var/named ) and copy over the files /etc/named.conf, db.cache, and db.127.0.0 :

# rcp /etc/named.conf host:/etc
# rcp db.cache db.127.0.0 host:db-file-directory

You must modify /etc/named.conf on the slave name server host. For BIND 4, change every occurrence of primary to secondary except for the 0.0.127.in-addr.arpa zone. Before the filename on each of these lines, add the IP address of the primary master server you just set up. For example, if the original BIND 4 configuration file line was this:

primary  movie.edu      db.movie.edu

then the modified line looks like this:

secondary  movie.edu      192.249.249.3 db.movie.edu

If the original BIND 8 or 9 configuration file line was:

zone "movie.edu" in {
      type master;
      file "db.movie.edu";
};

change master to slave and add a masters line with the IP address of the master server:

zone "movie.edu" in {
      type slave;
      file "bak.movie.edu";
      masters { 192.249.249.3; };
};

This tells the name server that it is a slave for the zone movie.edu and that it should track the version of this zone kept on the name server at 192.249.249.3. The slave name server keeps a backup copy of this zone in the local file bak.movie.edu.

For Movie U., we set up our slave name server on wormhole.movie.edu. Recall that the configuration file on terminator.movie.edu (the primary master) looks like this:

directory /var/named

primary  movie.edu                db.movie.edu
primary  249.249.192.in-addr.arpa db.192.249.249
primary  253.253.192.in-addr.arpa db.192.253.253
primary  0.0.127.in-addr.arpa     db.127.0.0
cache    .                        db.cache

We copy /etc/named.conf, db.cache, and db.127.0.0 to wormhole.movie.edu, and edit the configuration file as previously described. The BIND 4 configuration file on wormhole.movie.edu now looks like this:

directory /var/named

secondary  movie.edu                192.249.249.3 bak.movie.edu
secondary  249.249.192.in-addr.arpa 192.249.249.3 bak.192.249.249
secondary  253.253.192.in-addr.arpa 192.249.249.3 bak.192.253.253
primary    0.0.127.in-addr.arpa     db.127.0.0
cache      .                        db.cache

The equivalent BIND 8 or 9 configuration file looks like this:

options {
        directory "/var/named";
};

zone "movie.edu" in {
        type slave;
        file "bak.movie.edu";
        masters { 192.249.249.3; };
};

zone "249.249.192.in-addr.arpa" in {
        type slave;
        file "bak.192.249.249";
        masters { 192.249.249.3; };
};

zone "253.253.192.in-addr.arpa" in {
        type slave;
        file "db.192.253.253";
        masters { 192.249.249.3; };
};

zone "0.0.127.in-addr.arpa" in {
        type master;
        file "db.127.0.0";
};

zone "." in {
        type hint;
        file "db.cache";
};

This causes the name server on wormhole.movie.edu to load movie.edu, 249.249.192.in-addr.arpa, and 253.253.192.in-addr.arpa over the network from the name server at 192.249.249.3 (terminator.movie.edu). It also saves a backup copy of these files in /var/named. You may find it handy to isolate the backup zone data files in a subdirectory. We name them with a unique prefix like bak, since on rare occasions, we may have to delete all of the backup files manually. It's also helpful to be able to tell at a glance that they're backup zone data files so that we're not tempted to edit them. We'll cover more on backup files later.

Now start up the slave name server. Check for error messages in the syslog file as you did for the primary master server. As on the primary master, the command to start up a name server is:

# /usr/sbin/named

One extra check to make on the slave that you didn't have to make on the primary master is to see that the name server created the backup files. Shortly after we started our slave name server on wormhole.movie.edu, we saw bak.movie.edu, bak.192.249.249, and bak.192.253.253 appear in the /var/named directory. This means the slave has successfully loaded these zones from the primary master and saved a backup copy.

To complete setting up your slave name server, try looking up the same domain names you looked up after you started the primary master server. This time, you must run nslookup on the host running the slave name server so that the slave server is queried. If your slave is working fine, add the proper lines to your system startup files so that the slave name server is started when your system boots up and hostname(1) is set to a domain name.

4.8.2. Backup Files

Slave name servers are not required to save a backup copy of the zone data. If there is a backup copy, the slave server reads it on startup and later checks with the master server to see if the master server has a newer copy instead of loading a new copy of the zone immediately. If the master server has a newer copy, the slave pulls it over and saves it in the backup file.

Why save a backup copy? Suppose the master name server is down when the slave starts up. The slave will be unable to transfer the zone and therefore won't function as a name server for that zone until the master server is up. With a backup copy, the slave has zone data, although it might be slightly out of date. Since the slave does not have to rely on the master server always being up, it's a more robust setup.

To run without a backup copy, omit the filename at the end of the secondary lines in the BIND 4 configuration file. In BIND 8 or 9, remove the file line. However, we recommend configuring all your slave name servers to save backup copies. There is very little extra cost to saving a backup zone data file, but there is a very high cost if you get caught without a backup file when you need it most.

4.8.3. SOA Values

Remember this SOA record?

movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
                          1        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 day

We never explained what the values between the parentheses were for.

The serial number applies to all the data within the zone. We chose to start our serial number at 1, a logical place to start. But many people find it more useful to use the date in the serial number instead, like 1997102301. This format is YYYYMMDDNN, where YYYY is the year, MM is the month, DD is the day, and NN is a count of how many times the zone data was modified that day. These fields won't work in any other order, since no other order gives a value that always increases as the date changes. This is critical: whatever format you choose, it's important that the serial number always increase when you update your zone data.

When a slave name server contacts a master server for zone data, it first asks for the serial number on the data. If the slave's serial number for the zone is lower than the master server's, the slave's zone data is out of date. In this case, the slave pulls a new copy of the zone. If a slave starts up and there is no backup file to read, it will always load the zone. As you might guess, when you modify the zone data files on the primary master, you must increment the serial number. Updating your zone data files is covered in Chapter 7, "Maintaining BIND".

The next four fields specify various time intervals, in seconds by default:

refresh: The refresh interval tells a slave for the zone how often to check that the data for this zone is up to date. To give you an idea of the system load this feature causes, a slave makes one SOA query per zone per refresh interval. The value we chose, three hours, is reasonably aggressive. Most users will tolerate a delay of half a working day for things like zone data to propagate when they are waiting for their new workstation to become operational. If you provide one-day service for your site, you could consider raising this value to eight hours. If your zone data doesn't change very often or if all of your slaves are spread over long distances (as the root name servers are), consider a value that is even longer, say 24 hours.

retry: If the slave fails to reach the master name server after the refresh interval (the host could be down), it starts trying to connect every retry seconds. Normally, the retry interval is shorter than the refresh interval, but it doesn't have to be.

expire: If the slave fails to contact the master name server for expire seconds, the slave expires the zone. Expiring the zone means that the slave stops giving out answers about the zone because the zone data is too old to be useful. Essentially, this field says that at some point, the data is so old that giving out no data is better than giving out stale data. Expire times on the order of a week are common -- longer (up to a month) if you frequently have problems reaching your updating source. The expiration time should always be much larger than the retry and refresh intervals; if the expire time is smaller than the refresh interval, your slaves will expire the zone before trying to load new data.

negative caching TTL: TTL stands for time to live. This value applies to all negative responses from the name servers authoritative for the zone.

TIP: On versions of BIND before BIND 8.2, the last field in the SOA record is both the default time to live and the negative caching time to live for the zone.

Those of you who have read earlier versions of this book may have noticed the change in the format we used for the SOA record's numeric fields. Once upon a time, BIND only understood units of seconds for the four fields we just described. (Consequently, a whole generation of administrators know that there are 608400 seconds in a week.) Now, with all but the oldest BIND name servers (4.8.3), you can specify units besides seconds for these fields and as arguments to the TTL control statement, as we saw early in this chapter. For example, you can specify a three-hour refresh interval with 3h, 180m, or even 2h60m. You can also use d for days and w for weeks.

The right values for your SOA record depend upon the needs of your site. In general, longer times cause less load on your name servers and can delay the propagation of changes; shorter times increase the load on your name servers and speed up the propagation of changes. The values we use in this book should work well for most sites. RFC 1537 recommends the following values for top-level name servers:

Refresh        24 hours
Retry           2 hours
Expire         30 days
Default TTL     4 days

There is one implementation feature you should be aware of. Older versions (pre-4.8.3) of BIND slaves stop answering queries during a zone load. As a result, BIND was modified to spread out the zone loads, reducing the periods of unavailability. So, even if you set a low refresh interval, your slaves may not check as often as you request. BIND attempts a certain number of zone loads and then waits 15 minutes before trying another batch.

Now that we've told you all about how slave name servers poll to keep their data up to date, BIND 8 and 9 change how zone data propagates! The polling feature is still there, but BIND 8 and 9 add a notification when zone data changes. If both your primary master server and your slaves run BIND 8 or 9, the primary master notifies the slave that a zone has changed within 15 minutes of loading a new copy of that zone. The notification causes the slave server to shorten the refresh interval and attempt to load the zone immediately. We'll discuss this more in Chapter 10, "Advanced Features".

4.8.4. Multiple Master Servers

Are there other ways to make your slave name server's configuration more robust? Yes -- you can specify up to 10 IP addresses of master servers. In a BIND 4 configuration file, just add them after the first IP address and before the backup filename. In a BIND 8 or 9 configuration file, add them after the first IP address and separate them with semicolons:

masters { 192.249.249.3; 192.249.249.4; };

The slave will query the master server at each IP address in the order listed until it gets a response. Through BIND 8.1.2, the slave would always transfer the zone from the first master name server to respond if that master had a higher serial number. The slave would try successive master servers only if the previous master didn't respond. From BIND 8.2 on, however, the slave actually queries all of the master name servers listed and transfers the zone from the one with the highest serial number. If multiple master servers tie for the highest serial number, the slave transfers the zone from the first of those masters in the list.

The original intent of this feature was to allow you to list all the IP addresses of the host running the primary master name server for the zone if that host were multihomed. But since there is no check to determine whether the contacted server is a primary master or a slave, you can list the IP addresses of hosts running slave servers for the zone if that makes sense for your setup. That way, if the first master server is down or unreachable, your slave can transfer the zone from another master name server.