Users want solutions, not buzzwords

[D. J. Bernstein]

BIND company employee Jim Reid writes:
> Replicating views is a no-brainer. It just works.

With rsync, yes.

With zone transfers, no. As Tony Shah said a few days ago: ``The slave
downloads two copies, like it should, but each of them are identical.''
That's not the desired behavior.

> If you care so much for these better mechanisms, why can't you put
> them forward at IETF,

I could, but that would be a waste of time. The protocols are already
documented. Working implementations are available for free.

It's not my fault that the BIND company hurts its users by refusing to
support state-of-the-art replication tools.

Your ``IETF standards and only the IETF standards'' response is bogus.
There's no IETF standard specifying views, for example, or $GENERATE.

> When is djbdns going to support all the DNS protocols that you've so
> far failed to implement, like DDNS, A6/DNAME chaining, EDNS0, DNSSEC,
> IXFR, etc, etc?

Notably absent from your list of buzzwords is any indication of why the
system administrator should care. You also fail to mention that these
are _optional_ protocol extensions, not required for interoperability.

DDNS: I already support continuous service during updates. This applies
to manual editing too. Better than BIND.

A6/DNAME chaining: See http://cr.yp.to/djbdns/killa6.html and Itojun's
draft-ietf-dnsext-aaaa-a6-00.txt. A6/DNAME is a horrible idea.

EDNS0: Who cares?

DNSSEC: As discussed in http://cr.yp.to/djbdns/forgery.html, DNSSEC
doesn't work without central deployment. (It can be used locally, but
IPSEC does a better job of that.) I'll implement DNSSEC if and when I
hear a detailed, concrete, credible plan for central deployment.

IXFR: I already support incremental replication, through rsync. This
applies to manual editing too. Again, better than BIND.

> In a heterogeneous environment, the IXFR protocol is the sure way of
> doing incremental zone transfers because every DNS implementation is
> expected to support it. Except yours of course.

DNS implementations such as BIND 8.2, BIND 8.2.1, BIND 9.0.0, and BIND
9.1.0, for which there have been widespread reports of IXFR failures,
including data corruption? Funny how this is suddenly an essential
element of DNS.

> Now manage that with rsync-over-SSH with a few thousand discrete UIDs
> and SSH keys so each customer can only change their zone file.

Typical practice at big hosting companies is to accept database changes
through the web, then convert the data to the format used by the DNS
server, then use rsync to replicate the data. This all works right now.
The companies appreciate djbdns's easy-to-use data format, support for
rsync, and immediate use of new data files without any outages.

> And let's not forget the non-trivial problem of key management too.

You think that BIND's crude DNS-specific TSIG key-management tools are
better than advanced general-purpose tools such as ssh and IPSEC? Get a
grip. You pay a price for reinventing the wheel.

---Dan