Dan's "Ease of Use" Table, Redux (was Re: bind 8.2.4: limiting used memory?)

[Kevin Darcy]

D. J. Bernstein wrote:

> Kevin Darcy writes:
> > IMO, this is really the fault of the OS vendors, not BIND.
>
> You didn't answer my question. Exactly what files does ISC need in the
> chroot jail for its BIND 8.2.4 root server under Digital UNIX?

I have no idea. Why do I care? We don't run Digital Unix around here. Go ask a
Digital Unix sysadmin -- they probably know this off the top of their head. I
know that Solaris needs little, if anything, in the chroot jail.

The point is, BIND uses the standard logging facility, syslog. If the vendor for
Digital Unix (Digital? Compaq? I lose track of who makes what these days) makes
it hard to use syslog from inside a chroot jail, then go complain to them. It's
not BIND's fault if OS vendors do stupid things with their standard facilities.

> You said that my ``not thoroughly described in the BIND manual'' comment
> was a ``cheap potshot.'' So why can't you answer this simple question?

It's a cheap potshot because you're sneaking in a criticism of the quality of
BIND's documentation without a fair comparison -- or, for that matter,
*any* comparison -- with the quality of djbdns'es documentation. Are you afraid
to go head-to-head on quality-of-documentation?

Why don't you just say "maybe copy some system files, depending on your OS" and
leave it at that? That gets the point across without all of the
documentation-related snarkiness.

> Once again we find a serious annoyance for system administrators in the
> system that you call ``seamless,'' while everything works smoothly in
> the system that you call ``patchwork.''

BIND is "seamless" in this regard, because the logging facility, syslog, is
already on the box and configured according to the sysadmin's logging
preferences. djbdns has to interface with a new, unfamiliar-to-most-sysadmins
package, daemontools, in order to do logging. That's a "seam". That's
"patchwork".

> > tail -f on the error log
>
> That's a perfectly reasonable interpretation of ``Look for errors in
> your system's logs.'' (Assuming, of course, that you know where the log
> is,

Any competent sysadmin will.

> and that it isn't flooded by messages from some unrelated program.)

"tail -f | grep named". BFD.

> It's still an extra step, one that isn't necessary for djbdns.

No, it's not an extra "step" for each update, because you issue the command
*once* and then make however many changes you want to any number of zones and/or
any number of nameserver instances on the box. For that matter, if you have
centralized syslogging, you can make changes on any number of *machines*, and
watch all of the results in a single log, with a single "tail -f" command. The
"tail" command is amortized over all the updates you are doing in the session.
In fact, if one did nothing but DNS updates for a living, one would probably
start a "tail -f" at the beginning of the day and let it run continuously. So
it's (1/n) of a "step" per change, where n is the number of changes that are
made in the course of an update session.

With djbdns, on the other hand, if you want to save errors in a file, you
probably need to redirect each time. That qualifies more as a "step", in my
opinion.

> > By the way, the new named-checkzone and named-checkconf utilities in BIND 9
> > *do* in fact output their messages to the screen by default
>
> That's inadequate. If named runs out of memory loading the new zone, for
> example, how will you find out? You really need to learn something about
> reliability, Kevin.

I didn't say that the named-check* utilities should be the *sole* method of
verifying the integrity of an update, did I? Why do you attack straw-man
arguments?

> Anyway, running those utilities is still an extra step.

Not if they're an integral part of the update script. Again, we come back to the
point (which you have mostly evaded) that BIND is just a starting point for a
DNS maintenance system. It's not intended to be a complete DNS maintenance
system, as you sometimes seem to be claiming wrt djbdns.

> > the burden of having to download/build/install/configure/maintain an
> > extra package
>
> The upgrade procedure in http://cr.yp.to/djbdns/frombind.html already
> takes care of everything. The ``extra'' installation is fast; the
> configuration is handled automatically; there's nothing to maintain.

There's *always* something to maintain. "Install once and forget about it" is a
total myth.

> Why aren't you screaming about the BIND 9 ``burden'' of downloading,
> building, installing, configuring, and maintaining OpenSSL?

I'm surprised you'd bring that up. Doesn't OpenSSH (your recommended transport
for zone replication) also rely on the same package? So BIND is no *worse* in
this regard...

In any case, my understanding is that OpenSSL is only necessary for BIND to do
the RFC 2535 DNSSEC stuff (SIG/NXT/KEY), not for TSIG. Since the only crypto
I use so far in production is TSIG, this doesn't really bother me.


- Kevin