What was already known, and what was not

Cache poisoning was not a new idea in 2008. Everyone who worked on DNS (Domain Name System) understood the shape of it: a resolver asks an authoritative server a question and accepts the first answer that matches, and matching meant one thing - a sixteen-bit transaction identifier, sixty-five thousand five hundred and thirty-six possibilities. An attacker who could guess it and reply faster than the real server won. Papers had been written about it. It was regarded as difficult, slow, and largely theoretical.

Two things made it worse than the arithmetic suggested and nobody had put them together. Many implementations sent their queries from a fixed source port, so the only unknown really was the transaction identifier. And a failed attempt was expensive: guess wrong, the real answer arrives, the record is cached, and the attacker must wait for the time-to-live to expire before trying again - possibly a day.

, then director of penetration testing at IOActive, found the way around the waiting.

The trick

Instead of attacking www.example.com, ask the resolver for aaaa1.example.com - a name that does not exist and therefore cannot be in the cache. The resolver has no choice but to go and ask. Now race it. And crucially, put in the forged reply not just an answer for that meaningless name, but a delegation: authority records naming the attacker's server as the nameserver for the whole domain, with the glue records to reach it.

Lose the race and it costs nothing, because the name was junk. Try again immediately with aaaa2, aaaa3, as fast as the link allows. Win once and the resolver caches not one record but the attacker's server as the authority for the entire zone - every name under it, for as long as the delegation lives.

That is the whole discovery, and it converts a slow, chancy attack into one that succeeds in seconds. Everything the internet does rests on names resolving correctly: web traffic, mail routing, software updates, and the password reset email that authenticates most accounts. Kaminsky took it to , whose reported assessment was that everything in the digital universe was going to have to get patched.

8 July 2008

What happened next had no precedent. Kaminsky went to the Department of Homeland Security and to executives at Cisco and Microsoft. A secret meeting was convened. Vendors who competed with each other, and whose implementations shared nothing but the protocol, were briefed on a flaw none of them could fix alone - because a patched resolver talking to unpatched infrastructure is still exposed, and the whole point of DNS is that everyone's resolvers talk to everyone's servers.

On 8 July 2008 more than eighty vendors released patches simultaneously. The advisory carried -2008-1447 and CERT vulnerability note VU#800113. The Internet Systems Consortium's own bulletin for listed every affected version - which was, effectively, all of them - and said something worth quoting for its bluntness: is the only full solution, and the new versions provide increased resilience to the attack.

Resilience, not immunity. That word choice is the honest part of the whole episode.

What the fix actually bought

The patch was source port randomisation. Instead of asking from a predictable port, a resolver picks a random one for each query, and the attacker must now guess both the transaction identifier and the port - roughly thirty-two bits instead of sixteen. That does not make forgery impossible. It makes it about sixty-five thousand times harder, which converts an attack that takes seconds into one that takes long enough to notice.

This is worth being precise about, because it is a pattern practitioners meet constantly and often misread. The fix did not repair the protocol. DNS still authenticates a response by whether its fields match a question, which is not authentication in any cryptographic sense. What the fix did was raise the cost. The actual repair is DNSSEC, which signs the records so that a forged answer fails validation regardless of how well it guesses - and DNSSEC's adoption remains partial nearly two decades later, which is why the DNSSEC article on this site describes checking rather than assuming.

The embargo, and the thing embargoes cannot solve

The plan was that the patch would ship on 8 July and Kaminsky would explain the mechanism at on 7 August, giving the internet a month to update before anyone knew what they were updating against. The talk happened; the room was full to the floor.

But the month did not stay quiet, and the reason is structural rather than anyone's fault. A patch is a description of the vulnerability. Anyone competent can compare the new code with the old and work backwards to what it prevents. The Conficker retrospective makes the same point from Microsoft's side, and the Juniper backdoor is its sharpest illustration - researchers extracted the hardcoded password within six hours of the patch being public. An embargo protects the interval before the fix exists. Once the fix ships, the clock the defender is racing is set by whoever reads diffs fastest.

What a practitioner should take from it

Randomisation is a cost, not a boundary. Any control described in bits of entropy is buying time. That is often the right trade and it should be understood as one, especially when the number of bits was chosen decades ago for a network of a different size.

The resolver you run is the one that matters. The flaw was in resolvers, not authoritative servers, and the exposure belonged to whoever operated the recursive service - which is why the choosing a public resolver question is a security question and not just a latency one.

Coordination at that scale is possible and is rare. Eighty vendors patching one protocol flaw on one day happened because someone spent months organising it in private, and because the alternative was visibly catastrophic. It is the model the industry cites, and it has not often been repeated at that scale.

And the person mattered. Kaminsky found it, chose to coordinate rather than publish, and spent the years afterwards on the fix rather than the finding - named him one of the trusted community representatives for the DNSSEC root in 2010. He died in April 2021, aged forty-two. The New York Times had called him a digital Paul Revere, which is florid and, on the record of that summer, not wrong.

Sources