4.6 Running a Secondary Name Server

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 in your zone. 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 secondary name server instead.

How does a server know if it is a primary master or a secondary for a zone? The DNS server configuration information in the Registry tells the server it is a primary master or a secondary 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 secondaries for a zone—they only say who the servers are. (Globally, DNS doesn't care; as far as the actual name resolution goes, secondary servers are as good as primary master servers.)

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

A secondary name server is not limited to loading zones from a primary master name server; a secondary can load from another secondary. The big advantage of secondary name servers is that you maintain only one set of zone datafiles: the ones on the primary master name server. You don't have to worry about synchronizing the files among name servers; the secondaries do that for you.

A secondary name server doesn't need to retrieve all of its datafiles over the network; the cache.dns file is the same as on a primary master, so you'll need a local copy on the secondary. Fortunately, the DNS server installation process includes this file.

4.6.1 Add a New Server to the DNS Console

The first step in configuring a secondary server is to add the server to the DNS console's world view. Just as we did when configuring the primary master, select Action Connect to DNS Server, then enter the name or IP address of the secondary. In this case our secondary will be wormhole with IP address 192.249.249.1. Of course, the DNS server has to be installed and running on the secondary-to-be for the DNS console to be able to manage it.

4.6.2 Create a New Zone

This new server will be a secondary for every zone on the primary, so we'll have to go through the new zone process for each zone. Let's start with movie.edu. Select Action New Zone. This time, select Secondary zone in the second window of the wizard. In the third window, select Forward lookup zone. The fourth window is shown in Figure 4-29.

Figure 4-29. Creating a new secondary zone: specifying the zone's domain name

In the Zone name field, enter the domain name of the zone (in this case, movie.edu). Click Next to move to the next window, shown in Figure 4-30.

Figure 4-30. Creating a new secondary zone: specifying master servers

At this point, the processes of creating a primary master zone and a secondary zone really diverge. This is the screen where you specify where this name server will get the zone data. In this example, we're making wormhole a secondary for the movie.edu zone. We need to tell wormhole to load the zone from terminator, the primary master. In fact, on this screen you can specify multiple IP addresses. In advanced (and complicated) configurations, a secondary can sometimes get the zone information from multiple primaries or multiple sources. The DNS console supports those configurations. You could also just specify the IP address of another secondary after that of the primary: in case the primary is down, this secondary can load from another secondary. Of course, Movie U. doesn't have another secondary (yet).

For now, we just specify terminator's IP address, 192.249.249.3, then click Next. The final window in the process is the same as when creating a primary zone: it just tells you that you're done now and asks you to click Finish. We'll omit showing it to you.

When you're done, the new secondary immediately initiates a zone transfer to the primary to download the zone. Within a few seconds you should be able to double-click the secondary's icon for the zone and see the records in the zone.

4.6.3 Add an NS Record for the New Secondary Name Server

Your new secondary won't be much good if the rest of the world doesn't know about it. As a general rule, when you add another name server for a zone, you also need to add an NS record for it. (We'll discuss the exceptions to this in Chapter 9.)

You need to add an NS record for the secondary on the zone's primary. (Remember that all changes to a zone are made on the primary and propagate automatically to the secondaries. Don't get confused by the fact that the DNS console lets you see all your name servers—you make the changes only to the zone's primary.) In our case, we need to add an NS record for wormhole to the movie.edu zone. So we click on movie.edu under terminator and select Action Properties. Click on the Name Servers tab and you'll see a window like the one in Figure 4-31.

Figure 4-31. NS records for the movie.edu zone

This window shows that right now there's only one NS record for the movie.edu zone, which specifies terminator.movie.edu as an authoritative name server. To add another, click Add and you'll see the window shown in Figure 4-32.

Figure 4-32. Adding an NS record

Enter the name and IP address of the secondary name server and click OK.

4.6.4 Don't Forget the in-addr.arpa Zones!

Now repeat this secondary zone creation process with the 249.249.192.in-addr.arpa and 253. 253.192.in-addr.arpa zones.

4.6.5 SOA Values

Remember this SOA record for the movie.edu zone?

@                       IN  SOA terminator.movie.edu.  hostmaster.movie.edu. (
                         17           ; serial number
                         900          ; refresh
                         600          ; retry
                         86400        ; expire
                         3600       ) ; default TTL

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

The serial number applies to all the data within the zone. Think of it as a version number for the zone. When we created this zone with the DNS console, the serial number began at 1. The DNS console automatically increments the serial number in a zone's SOA record whenever you make a change to the zone. The current serial number of 17 shows we've made a few changes since creating the zone. If you look at SOA records from other zones, you might see the date encoded in the serial number—for example, 2000102301. 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. Note that you can't use this convention with the DNS console. It just increments the serial number by one each time a change is made and doesn't understand the date encoding.

When a secondary name server contacts a primary master server for zone data, it first asks for the serial number of the data. If the secondary's serial number is lower than the primary's, the secondary's zone data is out of date. In this case, the secondary pulls a new copy of the zone. As you might guess, if you ever modify the zone datafiles on the primary master by hand, you must increment the serial number, too. Updating zone datafiles is covered in Chapter 7.

The next four fields specify various time intervals in seconds:

refresh

The refresh interval tells the secondary how often to check that its data is up to date. To give you an idea of the system load this feature causes, a secondary will make one SOA query per zone per refresh interval. The default value generated by the DNS console when the zone was created, one hour, is reasonably aggressive. Most users will tolerate a delay of half 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 doesn't change very often, or if all your secondaries are spread over long distances (as the root name servers are), consider a longer value, such as 24 hours.

retry

If a secondary fails to reach the primary name server(s) after the refresh period (the hosts or hosts could be down), it starts trying to connect every retry seconds. The retry interval is usually shorter than the refresh interval, but it doesn't have to be.

expire

If a secondary fails to contact the primary server(s) for expire seconds, the secondary expires its data. Expiring the data means the secondary stops giving out answers about the data because the data is too old to be useful. Essentially, this field says: at some point, the data is so old that having no data is better than having stale data. We think Microsoft's default expire time of 86,400 seconds (24 hours) is awfully short. Expire times on the order of a week are common, and the interval can be 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 secondaries will expire their data before trying to load new data.

default TTL

TTL stands for time to live. This value applies to all the resource records in the zone datafile. The name server supplies this TTL in query responses, allowing other servers to cache the data for the TTL interval. If your data doesn't change much, you might consider using a minimum TTL of several days. One week is about the longest value that makes sense. The default value of 3,600 seconds (one hour) is very short, which we don't recommend 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 loading on your systems and lengthen the propagation of changes; shorter times increase the load on your systems and speed up the propagation of changes. We find the following values work well for most sites; they're also a good starting point if you're not sure what values to use:

       10800 ;  Refresh         3 hours
        3600 ;  Retry           1 hour
     2592000 ;  Expire         30 days
       86400 ;  Minimum TTL     1 day

Some final notes about TTL values. First, the DNS console only displays TTL values on individual records if you're in advanced mode. Check out the setting on the View menu. Second, the DNS console displays TTLs in a somewhat cryptic fashion. Take a look back at the NS record we added in Figure 4-32. Notice the TTL specified as 0: 1: 0: 0. "What the heck is that?" you ask. Well, the first field is days, then hours, minutes, and seconds. So rather than display a value in seconds and make you do the math, the DNS console lets you specify a TTL in a more convenient way.