D. J. Bernstein
Internet publication
djbdns
Blurbs
Security
Security features:
- dnscache runs as a dedicated non-root uid inside a chroot jail,
so it can't touch the rest of the machine.
- tinydns runs as another dedicated non-root uid inside its own chroot jail.
- walldns runs as another dedicated non-root uid inside its own chroot jail.
- dnscache discards
DNS queries from outside a specified list of IP addresses.
- dnscache and the dns library
use a new query ID and a new UDP port for each query packet.
They discard DNS responses from any IP address
other than the one that the corresponding query was just sent to.
- dnscache uses a cryptographic generator
to select unpredictable port numbers and IDs.
- dnscache is immune to cache poisoning.
- tinydns and walldns
never cache information.
They do not support recursion.
Security metafeatures:
- Security was, and is, one of the primary motivations
for the development of djbdns.
Every step of the design and implementation
has been carefully evaluated from a security perspective.
- The djbdns package has been structured
to minimize the complexity of security-critical code.
The package is modularized for easy review.
- Bug-prone coding practices and libraries
have been systematically identified and rejected.
There is a
$500 reward
for the first person to publish a security hole in djbdns.
Code complexity
The djbdns code is small, with under 7000 instructions.
In contrast, BIND 9 has nearly 100000 (not 10000) instructions.
Why is BIND so much larger than djbdns?
There are several big reasons:
- djbdns uses easy-to-parse configuration file formats.
BIND uses hard-to-parse configuration file formats.
This is not an accident:
the BIND company likes the fact that its complicated, unstable formats
are difficult for competitors to handle reliably.
In contrast, I'm doing my best to cooperate with external tools.
- djbdns relies on external tools to manage files:
for example, rsync provides immediate compressed incremental replication.
BIND reinvents the wheel:
the BIND company developed DNS-specific mechanisms, NOTIFY and IXFR,
for (almost) immediate incremental replication.
This isn't an accident either.
- djbdns relies on external tools,
such as ssh and IPSEC,
to protect local communications against forgery.
BIND again reinvents the wheel:
the BIND company developed a DNS-specific anti-forgery mechanism, TSIG.
- BIND supports DNSSEC.
The BIND company would like you to believe that DNSSEC prevents forgeries;
in fact, DNSSEC does not prevent forgeries.
(DNSSEC was disabled in the latest BIND release in March 2003;
did anyone notice?)
- djbdns has much better internal data structures than BIND.
For example, if you're an experienced programmer,
you'll find it amusing to compare djbdns's cache.c
to the sophomoric tree structures in the BIND code.
The BIND company keeps claiming that BIND 9 is ``auditable''
but never claims to have actually audited it.
``History has shown that most large projects have bugs, and that some of
these bugs will be security related or otherwise critical,''
Paul Vixie says.
``ISC lacks the hubris needed to announce that there will never be
another security-related or otherwise critical bug in BIND.''