bind vs djbdns

[D. J. Bernstein]

David R. Conrad writes:
> much easier to type ./configure;make and have a self-contained binary

You just have to type make if you want to compile djbdns.

Here's the complete portable procedure to compile and install djbdns and
run a local cache, once your system has daemontools running: download
dnscache-1.00.tar.gz, create dnscache and dnslog accounts, and type

   gunzip < dnscache-1.00.tar.gz | tar -xf -
   cd dnscache-1.00
   make setup
   ./dnscache-conf dnscache dnslog /etc/dnscache
   ln -s /etc/dnscache /service

That's it. Now, David, could you please explain the complete portable
procedure to compile and install the latest version of BIND and run a
local cache? Don't forget the localhost/127.0.0.1 zones.

> - full (incoming and outgoing) AXFR?

Yes, djbdns can transfer arbitrary zones in or out through AXFR.

The same is not true for BIND, because BIND chokes when it receives
unrecognized record types.

The standards clearly state that the type space is extensible. New types
are added all the time. BIND is blatantly violating the principles
discussed in RFC 1123, Requirements for Internet Hosts, section 6.1.3.5:

   A name server may acquire, via zone transfer, RRs that the server
   doesn't know how to convert to printable format. A resolver can
   receive similar information as the result of queries. For proper
   operation, this data must be preserved, and hence the implication is
   that DNS software cannot use textual formats for internal storage.

Seems pretty damn clear to me. Have you read this text in the eleven
years since it was written?

As I said before, it's funny how you keep talking about standards
compliance when you can't even get the basics right.

> you can't be
> bothered to implement the parts of specifications you don't agree with,
> regardless of the impact on interoperability.

As you can see from http://cr.yp.to/djbdns/notes.html, I think DNS is a
horrible design, but I implemented it anyway. I wanted a reliable DNS
implementation that wouldn't let attackers into my machine; BIND didn't
qualify and probably never will, so I wrote my own.

> A PIII-450 running stock BIND (v8.2.2p5) was happily responding to
> 2500 queries per second sustained, about 5000 queries per second peak.

The same load should work with tinydns too. 500 is simply the largest
report I've heard so far from servers handling user data. It's higher
than the per-CPU load of f.root-servers.net.

Brief answers to your other questions: DNS over TCP, IXFR, NOTIFY, and
BIND's pathetic anti-forgery mechanisms have already been discussed. For
dynamic updates, RTFM. There's no problem handling A6 et al. in the
cache and server; I'm going to wait until the standards settle down
before I add IPv6 interfaces to the client library. Your question about
NT makes no sense.

---Dan