Hi-
It seems you didn't really look at djbdns too carefully, but just
gave it a quick and cursory bashing, based on misunderstandings of
both the software and the RFCs.
Many of the responses below came from people on the djbdns mailing list.
>On Tue, 20 Feb 2001, Peter Cavender wrote:
> > So why don't you run djbdns? We know vixie's record in the past, despite
> > all the claims.
>
> I just looked into djbdns, having never heard of it before. From what I see
>on the website, I don't like it. It has a number of limitations. It does not
>support TCP.
It *does* support TCP, if you really think you need it:
http://cr.yp.to/djbdns/faq/tinydns.html#tcp
http://cr.yp.to/axfrdns.html
>It does not support NOTIFY.
No, but there are other programs from other people that can be used in
conjunction with "djbdns" that do.
Of course, this criticism is based upon the ill-conceived notion that the way
that BIND replicates its database across a set of content servers (with zone
transfers and "NOTIFY" messages) is the One True Way for DNS database
replication. This is, of course, not the case at all. The BIND database
replication scheme is inefficient, highly dependent upon the wellbeing of a
single central server, inflexible, restrictive, and, indeed, not able to cope
at all with some kinds of data. There are better schemes.
BIND's database replication scheme is *not* properly a part of the DNS, and is
*not* necessary for the DNS to operate.
To send NOTIFYs: <http://www.fefe.de/djbdns/notify.html>
>Its zone files are incomplete.
Since "djbdns" doesn't *have* zone files (all data served by a content server
are stored in a single file named "data.cdb"), this objection is obviously
nonsense.
I suspect that this senseless criticism is based on another ill-conceived
notion, namely that the way that BIND stores its database on disc (/i.e./
"zone files") is the One True Way to store databases. This is, of course, not
the case at all, as the many people using different sorts of back-end database
for their content servers will attest.
BIND's database file storage format is *not* properly a part of the DNS, and
is *not* necessary for the DNS to operate.
>It
>does not seem to allow running cache and authoritative server on the same
>system.
It doesn't allow running a proxy server and a content server on the same *IP
address*. But this is a *good* thing. It stops one from providing free
resolving proxy service to the entire world (unless one deliberately chooses
to do so). One generally runs the content server on a public IP address for
the rest of Internet to talk to, and the proxy server on a private IP address
(such as 127.0.0.1, 192.168.0.1, or 10.0.0.1) that the rest of the world
cannot even reach for one's own machine(s) to talk to. And since every
machine has 127.0.0.1, one *can* run a proxy server and a content server on
the same machine.
For an example of free resolving proxy service, by the way, look at the
content servers for the domain "relays.mail-abuse.org." (specifically the ones
that are on IP addresses 209.192.148.12, 207.166.203.193, 193.162.159.97,
130.239.18.140, 194.196.163.7, and 208.31.42.43). All of these are BIND, of
course. Anybody in the world can send them a recursive query for anything at
all, including names completely outside of their bailiwick, and they will
merrily do all of the work of resolving those queries, shouldering the burdens
of all of the traffic and of caching the answer, and all at their own
expense.
( Here's an exercise for the reader: Describe a mechanism, based upon the
above information, that can be employed by a rogue ISP, one that allows
Unsolicited Bulk Mail, to overload all but one of the MAPS content servers and
render MAPS largely useless. Assume that the rogue ISP has a reasonably large
number of customers. )
>Worst of all, it defeats the entire caching hierarchy that DNS is
>designed around.
DNS was designed for an authority hierarchy, not a caching hierarchy.
Here's a quote from RFC 882:
"The sheer size of the database and frequency of updates suggest that
it must be maintained in a distributed manner, with local caching to
improve performance."
Note the part about local caching. Nowhere is distributed caching
mentioned.
Another response:
"Caching hierarchy"? What nonsense is this? dnscache (the proxy part of
djbdns) does what proxies are supposed to do -- chase delegations from
the roots down. Does your poster think the roots cannot handle the load?
Baloney. The roots reportedly run at under 50% capacity 100% of the
time, all the time (it's supposed to be a requirement -- if they get
above 50%, they upgrade something). The ridiculous methods BIND uses to
avoid "overloading" the root servers are the reason that it's so easy to
fool BIND servers. If BIND followed DJB's model, used in designing
djbdns, the DNS would be a lot more reliable, and harder to spoof.
Having servers hand out addresses they know from their cache when asked
for authoritative data is _stupid_, plain and simple (Vixie "credibility
rules" or no).
Do those answers help? Please feel free to be much nicer to him than I
was in my post. ;)
>Karl Runge thought using TCP was bad, but if everyone
>suddenly switched to djbdns, the DNS would likely collapse.
Ironically, the contrary is the case. If everyone suddenly switched to
"djbdns", the DNS would very likely be more stable and less error prone. For
example, the accidental cache poisoning that happened in January 2001 that
made the news headlines would have caused no problems at all for anyone had
everyone been using "dnscache" as their proxy DNS server.
> As I read the documentation on djbdns, I really get the feeling the author
>is implementing *his* version of what *he* wants the DNS to be. He may not
>agree with the RFCs, but that does not give him the authority to override
>them. I have to work in the real world.
The BIND man pages are not the RFCs. DNS is based on protocols in
the RFCs. Just because one person's implementationb does not mimic
BIND's does not mean that it goes agains the specs.
> BIND has a serious history of buffer overflow problems, but it looks like
>djbdns just trades one set of problems for another. :-( I think running BIND
>unprivileged and chroot'ed gives you sufficient protection against attack.
What problems does one get with djbdns? I haven't heard a valid complaint yet.
>
> > We know vixie's record in the past, despite all the claims. It is crap.
> > They don't fix it.
>
> BIND is one of those programs (like sendmail) that has been around since the
>dark ages, from before Internet security was invented. Fixing it would likely
>mean rewriting it. Nobody seems to want to undertake all the work a complete
>rewrite and re-deployment of BIND.
No, people are writing better tools from scratch, like D.J. Bernstein.
sendmail is quickly losing market share, down to well under 50% today.
The time of these internet dinosaurs is coming to an end.
--Pete
>--
>Ben Scott <[EMAIL PROTECTED]>
>Net Technologies, Inc. <http://www.ntisys.com>
>Voice: (800)905-3049 x18 Fax: (978)499-7839
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
