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

Kevin Darcy kcd at daimlerchrysler.com
Fri Jul 20 02:35:25 UTC 2001


D. J. Bernstein wrote:

> Ease of use is actually one of the selling points of djbdns over BIND.
> See http://cr.yp.to/djbdns/blurb/easeofuse.html for a table showing
> exactly how various common operations work with djbdns and with BIND.

Well, I found that table somewhat unconvincing, maybe even a tad dishonest.
For the not-so-common operations, like setting up new nameservers, etc. you
have "padded" the BIND steps by including all of the named.conf file
verbiage in them. But in the real world, most of those would start out "1.
copy a named.conf from another, similarly-configured server. 2. Modify it
thusly ...". It's been a long time since I've created anything but a
trivial caching-only named.conf from scratch.

And you have some, er, suboptimal ideas about how to do various tasks in
BIND (e.g. getting named to follow delegations under a forwarded domain
does *not* require a new zone definition, neither does BIND require shared
libraries and various other stuff in a chroot jail unless you need to spawn
named-xfer processes -- and we wouldn't want to use that icky AXFR/IXFR
protocol for replication, now would we?). You also make an unfair
comparison when on the BIND side you have an extra step for "Look for
errors in your system's logs" and on the djbdns side the last step is just
"make". To be fair, shouldn't there be another step on the djbdns side that
says "watch your screen for errors"? Or does nothing *ever* go wrong in the
"make" step? Riiiight.

As for the truly *common* tasks, like adding records, you seem to be
assuming the crudest possible method of maintaining DNS data in BIND, i.e.
manually editing individual zone files. While I'm sure plenty of folks do
this, anyone who cares about ease of use (your audience here) would have at
least scripted these updates a long time ago to catch some of the more
common errors like forgetting to dot-terminate names, badly-formed
IP addresses, etc. not to mention performing mundane tasks like
incrementing serial numbers and reloading the nameserver. More
sophisticated maintenance systems (like mine) also do the reverse/forward
checking/synchronization automatically, and, as I mentioned previously, it
is based on Dynamic Update, so all of this fear about making syntax errors
in the zone file, the zone file getting truncated, etc. consequently making
a zone unusable, is irrelevant to me (if there were a disk problem, for
example, the Dynamic Update would be refused and the user would know about
it instantly).

> Unlike the BIND company---which sells support services---I don't have
> any financial interests in hard-to-use software.

Every time you make a snide reference -- like that one -- to "the
BIND company", you make yourself look like a conspiracy-theorist nutcase,
Dan (I think I just violated my self-imposed ban on namecalling, oh well).
Or, alternatively, it makes you sound envious that BIND is so popular that
people would pay good money for its support. You really are your own worst
enemy sometimes.

> Kevin Darcy writes:
> > They are *so* generic that you have to write glue stuff around them
>
> I support rsync+ssh for djbdns replication, so the necessary one-line
> command is shown in the documentation.

One line of command, maybe, but how many hours of prior
download/compile/install/config before that one line actually does anything
*useful*?

> > EDNS0 options are the biggest boon to DNS protocol extension that have
> > come down the pike in a long time.
>   [ ... ]
> > The possibilities are endless.
>
> Translation: ``I don't actually use EDNS0 for anything.''

The point is, by not supporting EDNS0, you're locking djbdns out of dozens
if not hundreds of potential useful extensions to DNS. You also undercut
your own arguments about interoperability, since EDNS0 options are a great
way to ensure that only clients and servers with the same knowledge level
and/or willingness to implement certain extensions, will actually use those
extensions over the wire. I'm sure there's a whole raft of "Notes on
DNS"-inspired extensions that could theoretically be turned on or off using
EDNS0, e.g. "collapse alias chains" (since you don't like CNAMEs), "send me
only addresses in referrals, not names" (since you abhor "gluelessness"),
"lowercase everything" (since you despise case-preservation), "use a real
compression algorithm instead of label compression" and so forth. Instead
of getting these extensions implemented via EDNS0, you just harangue people
who are trying to clarify the specifications, whine about interoperability
and/or flat-out call other people's extensions "broken". This is hardly
productive. Writing your own DNS implementation was a good step, but
proving that your way of doing DNS *at*the*protocol*level* is better,
requires an interoperable way for clients and servers to use extensions of
your choosing. Unless of course you plan to rewrite the entire protocol
from scratch.

Oh wait, Vixie came up EDNS0, right? Well, we couldn't possibly admit that
someone from "the BIND company" came up with something *useful*, now could
we? We're much too proud for that.


- Kevin





More information about the bind-users mailing list