Using Google Public DNS on Debian

It is one of those days where my Dutch ISP shows itself from it’s ugly side again. Snow has fallen out of the sky and in a country no longer used to such natural phenomenons this seems to always cause strange outages. Today it is apparently the DNS service that has been affected by the snow. ‘The Internet’ appears to be very slow for some reason and one look at my Vuurmuur log viewer shows why, I am seeing a lot of DNS forward requests by my local caching DNS being repeatedly sent to my ISP’s DNS.

Caching DNS

In my local network (LAN), I have a central server running a so called ‘caching DNS server’. It’s use is two-fold; It acts as a reverse lookup DNS for my LAN IP addresses so that 192.168.* IP addresses can be reverse resolved quickly and from one unique source. It also acts as a ‘forward and remember’ cache so that a query such as ‘google.com’ gets forwarded to my ISP’s DNS server first and on receiving an answer it gets remembered for the DNS record’s TTL (time to live) period.

In the diagram below we see how it works; When a LAN node (eg. One of our workstations / appliances) wants to find the IP address of a symbolic name such as google.com, the LAN node will first send a query to the caching DNS. The Caching DNS will then search it’s database to see if there’s still an active cached entry in it. If not, the request will be forwarded to the ISP’s DNS server and the entry will be stored in the Caching DNS’s database for TTL seconds. The curved line indicates that the machine the DNS server is running on also uses the DNS server.

This very simple forward and store mechanism has some drawbacks however. It basically forms a chain of DNS servers to resolve queries and as always a chain is as strong as it’s weakest link. Today it appeared that the ISP’s DNS had trouble replying to requests in time, causing retransmits to be sent out. While it’s not very frequent that I see this happening, I have noticed in the past that one of the two DNS servers my ISP provided through DHCP seems to be somewhat flaky, so since there is no priority in which DNS server to use, sometimes when reconnecting I’ll get the flaky DNS as the first one and all traffic will be somewhat slower.

DHCP on Debian

On the Caching DNS server I run the Debian flavor of the Linux OS. I’ve configured the eth0 interface to get it’s information on startup through the DHCP protocol using:

.iface eth0 inet dhcp

dns-nameservers 127.0.0.1

dns-search dutchie.org 3dn.nl

dns-domain dutchie.org.

in /etc/network/interfaces.

The typical configuration for DHCP connections is really somewhat annoying. The DHCP client will by default not only retrieve the IP address for the interface but a whole lot more information, also depending on which information the DHCP server chooses to give. Among the information the DHCP servers sends are such things as

• subnet mask

• broadcast address

• default gateway

• domain name server

While these are all trivial and required, the are also such things as:

• netbios name servers

• netbios scope

• ntp-servers

that get requested, some of which the ISP’s DHCP server does not even provide. Whenever the dhclient receives domain name server records however, it will use these records to simply overwrite the system’s resolv.conf file, essentially undoing the local caching for the caching DNS server itself! We see that the curved line has been replaced in the diagram below, which disables keeping the cache loaded altogether.

To prevent this from happening, I had installed a package called resolvconf . This appears to be a very recent addition to Debian at the time of writing this article so I figured I’d document some of my findings in this article, even though it’s not required to getting Google Public DNS up and running.

Resolvconf

The resolvconf package comes with a few scripts the can be run post/pre the configuration of an interface. One of these scripts is /etc/resolvconf/update.d/bind. By default this script will modify /var/run/bin/named.options which for my setup was incorrect as I have changed some paths on my system a long time ago and they’re apparently no longer fully compatible with Debian standards (either that or resolvconf isn’t). It required me to actually look through the script itself which isn’t bad altogether.

So I modified /etc/resolvconf/update.d/bind to modify /etc/bind/named.options instead, making resolvconf take the domain-name-servers parameters received from dhclient and put them in named.options in the following way:

• forwarders { 213.46.228.196; 62.179.104.196; 127.0.0.1; };

After adding these domain-name-server parameters to the named.options file, the local name server will be restarted, causing the lookups of the caching DNS to be forwarded to the ISP provided domain-name-servers. This was the situation I had configured before my ISP’s domain name servers started acting up.

Google Public DNS advantages

While the diagram looks like an ideal situation, we also need to realize that the ISP DNS itself essentially performs the same caching algorithm for those domains it doesn’t know by itself. It could be set up as a forwarding DNS as well, or it could go straight to the root DNS servers to first query for an authoritative domain name server but the bottom line is that a query that’s not known to the ISP DNS needs to be resolved somehow. An ISP’s DNS gets many more requests because of its larger user base, so the cache database will be much larger, thereby making it more effective. However, in the case the ISP DNS needs to resolve a query, a potentially long process needs to be followed to the domain’s authoritative DNS, over potentially suboptimal network paths. This last remark should not be overseen too easily as my assumption is that Google may have faster and more direct paths to the authoritative DNS of many domains than most ISPs.

Another important thing that should not be forgotten is that we’ve just seen that more users means a more effective use of the cache DNS. Certainly, Google potentially has MANY more users than most ISP’s. This remark should come as a bit of a surprise to the careful reader as it implies that Google Public DNS is a successful service already. However, we must assume that there is at the very least one HUGE user of Google Public DNS: Google’s own webcrawler! Google also has more insight of which sites get a lot of traffic so could conceivably have a much smarter algorithm to keep it’s DNS cache prepped in advance through it’s pagerank algorithm.

The obvious drawback is of course that the Google Public DNS server is further away from my DNS than my ISP’s DNS server. So while there are a lot of ‘what-ifs’, it stands to reason that using the Google Public DNS could be faster indeed, the only way to figure out whether this is true is by measuring from the outside of Google.

Advantages for Google

Google itself can also gain an advantage by its Public DNS being adopted by large groups of users; The number of DNS hits on specific domains will give Google additional insights on what’s hot on the web and what’s not.

So when this service is given sufficient time to develop, it may gain momentum to be weighed in a site’s page rank! This is interesting information for wannabe hackers. What if botnets for example would be instructed to use Google Public DNS to resolve a site many time from many different locations, would this cause Google to adjust page rank information?

Setting it all up

From the above, it seems fairly trivial how to actually set up my Debian caching DNS server. All we need to do is to:

1. Make sure that resolvconf will alter either named.options (which tells the DNS which forwarder to use) anymore and use 8.8.8.8 and 8.8.4.4 as DNS forwarders in named.options.
2. Make sure that dhclient does not alter resolv.conf (which tells the server which DNS to use to begin with.)

Both of these tasks are easily achieved by tricking the dhclient into hardcoding the domain-name-servers variable:

/etc/dhcp3/dhclient.conf:

prepend domain-name-servers 8.8.8.8, 8.8.4.4;

Additionally, we can also choose to no longer use the ISP DNSs anymore at all by removing domain-name-servers from the ‘request’ line in dhclient.conf:

/etc/dhcp3/dhclient.conf

request subnet-mask, broadcast-address, time-offset, routers, netbios-name-servers, netbios-scope, interface-mtu, rfc3442-classless-static-routes, ntp-servers, domain-name-servers;

After bringing our interface back up again, we should see the two Google Public DNS IP addresses in our named.options file.