bind vs djbdns

[Jim Reid]

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

    >> > There's also no startup delay; This is also true for BIND9.

    djb> Really? Let's say someone has a gigabyte of data in BIND zone
    djb> files.  You're saying that I can get an answer from any part
    djb> of that data several milliseconds after he starts the
    djb> program?

No. I am saying however that the BIND9 name server can serve queries
while it loads zone files. It all depends on how someone defines "no
startup delay". Our definitions differ. Oh well.

BTW BIND9's architecture allows for DNS data to be served from other
things beside zone files: like an RDBMS or LDAP repository. These
alternatives are not implemented yet, but folk are working on them.
Yes, I know this is vapourware to some extent. However I think it's
important to give a more balanced view of BIND9's capabilities which
eventually will provide your definition of "no startup delay".

    >> This implies that the RFCs defining zone transfers are "way
    >> behind the state of the art".

    djb> Correct. The modular rsync+openssh file-transfer system
    djb> provides immediate replication, error notification,
    djb> compressed transfers, automatic addition of new zones,
    djb> encryption, authentication, and incremental transfers. In
    djb> contrast, with BIND's ad-hoc DNS-specific file-transfer
    djb> system, you have delayed replication, hidden failures, poor
    djb> compression, manual zone lists, no encryption, a hard-to-use
    djb> experimental authentication system, and a rickety
    djb> implementation of an experimental incremental-transfer
    djb> mechanism. There's no contest.

First of all - and not for the first time - you confuse the protocol
with the implementation. Why do you blame BIND for the perceived
deficiencies in the zone transfer protocols defined in RFC1035 and
RFC1995? And why don't you work with the IETF to improve those
protocols?

An ad-hoc or implementation specific system seems like a perfect
description of your rsync+openssh scheme. And as for exchanging and
managing SSH keys.... Which RFCs document these protocols? Are they
implemented by any other name servers? Has this scheme been blessed by
the IETF? If not, why not?

Note too that I am not saying rsync or SSH are Bad Things. I use them
myself. But not for zone transfers or shunting DNS config files about.

    >> 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?

    djb> It's amazing how many mistakes you can make in a single
    djb> paragraph. RTFM: http://cr.yp.to/djbdns/faq/tinydns.html#tcp

My mistake is a direct result of reading your documentation. I quote
from http://cr.yp.to/djbdns/faq/axfrdns.html#udptcp:

	Can I run tinydns and axfrdns on the same IP address? 

	Answer: Yes. tinydns listens for packets on UDP port
	53. axfrdns listens for connections on TCP port 53.

I now see from the URL you quoted that the default behaviour of your
software is not to comply with RFC1035 and listen for TCP queries.
Apologies. It's a pity that your documentation is inconsistent and
misleading. The URL I quoted contradicts the one you referenced.

    >> Bill's survey is probably the biggest impartial sampling of the
    >> world's DNS servers,

    djb> Only in-addr.arpa servers. Pure caches are much more
    djb> common. Anyway, I already knew your number was wrong; I'm
    djb> questioning your integrity.

If you feel that personal attacks help, well question away.

Most reasonable people would accept that Bill Manning's in-addr.arpa
survey is probably the biggest and most representative sampling of the
Internet's name servers. I've asked here for details of anything
that's more comprehensive, so far without reply. If there was a bigger
or better survey, someone on this list would surely know about it.

And since Bill's survey (sort of) samples the current address space,
the distribution should be an honest reflection of the respective
deployment of DNS implementations. [Unlike domains such as rfc1035.com
or cr.yp.to or microsoft.com which definitely won't be representative
of the Internet as a whole.] Whether caching-only servers are more
common or not is irrelevant. I suspect they're not more prevalent but
I'm willing to listen to anyone who has got convincing arguments and
impartial data to support that claim.

What difference would the number of caching name servers *really* make
to the usage of different DNS implementations? Please show some real,
impartial numbers to back any assertions that you make about this. You
made the claim, so it's up to you to prove it. I suspect it's highly
unlikely that someone would use a BIND (say) name server for their
in-addr.arpa zone and choose to run some other implementation for any
caching servers they have. But if anyone has got useful numbers on
this topic, I'd be glad to see them.

I also note that you failed to answer many of the questions I asked
earlier. Why didn't you explicitly tell us whether djbdns supports
DNSSEC, TSIG, IXFR and RRs for IPv6 or not? Does djbnds fully support
these standards, yes or no?