Caching and TTLs

The $TTL zone directive and the TTL of the SOA record are also important parameters. Besides old zone data on slave servers, a source of old data is caches. This can't be avoided. The caches are out of your reach; you can't troubleshoot them. All you can do is set the TTLs correctly. The $TTL directive sets the default TTL for the zone. If your BIND version does not support the $TTL directive, the default TTL is taken from the minimum TTL field of the SOA. In modern caches, the SOA minimum TTL is used as the TTL for negative caching. Negative caching is described in RFC 2308. If a name is looked up and not found, the fact that it does not exist is cached for the time set by the minimum TTL. Older versions of BIND and DNS software did not perform negative caching. Negative caching means that if you ask about a name before it is available in DNS and then ask again but before the negative-caching expires, the entry is masked. The name is not available to you, even though it is available in DNS, because the cache knows it's not available. Running ndc restart flushes your cache.

The one thing about caches that you can troubleshoot, though, is what is in your cache. Problems with the cache can stem from cache corruption or DNS poisoning. DNS poisoning occurs when your cache receives and stores bogus DNS data, whether due to misconfiguration or ill will. Poisoning is discussed further in Chapter 8. Cache corruption stems from a bug in BIND causing the cache data structure to decay. I can honestly say that I have never experienced cache corruption; I have only read descriptions of it.

The contents of your cache can help you track down these things, but only if you enable a handy little option:

 options {     ...     host-statistics yes;     ... }; 

This enables accounting on the host level, including remembering where the cached records came from. It also keeps a lot of statistics about all the hosts BIND talks to. All in all, it uses a lot of memory. With ndc dumpdb, you can cause named to dump its cache into /var/named/ named_dump.db (if /var/named is your named directory). The contents of the file changes a bit with the versions of BIND. With BIND 8.2, the start of the file lists the sources of its authoritative zone data. The file reads like a zone file (see Listing 6.1).

Listing 6.1 A Database/Cache Dump

 $ORIGIN . .       314073  IN      NS      E.ROOT-SERVERS.NET.     ;Cr=auth [128.9.0.107]         314073  IN      NS      D.ROOT-SERVERS.NET.     ;Cr=auth [128.9.0.107] ... ORG     314090  IN      NS      A.ROOT-SERVERS.NET.     ;Cr=addtnl [192.33.4.12]         314090  IN      NS      E.GTLD-SERVERS.NET.     ;Cr=addtnl [192.33.4.12] ... $ORIGIN uio.noi. ;www    765     IN      SOA     A.ROOT-SERVERS.NET. hostmaster.nsiregistry.NET. ( ;               2000081201 1800 900 604800 86400 );.;NXDOMAIN   ;-$     ;Cr=auth  [192.36.148.17] $ORIGIN ORG. OPENNAP 164385  IN      NS      NS1.KINETIC.ORG.        ;Cr=addtnl [207.200.81.69]         164385  IN      NS      NS1.WIREDGLOBAL.COM.    ;Cr=addtnl [207.200.81.69]         164385  IN      NS      NS2.WIREDGLOBAL.COM.    ;Cr=addtnl [207.200.81.69] ... $ORIGIN ROOT-SERVERS.NET. K       400473  IN      A       193.0.14.129            ;NT=89 Cr=answer [128.9.0.107] L       400473  IN      A       198.32.64.12            ;NT=147 Cr=answer [128.9.0.107] ... $ORIGIN penguin.bv. emperor 172800  IN      NS      ns.emperor.penguin.bv.  ;Cl=2         172800  IN      NS      ns.herring.bv.          ;Cl=2 lbt     172800  IN      HINFO   "PC" "Linux"            ;Cl=2         172800  IN      A       192.168.55.132          ;Cl=2 

If the cache is corrupted, it should be easy to see either by corrupted names or corrupted data. Corrupted data should be especially easy to spot in an HINFO or a TXT record; you would expect them to contain sensible strings, not line noise or other garbage.

The commented entry is a negative cache entry, showing the SOA of the zone as well as the reason for the negativity: NXDOMAIN (nonexistent domain). As you see, someone typed http://www.uio.noi, a nonexistent name, instead of http://www.uio.no, which results in this negative entry.

The NT field in the comments indicates the RTT in milliseconds. In the case of nameservers, this is very significant. BIND prefers servers with lower RTTs. The Cl flag indicates that the data was loaded from a zone file, whereas the Cr flag says how credible BIND thinks the data is. auth is best and is set when an authoritative answer is received. answer is next best, and is set for non-authoritative answers, and addtnl is for data from the authority and additional sections of the answer. The credibility rating is used to decide whether cached data should be replaced when new data for the same name and record type arrives. Cached data is replaced when new data with a higher credibility rating arrives. As you see in Listing 6.1, the penguin.bv data was loaded from a zone file, and only one answer is in the data the address of k.root-servers.net.

The format and contents of the database dump has changed over time. The previous dump is from 8.2.2. In 8.2.3, there will be an additional section in the dump about forwarding zones.

You can control the name of the dump file with the dump-file option:

 options {     dump-file "/var/named/better_name_here.db"; };