djbdns: An alternative to BIND

Tue Apr 12 05:51:12 UTC 2005

sthaug at nethelp.no wrote:
> A contrary view from the trenches:
> 
> Around a year ago we tested DJB dnscache as the recursive DNS server
> in a high-volume ISP environment - mostly because we were not happy
> with BIND 9 performance at the time. Our conclusions were:
> 
> - dnscache used *more* CPU than BIND 9 in our environment, effectively
> ruling it out

It'd be interesting to find the actual causes for this. Did you by 
chance consult the djbdns mailing list for hints?

> - Not possible to get dnscache to listen to more than one IP address
> unless you introduce hacks/patches

It's easy enough to setup as many instances of dnscache as you have IP 
addresses and point them all at one central dnscache (typically on a 
loopback address). Assuming you've already setup the central dnscache, 
you need to execute the following commands:

   # dnscache-conf Gdnscache Ddnslog /etc/dnscacheX a.b.c.d
   # echo 127.0.0.1 > /etc/dnscacheX/root/servers/\@
   # echo 1 > /etc/dnscacheX/env/FORWARDONLY
   # touch /etc/dnscacheX/root/ip/a.b.c
   # ln -s /etc/dnscacheX /service

While I agree that it's more work than simply adding one line to a 
config file, in effect you've got no more than two variables: IP adress, 
netmask (which I happily assumed to be 255.255.255.0 above). It's 
trivial to write a script to handle this situation in a one-liner.

Personally, I also like the added flexibility that this approach gives you.

> - Weird failures reported from users

Did you actually investigate any of these?

> - Annoying installation process with lots of small programs that we
> don't want or need

I found the installation process to be relatively straightforward, if a 
little awkward (as some of DJB's habits are). As for the 'lots of small 
programs' you don't want or need, I don't see the point. If you install 
BIND, you get a monolithic binary whereas djbdns splits the 
functionality into separate programs. Most people only use a fraction of 
the code in BIND, would you argue that its binary is too large?

[snip]
> version that worked well for us (but still too low performance). We
> finally switched to Nominum CNS (two servers) and one BIND 9 server
> as backup. We really like Nominum CNS, and we're happy.

I've read that Nominum CNS provides good performance. Unfortunately (in 
my book), it's not Open Source, though.

Cheers,
Tobias