Caching DNS
(Domain Name System)

The main purpose of DNS (Domain Name Service) is to translate human-friendly textual computer names to the numeric IPaddresses used internally by computers. It's often called "name service" rather than the geekier internal name DNS. DNS is very occasionally also used to perform additional functions, which are generally only available from particular alternate DNS servers.

Most home users (who effectively have "read" but not "write" access to the Internet, and who have only a very small number of computers) don't even need to have (and so usually don't have) their own DNS servers. If they're present at all, Domain Name Service (DNS) servers most often provide name-to-IPaddress translation to other users for one's own computers. But providing such "authoritative" service isn't the only possible use of DNS servers. DNS servers can also be used to remember the answers to queries, and short-circuit future requests for the same information by responding with the remembered information (rather than sending any signals over the drop to or through the ISP). This use is usually called "caching DNS".

Why Caching DNS?

If there's no other alternative, every name-to-IPaddress translation request will go out over the ISP drop to domain name servers somewhere else on the Internet (probably some belonging to the ISP). Although each bit of DNS traffic is pretty small, all the bits can add up until a significant amount of the ISP drop bandwidth is being used for DNS request and response traffic. If internal computers instead send their queries to a local caching DNS server, DNS traffic over the ISP drop can be very significantly reduced. There will be quite a bit more bandwidth available for actual web data, so users will get the impression web browsing is speedier. (This performance problem will occur even if your ISP's name service to a single computer performs quite well. If in fact your ISP's name service does not perform adequately even for a single computer, that's yet another reason to consider implementing your own caching DNS.)

Typically web browsers search for websites by name (either because the name was typed in the address bar or because a hyperlink was clicked). Until its name-to-IPaddress translation request is answered, the web browser is "stuck". If a web filter is in place, it too will request name-to-IPaddress translation of the same computer name, and it too will be "stuck" until it gets a response. If the name-to-IPaddress translation requests can be responded to a little bit quicker, both the web browser and the web filter will become "un-stuck" sooner. Users will get the impression web browsing is snappier.

With a caching DNS server the initial request might take a few milliseconds longer. (If it appears noticeably longer to a human, something about the implementation has gone wrong.) But subsequent requests will be answered much faster since the information has already been saved locally. In other words, after asking the question only once the answer is shared quickly by all the computers on the network without repeating the exchange over the ISP drop again. Because subsequent requests don't need to go through your ISP, bandwidth (often a lot of bandwidth) is saved. And that extra bandwidth becomes available for other things such as displaying more web pages, and so typically results in a noticeably snappier web browsing experience.

How caching DNS?

It's traditional using BIND to provide DNS servers in pairs, for very high reliability of this critical function. We followed this tradition. One server is designated as the "master" and the other as the "slave". Their configurations differ slightly because of this; refer to your DNS server software documentation.

We repurposed a couple fairly old systems, added RAM to them, installed Linux, and connected a single monitor and keyboard through a KVM A/B switch. We used the standard DNS server code, specifically the rather old Bind 9.2.4, sometimes called either "bind9" or "named". The differences that make it a caching DNS server rather than the more typical DNS server are all in the configuration; we made no code nor installation changes.

Usually the configuration of a fullblown DNS server is fairly complicated. If almost everything is omitted, the default action that's left is to simply act as a caching DNS. Just specify auth-nxdomain no. You should have almost no zone definitions, and no need to do a zone transfer with any other server.

Especially on much smaller or more highly customized networks, experience has been that a caching DNS is more easily implemented and maintained with DNSMasq software rather than BIND software. DNSMasq does not have such a strong association with the tradition of implementing DNS servers in pairs. DNSMasq re-uses unchanged existing configuration files (such as the system hosts file) wherever possible, rather than requiring any duplication of information in its own format. And DNSMasq allows information for individual domains to be overridden for local users, even for remote domains controlled by someone else.

Where caching DNS?

Caching-only (non-authoritative) DNS servers can seemingly reasonably be directly connected to the local network. (Because DNS is a particular target for crackers, authoritative DNS servers are typically placed in a DeMilitarized Zone network [a DMZ is a separate network which is half-inside and half-outside, not exactly on the local network but not exactly on the Internet either].) Caching-only DNS service may even be an additional software application or configuration on an existing computer, rather than a dedicated purpose-specific computer.

