On Tuesday July 8, CERT/CC published advisory #800113 referring to a DNS cache poisoning vulnerability discovered by Dan Kaminsky that will be fully disclosed on August 7 at the Black Hat conference. While the long term fix for this attack and all attacks like it is Secure DNS, we know we can't get the root zone signed, or the .COM zone signed, or the registrar / registry system to carry zone keys, soon enough. So, as a temporary workaround, the affected vendors are recommending that Dan Bernstein's UDP port randomization technique be universally deployed.
Reactions have been mixed, but overall, negative. As the coordinator of the combined vendor response, I've heard plenty of complaints, and I've watched as Dan Kaminsky has been called an idiot for how he managed the disclosure. Let me try to respond a little here, without verging into taking any of this personally.
Q: "This is the same attack as <X> described way back in <Y>."
A: No, it's not.
Q: "You're just fear-mongering, we already knew DNS was terribly insecure."
A: Everything we thought we knew was wrong.
Q: "I think Dan's new attack is <Z>."
A: If you guess right, you can control the schedule, is that what you want?
Q: "I think Dan should have just come right out and described the attack."
A: Do you mind if we patch the important parts of the infrastructure first?
Q: "Why wasn't I brought into the loop?"
A: Management of trusted communications is hard. No offense was intended.
Now for a news bulletin: Tom Cross of ISS-XForce correctly pointed out that if your recursive nameserver is behind most forms of NAT/PAT device, the patch won't do you any good since your port numbers will be rewritten on the way out, often using some pretty nonrandom looking substitute port numbers. Dan and I are working with CERT/CC on a derivative vulnerability announcement since it appears that most of the NAT/PAT industry does indeed have this problem. The obvious workaround is, move your recursive DNS to be outside your NAT/PAT perimeter, or enable your NAT/PAT device to be an ALG, or use TSIG-secured DNS forwarding when passing through your perimeter.
Please do the following. First, take the advisory seriously — we're not just a bunch of n00b alarmists, if we tell you your DNS house is on fire, and we hand you a fire hose, take it. Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model — deploy it locally and push on your vendors for the tools and services you need. Third, stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching.
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
Afilias - Mobile & Web Services