bind vs djbdns

Jim Reid jim at rfc1035.com
Fri Aug 25 10:22:25 UTC 2000


>>>>> "Dan" == D J Bernstein <75628121832146-bind at sublist.cr.yp.to> writes:

    >> these obscure formats have an uphill struggle to find
    >> acceptance

    Dan> People who try djbdns find it much easier to use than
    Dan> BIND. Try it for yourself: http://cr.yp.to/djbdns.html

I did. I didn't find it easier to use. I felt the file format was
confusing and counter-intuitive. Maybe I've worked too long with
conventional zone file format that this is the "natural" and "obvious"
way of expressing DNS data to me. And anyway "ease of use" is
subjective and notoriously hard to measure objectively. Another aspect
of your code I didn't like was the requirement to use your tcpserver
and svscan programs to manage the various daemons.

    >> The last time I looked at tinydns, it only supported a small
    >> number of resource record types.

    Dan> False. tinydns handles records of all types. 

I see that now, though it's not well documented. The 45 words you have
explaining how to enter other record types was either missing or I
overlooked it the last time I played with your code. Apologies for my
error.

    Dan> tinydns has easy-to-use scripts for adding hosts, delegations, etc.  

  ... but no support for RFC2136 or 2137. If I had a DHCP server, it
couldn't send a Dynamic Update request to your name server to add an A
or PTR record for a newly assigned lease and have the request succeed,
could it?

    Dan> There's also no startup delay;

This is also true for BIND9. Seperate threads are used to load zones
and service queries, so the two things can proceed concurrently.

    >> incremental zone transfer

    Dan> The standard tinydns replication mechanism is incremental. 
    Dan> See http://cr.yp.to/djbdns/faq/tinydns.html#add-ns. 

The above URL suggests using rsync to propagate zone files. It's not
standard and only works if the servers trust each other and understand
your cdb format. Too bad if my ISP's slave name server doesn't allow
me to copy abitrary files or support cdb files or provide rsync. And
yes, I know if I jump through hoops your daemontools will let me run
axfrdns to get your server to support zone transfers, the standard and
interoperable way of replicating DNS data between name servers.

    Dan> BIND's zone transfers are way behind the state of the art

This implies that the RFCs defining zone transfers are "way behind the
state of the art". If you think you can do better, please submit a
proposal for an improved zone transfer protocol to the IETF. All that
BIND is doing is implementing the current protocol(s). Why are you
criticising BIND for perceived deficiencies in the protocol? Blame the
message, not the messenger.

    Dan> comments, see http://cr.yp.to/djbdns/faq/axfrdns.html.

Does your axfrdns program support IXFR or not? It's not clear from the
URL above.

BTW, your documentation states: "tinydns listens for packets on UDP
port 53. axfrdns listens for connections on TCP port 53". This is a
fundamental violation of RFC1035. Why does your name server not listen
for TCP connections? And why do you presume that the only reason for
making a TCP connection to port 53 is for a zone transfer?

    >> There was definitely nothing on DNSSEC

    Dan> The situation before DNSSEC was that an attacker could easily
    Dan> forge records for aol.com, or your rfc1035.com; the situation
    Dan> now is precisely the same. See
    Dan> http://cr.yp.to/djbdns/forgery.html.

So your code doesn't support RFC2845 or RFC2535. Even though DNSSEC
and TSIG are nowhere near fully deployed, they do allow consenting
adults - like business partners - to mutually secure and authenticate
their DNS data. So the situation is not precisely same. Since the root
and com zones are not signed, there's not a lot I can do with my keys
and signatures for rfc1035.com for the general public. However I can
make them available to whoever needs to verify my DNS data.

    Dan> The djbdns package has a $500 security guarantee:
    Dan> http://cr.yp.to/djbdns/guarantee.html

Your $500 means nothing. Other than the fact that you're willing to
put some money where your mouth is. And good on you for doing that.

A real security guarantee would provide a legally binding contract
indemnifying the user for all losses incurred as a result of a
security breach caused by the software. If I ran your code and it was
compromised, I wouldn't want your 500 bucks. I'd want you to cover my
costs for putting things right plus whatever I lost as a result of the
breach (trade secrets, client liability, loss of business, etc). Plus
legal and court costs. And damages. My lawyer probably wouldn't get
out of bed for $500. I'm not aware of anyone or any insurer who'd
accept unlimited liability like this.

    >> It's also possible to get a support contract for BIND from my
    >> employer, Nominum.

    Dan> Ah. So you give away a hard-to-use product and then sell
    Dan> support for it.  I guess the scam works as long as there's no
    Dan> competition.

I'm not going to respond to these cheap jibes.

Please tell us where we can buy support for your DNS software. This is
supposed to be a BIND forum, but what the hell...

    >> Well roughly 90% of the world's name servers run BIND.

    Dan> How exactly did you obtain this 90% number?

I dimly remembered this number from one of Bill Manning's in-addr.arpa
surveys, but didn't have the actual results to hand. He's already
stated here that "conservative estimates for 2q2000 would suggest
somewhere in the neighborhood of 20% may not be Bind or bind
derived". Bill's survey is probably the biggest impartial sampling of
the world's DNS servers, so the results are a good reflection of
what's in use today. [If anyone's got any better survey, I'd like to
hear about it.] So it would appear around 80%, not 90% of the world's
servers run BIND. I stand corrected. Fair-minded people would accept
that "around 80%" is not significantly different from "roughly 90%".

    Dan> Note that dnscache, the caching component of djbdns, doesn't
    Dan> respond to queries from unauthorized hosts, so automated
    Dan> surveys will give bogus results.

And you know full well that Bill Manning's survey takes account of
these non-responses. He's certainly told you often enough.



More information about the bind-users mailing list