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

[Kevin Darcy]

D. J. Bernstein wrote:

> http://cr.yp.to/djbdns/blurb/easeofuse.html is the table that we're
> discussing here.
>
> Kevin Darcy writes:
> > D. J. Bernstein wrote:
> > > ``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.
>
> You're wrong, according to the BIND 9 manual: ``Depending on your
> operating system, you may need to set up things like /dev/zero,
> /dev/random, /dev/log, and/or /etc/localtime.'' I've updated my summary
> to say ``Copy various system-dependent files, which are not thoroughly
> described in the BIND manual.''

Well, to tell the truth I haven't attempted to run BIND 9 chroot'ed, so I
can't really say with certainty what all is required in the chroot jail and
what isn't. All I know is that one of the big gripes about BIND 8 was the
necessity to populate the chroot jail with tons of junk for named-xfer, and
this was *never* necessary if you didn't use named-xfer (either because
you're not a slave for any zones, or you use an alternate method of
replication), and is certainly not true of BIND 9 (maybe _some_ device
nodes and/or system config files are necessary, but not "libraries" or
"programs"). Note also that many HOWTOs for chroot'ing BIND 8 recommended
compiling statically in order to obviate the need for shared libraries
(I never really agreed with that recommendation -- you're just trading
binary bloat for chroot-jail bloat, and making the build process more
convoluted -- but it is a valid alternative if you're paranoid about the
possible insecurity of a bloated chroot-jail). I think you're perpetuating
an old misconception about chroot'ing BIND. For the sake of honesty,
perhaps your table should note that named-xfer was responsible for the vast
majority of chroot-jail bloat, but named-xfer was never mandatory and is
now gone completely in BIND 9. Without named-xfer, the amont of chroot-jail
bloat is kept to a minimum.

> > In one of the BIND 8.2 versions the "forwarders { }" syntax was added
> > to selectively cancel forwarding,
>
> You seem to be saying that I can remove the ``10.1.2.6;'' part from the
> solution for BIND 8.2 and above. I agree that this is a bit simpler, but
> does it work correctly? When BIND looks up www.d.x.moon.mil in the
> example, will it start with the x.moon.mil server (ignoring delegations
> from moon.mil or above), then follow the d.x.moon.mil delegation? The
> documentation seems to suggest the opposite.
>
> Either way, the conclusion is the same: the sysadmin has to edit
> named.conf, while djbdns automatically does the right thing.

No, you're not understanding how forwarding cancellation works in BIND. You
specify "forwarders { }" *once* at the apex (e.g. moon.mil) and then you
don't need to specify it for any descendant zone.

> > if you're on a slow link lots of stdout can be painful
>

> Silly argument. _If_ there is a syntax error then djbdns will give you a
> one-line error message. Watching for BIND errors involves at least as much output, usually much more.
>


> You ask where the message is saved with djbdns. The answer is that
> running ``make'' again will very quickly show you the message again. Of
> course, people normally _fix_ the error, rather than looking at it again
> and again.

Oh great, so if you have multiple errors you have to keep on running make
over and over again, fixing errors each time? This is what you call ease of
use?!?! I'd rather have all of the errors recorded in a file -- I can have
one window open with the list of errors, and another window open where
I fix them. Fixing errors in "batch mode" like this is more efficient than
multiple make-fix-make-fix iterations, don't you agree? Some of us don't
have time for that nonsense.

> > 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.
>
> Learn to read. I'm comparing the supported, documented djbdns solutions
> to the supported, documented BIND solutions (except where I couldn't
> find any supported BIND solutions). I'm sure the BIND company will send
> me rsync solutions for my table _if_ they ever start supporting rsync.

How much "support" does one need for rsync in BIND? One could fairly
trivially implement rsync-based zone replication with BIND -- just define
the zone as "master" on all servers and use ndc/rndc to reload the zone
each time that rsync updates it. Does djbdns have any more "support" for
rsync than "here's the file(s) to copy, and here's how to tell the
nameserver to pick up the changes"? I don't see that there's much
difference between the "support" levels in the respective packages.

