When we introduced TTLs, we emphasized that your choice of a TTL dictates how current you keep copies of your data at the cost of increased load on your name servers. A low TTL means that name servers outside your network have to get data from your name servers often and therefore keep current. However, your name servers are then peppered by their 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.

If older BINDs followed the original DNS RFCs to the letter, the TTL field in the SOA record would really define the minimum TTL for all resource records in the zone. Thus, you could specify only explicit TTLs larger than this minimum. Older BIND name servers don't work this way, though. In other words, in BIND, "minimum" is not really minimum. Instead, BIND interprets the minimum TTL field in the SOA record as a "default" TTL. (Newer BINDs, of course, have the explicit default TTL set with $TTL to go by.) If there is no TTL on a record, the minimum applies. If there is a TTL on the resource record, BIND 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" TTL from the SOA record.

You should also know that when giving out answers, a slave 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 slave will, too. The slave doesn't decrement the TTL according to how long it's been since it loaded the zone. So, if the TTL of a single resource record is set smaller than the default, both the primary and slave name servers give out the resource record with the same, smaller TTL. If the slave 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.

So BIND 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 name server caching that data caches it only for a brief time. Unfortunately, while BIND makes tagging records with a small TTL possible, most administrators don't spend the time to do it. When a host's address changes, 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 FTParchive -- 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 needs 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 linger until the old TTL times out. And be sure to factor in the time it'll take your slaves to load from your primary master. For example, if your default 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 your slaves are BIND 8 or 9 name servers that use NOTIFY, the slaves shouldn't take the full refresh interval to synch up.