Speeding Up DNS Access In Regions With Very Low Infrastructure

Introduction

Let's say you are on an expensive satellite link that can barely provide enough bandwidth for your company's Internet access and you will want to do whatever you can to get as much as possible out of this link. Moreover, occassionally you lose power from the utility company, long enough for your UPS to run out. There are a few things you could do to get a lot more from your link. In this article, we will be looking at speeding up your dns requests by keeping a cache of responses to your dns requests on your hard disk. Subsequent dns request are then served from the cache and because a copy is on disk, you don't lose it when there is a power outage or a reboot.

The updated version of this document is at: www.httpcompression.net.

Analysis

Do I need this? Well let's see. From your Linux issue the following command:

dig www.httpcompression.net

Among other things I get the following result:

;; Query time: 583 msec

After a few seconds I issued the command again and got:

;; Query time: 612 msec

Obviously my ISP's dns servers simply forwards the requests to the US (I am in Accra, Ghana, West Africa, connecting to the Internet over submarine fibre optic cable SAT3). Apparently, the results of the first request was not cached. If it was, it had timed out by the time of the second request. Certainly, such an environment is a perfect candidate for this setup.

HowTo

I am working on an Ubuntu server. The software we will be using is pdnsd. The website has this to say about pdnsd:

"pdnsd is a proxy DNS server with permanent caching (the cache contents are written to hard disk on exit) that is designed to cope with unreachable or down DNS servers (for example in dial-in networking). Since version 1.1.0, pdnsd supports negative caching."

From your Ubuntu or any other Debian based distribution issue the following command:

apt-get install pdnsd

A configuration page came up with three options "resolvconf / Use root servers / Manual". I selected "Manual" and continued with the installation.

The default installation has a configuration file, parts of which have been remarked. A line is remarked out with "//" whilslt multilines are remarked with "/* */". Eg:"

// This is a remarked line in the conf file.
/*
These are remarked
lines in the 
coniguration file.
*/

Use your favourite text editor to edit the following configuration files:

1. /etc/default/pdnsd

   Edit the line with START_DAEMON as follows:

   START_DAEMON=yes

2. /etc/pdnsd.conf

   In the global stanza you may want to change the following setting: server_ip = 127.0.0.1; This is the ip on which pdnsd can be reached. If the address is left at the default of 127.0.0.1, only programs on the server itself can access the pdnsd server. However, if you want other servers and PCs to use this pdnsd installation as their dns server, then you should change the ip address to the appropriate ip address on your server that you will want your clients to use.

   Use the server stanza to set the dns servers that the pdnsd will consult to resolve domain names. There are two server stanzas which are commented out by default. The opendns servers are very reliable and popular, you may want to use them:

   server {
       label="opendns";
       ip = 208.67.220.220,208.67.222.222;
   }
   

   Make sure the server stanza is not commented out. If your ISP has a reliable dns server, you may use it instead. As much as possible, spare the root servers.

3. /etc/resolv.conf This file contains the dns servers that programs on your server (say squid, apache) will normally consult for name resolution. Now, you will want to consult the local pdnsd server you have just installed, so you enter the ip address of your loopback interface (lo) namely 127.0.0.1. This should be the only entry in this file.

   127.0.0.1
   

Tests And Conclusion

Now start you pdnsd server:

/etc/init.d/pdnsd start

Now issue the following command and look out for the Query time: in the response to determine how well you are doing:

dig www.httpcompression.net

;  DiG 9.4.2-P2  www.httpcompression.net
;; Query time: 3323 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov  3 20:02:37 2008
;; MSG SIZE  rcvd: 71

After a while, issue the command again:

dig www.httpcompression.net

;  DiG 9.4.2-P2  www.httpcompression.net
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov  3 20:03:07 2008
;; MSG SIZE  rcvd: 71

From the two results above, the first query took 3323 msecs whilst the second, 30 seconds later, took only 1 msec to resolve. Now after a reboot of the server:

dig www.httpcompression.net

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov  3 20:06:38 2008
;; MSG SIZE  rcvd: 71

After the reboot the query took only 3ms to resolve. We did not loose our cache. You may want to read the manual and change some settings to suit your situation. A few of these setting are:

1. min_ttl: The default minimum time that a cached response should be kept is 15 minutes. You may want to inrease this to reduce the frequency you contact parent servers. The side effect is, if the address of a site changes, it will take a while for your qdnsd to contact the parent servers for the new address. If the minimum time is not long enough, you will also lose your cache after an extended power outage.
2. perm_cache: This is the size of disk space for your cache. Depending on the traffic on your network, you may want to increase this to a value that can comfortably store at least a weeks data. You could be monitoring the size of the cache file over a period of time to get a feel of what should be adequate for you.