On 3/14/2007 8:18 PM, Sam Trenholme wrote:
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.
While I don't argue your point here, can you give an example of a RR
that a vanilla dnscache can't resolve ?
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
It sounds that at first, you're relying on the official "how to install"
guide to find the ucspi-tcp and daemontools prerequisites. Then you're
saying that following step 4 of 5 is so hard that it's really "finding
an incantation to make it compile".
If you weren't relying on the "how to install", I'd say that djbdns only
depends on one package, ucspi-tcp. Running under daemontools is a
recommended, not required, configuration.
Package dependencies can be a very good idea. Apache, for example,
utilizes the skill set of the openssl team, instead of reinventing the
wheel and bloating their own code. On the same note, djb keeps his code
clearly separated -- easily modified, inspected, and modular.
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.
he does have intent to fix issues:
http://cr.yp.to/djbdns/install.html
Step 4 was modified years after the release of djbdns-1.05 and was
modified in order to make it work with new glibc in Linux.
As for confirming a bug, I'm one up on you:
http://marc.theaimsgroup.com/?l=djbdns&m=108508170028045&w=2
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.
As a service provider, I've run into this and haven't a solution to the
problem.
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.
tinydns.org is an excellent community resource.
> there is no longer any reason to use djbdns.
I couldn't disagree more. :)
--
Jeremy Kister
http://jeremy.kister.net./
|