What I want in a caching nameserver

August 14, 2010

What the world needs is a good caching nameserver. What brought this on is that I am currently flirting with yet another caching nameserver, which is something that I do from time to time because every caching nameserver I've ever found sucks in its own way. This is actually somewhat surprising to me, because at one level the job is not all that difficult so you'd think that someone would have written a sane implementation by now.

(Possibly the DNS system actually is sufficiently difficult that it drives every implementer insane. Sadly I can believe it; DNS is both baroque and peculiar, and I'm sure there are lots of dark corners.)

What I want in a caching nameserver, beyond 'works', is:

  1. it can forward queries for some zone(s) off to other recursive (caching) nameservers, as recursive queries.
  2. it can send queries for some zone(s) directly to primary nameservers, as non-recursive queries.

  3. it has a sane and small configuration system. I am not interesting in anything that requires a SQL server, for example.
  4. it has a small memory footprint.

The first and second give you different ways of splicing in local zones so that you can resolve private internal names and you can still resolve things in your own organization even when your Internet link is down. I need both; sometimes I want to do a recursive query to another caching nameserver that handles all the details, and sometimes I want to talk directly to a primary nameserver that will laugh at me if I send it DNS queries that are marked as 'recursion allowed'.

DJ Bernstein's dnscache is the usual recommendation but it falls down on the first issue (and arguably on the second one as well, depending on how you interpret what it should do if it gets NSes back); it's what I normally use (because years ago I got horribly offended at Bind's memory usage). My current flirtation is with unbound, which has both recursive and non-recursive forwarding, mostly has a sane configuration system, and unfortunately falls down on memory usage even more spectacularly than Bind did.

(Looking at the package list in Fedora 13 suggests that there are a lot more potential nameservers than I thought. This list covers a lot, but the only likely candidates are MaraDNS and PowerDNS's caching server.)


Comments on this page:

From 173.206.97.75 at 2010-08-14 09:59:04:

I don't think bind's memory usage is all that bad. It could be lower, but it does everything you want. The following output is from /proc/PID/status for a bind that is serving up a small local domain, and caching requests:

VmPeak:	   63116 kB
VmSize:	   60512 kB
VmLck:	       0 kB
VmHWM:	   30512 kB
VmRSS:	   28036 kB
VmData:	   49808 kB
VmStk:	      84 kB
VmExe:	     420 kB
VmLib:	    9804 kB
VmPTE:	      64 kB

Mind you an RSS of 28M is more then half of my firewall's real memory usage.

From 70.95.101.194 at 2010-08-14 12:45:06:

I haven't actually looked in to the technical details of it, but I use dnsmasq (http://www.thekelleys.org.uk/dnsmasq/doc.html) on my workstation as a DNS caching resolver. It comes installed by default on CentOS (but not enabled), and is in the repository for most major distributions. Setting it up is trivial, and it doesn't seem to use much by way of resources.

By cks at 2010-08-14 14:36:07:

By dnscache's standards, a memory size of 59M (28M resident) is huge. Typical numbers for dnscache are 3M / 1.5M.

(And unbound is 191M, 19M resident.)

From 64.134.144.252 at 2010-08-14 23:04:46:

Maybe I'm misunderstanding what you want… but in /etc/dnscache/root/servers, you can configure what nameservers to contact for zones. I use this feature to accomplish (2) with djbdns; I don't think djbdns discerns between recursive or non-recursive nameservers upstream from it, so don't see why it couldn't accomplish (1) as well.

The format is simple: create a file listing the IP address of name servers to contact for that zone (that's a limitation—I don't think hostnames work here, understandably). djbdns ships with '@', a "default zone", which contains the root nameservers.

— SamatJain

From 70.113.114.18 at 2010-08-15 00:43:05:

I've been wanting to play around with PowerDNS for a while. Keep us posted on what you learn.

--
Scott Hebert
http://www.geek-run.com/

From 84.195.129.174 at 2010-08-16 07:41:05:

I never really understood why people liked djbdns, it doesn't play well with others. What I want is a name server that supports all the modern options (EDNS0/DNSSEC) out of the box, instead of a 3 page rant about why protocol X is better. Its extremely outdated as well, the last update was like 10 years ago.

Dnsmasq is small, but its written especially for low-memory devices. It doesn't really cache much (150 records by default) and don't expect anything fancy from it. I've seen it do some very ugly non-RFC things, but it works, so thats the typical choice for embedded devices. But if you have a real server with a couple hundred MB, i wouldn't use it.

If you have a real caching name server used by multiple clients, I'd rather have better caching than low memory usage. Most of the memory is consumed by cached data anyway, so if the server doesn't use more than 5M, it probably isn't caching much. Try finding a server with less than 1G of RAM nowadays, its hard to find so I don't care about a couple MB.

My choice would be either BIND or Unbound. Bind because it just works and its the standard name server, so you know it will do a better job resolving records when servers give flaky responses. Unbound because it has a lot of interesting settings to tinker with.

I'd also compare the memory usage after running a number of queries against it, say some 200000 or so. Maybe some deamons just preallocate some memory for the cache and others don't.

-- Bart

Written on 14 August 2010.
« PPP over ssh: solving problems with indirection
Why I change font sizes »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Aug 14 02:15:44 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.