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

[Kevin Darcy]

D. J. Bernstein wrote:

> Michael Kjorling writes:
>
> > And in the end, that comparisation chart looks
> > much like Microsoft's (and other big companies') ones: show the worst
> > possible way of doing things in the competitor's software.
>
> Kevin made the same accusation. When I demanded details, he repeatedly
> made a fool of himself,

Sorry, I can't let such a statement go by without challenging it. Just
because Dan says that I made a fool of myself, doesn't necessarily make it
true. Let's review what we talked about:

1) Dan claimed in his table that chroot'ing BIND requires populating the
jail with lots of OS files and/or device nodes. I pointed out that on some
platforms (e.g. Solaris 8), when not running DNSSEC, *no* OS files or
device nodes are necessary. I also pointed out that, where necessary, most
of that stuff was required to support syslog. djbdns doesn't use syslog, so
it's very easy to say it requires less population of the chroot jail, on
some platforms. Easy, but superficial, perhaps even to the point of
misleading. Anyone wanting decent logging from djbdns needs to
download/compile/install/configure the "multilog" package instead of
syslog. Is that a net improvement in "ease of use"? Syslog comes standard
with most if not all Unix OS'es, and most Unix admins already know how to
configure it. So it is often the case that BIND's approach has more
ease-of-use -- populating the chroot jail with a few nodes/files versus
dealing with a whole new logging package. But Dan's table only reflects the
*worst* aspect of chroot'ing BIND, and conveniently ignores the downside of
djbdns'es non-standard logging-subsystem requirements. In fact, the "ease
of use" table doesn't explicitly mention *any* of the other software
packages upon which djbdns relies -- admittedly, "rsync" and "ssh" are
mentioned in passing in one of the items, but nowhere is it pointed out
that these utilities don't ship standard with most Unix OS'es (at least,
not with most commercial Unix'es), or that, 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.

2) I pointed out that the "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" in the corresponding
djbdns cells in the table. Dan replied that it wasn't a separate step in
the case of djbdns. Where one delimits one "step" from another in a process
can of course be open to debate, but the (arbitrary) choice in this case
seems deliberately slanted against BIND. We then discussed the relative
merits of interactive error messages versus logging errors to a file. In
particular, I pointed out how inconvenient it was, when faced with several
errors, to constantly have to run the "make" step for each error (as
opposed to just collecting all of the errors in a separate
window/file/hard-copy/whatever and fixing all of them in one pass).

3) More generally, I pointed out that BIND takes a rather minimalist
approach towards DNS maintenance _per_se_ -- BIND provides basic
DNS functionality and expects administrators to write their own customized
scripts to automate their DNS maintenance (or it expects vendors of
commercial products based on BIND to write fancy frontends). Due to this
approach, it is rather unfair to compare functions like "Send incoming mail
for x.mil to a mail server at 1.2.3.4" (aka "add an MX record to a zone")
between BIND and djbdns, since djbdns has a helper script ("add-mx")
specifically to perform this function, and BIND does not. In the real
world, however, any BIND admin who cares about ease of use would have
already created such helper scripts a long time ago, and these custom
helper scripts probably include a lot more site-specific functionality in
them (e.g. configuring the mail server(s) to accept the mail at the same
time as adding the MX record to DNS) than djbdns'es generic,
one-size-fits-all helper scripts. So, again, while the table is literally
true, it is rather superficial, and perhaps misleading. It doesn't reflect
the reality of most BIND and/or djbdns installations.

4) I pointed out that configuring AXFR service to co-exist with regular,
TCP-capable DNS cache service, on the same interface of the same box, was a
very common operation and was somewhat more painful to do with djbdns than
with BIND, yet is not featured in Dan's table. Of course, BIND always
listens on the TCP port, and provides AXFR service by default -- to get
both of these things working and co-existing requires no extra
BIND configuration at all. In passing, I also pointed out the wastefulness
of having to duplicate ordinary-query-processing code in both the caching
process and the AXFR-server process (this is necessary in djbdns, since the
AXFR server monopolizes TCP port 53 on the machine, yet sometimes even
"normal" lookups use TCP, so the AXFR server needs to be able deal with
them too).

