It's usually interesting to be proven wrong, but perhaps not in this case. I was among the first to point out that the 11-second DNS poisioning claim made by Vixie only worked out to about a week of concentrated attack after the patch. This was a number I extrapolated purely from Paul's 11-second number and the factor-of-65000x introduced by port randomization. I am very, very, very disheartened to be shown to be wrong. As if 8 days wasn't bad enough, a concentrated attack has been shown to be effective in 10 hours. See http://www.nytimes.com/2008/08/09/technology/09flaw.html With modern data rates being what they are, I believe that this is still a severe operational hazard, and would like to suggest a discussion of further mitigation strategies. On my list of concepts: 1) Use of multiple IP addresses for queries (reduce success rate somewhat) 2) Rate-limiting of query traffic, since I really doubt many sites actually have recursers that need to be able to spike to many times their normal traffic, 3) Forwarding of failed queries (which I believe BIND doesn't currently allow) to a "backup" server (which would seem to be interesting in combination with 2) 4) I wonder if it wouldn't make sense to change the advice for large-scale recursers to run multiple instances of BIND, internally distribute the requests (random pf/ipfw load balancing) to present a version of 1) that would render smaller segments of the user base vulnerable in the event of success. It would represent more memory, more CPU, and more requests, but a smaller victory for attackers. 5) Modify BIND to report mismatch QID's. Not a log report per hit, but some reasonable strategy. Make the default installation instructions include a script to scan for these - often - and mail hostmaster. 6) Have someone explain to me the reasoning behind allowing the corruption of in-cache data, even if the data would otherwise be in-baliwick. I'm not sure I quite get why this has to be. It would seem to me to be safer to discard the data. (Does not eliminate the problem, but would seem to me to reduce it) 7) Have someone explain to me the repeated claims I've seen that djbdns and Nominum's server are not vulnerable to this, and why that is. It would seem that the floor is wide open to a large number of possibilities for mitigating this beyond the patch. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.