On Mar 14, 2007, at 8:18 PM, Sam Trenholme wrote:
That said, djbdns has a number of issues which make it not
practical to
deploy on new installations.
That's a strong claim, as you're no doubt aware, and you'll have to
be pretty persuasive to make it stick. Let's see how it goes.
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.
I use dnscache and haven't noticed this problem. What are some sites
I should be unable to resolve?
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.
Sure, and this is slightly annoying, but is dealing with it
particularly difficult?
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".
I'd be surprised if many competent sysadmins are still installing
from source by hand these days. I install from source using a
packaging system, which takes care of things like dependencies and
platform-specific patches. So I do in fact install djbdns by typing
"make && make install", and it does what I want.
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.
This is an old debate. But how is it a practical problem?
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.
It's already doable (see netqmail). For some reason, something
similar hasn't been done for djbdns. Perhaps there's no need for it?
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.
I'm quite sure I have; it just doesn't happen very often.
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.
I don't know that one. URL to discussion?
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.
Do you really believe this? It's a stretch, to say the least. Patches
exist, and people can and do apply them if and when they're needed.
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.
What about folks already using djbdns? Are you contending it doesn't
actually work for them and they should be unhappy about it?
I'm sure BIND9 and MaraDNS have their merits, but you haven't
persuaded me that djbdns doesn't have nearly enough of its own. That
was your goal, right? So I'd suggest either revamping your reasoning
or, failing that, reconsidering whether the conclusion can be
logically reached.
|