|
Chapter 4 Setting Up BIND |
|
|
|
Chapter 4 Setting Up BIND |
|
You need to set up another name server for robustness. You can (and probably will) set up more than two name servers. Two servers are the minimum. If you have only one name server and it goes down, no one can look up 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. Set up a slave name server. You can always change a slave name server into a primary master name server later if you decide that you want to expend the extra work it takes to run multiple primary master name servers.
How does a server know if it is a primary master or a slave for a zone? The named.conf file tells the server it is a primary master or a slave on a per-zone basis. The NS records don't tell us which servers are the primary master for a zone and which servers are slave for a zone - 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 is different 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 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 master name server; a slave server can load from another slave server.
The big advantage of slave name servers is that you only maintain one set of the DNS database files, 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 it is current. The polling interval is one of those numbers in the SOA record that we haven't explained yet. ( BIND version 8 speeds up the distribution of zone data, which we will describe later.)
A slave name server doesn't need to retrieve all of its db files 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 data never changes - it might as well be a primary master.
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.0host: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.
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.
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.
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:
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.
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.
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 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 .
|
|
|
|
| 4.7 Running a Primary Master Name Server |
|
4.9 Adding More Domains |