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

[Kevin Darcy]

D. J. Bernstein wrote:

> Kevin Darcy writes:
> > Well, to tell the truth I haven't attempted to run BIND 9 chroot'ed
>
> Obviously. Nor did you read the manual. But you were perfectly happy to
> make a fool of yourself.

I just set up BIND 9 to run chroot'ed on my Solaris 8 workstation. It
didn't need any device nodes or library files -- just the config file,
somewhere to write the pid-file, and of course the data directory. A grand
total of 3 directories, not including intermediate directory levels. It's
running fine -- answering queries from authoritative data, resolving
recursive queries iteratively, transferring zones in and out, syslogging
what it is supposed to be syslogging; all the usual stuff one would expect
a DNS implementation to do. I don't know why the documentation says what it
does, i.e. you need /dev/null and library files. Maybe that's for the
benefit of more primitive (*cough*) operating systems than Solaris.

Perhaps *you* should have tried setting up BIND 9 to run chroot'ed before
putting misleading information in your "ease of use" table. I don't know
what operating system you typically use (OpenBSD?); you may find, like I
did, that *very*little* is required in a BIND 9 choot-jail.

> > You specify "forwarders { }" *once* at the apex (e.g. moon.mil)
>
> That doesn't solve the problem. It isn't even close. You are continuing
> to make a fool of yourself.

Okay, I did misunderstand what you were trying to do there. It's true that
if you selectively-forward a domain in BIND, and then want to "unforward" a
delegated subdomain, that requires two zone definitions. That's because of
the hierarchical nature of BIND's forwarding model.

But, I have to ask, how would one configure djbdns to do the converse, i.e.
*ignore* the delegations, in this situation? Explicitly define forwarding
for d.moon.x.mil? What about even deeper levels of delegation, e.g.
foo.bar.d.moon.x.mil? Explicitly define forwarding for *all* delegation
levels? Ick. If one uses forwarding -- and personally I'm not a big fan of
forwarding -- the hierarchical nature of BIND's forwarding model can be a
boon for this kind of thing. It's only at the "edge case", i.e. right at
the boundary of a forwarded hierarchy and a sub-hierarchy that is
not-to-be-forwarded, that BIND's configuration appears excessive. As usual,
you have taken the worst case for BIND and presented it as a "normal" case,
while conveniently not showing the relative ugliness of djbdns'es
configuration in an equally-likely scenario where BIND apparently has the
advantage.

BTW, how does "global" forwarding in djbdns (i.e. FORWARDONLY) interact
with the selective "/root/servers" style of forwarding? Does the selective
forwarding "cancel" the global forwarding from that point down, so that
delegations are followed for all descendant zones? If so, what if that's
not what the admin wants? Or, does the selective forwarding only apply to
that specific name, and if you want to override the global forwarding for
descendant zones, you have to selectively forward for *all* of them? Ick.
Seems like the non-hierarchical nature of djbdns'es selective forwarding
could often necessitate tons of explicit forwarding configuration.
BIND handles this fairly elegantly: once global forwarding is in effect
(i.e. specified in the "options" statement), you can cancel forwarding for
an entire hierarchy by defining a zone at the apex (which could be
something lightweight like a "type stub" zone), and specifying "forwarders
{ }" in it. This is the scenario, i.e. global-versus-selective forwarding,
I originally thought you were getting at in your example. For balance,
something along these lines should probably be included in your "ease of
use" table, since I suspect djbdns doesn't handle this as well as
BIND does.

I acknowledge that djbdns'es "/root/servers" mechanism may not be
completely analogous to BIND's forwarding, since the former is
non-recursive (right?), whereas BIND's forwarding is always recursive,
whether it's selective or global. Admittedly, BIND offers no elegant way
for an admin to simply "hardwire" named to use a particular nameserver or
set of nameservers non-recursively for a particular name or zone. The
closest analog would be defining a "stub" zone, but that's a little
different because it involves periodic replication, albeit far more
lightweight than slaving. So we're basically comparing apples to oranges
here anyway. Obviously an admin will *want* their forwarding to be
recursive if they have no direct connectivity to the published nameservers
for various zones in a particular hierarchy. On the other hand, recursive
forwarding tends to not scale well. It needs to be left up to the
administrator which form of forwarding to choose in a particular situation.
As far as I can tell, djbdns only offers recursive forwarding at the root;
anything below that, and one is restricted to non-recursive
"forwarding" via explicit configuration.

