4.8.1 Setup

To set up your slave name server, create a directory for the db files on the slave name server host (e.g., /usr/local/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 version 4, change every occurrence of primary to secondary except for 0.0.127.in-addr.arpa . 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 version 4 configuration file line was this:

primary  movie.edu      db.movie

then the modified line looks like:

secondary  movie.edu      192.249.249.3 db.movie

If the original version 8 configuration file line was:

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

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

zone "movie.edu" in {
      type slave;
      file "db.movie";
      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 that is being kept on the host 192.249.249.3. The slave name server will keep a backup copy of this zone in the local file db.movie .

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

directory /usr/local/named

primary  movie.edu                db.movie
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 copied /etc/named.conf , db.cache , and db.127.0.0 to wormhole and edited the configuration file as described above. The version 4 configuration file on wormhole now looks like this:

directory /usr/local/named

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

The equivalent version 8 configuration file looks like this:

options {
        directory "/usr/local/named";
};

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

zone "249.249.192.in-addr.arpa" in {
        type slave;
        file "db.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 to load movie.edu , 249.249.192.in-addr.arpa , and 253.253.192.in-addr.arpa over the network from 192.249.249.3 ( terminator ). It also saves a backup copy of these files in /usr/local/named . You may find it handy to isolate the backup files in a subdirectory or to name them with a unique suffix like .bak ; on rare occasions, you may have to delete all of the backup files manually. We'll cover more on backup files later.

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:

# 

/etc/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 , we saw db.movie , db.192.249.249 , and db.192.253.253 show up in the /usr/local/named directory. This means the slave has successfully loaded these zones from the primary master and has saved a backup copy.

To complete setting up your slave name server, try looking up the same names you looked up when the primary master server was started. This time nslookup must be run on the slave name server host 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 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 server is down when the slave starts up. The slave will be unable to transfer the zone and therefore won't function as a server for that zone until the master server is up. With a backup copy, the slave has some data, although it might be slightly out of date. Since the slave does not rely on the master server always being up, it is a more robust system.

To run without a backup copy, omit the filename at the end of the secondary lines in the version 4 configuration file. In version 8, remove the file line. We recommend having all your slave servers save backup copies, though. There is very little extra cost to having a backup file, but there is a very high cost if you get caught without a backup file when you need it most.

4.8.3 Multiple Master Servers

Are there other ways to make your slave server configuration more robust? Yes, you can specify up to ten IP addresses of master servers. In a version 4 configuration file, just add them after the first IP address, before the backup filename. In a version 8 configuration file, add them after the first IP address and terminate them with semicolons:

masters { 192.249.249.3; 192.249.249.4; };

The slave will try the master server at each IP address, in the order listed, until it successfully transfers the zone. The intent of this feature is to allow you to list all the IP addresses of the host running the primary master for the zone if that host is multihomed. But, since there is no check made that the contacted server is a primary master or slave, you can list the IP addresses of hosts running slave servers for the zone, if that makes sense for your setup.

4.8.4 SOA Values

Remember this SOA record?

movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
                          1        ; Serial
                          10800    ; Refresh after 3 hours
                          3600     ; Retry after 1 hour
                          604800   ; Expire after 1 week
                          86400 )  ; Minimum TTL of 1 day

We never explained what the values in 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 Y is the year, M is the month, D is the day, and NN is a count of how many times the zone data were modified that day. Whatever you choose, it's important that this 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 is lower than the master server's, the slave's zone data are out of date. In this case, the slave pulls a new copy of the zone. When a slave starts up and there is no backup file to read, it always loads the zone. As you might guess, when you modify the db files on the primary master, you must increment the serial number. Updating your db files is covered in Chapter 7 .

The next four fields specify various time intervals in seconds:

refresh

The refresh interval tells the slave how often to check that its data are up to date. To give you an idea of the system load this feature causes, a slave will make one SOA query per zone per refresh interval. The value we choose, three hours, is reasonably aggressive. Most users will tolerate a delay of half of a working day for things like name server data to propagate when they are waiting for their new workstation to be operational. If you provide one-day service for your site, consider raising this value to eight hours. If your data don'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: 24 hours.

retry

If the slave fails to reach the master name server(s) after the refresh period (the host(s) could be down), then 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 server(s) for expire seconds, the slave expires its data. Expiring the data means the slave stops giving out answers about the data because the data are too old to be useful. Essentially, this field says: at some point, the data are so old that having no data is better than having 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 their data before trying to load new data.

TTL

TTL stands for time to live . This value applies to all the resource records in the db file. The name server supplies this TTL in query responses, allowing other servers to cache the data for the TTL interval. If your data don't change much, you might consider using a minimum TTL of several days. One week is about the longest value that makes sense. A value as short as one hour can be used, but it is not recommended because of the amount of DNS traffic it causes.

What values you choose for your SOA record will depend upon the needs of your site. In general, longer times cause less load on your systems and lengthen the propagation of changes; shorter times increase the load on your systems 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 domain servers:

       86400 ;  Refresh        24 hours
        7200 ;  Retry           2 hours
     2592000 ;  Expire         30 days
      345600 ;  Minimum TTL     4 days

There is one implementation feature you need to be aware of. Older versions (pre-4.8.3) of BIND slaves stopped 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 servers poll to keep their data up-to-date, BIND version 8 changed how zone data propagates! The polling feature is still there, but version 8 adds a notification when zone data changes. If both your primary master server and your slaves are version 8, the primary master will notify 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 .