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

Kevin Darcy kcd at daimlerchrysler.com
Sat Jul 21 05:06:02 UTC 2001


D. J. Bernstein wrote:

> Kevin Darcy writes:
> > anyone who cares about ease of use (your audience here) would have at
> > least scripted these updates a long time ago
>
> Gee. A moment ago I thought you said something like ``Users Want
> *Seamless* Solutions, Not Patchwork.'' And now you're saying that I'm
> ``dishonest'' for not taking your local BIND patchwork into account.

There's a difference between the software package or packages one grabs off the
Net to perform a particular function, which is often just a starting point, and
an entire infrastructure subsystem built around that package, which typically
includes a lot of local scripting "glue". The latter is almost always somewhat
patchwork-like. But the former need not be. djbdns seems very patchwork-y even
when configured to do fairly trivial, generic things like be a cache in
addition to serving authoritative data (that's two programs in djbdns instead
of just one BIND program, right?) or replicate zone data. Once you add the
local scripting on top of the patchwork that constitutes "native" djbdns, you
can easily end up with something very complex and convoluted and difficult to
maintain. At least with BIND, you have a minimum of moving parts (only 2 main
executables -- named+named-xfer in BIND 8, named+rndc in BIND 9). You can add a
lot of local scripting to that relatively simple (okay, monolithic) base before
it starts to get unmanageable.

> My table compares the supported, documented djbdns solutions to the
> supported, documented BIND solutions. The only exceptions are cases
> where I couldn't find _any_ supported BIND solutions.
>
> If the BIND company tells me that version 9.whatever now supports an
> easier solution, namely blah blah blah, I'll be happy to add that
> information to my table.
>
> > getting named to follow delegations under a forwarded domain
> > does *not* require a new zone definition
>
> On the contrary. As the DNS and BIND book says, in a discussion of BIND
> scaling problems:

No, Dan, don't try to pull a fast one here: what you're referring to is a
discussion of scaling problems with *forwarding*. There's nothing BIND-specific
about the non-scalability of forwarding.

> ``zardoz will ignore the delegation information and
> forward the query to terminator.''

You're probably quoting that from 3rd Edition of the book, which only covers
through BIND 8.1.2. In one of the BIND 8.2 versions the "forwarders { }" syntax
was added to selectively cancel forwarding, which in your terminology, enables
named to follow delegations.

Granted, if one is using "global" forwarding (i.e. forwarding specified in the
"options" statement), then one has to define the *apex* of each
not-to-be-forwarded domain as a zone with "forwarders { }". But the impression
your table gives is that each and every not-to-be-forwarded zone needs to be
defined in named.conf. That's simply not true with modern versions of BIND.

> > neither does BIND require shared libraries and various other stuff in
> > a chroot jail
>
> On the contrary. ``Copy various programs, system-dependent libraries,
> and system-dependent devices'' is a perfectly reasonable summary.

No it's not. You don't need that stuff if you're not using named-xfer. Be fair,
Dan: just as one can run djbdns with or without using AXFR/IXFR, one can run
BIND with or without using AXFR/IXFR. For those who choose to go that route, it
is not necessary to load up the chroot jail with all of that crap. Since you
*recommend* not using AXFR/IXFR, it even strikes me as even a little
hypocritical that you would assume its use in your supposedly apples-to-apples
comparison of djbdns and BIND.

All of this is somewhat moot anyway, since named-xfer doesn't even exist in
BIND 9.

I'll also note that some OS'es which include BIND have it configured to be
chroot'ed by default. In that case, arranging for BIND to run chroot'ed is
practically effortless.

> > you have an extra step for "Look for errors in your system's logs"
>
> With djbdns, the errors are displayed automatically. With BIND, the
> system administrator has to go to extra effort to check for errors.

No, the sysadmin doesn't have to go to "extra effort". The errors BIND reports
are logged by default to syslog, which then puts them exactly where the
sysadmin expects them and has configured them to go. Now, maybe writing the
errors directly on stdout is convenient for a lot of people. But then again,
maybe not (e.g. if you're on a slow link lots of stdout can be painful). And
what if you want a copy of the error messages on disk so that you can go back
and refer to it? Sure, it's possible to redirect stdout. But now we're talking
"extra effort", aren't we? Logging to syslog lets the error messages be handled
according to the sysadmin's established preferences for logging, not Dan
Bernstein's one-size-fits-all preferences for how logging should work for
everyone.

If you want to put "check for errors" as a separate step, then fine. But it's
unfair to add that step to the BIND sequence of events, where the errors are
logged according to the sysadmin's expressed syslogging preferences, and
*not* to add it to the djbdns sequence of events, where the errors are logged a
particular way, which may or may not be the sysadmin's preference. You can't
say that one logging method or the other is invariably "extra effort" for all
sysadmins. The "check for errors" part of the process should either be listed
as a separate step for *both* packages, or for *neither*.

> > > 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,
>
> The BIND company sells support services. It has a financial interest in
> hard-to-use software. This is not a conspiracy theory; it is a simple
> statement of the economic facts.

Well, I'm in the support *business*, and I disagree with your interpretation of
these "economic facts". Support services aren't always necessitated by a
software package's difficulty-of-use. Often support services are purchased to
provide a higher level of functionality than that for which the software was
originally designed. To be perfectly candid, many times support contracts are
nothing more than a beancounter-ish CYA, i.e. someone to point the finger at --
possibly sue -- if the software breaks. There are many reasons why companies or
individuals buy software support services. The fact that people buy them is
certainly not proof positive that the software is hard to use.

Even if you could prove that Nominum benefits financially from BIND's alleged
difficulty-of-use, you haven't proven a conflict of interest. The Nominum
people who write BIND code aren't necessarily the same Nominum people who sell
or provide support services. In fact, doesn't one facet of Nominum's business
use a non-BIND nameserver? At most, you'd have a circumstantial case of
collusion or conflict of interest.

> > how many hours of prior download/compile/install/config
>
> The normal situation is that ssh is already working and rsync is
> unnecessary. It is straightforward to download, compile, and install
> daemontools, ucspi-tcp, and djbdns---much easier than downloading,
> compiling, and installing BIND. You don't need anything else.
>
> > The point is, by not supporting EDNS0, you're locking djbdns out of dozens
> > if not hundreds of potential useful extensions to DNS.
>
> ``Locking out''? Don't be silly. I can implement EDNS0 later, and I will
> do so _if_ it means something for my users.

I thought djbdns'es codebase was frozen for all eternity. That's the impression
you've been giving in the whole AXFR-clarify discussion...

> > Writing your own DNS implementation was a good step, but
> > proving that your way of doing DNS *at*the*protocol*level* is better,
>
> What are you babbling about? djbdns uses the existing DNS protocol to
> help administrators retrieve and publish DNS records. It is a research
> project in security and in ease of use; it is not a research project in
> protocol design.

If you're not interested in improving the protocol, then why constantly
antagonize the protocol community with your jabs and barbs? What purpose does
it serve?


- Kevin





More information about the bind-users mailing list