One Domain; Multiple IPs.

[Jim Reid]

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

    djb> BIND company employee Jim Reid writes:
         ^^^^^^^^^^^^^^^^^^^^^ Grow up, Dan!

    >> if you think you can design and document better protocols than
    >> AXFR and IXFR

    djb> I don't have to. Other people have done the work already. 

Where? Which RFCs document them? Please tell me. Did I miss a meeting
when the DNS protocols changed?

    djb> As my table shows, AXFR and IXFR are amazingly far behind the
    djb> state of the art in replication tools.

To the best of my knowledge none of these replication tools have
surfaced as internet drafts at the IETF. I have asked you on several
occasions to write up such a draft. You have repeatedly failed to do
so and explain why you can't or won't do that. If you care so much for
these better mechanisms, why can't you put them forward at IETF, the
only place they can be developed as Internet standards? Remember the
proverb "it is better to light a candle than curse the darkness"?
Whining about the deficiencies of AXFR and IXFR is not going to
achieve anything. Other than venting bile. Go on, be a pal. Light a
candle for these better replication mechanisms. You might even get
support for them from the engineers at "the BIND company" that you
seem to dislike so much. Or is that a risk you're unwilling to take?

    >> Your comparison table between djbdns and BIND

    djb> It's a comparison between rsync and zone transfers.

You said "BIND zone transfers".

    djb> The reason that BIND company people talk about it as
    djb> djbdns-versus-BIND is that they don't support rsync.

If/when rsync gets blessed by the IETF and IAB as a mechanism for zone
replication, you can be sure it will be in the reference DNS
implementation. 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?

    djb> For example, when people on this mailing list ask how to
    djb> automatically replicate views, the BIND company never tells
    djb> them how easy this is to do with rsync. They haven't answered
    djb> Tony Shah's question, for example.

If I had seen that question, I would have answered it. Replicating
views is a no-brainer. It just works. The view a client sees of some
zone depends on that client's IP address so the regular zone transfer
mechanisms work just fine.

    djb> One of the major benefits of rsync for system administrators
    djb> is that it's a general-purpose tool that works with many
    djb> programs. It's clear why the BIND company insists on
    djb> reinventing the wheel, and making sure that the reinvented
    djb> wheel is a pain for other programs to use: this helps achieve
    djb> product lock-in.

This is utter nonsense and you know it. Where's the "lock-in"? There
are other DNS implementations for people to use. Some of them even
choose to run your code I believe. The RFC for Incremental Zone
Transfer was written by Masataka Ohta at the Tokyo Institute of
Technology. AFAIK he has no affiliation with Nominum or the ISC. All
Nominum has done is implement that protocol on behalf of the ISC for
the reference DNS implementation, BIND. And nobody is compelled to use
IXFR either. So where's the lock-in? BIND is open-source. It always
will be. How can anyone be locked-in to an open source implementation
of a non-mandatory protocol that is in the public domain? Please
explain.

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. As I said before not
every platform has rsync and SSH. Some organisations even have their
name servers under different administrative control which makes SSH an
administrative nightmare. Imagine an ISP providing slave DNS service
for say a few thousand customer zones, each under the control of a
different customer. 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. It's do-able but practically unworkable in the real
world. And let's not forget the non-trivial problem of key management
too.

    djb> This is also why the BIND company always
    djb> refers to their specific wheel (IXFR, for example) rather
    djb> than what the system administrator wants (incremental
    djb> transfers).

Now you're deliberately confusing protocols and implementations. You
should know better than that. And IXFR is an open standard endorsed by
the IETF. It's in the public domain. It is not a "specific wheel of
the BIND company" and nobody is forced to use it. At least BIND
implements the IXFR protocol which is more than can be said for your
DNS software.