DNS caching Linux for faster Internet access

If you are familiar with what is a DNS, please skip to next paragraph. Internet protocol enabled network interface on your computer typically receives its IP address and related parameters when the computer starts and enables this interface. When one refers Web sites by name, like google.com in their browser software, that name (technically called domain name) is translated into a numeric address. That address is then used by browser to reach the desired Web site. This process of converting human readable name of a site into numeric address is served by another computer that can be reached over network connected to your computer. Such remote computer is called domain name server (DNS). It is assigned to you by your Internet service provider. You can even override that and choose the ones like Google public DNS.

So each such name lookup takes finite time for the request to travel to the name server and back, plus the time taken by the server for lookup. Typically these name-to-address mappings do not change rapidly over time. One can harness this fact to their advantage by saving the results of name lookups locally on their computer. This is called DNS caching.

djbdns, the DNS cache software
This site provides details on how to setup: http://cr.yp.to/djbdns.html.

Some vital but missing points in the How-To instructions

1. NetworkManager on Ubuntu was found diligently adding nameserver entries in /etc/resolv.conf as assigned by my router each time the network interface was brought up. This nullified the advantage of having a local cache and queries were anyways sent to the external name server over and over. So I set the DHCP settings to obtain only IP address from my router, sans the DNS address, as shown below:
   

   

   DHCP settings for network interface

2. Now how do I know whether DNS cache is indeed being used for name resolution and how fast are subsequent/ repeat requests served by this cache? So there's this utility called dig (domain information groper). Here's sample output:
   
   $ dig google.com  (first query)
   
   ; <<>> DiG 9.7.3 <<>> google.com
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41195
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
   
   ;; QUESTION SECTION:
   ;google.com.            IN    A
   
   ;; ANSWER SECTION:
   google.com.        300    IN    A    74.125.235.52
   google.com.        300    IN    A    74.125.235.51
   google.com.        300    IN    A    74.125.235.48
   google.com.        300    IN    A    74.125.235.50
   google.com.        300    IN    A    74.125.235.49
   
   ;; Query time: 301 msec
   ;; SERVER: 127.0.0.1#53(127.0.0.1);; WHEN: Sat Aug 20 01:49:04 2011
   ;; MSG SIZE  rcvd: 108
   
   $ dig google.com  (second query)
   
   
   
   ;; Query time: 0 msec
   ;; SERVER: 127.0.0.1#53(127.0.0.1)
   ;; WHEN: Sat Aug 20 01:49:08 2011
   ;; MSG SIZE  rcvd: 108
   
   $ dig google.co.in  (first query)
   
   ; <<>> DiG 9.7.3 <<>> google.co.in
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38836
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
   
   ;; QUESTION SECTION:
   ;google.co.in.            IN    A
   
   ;; ANSWER SECTION:
   google.co.in.        300    IN    A    74.125.235.50
   google.co.in.        300    IN    A    74.125.235.51
   google.co.in.        300    IN    A    74.125.235.48
   google.co.in.        300    IN    A    74.125.235.49
   google.co.in.        300    IN    A    74.125.235.52
   
   ;; Query time: 1713 msec
   ;; SERVER: 127.0.0.1#53(127.0.0.1)
   ;; WHEN: Sat Aug 20 01:49:15 2011
   ;; MSG SIZE  rcvd: 110
   
   $ dig google.co.in  (second query)
   
   
   
   ;; Query time: 1 msec
   ;; SERVER: 127.0.0.1#53(127.0.0.1)
   ;; WHEN: Sat Aug 20 01:49:18 2011
   ;; MSG SIZE  rcvd: 110
   

Fit more in limited RAM -- compcache

'What's new' for Linux kernel version 2.6.33 had mention for it; so I tried out this compcache--using part of RAM for saving swapped out memory contents after compressing them to fit more. While the argument for using it is to let CPU do more work and save on disk access latencies, after having configured it the difference in responsiveness on my desktop was somewhat noticeable. The mouse movements were jerky. Firefox browser was not responding for tab switch when loading a large Web page... Guess, this argument works better on multi-core, faster processors than my single core 1.6GHz Intel P4 running Ubuntu.

Was going to disable it. However, when I re-ran the same tests without compcache configured, the issue with Firefox persisted. So, in the interest of using less of my aging disk having the swap partition, I have retained compcache and bear with that minor mouse jerkiness :-). To benefit better from the same, I have increased the value for swappiness kernel tunable parameter to 50 from a previous lower value of 40.

Using SSD memory for swap partition may be a better idea. A good friend had originally mentioned this idea to me few months back. What do you say?