/dev/rob0 rob0 at
Mon Jan 5 20:19:44 UTC 2004

In article <btc9o7$1bti$1 at>, Isaac Grover wrote:
> djbdns.  Djbdns claims to be more secure and more stable than bind,

AFAIK there are no known exploits of djbdns. BIND 9 was a complete
rewrite, and AFAIK the same is true of BIND 9. Don't let unsubstantiated
claims of better security sway you. Find out exactly what they mean.

It is true that older versions of BIND have a poor history of security

I ran djbdns for a long time. I am not aware of it ever having crashed.
I have switched (in some places, am switching) to BIND, and I have not
seen it crash either.

IMO: "red herring" argument.

> and also claims to be widely used on high-traffic open-source

I don't think djbdns is nearly so widely-used as BIND, and for good
reason. One thing Prof. Bernstein is not likely to mention is that his
server suite is not standards-compliant. If you research his complaints
against BIND, it seems that many of them are complaints against the
standards, which BIND implemented, and djbdns did not. ISC has never
seen "throw out the standards and make some up" as a viable option.

Maybe I never fully understood how tinydns works -- probably so -- but I
do not think there is any distinction between "A" and "CNAME" records.
The "add-alias" script only accepts an IP address for the target! Why

I switched (am switching) in part to get dynamic DNS from DHCP. That is
a very nice feature for an internal DNS server. When a new client
connects it gives its hostname to the DHCP daemon, and instantly, from
anywhere in the local network, you can resolve that hostname.

I've also set up an extensive list of service aliases as CNAME records.
A client can always expect to find a server for $SERVICE by connecting
to "$SERVICE.local.lan". Multiple CNAMEs compensate for forgetful users:
"mail" or "smtp" or "imap" or "pop3" all point to the mail server. You
can do this in tinydns, but I prefer BIND's way.

> networks.  I looked at some of the documentation, and it looks like
> quite a learning curve to get djbdns set up properly when converting
> complicated installations of bind.

:) I can't comment on switching from BIND. I set my first DNS servers up
from scratch in djbdns.

I can, however, say that the djbdns documentation is, as Twain said of
Wagner's music, not as bad as it sounds. He somehow makes it sound more
difficult than it really is. There is very little you would ever need to
do to dnscache. The tinydns zone data is kept in a text file whose
formatting is not complex, and the add-* scripts ensure you format it
correctly. To remove a record, use $EDITOR. After your changes, run
"make", and that's it.

> Does anyone have any personal experience with djbdns and its
> management features?

The worst thing IMO about djbdns is the daemontools package. If you have
a good grasp of how Unix works, it's not hard -- just hard to swallow,
perhaps. :) At the time I did it, I did not have such understanding. All
the sample inittab lines have svscanboot respawning in "123456": yes,
even 1 and 6!! That gave me a lot of grief as a newbie, got me a lot of
fsck's at boot time. :)

I don't think djbdns is terribly difficult, but for various reasons,
most specifically CNAMEs and DDNS, I'm choosing BIND. I might, if I ran
any external nameservers, consider using tinydns for that, but I think
if the choice was left entirely to me I'd run BIND in a user-mode Linux
virtual machine.

If you're considering a switch from BIND to djbdns, you should think
about and perhaps post about what you hope / expect to gain. This being
a BIND-centric forum, you might not get unbiased answers.
  /dev/rob0 - preferred_email=i$((28*28+28))
  or put "not-spam" or "/dev/rob0" in Subject header to reply

More information about the bind-users mailing list