bind vs djbdns

[D. J. Bernstein]

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

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

This works with tinydns data files. The tinydns program doesn't have to
read the entire gigabyte of data into memory before it answers queries.
It loads records from disk on demand. It tries to keep frequently used
records in memory, but it can survive with very little memory---hence
the ``tiny'' name.

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

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

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

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

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

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

---Dan