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