Yet another misleading DJB rant

[Jim Reid]

>>>>> "djb" == D J Bernstein <75628121832146-bind at sublist.cr.yp.to> writes:

    djb> For example, according to recent discussions here, BIND
    djb> becomes more susceptible to packet forgery if /dev/random
    djb> isn't in the chroot area.  Copying /dev/random is an extra
    djb> step for the sysadmin.

Coming from you, that's very ironic. And it's misleading. The "packet
forgery" you refer to applies to verifying and signing DNS data with
DNSSEC. In fact the name server only needs /dev/random to do on-line
signing with Secure Dynamic Update. As my BIND company colleague,
Brian Wellington, explained earlier, there's no need for /dev/random
in a chroot jail for BIND if Secure Dynamic Update isn't used.

The reason for the irony is that your DNS software doesn't support
DNSSEC or Secure Dynamic Update at all. That means it has no way of
validating DNSSEC- or even TSIG-cryptographically signed DNS
answers. Or generating them. If DNS packets are signed, forging them
becomes almost impossible. So what, please, does djbdns do to make
itself not susceptible to packet forgery? Does your (subjective,
selective and far from impartial) table of contrasts have an entry
like:

					djbdns	BIND
     Vulnerable to forged DNS packets	  Yes	 No

Does it have entries for all the DNS protocols and record types your
software doesn't support? If not, why not?

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

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

Duplicate code is duplicate code -- if that's what tdlookup.o is (I
don't care) -- no matter how big or small it is.