The flaws that make djbdns’s cache vulnerable appear to be the lack of SOA caching, ability to queue multiple (read 200+) identical requests, and the dropping of older queries when the buffer is full and a new request is received. If any one of these flaws was fixed then djbdns would be no more vulnerable than the other offerings (i.e. 1 in 4 billion chance of cache poisoning).

Some fixes would be more effective than others obviously. Refusing to drop old requests when the maximum number was reached could cause various Denial of Service issues (users can no longer request resolution, or the server could be overloaded with thousands of requests). Caching the SOA seems to make sense, but as you said this is only an accelerant. With the other flaws left unpatched the server would never receive a valid response (the older queries would drop off the queue and the response from the nameserver would be ignored). SOA caching coupled with prevention of multiple identical requests seems to make sense from my standpoint (not a DNS expert by any means). Although what process is used to match the new request could be another issue altogether. I’d like to see what overhead Kevin’s unofficial patch for this puts on the server under load.

I’d appreciate your opinions if I’m seeing something wrong here. As I said, I’m no DNS expert , I just hack stuff.