This leaves two DNS servers without this issue fixed.
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.
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.
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)