bind vs djbdns

[D. J. Bernstein]

Jim Reid writes:
> these obscure formats have an uphill struggle to find acceptance

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

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

False. tinydns handles records of all types. In contrast, BIND has to be
upgraded for every new record type. BIND chokes if it transfers a zone
with a record of an unrecognized type. BIND also has many artificial
record-size limits, and it doesn't support scheduled record changes.

> dynamic updates

tinydns has easy-to-use scripts for adding hosts, delegations, etc.
There's no gap in service when you update the tinydns database. There's
also no startup delay; records are loaded into memory on demand.

> incremental zone transfer

The standard tinydns replication mechanism is incremental. See
http://cr.yp.to/djbdns/faq/tinydns.html#add-ns. BIND's zone transfers
are way behind the state of the art; for further comments, see
http://cr.yp.to/djbdns/faq/axfrdns.html.

> There was definitely nothing on DNSSEC

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

Furthermore, even if DNSSEC were replaced by a real anti-forgery system,
you'd need a server without security holes. The djbdns package has a
$500 security guarantee: http://cr.yp.to/djbdns/guarantee.html

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

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

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

How exactly did you obtain this 90% number? Note that dnscache, the
caching component of djbdns, doesn't respond to queries from
unauthorized hosts, so automated surveys will give bogus results.

---Dan