DNS on Windows 2000, Second Edition

Running a Slave 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 slave name server instead.

How does a server know if it is a primary master or a slave for a zone? The DNS server configuration information in the Registry tells the server it is a 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 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 maintain only one set of zone data 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.

A slave name server doesn’t need to retrieve all of its data files over the network; the cache.dns file is the same as on a primary master, so keep a local copy on the slave.

Tip

One point about slaves may become confusing: slaves used to be called secondary master name servers. We’ll use the term slave in this book, but you’ll see that the DNS console still uses the term secondary. As we said, the two are synonymous.

Add a New Server to the DNS Console

The first step in configuring a slave 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 Computer..., then enter the IP address of the slave. In this case our slave will be wormhole with IP address 192.249.249.1. Of course, the DNS server has to be installed and running on the slave-to-be for the DNS console to be able to manage it.

Create a New Zone

This new server will be a slave 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 Standard secondary (remember, this is synonymous with slave) in the second window of the wizard. In the third window, select Forward lookup zone. The fourth window is shown in Figure 4-23.

Figure 4-23. Creating a new secondary zone: specifying the zone’s domain name

In the Name field, enter the domain name of the zone (in this case, movie.edu). In the Server field, enter the IP address of the primary master name server. You can type this information or take advantage of a shortcut offered by the DNS console. When you click the Browse button, the DNS console shows you a view of the zones on all the name servers it’s managing. So rather than typing out movie.edu, we could have drilled down to find that zone in the Browse window, as shown in Figure 4-24.

Figure 4-24. Finding a zone with the Browse window

Whether you enter the zone and server manually or use the Browse shortcut, click Next to get the next window, shown in Figure 4-25.

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

At this point, the process of creating a primary master zone and a slave 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 slave 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, sometimes there are multiple primaries or multiple sources from which a slave can get the zone information. The DNS console supports those configurations. You could also just specify the IP address of another slave after that of the primary: in case the primary is down, this slave can load from another slave. Of course, Movie U. doesn’t have another slave (yet).

For now, we just specify terminator’s IP address, 192.249.249.3. (Once again you can click the Browse button and find terminator among the DNS console’s list of known name servers to avoid having to type its IP address.) 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 slave immediately initiates a zone transfer to the primary to download the zone. Within a few seconds you should be able to double-click the slave’s icon for the zone and see the records in the zone.

Add an NS Record for the New Slave Name Server

Your new slave 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 8.)

You need to add an NS record on the zone’s primary. (Remember that all changes to a zone are made on the primary and propagate automatically to the slaves. 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 highlight 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-26.

Figure 4-26. 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-27.

Figure 4-27. Adding an NS record

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

Don’t Forget the in-addr.arpa Zones!

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

SOA Values

Remember this SOA record for the movie.edu zone?

@    IN   SOA terminator.movie.edu.    administrator.movie.edu.    (
                        1           ; serial number
                        3600        ; refresh
                        600         ; retry
                        86400       ; expire
                        3600      ) ; minimum TTL

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. The DNS console automatically increments the serial number in a zone’s SOA record whenever you make a change to the zone. If you’ve maintained zone data files by hand, you might have encoded the date 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 were modified that day. Unfortunately, you can’t use that 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 slave name server contacts a primary master server for zone data, it first asks for the serial number of the data. If the slave’s serial number is lower than the primary’s, the slave’s zone data is out of date. In this case, the slave pulls a new copy of the zone. As you might guess, if you ever modify the zone data files on the primary master by hand, you must increment the serial number, too. Updating zone data 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 is 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 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 slaves are spread over long distances (as the root name servers are), consider a longer value, such as 24 hours.

retry

If a slave 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 slave fails to contact the primary 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 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 slaves will expire their data before trying to load new data.

minimum TTL

TTL stands for time to live. This value applies to all the resource records in the zone data file. 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. Again, 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 hours
     2592000 ;  Expire         30 days
       86400 ;  Minimum TTL     1 day

One final note about TTL values: the DNS console displays them in a somewhat cryptic fashion. Take a look back at the NS record we added in Figure 4-27. 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 (slightly) more convenient way.