9.4 Changing TTLs

An experienced zone administrator needs to know how to set the time to live on his zone's data to his best advantage. The TTL on a resource record, remember, is the time for which any server can cache that record. So if the TTL for a particular resource record is 3,600 seconds and a server outside your network caches that record, it will have to remove the entry from its cache after an hour. If it needs the same data after the hour is up, it'll have to query your name servers again.

When we introduced TTLs, we emphasized that your choice of a TTL would dictate how current you would keep copies of your data, at the cost of increased load on your name servers. A low TTL would mean that name servers outside your network would have to get data from your name servers often and that the data would therefore be kept current. On the other hand, your name servers would be peppered by the name servers' queries.

You don't have to choose a TTL once and for all, though. You can—and experienced administrators do—change TTLs periodically to suit your needs.

Suppose we know that one of our hosts is about to be moved to another network. This host houses the movie.edu film library, a large collection of files our site makes available to hosts on the Internet. During normal operation, outside name servers cache the address of our host according to the minimum (default) TTL in the SOA record. (We set the movie.edu TTL to be one day in our sample files.) A name server caching the old address record just before the change could have the wrong address for as long as a day. A loss of connectivity for a full day is unacceptable, though. What can we do to minimize the loss of connectivity? We can lower the TTL so that outside servers cache the address record for a shorter period. By reducing the TTL, we force the outside servers to update their data more frequently, which means that any changes we make when we actually move the system will be propagated to the outside world quickly. How short can we make the TTL? Unfortunately, we can't safely use a TTL of zero, which should mean "don't cache this record at all." (Some older BIND Version 4 name servers can't cope with a zero TTL.) Small TTLs, like 30 seconds, are okay, though. To add an explicit TTL on an individual resource record, you'll need the DNS console's advanced view so that you can actually see individual records' TTLs: choose View Advanced.

Click on the domain name of the zone in the left panel, then double-click the record when it appears in the right panel. The Properties window is displayed, and you can type the TTL. Recall that the subfields in the TTL field are (from left to right) days, hours, minutes, and seconds.

Figure 9-7 provides an example of an explicit TTL from movie.edu.

Figure 9-7. An explicit TTL on cujo.movie.edu

The record the DNS console adds to the movie.edu zone datafile looks like this:

cujo  3600  IN  A  192.253.253.5

Note the explicit TTL of 3,600 seconds (one hour) in the TTL field, overriding the TTL in the zone's SOA record.

You may have seen the last field of the SOA record called simply the "minimum" field (some versions of nslookup display it that way, for example). So why does it show up in the DNS console as "Minimum (default)"? (To see what we mean, take a look at the SOA record shown back in Chapter 4 in Figure 4-19.) If the Microsoft DNS Server followed the original DNS RFCs, the TTL field in the SOA record would really define the minimum TTL value for all resource records in the zone. Thus, you could specify only explicit TTLs larger than this minimum. Neither Microsoft nor BIND name servers work this way, though. In other words, in real life, "minimum" is not really minimum. Instead, the Microsoft DNS Server implements the minimum TTL field in the SOA record as a "default" TTL—hence the "Minimum (default)" wording. If there is no TTL on a record, the minimum applies. If there is a TTL on the resource record, the Microsoft DNS Server allows it even if it is smaller than the minimum. That one record is sent out in responses with the smaller TTL while all other records are sent out with the "Minimum (default)" TTL from the SOA record.

You should also know that when giving out answers, a secondary supplies the same TTL a primary master does—that is, if a primary gives out a TTL of one hour for a particular record, a secondary will, too. The secondary doesn't decrement the TTL according to how long it has been since it loaded the zone. So, if the TTL of a single resource record is set smaller than the SOA minimum, both the primary and secondary name servers give out the resource record with the same, smaller TTL. If the secondary name server has reached the expiration time for the zone, it expires the whole zone. It will never expire an individual resource record within a zone.

The Microsoft DNS Server does allow you to put a small TTL on an individual resource record if you know that the data is going to change shortly. Thus, any server caching that data caches it only for a brief time. Unfortunately, while the name server makes tagging records with a small TTL possible, most administrators don't take the time to do it. When a host changes addresses, you often lose connectivity to it for a while.

More often than not, the host having its address changed is not one of the main hubs on the site, so the outage affects few people. If one of the mail hubs or a major web server or ftp archive—like the film library—is moving, though, a day's loss of connectivity may be unacceptable. In cases like this, the administrator should plan ahead and reduce the TTL on the data to be changed.

Remember that the TTL on the affected data will need to be lowered before the change takes place. Reducing the TTL on a workstation's address record and changing the workstation's address simultaneously may do you little or no good; the address record may have been cached seconds before you made the change and may linger until the old TTL times out. You must also be sure to factor in the time it'll take your secondaries to load from your primary master. For example, if your minimum TTL is 12 hours and your refresh interval is 3 hours, be sure to lower the TTLs at least 15 hours ahead of time, so that by the time you move the host, all the old, longer TTL records will have timed out. Of course, if all of your secondaries are using NOTIFY, the secondaries shouldn't take the full refresh interval to sync up.

9.4.1 Changing Other SOA Values

We briefly mentioned increasing the refresh interval as a way of offloading your primary name server. Let's discuss refresh in a little more detail and go over the remaining SOA values, too.

The refresh value, you'll remember, controls how often a secondary checks whether its zone data is up-to-date. The retry value becomes the refresh time after the first failure to reach a master name server. The expire value determines how long zone data can be held before it's discarded when a master is unreachable. Finally, the minimum TTL sets how long zone information may be cached.

Suppose we've decided we want the secondaries to pick up new information every hour instead of every three hours. We change the refresh value to one hour in each of the zones. Since retry is related to refresh, we should probably reduce retry, too—to every 15 minutes or so. Typically, retry is less than refresh, but that's not required. Although lowering the refresh value will speed up the distribution of zone data, it will also increase the load on the server from which data is being loaded, since the secondaries will check more often. The added load isn't much, though; each secondary makes a single SOA query during each zone's refresh interval to check its master's copy of the zone. So with two secondary name servers, changing the refresh time from three hours to one hour will generate only four more queries (per zone) to the primary master in any three-hour span.

If all of your secondaries use NOTIFY, of course, refresh doesn't mean as much. But if you have even one BIND Version 4 slave, your zone data may take up to the full refresh interval to reach it.

Some older versions of BIND secondaries 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 secondaries may not check exactly as often as you request. BIND Version 4 name servers attempt a certain number of zone loads and then wait 15 minutes before trying another batch. On the other hand, BIND Version 4.9 and later may also refresh more often than the refresh interval. These versions of BIND will wait a random number of seconds between one-half of the refresh interval and the full refresh interval to check serial numbers.

Expiration times on the order of a week—longer if you frequently have problems reaching your updating source—are common. 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. If your zone's data doesn't change much, you might consider raising the minimum (default) TTL. The SOA's minimum (default) TTL value is typically one day (86,400 seconds), but you can make it longer. One week is about the longest value that makes sense for a TTL. If it's longer than that, you may find yourself unable to change bad, cached data in a reasonable amount of time.