So Dan Kaminsky’s attack really isn’t that sophisticated after all. It’s not a birthday attack — per request (on unpatched servers) it still requires throwing 2^15 spoofed packets at the server before the real reply arrives for a reasonable expectation of success. Getting that many packets on target in time is difficult. The weakness is in the way recursive (i.e. caching) name server accepts in-bailiwick glue records thrown at it for any domain that kind-of looks like it belongs. Each potential in-bailiwick name becomes a potential point of attack so there is a very broad front for a mass spoofing session to attack. Each point could alone reliably defend against many packets but with a small chance of failure across a very broad front a storm of packets still leads to a quick failure (about 2^16 points of request and spoofed packets to match).

However, by making a recursive name server instead throw away those in-bailiwick responses and only accept glue when it (subsequently) is actually asking for the A record for an in-bailiwick name-server a mass attack is suddenly collapsed to a single and more easily defended attack.

Of course, it would then be possible for an attacker (in their attempted mass infiltration) to randomly generate the in-bailiwick names for name-servers in their authority sections and so provide the required broad front. Any that succeeded in the first round of spoofing would have to succeed in a further round of spoofing vastly reducing the effectiveness of the attack (by a square). Even that can be defended against by feeling out for name server addresses one domain segment at a time out from the root, and not jumping right away to ask for the NS of the fully qualified name (most names in use are quite shallow anyway). Each zone would be defended against spoofing by a single narrow defile and mass attacks would lose the effectiveness of their strength in numbers.

This would require a bit of coding on the recursive name servers part, and a bit more traffic to the root and first-level domain servers, but the results are cacheable and, as this is the chain of authority upon which DNS rests, it seems reasonable to defend it.

If you were a crook even Dan Kaminsky’s insights weren’t really necessary for a successful DNS attack. After all, crooks didn’t really care who they scammed, so they could cast their spoofed packets widely and still have had a reasonable chance of success. Only one chance in 65536 was reasonable if you don’t care who the victim was and the assault was cheap. This vulnerability isn’t so new in that light — it is just more personal.