> > Or look at how ridiculously convoluted it is to set up AXFR-based
> > replication on the same box as dnscache or tinydns, where that program
> > is configured to deal with TCP retransmissions (I'm still not sure
> > whether this is even *possible*, given your AXFR server's apparent
> > reliance on having unfettered access to TCP port 53).
>
> The simple procedure in http://cr.yp.to/djbdns/frombind.html takes care
> of everything. The convolutions, configurations, and impossibilities are
> figments of your imagination. You are again making a fool of yourself.

So, let me get this straight: axfrdns (your AXFR server) can, with the
right (non-default) configuration, answer regular, non-AXFR queries on the
TCP port (?) So you have to configure and run two daemons (tinnydns and
axfrdns)? Why don't you show *that* in your "ease of use" table? Of course,
this is *automatic* in BIND. Or, perhaps I should say, in your phrasing,
"Relax: named automatically listens on the TCP port". Sounds pretty
patronizing, doesn't it?

Not to mention, those two daemons are obviously sharing some of the same
algorithms in order to be able to access the (proprietary-looking) backend
database and serve up queries from it. So you're basically running
duplicate copies of some of the code. This is wasteful.

Yes, I know you think TCP is an optional part of the DNS protocol, but
I doubt many protocol-knowledgeable people agree with that position. While
it may be a bad idea, operationally, to create huge datasets that require
TCP retransmission, this *will* happen and implementations -- both
nameservers and resolvers -- are expected to deal with that contingency
without the administrator having to jump through hoops to enable it.

> > How difficult is it to make the opposite choice with djbdns, i.e. run
> > an auth-server and a cache on the same box?
>
> The procedures shown in http://cr.yp.to/djbdns/blurb/easeofuse.html work
> exactly as shown. The number of machines is irrelevant.
>
> If you're asking why the programs and IP addresses are separate: This
> prevents incoming data from interfering with outgoing data. Perhaps you
> were unaware that the ``DNS and BIND'' book tells you to do this, in the
> ``Securing Your Name Server'' section.

That's a *recommendation*, but it's not always feasible in a given
organization, because of economic or logistical constraints. Administrators
should have the *choice* of mixing these functions if they wish. Choice is
a good thing. Isn't that a principle upon which djbdns actually *depends*,
i.e. offering a choice other than BIND, which has been and continues to be
the_de_facto_ standard?

> > > > only 2 main executables
> > > So what? Is that supposed to help the system administrator?
> > It most certainly *does* help when you're trying to integrate a DNS
> > package into a standardized server load image.
>
> What kind of copying mechanism would require manual work for every file?
> Ridiculous.

I'm not talking about a mere "copying mechanism", I'm talking about
building a server image. You know, vendors keep coming out with new
releases of their OSes and to keep current, you need a "gold" server image
for each new release from which to install new servers. The more little
bits and pieces you have to muck with, the harder that task is. Actually,
the difficulty of the task probably varies more with the number of
different directories, on different filesystems, that the package requires.
In our latest Solaris server image, BIND has its binaries in one spot
(/usr/sbin), its config files and pid-file in another (/etc) and its data
files in a third (in a part of the filesystem which is Chrysler-specific;
I don't care to disclose the details of our filesystem structure
publically). djbdns looks like it's all over the place (possibly that
appearance is just the effect of the directories you have chosen for your
examples, but I doubt it).

> Next you'll be telling us that the smooth cooperation between inetd and
> bootpd is ``patchwork,'' and that your UNIX distributor has causedendless
> problems for you by not combining those two programs.

Modularity has its place. If you want the freedom to mix your OS-provided
services with services from a third-party vendor (e.g. the vendor of a
commercial POP3 or IMAP server), or OS-provided services with
open-source-based services, then you don't want everything comingled in one
monolithic executable. 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. It is generally assumed
that a particular network subsystem will be handled by software from a
single package. inetd is somewhat of a special case because it provides a
particular service for *multiple* subsystems. Therefore it needs to be
"package-independent" and the only reasonable way to achieve this is to
make it a separate program.


- Kevin