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

D. J. Bernstein 75628121832146-bind at sublist.cr.yp.to
Sun Jul 29 05:42:01 UTC 2001


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.

> 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.

> 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.

> 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.

> 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.

The documentation also answers your remaining questions. RTFM.

---Dan


More information about the bind-users mailing list