The big DNS security hole for early 2012 is the "ghost domain" attack (PDF file). It has hit every single major recursive DNS server out there: BIND, Unbound, PowerDNS, Deadwood (while the ghost domain paper correctly points out that Deadwood's recursion is immune to this particular attack, Deadwood was vulnerable to a related attack: allowing a really long TTL), and, yes djbdns.
BIND has been patched to fix this issue. Unbound fixed this issue a while ago; the CVE simply informs users to make sure their copy of Unbound is up to date. I updated Deadwood back in February and made new MaraDNS releases with the updated Deadwood this week.
This leaves two DNS servers without this issue fixed.
I am surprised that PowerDNS has not fixed this issue yet; they appear to have an active development community so hopefully a fix is in the pipeline.
DjbDNS, not surprisingly, has no update for this issue. I don't see any updates to fix this issue from the unofficial forks; Zinq-djbdns, for example, hasn't been updated for nearly a year.
There is no traffic on the mailing list about this issue. Indeed, there hasn't been a single posting to this mailing list this month and none of the postings last month discussed this security hole.
The last active discussion on the djbdns mailing list was people whining about how www.nature.com takes 30 seconds to resolve with dnscache.
Let me give the five people still using dnscache a hint: It is not Akamai's problem that www.nature.com takes 30 seconds to resolve with DjbDNS' dnscache. It is dnscache's problem.
Deadwood 3.2.02 is able to, with an empty cache, resolve www.nature.com within 2 seconds. With an active cache, it can resolve it in under a second.
I have not investigated exactly why it is www.nature.com takes so long to resolve with dnscache. My guess is that it is similar to the EasyDNS tarpit issue Deadwood had.
The only way to take responsibility is to have someone step up and say "I will make sure that bugs in djbdns get fixed". DJB stopped doing this well over a decade ago.
It was not feasible for someone else to take responsibility for the program for many years because of DjbDNS' old license. When it finally became legal to make DjbDNS forks, it was too little, too late. There is no longer an active community of developers contributing improvements to DjbDNS' in a cohesive, organized manner. There is no one in the DjbDNS community that you can point to and say "DjbDNS is vulnerable to security bug CVE-2012-1191. You are responsible for making sure this issue gets fixed."
Because there is no one left responsible for DjbDNS' bugs, the community handles bugs in an immature, unprofessional manner. They either blame someone else for DjbDNS' bugs (such as blaming Akamai), or they come up with convoluted justifications about why a bug isn't really a bug, or they simply ignore the bug altogether.
Blaming Akamai for not resolving a domain quickly isn't going to make the offending domain resolve any more quickly. Ignoring a security bug isn't going to magically make the security problem go away.
For DjbDNS to remain viable, someone needs to step up to plate to take responsibility for its bugs.
See also: DjbDNS: False security is dangerous
To post a comment about an entry, send me an email and I may or may not post your comment (with or without editing)