5) More generally, I decried the "patchwork" nature of (djbdns + the
packages upon which it depends), compared to the relatively self-contained,
monolithic installation footprint of BIND, and explained how a small,
coherent set of files was much easier to deploy and maintain in a large
enterprise than a larger set of files in various directory locations,
hailing from disparate software packages with different
installation/configuration paradigms.

6) I pointed out how the "ease of use" items relating to delegation and
forwarding present only the worst-case scenarios for BIND but fail to show
the corresponding worst-case scenarios for djbdns. To summarize, djbdns
appears (from the sparse documentation) to have two kinds of "forwarding":
a global, recursive form of forwarding specified via "FORWARDONLY", and
then a non-recursive form of forwarding which can be specified on a
zone-by-zone basis by specifying the forwarders in a file with the name of
the zone to be forwarded, somewhere under the "root/servers" part of
djbdns'es configuration tree. Dan claims that djbdns'es selective/iterative
forwarding is easier to configure than BIND's selective forwarding when it
is desired for the cache to follow delegations. This is because Dan
apparently can only conceive of one way to make a BIND server "follow
delegations" within a forwarded hierarchy -- a separate, explicit "type
forward" definition for each zone within the hierarchy. I pointed out to
Dan that other options included a) defining a zone of type "stub" for the
apex of the hierarchy, b) defining a zone of type "slave" for the apex of
the hierarchy, or c) defining the apex as "forward first" rather than the
customary "forward only", which will make named "fail over" from recursive
to iterative resolution where necessary, and thus allow it to find
nameservers for subzones within the hierarchy. Dan pointed out, correctly,
that a) "stub" has a requirement that the NS records in the apex zone match
reality, b) "slave" is relatively inefficient, and c) in some
circumstances, the "forward first" approach might generate undesirable
results. But the fact remains, that in many if not most cases, it is
possible to get the same results as djbdns, vis-a-vis following delegations
under a "forwarded" zone, with a *single* zone definition in BIND, an "ease
of use" which is roughly equivalent between the two packages. Yet the table
does not reflect this. I also pointed out that in the converse case, i.e.
where the admin does *not* want the cache to follow delegations for a
particular forwarded hierarchy, BIND appears to have a clear ease-of-use
advantage, since in this case BIND requires only a single zone definition,
but it appears that djbdns would require explicit forwarding definitions
for every zone in the hierarchy in question. More generally, BIND's
forwarding is based on a single, hierarchy-based paradigm, with a mechanism
for selectively cancelling forwarding for a given (sub-)hierarchy, so it
seems to accommodate a wider range of forwarding/delegation scenarios than
djbdns, which appears to have no way to forward both selectively and
hierarchically, and is therefore more likely to require zone-by-zone
configuration. (Of course, since Dan and/or his documentation never
adequately explain how his recursive/global and his non-recursive/selective
forms of forwarding interact with each other, it's possible that there are
"secret" configuration alternatives in djbdns which can address some of
these shortcomings, but, frankly, if such options exist, I think we would
have heard about them by now).

Now, did I make a fool of myself in that thread? That's obviously a matter
of opinion. Sure, Dan educated me on a few aspects of djbdns configuration
(it would have been nice for these aspects to have been properly documented
in the first place, so that this "education" wasn't necessary, but never
mind that now). He also brought my attention to some of the negative
aspects of using "forward first" in BIND, which I had overlooked. But my
criticisms of his "ease of use" table still stand (at least their main
thrust), and for the most part, go unchallenged, due to Dan's irritating
habit of simply failing to respond to parts of posts he chooses not to deal
with.


- Kevin