Re: djbdns (was: negative vote for maintainer Michael Gilbert)
debian-newmaint really isn't the place for this discussion, so I'll copy
the bug and will send further discussion directly there. I'm not
subscribed to the bug, so please copy me if you want me to see replies.
Sergiusz Pawlowicz <email@example.com> writes:
> As dnscache in Debian package is not configured to be run out of the
> box, security team effectively prohibits the community from using
> absolutely free, safe and efficient software, as there is no exploits
> available when you configure it on the loopback interface or for hosts
> you trust, e.g. for your cloud of services.
Well, there aren't *no* exploits; there's still the standard DNS cache
poisoning attacks by brute-force port guessing after inducing queries that
are inherent in non-DNSSEC and present in every server, and which can be
done (with more difficulty) even if you can't query the server directly if
you can induce a trusted service to do DNS queries. But that isn't a
The remaining statement on this bug from the security team is:
| djbdns should not be part of squeeze until it is properly hardened
| against cache poisoning. It is between 100 and 200 times easier than
| with other DNS servers.
I don't understand the basis of that comment just from the bug log. The
djbdns-specific attack I'm aware of is on SOA, but the bug discussion
indicates that protecting against SOA isn't sufficient and any cache miss
will do. So apparently there's some hardening other than UDP port
randomization (which djbdns has done for eons) that needs to be done here
from the security team perspective? It looks like the hardening that they
want to implement is duplicate query merging?
So far as I understand the additional protection provided by duplicate
query merging, the attack that protects against practically requires
direct access to the caching resolver, so listening only on localhost (or
the equivalent) would make dnscache equivalently secure to any other DNS
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>