2.10 Preventing Remote Name Servers from Caching a Resource Record

2.10.1 Problem

You want to prevent remote name servers from caching one or more records in your zone.

2.10.2 Solution

Give the record (or records) an explicit -- and low -- time to live (TTL). For example, to keep other name servers from caching your web server's addresses, you could add these A records to the zone data file:

www.foo.example.    1    IN    A    10.0.0.1
www.foo.example.    1    IN    A    10.0.0.2
www.foo.example.    1    IN    A    10.0.0.3

Specify the explicit TTL between the domain name owner of the record and the class field. By default, the value is an integer number of seconds. You can also use a scaled value, as you would in the $TTL control statement.

2.10.3 Discussion

Note that the TTLs for the three www.foo.example A records are the same; that's no accident . If you were to use different TTLs for records in the same RRset (of the same type, and attached to the same domain name), a remote name server might age only some of them out, leading to unpredictable results. Consequently, modern name servers notice this misconfiguration and "trim" mismatched TTLs within a single RRset to the smallest TTL of the group .

Why did I use a TTL of one instead of zero? After all, a zero TTL would seem to say, "Don't cache this record." Unfortunately, TTLs of zero tickle a bug in some older name servers, which age out the records before returning them to the resolver that initiated the query. D'oh!

2.10.4 See Also

Section 2.2 for the syntax of scaled values, and "Changing TTLs" in Chapter 8 of DNS and BIND .

2.11 Adding a Multihomed Host

2.11.1 Problem

You want to add a multihomed host to DNS.

2.11.2 Solution

Add multiple A records to the host's domain name , one per IP address. For example, for a file server with two network interfaces, you might add these records:

fs.foo.example.    IN    A    10.0.0.9
fs.foo.example.    IN    A    192.168.0.9

To handle reverse mapping for the host, add one PTR record to each of the appropriate two reverse-mapping zones:

9.0.0.10.in-addr.arpa.    IN    PTR    fs.foo.example.

and

9.0.168.192.in-addr.arpa.    IN    PTR    fs.foo.example.

2.11.3 Discussion

Clients looking up the address of fs.foo.example will see both IP addresses, and can choose which one to use (though most clients will just use the first address returned). Remember that, by default, they'll be returned in round robin order.

For troubleshooting purposes, you may want to add two more A records, each of which maps to just one of your multihomed host's addresses. For example:

fs-eth0.foo.example.    IN    A    10.0.0.9
fs-eth1.foo.example.    IN    A    192.168.0.9

This lets you test whether a particular network interface on the file server is up, by pinging fs-eth0.foo.example , for instance. You probably shouldn't add PTR records mapping the addresses back to these interface-specific names , though: most software can't handle multiple reverse mappings for a single IP address.

2.11.4 See Also

Section 2.8 for the behavior of round robin, and Chapter 4 of DNS and BIND .

2.12 Updating a Name Server's Root Hints File

2.12.1 Problem

You need to update a name server's root hints file.

2.12.2 Solution

FTP a copy of the most recent root hints file from ftp.rs.internic.net. It's called named.root , in the directory domain .

2.12.3 Discussion

The root hints file, which tells a name server the domain names and addresses of the root name servers, doesn't need to be updated often. The "current" version dates to August 1997, and the file can be slightly out-of-date without causing adverse effects. Still, you should probably check every six months or so to see if it's changed.

If you do download a new root hints file, remember to change the name of the file to whatever you have defined in your zone statement for the root hints, and then reload the name server.