Placing caching-only DNS service on the local network (rather than in a DMZ) may both be simpler to set up and often perform a little better, as DNS traffic will not have to go through any router or firewall at all. (In our own network, a third reason was that some older DNS server hardware was already connected to the local network and got left that way partly out of simple inertia.)

(The placement of caching DNS servers directly on the local network will probably horrify some less-sophisticated security experts. Nevertheless, it seems to be a reasonable compromise. Specifically, it seems reasonably safe to place a DNS server directly on a local network so long as it does no zone transfers either in or out with any other DNS server that's not also on the local network.)

Once you put it in place, any caching DNS system should be used by all computers on the local network. The efficiency of a caching DNS system actually increases (perhaps significantly) as more and more client computers use it.

DNS Security

I know of no security issues with caching-only DNS that is accessed only locally. (Of course if your caching DNS system gets bad information from a compromised upstream DNS server, it can then repeat that erroneous information over and over. So make sure your caching DNS server gets its information in turn from a trustworthy upstream DNS server.)

(Authoritative DNS, on the other hand, may be subject to cache poisoning attacks, insufficient requesting port randomness, and other attacks. So if you provide any public name service [especially if you provide any service related to e-commerce], either contract out your DNS service to a trustworthy provider, or make sure you're running the latest version of the software, all patches have been applied, and the system is monitored for any hints of abuse.)

Other uses of our DNS

Since we already have DNS servers on our local network, mainly for caching responses, we can use them for other purposes too. By keeping all our local name-to-IPaddress and IPaddress-to-name information in our DNS, it's available anywhere on our local network without us needing to maintain any hosts files.

So we have a couple very small zones which are entirely defined in local files for our own information. We define some commonly used computers. But we specifically do not define every computer. We do not include information for computers whose addresses may change, computers whose existence we prefer to not widely publicize, or computers nobody has a legitimate reason to contact.

DNS is also sometimes used to provide a sort of filtering, by returning bogus or no information for name-to-IPaddress lookup requests for suspect systems. If it occurs at all, such filtering will probably be done by the upstream DNS server that in turn provides the information to your caching DNS servers. Most caching DNS is agnostic about whether or not filtering is occurring; it's purely a matter for the upstream DNS service. Point your caching DNS servers at a non-filtered upstream service, and you will repeat the non-filtered service to your users. On the other hand point your caching DNS servers at a filtered upstream service, and you will repeat the filtered service to your users.

How are computers directed to the caching DNS?

Most computers have places for the addresses of a couple DNS servers in their configuration. If the configuration points at the caching DNS server, queries will go there first. (A caching DNS server may either answer the query itself, or may "forward" the question to other more likely servers without immediately informing the original requester.) For statically configured computers, DNS server information is generally a fairly prominent part of that configuration. For computers that get configuration via DHCP, the extensive DHCP response usually includes pointers to the initial DNS servers.

So in our environment, simply setting the addresses of our own caching DNS servers into the configuration of our DHCP takes care of most computers. We explicitly enter pointers to our own caching DNS servers into the few computers that do not use DHCP (in other words they're statically configured). A remaining problem is our gateway/firewall which connects to our ISP drop and obtains configuration information from the ISP. Where DHCP is used, the problem is this system generally points at the ISP's DNS servers rather than at our own internal caching DNS servers. The DNS configuration (probably in /etc/resolv.conf) can be manually corrected, but the DHCP client will overwrite it the next time either the computer or the connection to the ISP is restarted. The proper solution to this problem is probably to reconfigure the DHCP client so there is no overwriting. (What we did instead —because we didn't know any better— was to actually modify the code of the DHCP client script:-)

Because all DNS requests initially come to our caching DNS servers, we can change the handling of them very easily without impacting any computer other than our servers. For example we've enhanced the configuration of our caching DNS servers to forward requests to OpenDNS whenever possible, and contact the general DNS hierarchy (via the DNS root servers) only when absolutely necessary (which is probably never). By using OpenDNS in this way, if a user misspells or otherwise garbles a website name, they don't have to wait and then get an error message and then retype everything. Instead, the user is either taken to the website whose name they intended to type, or immediately presented with a clickable list of the websites they may have really meant.