The simple fact is that BIND offers AXFR/IXFR as an *option* for zone
replication. People can accept or reject that option as they see fit. Yet
you, who vociferously denounce the use of AXFR/IXFR for zone replication,
assume, when it suits your purposes, that BIND users will invariably
replicate using AXFR/IXFR. This strikes me as hypocritical. Or at least
inconsistent.

> > only 2 main executables
>
> So what? Is that supposed to help the system administrator?

It most certainly *does* help when you're trying to integrate a DNS package
into a standardized server load image. If I had to work with our Unix
deployment team trying to integrate all of djbdns'es little bits and pieces
into the standard "Chryslerization" server load, it would undoubtedly be a
nightmare. With BIND, I just tell them to replace 2 executables that
already exist on the system (because what Sun/IBM/whomever ships is usually
obsolete). Easy as pie.

> Then why are
> the BIND solutions more difficult than the djbdns solutions?

Well, I think I've already explained some of the "padding" in your table,
as well as just plain unfair comparisons. And I've already explained the
difference between the base software package and all of the scripting glue
that typically surrounds it. True, djbdns is more scripted than BIND
out-of-the-box. And as long as one wishes to admin their DNS the Dan
Bernstein way, that's great. If not, then you're basically SOL. Either you
have to replace significant parts of djbdns with your own stuff, or try to
shoehorn it to do what you want. In either case, you'd probably be better
off just starting on a solid BIND base and writing your local stuff on top
of it.

To boil most of this discussion down to simpler terms: BIND, as an
integrated DNS auth-server/cache/replication program, is seamless, but
rather minimal: scripting "glue" is necessary to surround BIND and make it
a usable part of a production DNS subsystem. djbdns comes with more of the
scripting out-of-the-box, at the expense of being more patchwork-like, even
for basic tasks, but unless one happens to have the same tastes and
preferences as Dan Bernstein, one is likely to have to largely replace
and/or fight against it, in which case how is one better off than just
starting with BIND in the first place? The Unix "tool" philosophy is a
wonderful thing, but it needs to be traded off against the negative effects
of disjointedness and complexity. Moreover, I think the patchwork approach
in many ways results in *less* deployment choices. If I want my
BIND nameserver to only be an auth-server, all I do is specify "recursion
no". How difficult is it to make the opposite choice with djbdns, i.e. run
an auth-server and a cache on the same box? Why isn't *that* in your "ease
of use" table? Or look at how ridiculously convoluted it is to set up
AXFR-based replication on the same box as dnscache or tinydns, where that
program is configured to deal with TCP retransmissions (I'm still not sure
whether this is even *possible*, given your AXFR server's apparent reliance
on having unfettered access to TCP port 53). You give people the
"choice" of running these things separately, and then they have to jump
through hoops to integrate them. In some contexts, it's better to give the
user more than they may want, and then let them selectively turn off what
they don't use.

> > Support services aren't always necessitated by a
> > software package's difficulty-of-use.
>
> There are, of course, some support services for easy-to-use packages.
> However, support services for hard-to-use packages generally have a
> larger income-per-package-user ratio. Do you understand what the phrase
> ``financial interest'' means?

Do you understand what the term "circumstantial evidence" means? Just
because ISC/Nominum *may* benefit from various ease-of-use shortcomings in
BIND (I'm certainly not saying that BIND is trivial to maintain) doesn't
mean that this is an intended result or that this alleged difficulty-of-use
is being perpetuated for financial reasons. You have failed to prove intent
or collusion.

Bear in mind, of course, that folks who make big bucks off of BIND-based
products -- both the software cost and the maintenance thereof -- usually
put a nice GUI frontend on it that's even easier to use than either
"raw" BIND or djbdns for simple tasks. Point and click. So anyone who
really *needs* better ease of use can always pay for it, and if they do,
they'll get the DHCP server, DHCP/DNS integration, IP address management,
inventory/asset control, etc. that typically comes with such products in
addition to just basic DNS. I'm not saying that this solution is for
everyone. Admittedly the commercial products are rather expensive. But I'm
just pointing out that if "ease of use" is supposed to be the be-all and
end-all of a DNS package, the alpha and the omega, then comparing yourself
to raw BIND is rather pointless since there are more fully-functional
BIND-based products out there. The BIND software package is often just a
starting point for bigger and better things.


- Kevin