It is very difficult for me to be critical of djbdns.  Djbdns came out at
a time when the only other viable name server was the very insecure BIND8.
It allowed people who needed a DNS server to have a secure solution at
a time when BIND had security patches released almost monthly.  I myself
have used it to keep installations I administered at the time secure.

In addition, Dr. Bernstein, djbdns' author, has written a number of 
documents about keeping DNS secure which were very valuable during 
the design phase of MaraDNS, and have undoubtably improved MaraDNS'
security.  I have a good deal of respect for Dr. Bernstein's coding
abilities.

That said, djbdns has a number of issues which make it not practical to
deploy on new installations.

Djbdns has not changed one iota for over five years.  In addition, it is
not legal to distribute a changed version of djbdns.  This is the number
one problem with djbdns: Djbdns is *not* open source.  Its license is
not compatible with one fundamental pillar of open source: The right to
distribute modified versions of a program.

This is a very practical problem: There are high profile internet
sites that djbdns' recursive resolver simply can not resolve.  In order to
make djbdns' recursive resolver resolve these sites, after downloading
djbdns, you need to find the patch that fixes the broken recursive
resolver, apply the patch, and hope the patch doesn't break anything.

This isn't the only problem with djbdns' recursive resolver.  Its list
of root servers is out of date by five years; two root servers have
changed since then.  This makes the recursive server less reliable;
fixing this requires changing the configuration by hand, or by applying
yet another third-party patch.

Installing djbdns is non-trivial; you need to download and install no
less than three different packages.  Djbdns will not compile on a modern
Linux system; you need to find the incantation to make it compile.
Compare this to MaraDNS, where installing is as simple as downloading
one package and typing in "make; make install".

Once djbdns is installed, you will find some directories in the root
of your filesystem that weren't there before.  This breaks UNIX and
Linux standards on how the filesystem can be organized.

All of these issues could be fixed if Dr. Bernstein had released djbdns
under an open-source compatible license.  I understand that such modified
versions of djbdns may introduce security problems that Dr. Bernstein's
code does not have.  The solution is simple: Distribute djbdns under a
LaTeX license, which is open source compatible and would require modified
versions of djbdns to be called something besides djbdns.

There are a number of programs which are still being actively maintained
long after the original author stopped contributing to the project.  The
fvwm project is still thriving even though Rob Nation stopped working 
on the project over 12 years ago.  When Atheos development stopped, 
its users forked the code and started the Syllable project.  Both Perl
and Python are no longer being actively worked on by their primary 
developers; most, if not all, code changes now come from other people.
It is a shame that Dr. Bernstein does not allow djbdns to have the same
development.

This wouldn't be so bad if djbdns was being actively manintained and bug
were being fixed.  Dr. Bernstein, as far as I can tell, has no intention
to fix any issues with djbdns.  He acts too arrogantly to acknowledge
that his programs have bugs, much less fix his bugs--I have never seen
him admit any of his programs has a bug.

Djbdns's license and the author unwillingness to fix bugs limits the
options for people supporting djbdns.  For example, when somone pointed
out yet another bug with djbdns' recursive resolver on the djbdns mailing
list, he was told that people who have this problem that it was "their
own fault".  In more detail, if someone has a domain with an provider
and, for whatever reason, wants to change providers without their current
provider's help, djbdns' cache will incorrectly point to the old provider
until the cache program is restarted.

This goes back to the djbdns license; the person who blamed the user for
a djbdns problem really had no other choice.  He could not patch djbdns
and distribute a modified djbdns to fix the issue.  While he could made
a patch available, the number of djbdns users who would actually apply
the patch is next-to-zero.  Since Dr. Bernstein has abandoned djbdns,
there is no system in place to allow people to fix issues with djbdns.

djbdns has a good security record; however, it is not the only dns
server with good security.  No stable version of MaraDNS on a non-Linux
system has ever had an exploitable security problem.  The one and only
denial-of-service problem was caused by Linux's broken TCP/IP stack and
not by MaraDNS, and has long since been fixed.

Djbdns was the best DNS option available when it came out.  That was
over five years ago.  Since then, the internet has changed and djbdns has
not kept up.  Now that BIND9 and MaraDNS have a proven security record,
and are both under an open-source license and being actively maintained,
there is no longer any reason to use djbdns.

