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:
> > djbdns has a helper script ("add-mx") specifically to perform this
> > function, and BIND does not
>
> Exactly! This is one of many things making the package easier to use.

In the rest of the paragraph (which you deleted in your response), I
explained why the comparison was an unfair one: because BIND never claims
-- or is expected -- to be a complete DNS maintenance system. It's just a
starting point: people are expected to write custom scripts/programs on top
of BIND. Now, if djbdns claims to be a complete DNS maintenance system,
I'll judge it as such. But, be aware, I have high standards for such
things. None of the mucho-$$$ commercial products I've evaluated have
passed muster; djbdns'es chances look pretty slim.

> > Anyone wanting decent logging from djbdns needs to
> > download/compile/install/configure the "multilog" package instead of
> > syslog.
>
> There is no multilog package; multilog is included in daemontools. All
> the necessary multilog configuration is handled automatically by the
> dnscache-conf and tinydns-conf steps shown in my table. (The default
> logs are much more comprehensive than BIND's default logs, by the way.)
>
> As for the initial installation of daemontools, ucspi-tcp, and djbdns:
> Download the three tarballs, and then copy and paste the eight lines
> shown in http://cr.yp.to/djbdns/frombind.html. That's it.

That would be highly irresponsible, don't you think? I mean, downloading
packages with unknown contents, and then installing them blind --
presumably as superuser -- whereever they happen to want to install (?) And
you call yourself security-conscious? I scrutinize every new package I
install to make sure it plays nicely with everything else I already have
installed, and doesn't do anything surprising or unexpected that might lead
to maintainability problems or outright security vulnerabilities. Every
package has to be assimilated into the "Chrysler" way of doing things,
which often means reworking pathnames, changing assumptions about what is
or is not in the $PATH variable, what shells admins use, etc. etc. We
generally install packages on test boxes and run them for weeks or months
before they get anywhere near a production server. You live in a dream
world if you think everyone can just slap generic software packages with
default settings on a box _ad_nauseum_ and expect them to be maintainable
and to all co-exist nicely with each other. After about the 30th or 40th
package you put on the box, you have an unholy mess to deal with unless
you've carefully established ground rules, standards and conventions for
*every* package that is installed. It takes time and effort for *each* new
package to be made conformant, to be piloted and eventually approved for
production.

Less packages to deal with is a *good* thing. I don't know where you got
this idea that patchwork makes admins' lives easier. Is this a common
delusion in academia? Here in the trenches, we see things differently: less
packages, less headaches.

> > in the case of ssh at least, that a certain amount of planning,
> > configuration, key-generation/-exchange, etc. needs to be performed
> > before the utility is actually usable according to the examples shown.
>
> Certainly. But this is something that multiple-machine administrators
> have already done, because it's useful for many other applications. In
> contrast, setting up BIND's ad-hoc security mechanisms is a bunch of
> extra work.

I'd hardly call TSIG an "ad-hoc security mechanism". We were, after all,
talking about how to secure zone replication, and TSIG is the preferred
method for doing that between BIND servers...

> > Dan claimed in his table that chroot'ing BIND requires populating the
> > jail with lots of OS files and/or device nodes.
>
> What I actually said was ``Copy various programs, system-dependent
> libraries, and system-dependent devices,'' which is a reasonable summary
> of the situation for BIND 8.
>
> I later changed that to ``Copy various system-dependent files, which are
> not thoroughly described in the BIND manual,'' which is a reasonable
> summary of the situation for both BIND 8 and BIND 9.

No, it's an extremely *biased* summary. As I pointed out in the part(s) of
the paragraph you deleted: a) not all platforms (e.g. Solaris 8) need
"system-dependent files" in the chroot jail unless they're using DNSSEC,
b) most of those "system-dependent files" are only necessary for syslog,
and copying the files *once* into the chroot jail is easier for many admins
(let's assume they know how to copy files) than screwing around on an
ongoing basis with an unfamiliar package like multilog or daemontools or
whatever, which is what djbdns offers as an alternative to using syslog.
This dependency/complication is conveniently *not* mentioned in your "ease
of use" table.

As for "... not thoroughly described in the BIND manual", this phrase is
just a cheap potshot. If you want to stack up the qualilty of djbdns'es
documentation against the quality of BIND's, then please do so in a
balanced, comprehensive way. And make sure you include the _DNS_and_BIND_
book as part of BIND's documentation, because almost everyone who is
serious about BIND administration is going to have a copy of that book.
Sure, it costs money. So, are you going to accuse O'Reilly of being "the
BIND company" now, and of deliberately making BIND harder to use in order
to increase book sales? In that case, you might as well accuse them of
being "the ssh company" since they also sell books about that package (the
O'Reilly ssh book also mentions rsync, so let's call them "the rsync
company" too).

Yes, the book costs money. But so does an admin's time wasted stumbling
around trying to configure djbdns or BIND without adequate documentation.
So does downtime incurred because their DNS ends up being misconfigured
and/or poorly maintained. Most intelligent organizations consider the
investment in documentation and/or training a wise one. (DaimlerChrysler
paid for me to take an Advanced BIND course from Cricket last year, for
example, and I'm certain they got their money's worth).

> > "Look for errors in your system's logs" step that Dan lists for BIND
> > for multiple "ease of use" items should be matched in many cases by
> > "watch the make output for errors"
>
> Don't be ridiculous. The make output is already on the screen. The BIND
> syslog output, in typical installations, is not. BIND administrators
> have to go to extra effort to see it, exactly as shown in my table.

In the part of the paragraph which you deleted, I explained *why* it is
often preferable for errors to be logged in a file -- because sometimes
there are multiple errors and you might want to fix all of them in a single
pass. Having a record of the errors in non-volatile storage is a Good Thing
in such a situation.

Sure, all of this is fairly trivial. "make" can be "typescript"ed, "tee"d
or its output simply redirected to a file. Conversely, the error log can be
"cat"ted or "tail"ed (sometimes I'll even "tail -f" in a separate window
when I'm doing major reconfigurations). BFD. But if it's so trivial, why
bother making a separate "step" out of it in the BIND column? Either
"checking the results" is so arduous that it deserves a "step" for
*both* packages, or so trivial that it deserves a "step" for *neither* of
them. The fact that it is a "step" in the BIND column, but not the djbdns
column, only serves to announce the bias of the table's author.


- Kevin