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

[Kevin Darcy]

D. J. Bernstein wrote:

> Kevin Darcy writes:
> > Perhaps *you* should have tried setting up BIND 9 to run chroot'ed
> > before putting misleading information in your "ease of use" table.
>
> The BIND 9 documentation says ``Depending on your operating system, you
> may need to set up things like /dev/zero, /dev/random, /dev/log, and/or
> /etc/localtime.''
>
> For example, according to recent discussions here, BIND becomes more
> susceptible to packet forgery if /dev/random isn't in the chroot area.
> Copying /dev/random is an extra step for the sysadmin.
>
> My summary is ``Copy various system-dependent files, which are not
> thoroughly described in the BIND manual.'' You are being unreasonable
> when you demand that this step be omitted from the list.

Okay, here's *my* summary of the BIND step: "Your OS may require certain
files and/or device nodes to be set up in the chroot jail, primarily for
purposes of logging to syslog. Also, if you are using DNSSEC, you may need
/dev/random in the chroot jail to serve as a high quality source of
randomness. On certain OS'es, and when you are not using DNSSEC, you may
need nothing in the chroot jail at all besides the config file and of
course the zone files themselves".

Additionally, I'd add a corresponding step to the djbdns side: "Since
djbdns doesn't use your OS'es native syslog for logging, you don't have to
add anything to the chroot jail to support syslog. However, in its place
you have to build/install/configure "multilog" instead, see <a
href=http://cr.yp.to/daemontools/multilog.html>here</a> for more
information.".

That would be a reasonable, balanced amendment, I think.

> > But, I have to ask, how would one configure djbdns to do the converse,
> > i.e.  *ignore* the delegations, in this situation?
>
> Do you understand what a delegation means? The server doesn't have the
> answer. It is telling you to ask another server about that domain.

Um, Dan, what you described is a *referral*, not a "delegation". Referrals
*contain* delegation records, but referrals are *not* delegations, any more
than talking about George W. Bush is the same as *being* George W. Bush
(perish the thought!). It's a somewhat subtle semantic distinction,
admittedly, but an important one.

You seem confused by my question, so I'll try to ask it a different way:

If I have my dnscache "hardwired" to ask a particular set of servers about
the example.com zone, through the "root/servers" mechanism, and I also want
to hardwire my dnscache to use that same set of servers for foo.example.com
and all subzones thereof, *even*though*the*delegations*point*elsewhere*,
can I do this with a *single* configuration step, or do I need to do it for
every subzone in the whole hierarchy?

