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:
> > I scrutinize every new package I install
>
> Ah. So now you're claiming that it's easier to review the BIND package,
> totalling 1372 kilobytes, than to review the daemontools and ucspi-tcp
> and djbdns packages, totalling 173 kilobytes?

Sheesh, I don't go through every line of code; I'm just looking at how to
customize pathnames to conform to Chrysler standards, nasty interactions with
system utilities and/or other packages, etc.. It's a
"compatibility" scrutinization, not an in-depth code review. BIND is
relatively self-contained, so it's easy to check -- about the only system
utility it interacts with is syslog. And with only 2 main executables, and a
fairly small number of pathnames to care about (where is the named.conf
file? where is the rndc.conf file? where does the pid file get written?) it's
easy to customize it to fit in a standard Chrysler distribution.

Can you say the same of all of the various interlocking bits and pieces of
the 3 software packages you mentioned?

> > As for "... not thoroughly described in the BIND manual", this phrase is
> > just a cheap potshot.
>
> It actually understates the difficulty for BIND system administrators.
>
> Consider, for example, ISC's f.root-servers.net, which reportedly uses
> BIND 8.2.4 under Digital UNIX. Can you tell me what files need to be
> copied to a chroot jail for this operating system? (Does ISC know? Is
> BIND running chrooted on f.root-servers.net?)

IMO, this is really the fault of the OS vendors, not BIND. They provide a
standardized logging facility (syslog) and a security facility (chroot), but
then to make the two work together properly on some platforms you have to
copy crap into the chroot jail, which is a minor setup headache and arguably
makes the jail less secure. It also seems to be inconsistent between
platforms (what does POSIX have to say about syslog, he wonders aloud?) Some
OS vendors (e.g. Sun) seem to be better at this than others. Maybe eventually
they'll all get a clue.

But does this minor, one-time ugliness warrant replacing the logging facility
altogether with something unfamiliar and possibly less maintainable? I don't
think so. That would be throwing the baby out with the bathwater. syslog may
have its flaws and limitations, e.g. its chrootability requirements on some
platforms, but at least syslog is a known quantity and something any Unix
admin can be expected to be familiar with. That, in and of itself, has a very
high value. Training time, getting-up-to-speed time, is expensive. I wouldn't
want to have to train every new Unix sysadmin on how to configure and
maintain "daemontools".

> > people are expected to write custom scripts/programs on top of BIND
>
> How can you claim that this is as easy as having the scripts already
> provided? Ridiculous.
>
> Why doesn't the BIND company write their own add-ns and add-host and
> add-mx and add-childns tools, and include them with the package, and
> support them, instead of making their users suffer?

I don't speak for them, of course.

I will say, though, that if they provided such things, I wouldn't bother
using them. My zones are all Dynamic Update-enabled, so "nsupdate" (with
perhaps some convenience frontends) is all I really need to perform any or
all of those functions, with the possible exception of "add-childns" (if it
actually creates an instance of a zone,admittedly I'd have to create a
minimal zonefile, modify named.conf and reconfig/reload in addition to just
running nsupdate to add delegation records). I suspect the vast majority of
other BIND users have scripts to perform these functions also. Those who
don't have scripts, are apparently happy with manual editing of zonefiles. As
far as I can see, no-one is "suffer"ing here, except in your imagination.

Maybe BIND's userbase is just more sophisticated than djbdns'es?

djbdns == "BIND for Dummies"?

> > Either "checking the results" is so arduous that it deserves a "step"
> > for *both* packages
>
> Checking for errors is trivial ONCE THE ERROR LIST IS ON THE SCREEN.
> With djbdns, this happens automatically. In contrast, with a typicalBIND
> installation, this needs an extra step, as shown in my table.

If you're doing a tail -f on the error log, then the errors are listed on
your screen regardless. Anybody who *wants* the errors on their screen can
therefore *get* the errors on their screen. And, conversely, anybody who
*wants* the errors recorded in a file can *get* the errors recorded in a
file. A reasonably competent sysadmin can get the errors in either place --
or both!

My point stands: either "check for errors" is arduous enough to require a
step for both packages or trivial enough to not warrant a step for either
package. There really is no discernible difference between BIND and djbdns in
this regard. Error messages are error messages, and they go whereever the
admin told them to. The fact that djbdns'es go to the screen, by default, and
BIND's go to syslog, by default, isn't an "ease of use" difference that
warrants mention, IMO.

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, and folks would
probably be well-advised to use those utilities to check zonefiles and/or
config files before committing any changes to the nameserver anyway.
Pre-checking changes in this way also effectively knocks out the "Make sure
there are no syntax errors in new data" item from your "ease of use" table.

> > This dependency/complication is conveniently *not* mentioned in your
> > "ease of use" table.
>
> That's because the extra work is a figment of your imagination. All
> these tools are included in the initial installation. Configuration is
> handled automatically by the dnscache-conf and tinydns-conf steps shown
> in my table, as I told you before.

The fact remains that, instead of just using syslog, like a normal system
utility does, djbdns requires daemontools for logging. While this may relieve
some requirements for population of chroot jails (as I discuss above), the
burden of having to download/build/install/configure/maintain an extra
package may, for many shops, far outweigh that tiny advantage.


- Kevin