Note that djbdns wasn't vulnerable to the attack, because it was designed from the outset to exploit other sources of randomness. (I'm a little rusty here, but) The countermeasures djbdns employed against the attack were known all the way back when djbdns was started, and proposed on mailing lists before it. But BIND didn't employ them, because (I think, but could be wrong) that the BIND architects believed DNSSEC would be the operationally "correct" solution.
I trust djbdns more than perhaps any other piece of C code I run, and recommend it.
The last released djbdns is vulnerable to simple poisoning attacks however.
It does not merge duplicate queries, permitting infinite retries of spoofing
(just like Kaminsky's child label-NS replacement technique).
This failure undoes much of the benefits of source port
randomization. A patch is available from a third party, but it is not
part of the standard source tree.
http://www.your.org/dnscache/
There are also attack scripts for djbdns.
BIND, Unbound and other recursives have both SPR and duplicate
query control. This fact explains things like this:
http://dnsreactions.tumblr.com/search/djbdns
From a poisoning point of view, BIND and Unbound are more secure
than djbdns. To be fair djbdns is no longer maintained, so this poisoning
fix has not been integrated).
Security is relative. From a software coding point of view,
djbdns is smaller, has fewer features (e.g., ipv6 and dnssec lacking).
I.e., there might be coding errors in large code bases.
But for me, an unmaintained code base with known, unpatched
attacks is not a good choice.
Comments
Note that djbdns wasn't vulnerable to the attack, because it was designed from the outset to exploit other sources of randomness. (I'm a little rusty here, but) The countermeasures djbdns employed against the attack were known all the way back when djbdns was started, and proposed on mailing lists before it. But BIND didn't employ them, because (I think, but could be wrong) that the BIND architects believed DNSSEC would be the operationally "correct" solution.
I trust djbdns more than perhaps any other piece of C code I run, and recommend it.
The last released djbdns is vulnerable to simple poisoning attacks however. It does not merge duplicate queries, permitting infinite retries of spoofing (just like Kaminsky's child label-NS replacement technique).
This failure undoes much of the benefits of source port randomization. A patch is available from a third party, but it is not part of the standard source tree.
There are also attack scripts for djbdns.BIND, Unbound and other recursives have both SPR and duplicate query control. This fact explains things like this:
From a poisoning point of view, BIND and Unbound are more secure than djbdns. To be fair djbdns is no longer maintained, so this poisoning fix has not been integrated).Security is relative. From a software coding point of view, djbdns is smaller, has fewer features (e.g., ipv6 and dnssec lacking). I.e., there might be coding errors in large code bases.
But for me, an unmaintained code base with known, unpatched attacks is not a good choice.