The bottom line is that BIND defaults to forwarding whole hierarchies and
djbdns defaults, apparently, to forwarding only the apex zone of any given
hierarchy (that's what I gather from your "automatically follows
delegations" claim). So djbdns has the ease-of-use advantage in "forwarding
boundary" situations where you have a parent zone that is forwarded and a
child zone which is not -- that requires only one definition in djbdns, two
definitions in BIND. But BIND has the advantage, apparently, when a whole
namespace hierarchy needs to be forwarded, ignoring the delegations
therein. In that case, BIND requires only one definition, and djbdns
apparently requires as many definitions as there are subzones in the
hierarchy. I think your "ease of use" table is slanted in this respect
because it chooses a worst case for BIND and doesn't show the converse
worst case for djbdns. Why don't you show a side-by-side comparison with a
forwarded hierarchy containing five levels of subzones or more? Perchance
because it would make djbdns look pretty bad compared to BIND?

> > As usual, you have taken the worst case for BIND and presented it as a
> > "normal" case,
>
> It's exactly the case discussed for _pages_ in the DNS-and-BIND book.

Which only goes to prove my point. Worst-case scenarios usually require
*more* documentation, not less. It is quite common for an admin to want to
forward for a whole hierarchy, ignoring delegations. Since this is easy to
do in BIND, the _DNS_and_BIND_ book doesn't need to spend as much time
explaining it. Things that are more difficult, such as *preventing* BIND
from forwarding at some particular branch under a forwarded namespace, get
more page space in the documentation because they are harder/trickier to
do.

A good question would be: which package, BIND or djbdns, optimizes best in
this respect for the most *common* case? I'm not sure -- as I mentioned
earlier, I don't like forwarding very much, so I use it extremely
sparingly, and only when absolutely necessary. So I don't have a good basis
for comparison.

> > So you're basically running duplicate copies of some of the code. This
> > is wasteful.

> tdlookup.o on this machine is exactly 3456 bytes. Get a grip.

Well, unsurprisingly, it's about 10 times that size on my SPARC box. And
let's not forget all of the functions that are linked from the tdlookup
module (such as all those response_*() functions) which probably wouldn't
be necessary if axfrdns wasn't being called upon to handle ordinary lookups
as well as zone transfers. If I had the time, I'd hack the
non-AXFR-query-processing code out of axfrdns and see how much the
*total* savings would be. The difference might surprise you.

My point is, though, whether it's 3Kb or 3Mb, waste is waste. Because of
your design decision to split the AXFR server from the main authoritative
server, you have to put lookup code into axfrdns so that people can run
axfrdns alongside tinydns on the same address. This lookup code in axfrdns
duplicates what's already in tinydns. Now, maybe if you had a way to put
the code which was shared by the two programs into a shared object,
dynamically-linked from both tinydns and axfrdns, I wouldn't be griping so
much. But that would complicate the build and installation process,
wouldn't it? Overall, I don't think it would be a net win in terms of
ease-of-use. You're in a no-win situation because of your fundamental
design decision. rsync and ssh are nifty tools for replicating files, but
in the process of accommodating (nay promoting) their use, apparently you
have sacrificed some elegance/efficiences that you could have otherwise
realized, for folks who want to use plain old AXFR for replicating their
zone data -- they have to configure and run a separate program, which
partially duplicates tinydns code. Your personal bias against AXFR is
reflected in the design of your package. What a shame for folks who find
AXFR quite usable, or might actually prefer it (gasp!). Apparently they
don't matter....

> > But am I *ever* going to want to run an authoritative nameserver from
> > one package, an AXFR server from another package, and a DNS cache from
> > yet another package? I don't think so. Nowhere on your website do I
> > recall seeing any instructions for configuring djbdns to run
> > *alongside* BIND on the same box.
>
> In fact, the first step of the standard upgrade procedure is to switch
> to dnscache on one address, while BIND continues to publish data on
> another address. See http://cr.yp.to/djbdns/frombind.html.

Yes, as a step in the migration from BIND to djbdns, at one point you do
explain how you can run them both in parallel. But as you recall, this
particular sub-thread concerns the relative ease of
installing/maintaining/cloning a "patchwork" DNS package like djbdns versus
a "monolithic" one like BIND. I can't imagine anyone who cares about the
ease of installing/maintaining/cloning their DNS setup running with *both*
packages simultaneously, except possibly as a temporary migration step. If
they do, they're insane.

> The documentation also answers your remaining questions. RTFM.

I have RTFM'ed, but the FM hasn't been of any help.

My only relevant remaining questions were:

1) Does the "root/servers" selective forwarding mechanism (or whatever you
want to call it) generate recursive or iterative queries? faq/cache.html
basically just says "enter the IP addresses of the servers you want to be
consulted into the relevant root/servers file". The pertinent "cell" in the
blurb/easeofuse.html table says the same thing, even more
tersely/cryptically. Neither of them mention whether the
"forwarded" queries are recursive or not. I'm _assuming_ they are
non-recursive, since otherwise all of the talk of following delegations
doesn't quite make sense. But this is not clearly spelled out in the
documentation, so I asked.

2) How does the FORWARDONLY mechanism in djbdns interact with the
"root/servers" selective forwarding mechanism? Again, the FM isn't very
helpful here. The description of FORWARDONLY in
faq/cache.html says it makes dnscache "send recursive queries to the
external cache
for any information it doesn't have" and that same doc says that dnscache
"will contact the internal servers for information about moon.af.mil and
10.in-addr.arpa" if those zones are configured under "root/servers", plus
it will follow delegations from those zones. But what if
*both* FORWARDONLY and "root/servers" are defined? Which takes priority
when a queried name, e.g. foo.moon.af.mil doesn't happen to be dnscache's
cache? The documentation is silent with respect to the *interaction* of
these features -- it describes them only separately. With BIND, it is
clearly spelled out that per-domain forwarding overrides global forwarding.
In fact, conceptually it is quite elegant -- if you think of global
forwarding as equivalent to defining the root zone as a "type
forward" zone, then there really is only *one* forwarding mechanism in
BIND, with forwarding at lower levels of the hierarchy overriding
forwarding at higher levels. In contrast, FORWARDONLY in djbdns seems like
an afterthought bolted onto the package after the fact.

One would have to grovel through the code to get the answers to these
questions. I decline to do so. Such laborious methods of ascertaining
answers to basic configuration questions should not be necessary with a
package which makes extravagant claims about its "ease of use".

(To everyone: yes, I know this thread is now starting to drift from
strictly "ease of use" issues to quality-of-documentation issues, but my
opinion is that inadequacy of documentation is a factor in "ease of use",
since it's hard to configure a DNS package if you can't easily find out
*how* to configure it. Besides, Dan started the drift by telling me to
RTFM... :-)


- Kevin