Users Want *Seamless* Solutions, Not Patchwork (was Re: Users want solutions, not buzzwords)

Kevin Darcy kcd at daimlerchrysler.com
Thu Jul 19 01:06:47 UTC 2001


My 2 cents...

-- AXFR/IXFR ---

AXFR and IXFR are certainly DNS-specific, but beyond that they are also
locked into the same query/response model of ordinary DNS queries, where
only a sequence of RRs (delineated clearly by section, of course :-) is
sent back to the client. It is the rigidity of this model that I think
makes AXFR/IXFR so crude, not necessarily the fact that it is
DNS-specific, _per_se_.

rsync and/or ssh, on the other hand, tend more towards the other extreme.
They are *so* generic that you have to write glue stuff around them in
order for them to be at all useful for DNS zone-replication. And they
don't lend themselves easily to being embedded within a
DNS implementation. A lot of people don't have rsync and/or ssh already
set up, and would rather just have their DNS implementation be
replication-capable "out of the box", without having to dowload, compile,
install and configure a bunch of extra packages.

What I'd prefer to see is something in between these two extremes. It can
be DNS-specific, but should be more flexible than AXFR and/or IXFR in
terms of compression/incrementality and it should allow data to be sent
along with the transfer which isn't strictly speaking zone data, i.e.
metadata, which might even be implementation-specific (subject to
negotiation and/or user configuration, of course).

-- DDNS --

Sorry, but I just have to flat-out disagree with you here, Dan. The
ability to provide continuous service during updates is *not* the only
reason for implementing Dynamic Update. I've converted over our
maintenance system to use Dynamic Update, and this allows me to separate
the updating function from the nameserver itself. My maintenance system
has a web interface -- since I don't want to run a web server on my
nameserver box, I can run it elsewhere and have it update the nameserver
via TSIG-signed Dynamic Updates. Oh, sure, I could probably set up some
ssh goop between the two boxes, so that the webserver can update the
nameserver's data files and then tell the nameserver to reload them, but
how is this preferable to just using Dynamic Update? Correct me if I'm
wrong, but wouldn't I have to set up a remote-execution facility in the
ssh scenario, in order to tell the nameserver to reload the data? Isn't
remote-execution inherently rather insecure? I'd rather not implement it
if I don't have to. Note that BIND has rndc, which allows secure, remote
nameserver operation, including single-zone reload. So ssh/rsynch in
conjunction with rndc would be another possibility. But Dynamic Update
does everything in one step. It's more elegant. Less stuff to break.

And Dynamic Update prerequisites enable greater guarantees of data
consistency. Perhaps you could elaborate on how djbdns prevents corruption
as a result of simultaneous writes to the same data file (?). Or is this
yet another thing that needs to be controlled using the WhizBang
file-locking tool from the FooBar Toolkit available for download from
Blurfl.org?

Dynamic Update also integrates better with DHCP servers and/or (I shudder
to mention it) Windows 2000/Active Directory. Don't hold your breath
waiting for *those* things to support ssh.

-- EDNS0 --

Who cares!?!?! I do. EDNS0 options are the biggest boon to DNS protocol
extension that have come down the pike in a long time. They allow new
extensions to be implemented without breaking existing interoperability.
In fact, a lot of this interoperability stuff you've been whining about on
namedroppers could be solved if you'd just support the idea of using EDNS0
for clients and servers to negotiate what they support and what they
don't. Hell, maybe there could even be an EDNS0 option for using rsync
*through* DNS to replicate zone data and/or metadata. The possibilities
are endless. Just open your imagination.

And the MTU-advertisement (or whatever you want to call it) feature of
EDNS0 is extremely useful for avoiding those nasty TCP re-transmissions
that default-configured djbdns handles so badly too...

---

In general, my impression of djbdns, from what little I've seen of it, is
that it suffers too much from Patchwork Syndrome. One has to assemble
solutions out of multiple toolkits, even just to get a basic nameserver
setup working. Many folks don't want to work that hard. BIND may be
monolithic, but I can slap a small number of binaries and config files on
a box and have a working nameserver in a matter of minutes. Not so with
djbdns. One has to tinker and tinker, connect piece A with piece B and
piece C with piece D, and *still* one ends up with something that has
missing functionality, in terms of supported Internet Standards. It's just
not worth the trouble, IMO, even with the security guarantee and the
likely performance advantage on uniprocessor systems...


- Kevin

D. J. Bernstein wrote:

> 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





More information about the bind-users mailing list