...making Linux just a little more fun!
[ In reference to "The Village of Lan: A Networking Fairy Tale" in LG#170 ]
Rick Moen [rick at linuxmafia.com]
Forwarding with Peter's permission.
----- Forwarded message from Peter Hüwe <[email protected]> -----
From: Peter Hüwe <[email protected]> To: [email protected] Date: Tue, 5 Jan 2010 02:09:58 +0100 Subject: Thanks for your DNS articles in LGHi Rick,
I just stumbled upon your DNS articles in Linux Gazette and although I first though this topic is not that interesting for me it turned out to be really really interesting!
I found out that the dns I used to use (dns from my university) was horribly slow and seemed not to use any caching mechanism - first request 200-300ms, second request 200-300ms :/
Then I checked out other dns servers like googles and opendns which were quite fast (1st ->130 2nd ->30ms).
But as I don't like using google for everything (no googlemail account here 
and I really dislike the "wrong" answer of opendns for nonexistent domains
(as it breaks google search by typing into firefox url bar)
-> I eventually installed Unbound and I'm really really happy with it.
Installation was really easy and the results are tremendous (especially given
the fact that I surf most of the time on only a handful pages) - so speedup
from 300ms to 0(for the second hit) - that's really nice.
The only minor drawback I see is that (as I have to run it locally on my box -
yes I'm one of your oddballs it looses its cache after reboot. - do you
happen to know if there is something I could do against that?
Anyways - thank you for your great articles and improving my internet experience even further.
Kind regards, Peter
----- End forwarded message -----
Rick Moen [rick at linuxmafia.com]
Quoting [email protected]:
> I just stumbled upon your DNS articles in Linux Gazette and although I first > though this topic is not that interesting for me it turned out to be really > really interesting!
I'm delighted that you found those pieces worthwhile reading.
[running a local copy of Unbound:]
> The only minor drawback I see is that (as I have to run it locally on > my box - yes I'm one of your oddballs
Yes, indeed, most recursive nameservers use RAM-based caches, and Unbound certainly is among them. That would indeed be at least slightly irritating with workstations/laptops that get restarted frequently.
I can think offhand of two candidate solutions:
1. dnscache from Dan Bernstein's djbdns package is the sole exception I know of to that generalisation about RAM-based caches. Instead, it back-ends into an embedded copy of Bernstein's disk-based "cdb" ("constant database") package, http://cr.yp.to/cdb.html . As I mentioned in my article, there are four maintained forks of Prof. Bernstein's package. You could try one of those.
Prof. Bernstein's software tends to be... how shall I put it... a bit eccentric in its design and operation, and I have only limited experience with it, for a number of reasons. Indeed, there's a certain lovely irony in my recommending his software, having been among the best-known critics of both his past licensing and some aspects of its operation. However, you might try it and see if you like it.
2. It might be possible to use a recursive server with a RAM-based cache in conjunction with pdnsd (http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdnsd). pdnsd is a forwarder with disk-based cache, written specifically to service workstations/laptops likely to getting rebooted. From that perspective, it's a pity that pdnsd is just a forwarder -- but my idea is to have /etc/resolv.conf point to an instance of pdnsd (thus getting the benefit of its persistent disk-based cache), and having pdnsd in turn point to a full-service recursive nameserver such as Unbound.
Alas, I'm not 100% sure how one would configure such a setup, especially on a dynamic-IP workstation. You would have to play with the software, to see if that could be made to work. E.g., it might be possible to make Unbound listen for queries on localhost port 9999 (picking an example port number), and configure pdnsd issue queries to that same host/port combination.
I hope that helps -- although I'm aware of my answers containing quite a bit more handwaving than I'm happy with.
-- Rick Moen "Having the right word is much more satisfying than just [email protected] sleeping around with any old word that comes along." -- FakeAPStylebook
Kapil Hari Paranjape [kapil at imsc.res.in]
Dear Rick and TAG,
I liked Rick's article on the Village Lan (still to read the other one).
On Mon, 04 Jan 2010, Rick Moen wrote:
> 2. It might be possible to use a recursive server with a RAM-based > cache in conjunction with pdnsd > (http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdnsd). pdnsd > is a forwarder with disk-based cache, written specifically to service > workstations/laptops likely to getting rebooted. From that perspective, > it's a pity that pdnsd is just a forwarder -- but my idea is to have > /etc/resolv.conf point to an instance of pdnsd (thus getting the benefit > of its persistent disk-based cache), and having pdnsd in turn point to a > full-service recursive nameserver such as Unbound.
I've been running pdnsd for a long time myself and after reading the article I wondered a bit at the characterisation of pdnsd as an iterative server rather than a recursive one.
It is possible to run pdnsd with only one server section which declares "root_server=on" and then lists all the known root servers.
In this case, I imagine that it does in fact do all the running around gathering and caching authoritative information so it seems to look less like Dwayne and more like Ralph ... but perhaps I'm missing something (and I haven't checked the source!).
If running unbound would actually be better than doing this, I would certainly like to know as I would start doing it right away!
Regards,
Kapil. --
From: Rick Moen <[email protected]> To: Kapil Hari Paranjape <[email protected]> Date: Sun, 31 Jan 2010 16:12:46 -0800 Subject: Re: [TAG] (forw) Thanks for your DNS articles in LG
Quoting Kapil Hari Paranjape ([email protected]):
> I've been running pdnsd for a long time myself and after reading > the article I wondered a bit at the characterisation of pdnsd as an > iterative server rather than a recursive one. > > It is _possible_ to run pdnsd with only one server section which declares > "root_server=on" and then lists all the known root servers.
That argues that it's not just a forwarder (which I already knew). It doesn't cast any light on whether it does iterative or recursive service.
To be able to tell about that, you'd need to have your DNS client send it a DNS query with the "RD" (recursion desired) bit set, and then somehow (e.g., with a network sniffer) monitor the subsequent traffic. If pdnsd comes back only once, with the end-result of pursuing the delegation chain, _and_ assuming it didn't answer the query from cache, then it was giving recursive service. If the client is obliged to follow up NXDOMAIN ("can't find that") answers with queries of names higher up the chain towards the root, e.g., asking about linuxmafia.com after getting NXDOMAIN on uncle-enzo.linuxmafia.com, or about .com after getting NXDOMAIN on linuxmafia.com), then it's not recursing.
In writing my recent articles, and in compiling my bestiary of DNS software for Linux (http://linuxmafia.com/faq/Network_Other/dns-servers.html) over the years before it, one of the biggest obstacles has been lack of information, and actual bad information, from the software authors about what their codebases do and don't do -- with some notably honourable exceptions, such as NLnet Labs, creators of NSD and Unbound. In the case of each package, I've spent considerable time reading available documentation and some of the source code, to answer questions like the one Kapil raises about pdnsd. Does pdnsd do recursive service? I honestly cannot say for certain. It's a pity the authors of such packages don't make the answer clearer. I can say only that I made my best guess, where documentation didn't suffice -- as, sadly, it often did not.
-- Rick Moen "The word 'axiomatic' is George Will's thing, and [email protected] he will straight up cut you, if you try to use it." -- FakeAPStylebook