DNS configuration on Ubuntu, part I: the case for a local caching nameserver

One thing which is surprisingly lacking from the C resolver library (libresolv, part of glibc) is caching. Support for asynchronous DNS queries is also lacking, but that's less surprising. So, all calls to gethostbyname/_r() and getaddrinfo() are actually hitting the DNS servers in /etc/resolv.conf.

Many people don't distinguish between a stub resolver (the one in the C library) and a full-blown resolver, or caching (and recursing) nameserver, which is what those IP addresses in your /etc/resolv.conf represent. The stub resolver just asks a question to a caching nameserver among the lines "what is the address of www.foo.bar.com?", and then interprets what it receives back. However, nameservers have a more difficult job - you can get a glimpse of how they have to operate by playing with 'dig +trace'. What you will see is something along the lines: query root nameservers for the .com gTLD nameservers, then query one of the gTLDs for www.foo.bar.com, then maybe receive another referrral to the nameserver of bar.com, etc.

On Ubuntu, dig is part of dnsutils, which is unfortunate, since dig is part of the BIND distribution.

However, if all you use is a web browser like Firefox, you won't get hit that hard, because Firefox caches answers to DNS queries (for 15 minutes - see here,
- a google cache link on global server load balancing, which touches on browser DNS caching). However, whenever the cached records expire (or the first time around), firefox will hit your provider's nameservers, generating needless network traffic. Why?

Well, every DNS record has a TTL (time to live) field, which Firefox doesn't honor (because it's not visible in the structure returned by gethostbyname/_r()). If a record has a TTL of 1 hour, that means you hit the network 45 minutes too soon (and 4 times more than necessary).

Now, consider what would happen if the caching nameserver would be running on your computer. All traffic would go on the loopback, which is much faster and doesn't involve the network. Since the nameserver would honor TTLs, it won't make unnecessary queries. Depending on the domains you want to access, you could even bypass your ISP's nameservers completely; however, some ISPs might have some internal domains accesible only to their clients, and in that case you might need to query them sometimes. This can be easily solved with the 'forwarders' feature - you can have your local nameserver forward all its queries further to one of the ISP's nameservers. If the provider's nameservers are down, you can however configure your local caching nameserver to bypass them (although, as we'll see, it might involve disabling the forwarders).

Note that if you ask on bind-users about using forwarders, everybody will tell you that it's a bad idea - there is extra latency involved, and you have one more point of failure in the provider's DNS servers - if they fail, you won't be able to access the internet in the case you use forwarders exclusively ('forward only' option in BIND) or, in the best case, experience significant delays - the DNS query to one of the forwarders must time out, and then the local cache is free to try to resolve the name on its own. So, use it with care, and only if you want to be able to access some domains that you couldn't by having your local nameserver walk the DNS tree from the root nameservers down to your provider.

OK, I don't know how clear I have been, but I can recommend some extra reading: Cricket Liu and Paul Albitz - DNS and BIND, fifth edition. All the DNS veterans on bind-users swear by it.