Well, this sounds like a good idea. After all, we would all prefer to have any clicked link or icon or speeddial applet cause the desired webpage to show up as near to instantaneously as possible.
As all of the usual means of calling up a webpage involve adding a "word" address to the address bar, the first stop nearly always has to be to the DNS server to translate those words into the numbers which the computer can understand.
So, how long does this take?
I use OpenDNS (208.67.222.222 and 208.67.220.220) and if I ping either of these, I get a reply after about 65 ms. So, if I could use a local DNS server that allowed me to retrieve the IP address of the webpage I could perhaps save up to 65 ms of time per page.
If page typically takes 2 seconds to open, am I really going to notice if it opens 0.065 seconds more quickly? I really don't think so.
What I'm not sure of in this scenario is how long the OpenDNS servers take to find the IP of the web address compared to how long it would take to retrieve the same information from a small local cache.
So, there may be a possibility here to speed up my browsing so I though I'd give it a try.
The first one I tried was dnsmasq which is available in the Hardy repos. I used this guide.
The installation and configuration went smoothly (I listened to 127.0.0.1) but trying to retrieve a new web page was intolerably slow and sometimes didn't happen at all. Seemingly, when nothing relevant was in the LocalHost cache, it didn't then look in the OpenDNS servers (although I didn't have these included in /etc/resolv.conf -- only 127.0.0.1 here -- 208.67.222.222 and 208.67.220.220 are the DNS servers in my router).
Certainly, running, for example, dig google.com showed the 127.0.01 was being used as the DNS server. Also, the first attempt at this gave maybe up to 300 ms as the retrieval time, the second time gave typically 0-2 ms retrieval which is certainly a vast improvement.
Unfortunately, these encouraging results did not translate themselves into good browsing performance. Indeed, browsing became almost impossible.
There are several other howtos on dnsmasq for Ubuntu such as this and this, but nothing I found allowed me to eliminate this problem.
Also, because dnsmasq saves the cache to RAM, this means that you have to start building your cache again after a reboot -- which means slow browsing until all your usual page have been called up at least once.
Given these disadvantages, I decided to give pdnsd a try. This saves the cache to disk so it's not lost.
I first used this guide but this simply didn't work. In trying to start pdnsd, I consistently got an error about the absence of the file
/etc/cache/pdnsd/pdnsd.status
which indeed was not present.
Also, I could't find any reference to the absence of this file in google.
So, next I tried this Ubuntu howto although I first tried the guide in this post from much later in this thread.
This however, didn't give a working pdnsd as this command
$ sudo /etc/init.d/pdnsd restart
always gave an error on the start part of the command.
Finally, I tried the guide in post #1 and this worked without problems.
What I did was as follows:
sudo apt-get install pdnsd##I did NOT install resolvconf
sudo gedit /etc/pdnsd.conf
My /etc/pdnsd.conf is given here:
// Read the pdnsd.conf(5) manpage for an explanation of the options.
/* Note: this file is overriden by automatic config files when
/etc/default/pdnsd AUTO_MODE is set and that
/usr/share/pdnsd/pdnsd-$AUTO_MODE.conf exists
*/
global {
perm_cache=1024;
cache_dir="/var/cache/pdnsd";
run_as="pdnsd";
server_ip = 127.0.0.1; // Use eth0 here if you want to allow other
// machines on your network to query pdnsd.
status_ctl = on;
paranoid=on;
// query_method=tcp_udp; // pdnsd must be compiled with tcp
// query support for this to work.
min_ttl=15m; // Retain cached entries at least 15 minutes.
max_ttl=1w; // One week.
timeout=10; // Global timeout option (10 seconds).
// Don't enable if you don't recurse yourself, can lead to problems
// delegation_only="com","net";
}
server {
label=OpenDNS;
ip=208.67.222.222;
ip=208.67.220.220;
timeout=30;
interval=30;
uptest=ping;
ping_timeout=50;
purge_cache=off;
}
// This section is meant for resolving from root servers.
server {
label = "root-servers";
root_server=on;
ip = 198.41.0.4
, 192.228.79.201
, 192.33.4.12
, 128.8.10.90
, 192.203.230.10
, 192.5.5.241
, 192.112.36.4
, 128.63.2.53
// , 192.36.148.17
// , 192.58.128.30
// , 193.0.14.129
// , 198.32.64.12
// , 202.12.27.33
;
timeout = 5;
uptest = query;
interval = 30m; // Test every half hour.
ping_timeout = 300; // 30 seconds.
purge_cache = off;
exclude = .localdomain;
policy = included;
preset = off;
}
source {
owner=localhost;
// serve_aliases=on;
file="/etc/hosts";
}
rr {
name=localhost;
reverse=on;
a=127.0.0.1;
owner=localhost;
soa=localhost,root.localhost,42,86400,900,86400,86400;
}
/*
neg {
name=doubleclick.net;
types=domain; // This will also block xxx.doubleclick.net, etc.
}
*/
/*
neg {
name=bad.server.com; // Badly behaved server you don't want to connect to.
types=A,AAAA;
}
*/
/* vim:set ft=c: */
I will admit that I have no idea why the root-servers section is required particularly as the servers involved have no relevance to my setup. I'll try a test where I take this section out.
Next, I amended /etc/dhcp3/dhclient.conf where I took out the line
prepend domain-name-servers 208.67.222.222, 208.67.220.220;
and added
prepend domain-name-servers 127.0.0.1;
Now I rebooted (and this seems to be important and started pdnsd with this
sudo /etc/init.d/pdnsd restart
and it started without a hitch.
Now everything worked perfectly. For example
dig google.com
gives this
; <<>> DiG 9.4.2-P1 <<>> google.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44898
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 855 IN A 72.14.207.99
google.com. 855 IN A 64.233.187.99
google.com. 855 IN A 64.233.167.99
;; AUTHORITY SECTION:
google.com. 172704 IN NS ns1.google.com.
google.com. 172704 IN NS ns2.google.com.
google.com. 172704 IN NS ns3.google.com.
google.com. 172704 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 172704 IN A 216.239.32.10
ns2.google.com. 172704 IN A 216.239.34.10
ns3.google.com. 172704 IN A 216.239.36.10
ns4.google.com. 172704 IN A 216.239.38.10
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 20 00:23:44 2008
;; MSG SIZE rcvd: 212
Note that the first time I used dig google.com, the Query time was something quite high (350 ms) but the second time it reverted to 0 ms presumably because of the local DNS cache.
Another useful command is
sudo pdnsd-ctl server OpenDNS retest
which gives this output
Opening socket /var/cache/pdnsd/pdnsd.status
Succeeded
and
sudo pdnsd-ctl status
which gives this output
pdnsd-1.2.6-par running on ubuntu-mac.
Cache status:
=============
1024 kB maximum disk cache size.
133062 of 1058816 bytes (12.6%) memory cache used in 513 entries.
Thread status:
==============
server status thread is running.
pdnsd control thread is running.
tcp server thread is running.
udp server thread is running.
476 query threads spawned in total (0 queries dropped).
0 running query threads (0 active, 0 queued).
Configuration:
==============
Global:
-------
Cache size: 1024 kB
Server directory: /var/cache/pdnsd
Scheme file (for Linux pcmcia support): /var/lib/pcmcia/scheme
Server port: 53
Server ip (0.0.0.0=any available one): 127.0.0.1
Ignore cache when link is down: off
Maximum ttl: 604800
Minimum ttl: 900
Negative ttl: 900
Negative RRS policy: auth
Negative domain policy: auth
Run as: pdnsd
Strict run as: on
Use NSS: on
Paranoid mode (cache pollution prevention): on
Control socket permissions (mode): 600
Maximum parallel queries served: 40
Maximum queries queued for serving: 60
Global timeout setting: 10
Parallel queries increment: 2
Randomize records in answer: on
Query method: udp_only
Query port start: 0
Query port end: 65535
TCP server thread: on
TCP query timeout: 30
Delegation-only zones: (none)
Server 0:
------
label: OpenDNS
ip: 208.67.222.222
server assumed available: yes
ip: 208.67.220.220
server assumed available: yes
port: 53
uptest: ping
timeout: 30
uptest interval: 30
ping timeout: 50
ping ip: (using server ip)
interface:
device (for special Linux ppp device support):
uptest command:
uptest user: (process owner)
force cache purging: off
server is cached: on
lean query: on
Use only proxy?: off
Assumed root server: no
Randomize server query order: no
Default policy: included
Policies: (none)
Server 1:
------
label: root-servers
ip: 198.41.0.4
server assumed available: yes
ip: 192.228.79.201
server assumed available: yes
ip: 192.33.4.12
server assumed available: yes
ip: 128.8.10.90
server assumed available: yes
ip: 192.203.230.10
server assumed available: yes
ip: 192.5.5.241
server assumed available: yes
ip: 192.112.36.4
server assumed available: yes
ip: 128.63.2.53
server assumed available: yes
port: 53
uptest: query
timeout: 5
uptest interval: 1800
ping timeout: 300
ping ip: (using server ip)
interface:
device (for special Linux ppp device support):
uptest command:
uptest user: (process owner)
force cache purging: off
server is cached: on
lean query: on
Use only proxy?: off
Assumed root server: yes
Randomize server query order: no
Default policy: included
Policies:
exclude: .localdomain.
Succeeded
The big question, of course, is "is browsing any faster"? Well, it's certainly not a whole lot slower. However, I have the impression that pages which are opened for the first time are just a little bit slower than they would have been with the OpenDNS servers alone. Thereafter, I believe they might be just a shade faster.
I have the impression that I should not have stopped prepending the servers 208.67.222.222 and 208.67.220.220 from /etc/dhcp3/dhclient.conf as now, these servers are missing from /etc/resolv. I believe that when 127.0.0.1 can't resolve the address, the OpenDNS servers should then be used to do the resolving and thereby avoid untoward delays with pages whose adresses are not yet in the cache.
Nevertheless, I believe I would need a few days of browsing to get a better feel for whether or not there is a performance boost.
No comments:
Post a Comment