The Domain Name System turns havenmessenger.com into a numeric address your computer can actually route to. To make this fast, recursive resolvers — the DNS servers run by your ISP, your company, or a public provider — cache the answers they fetch. Ask for a popular domain and you usually get a cached reply in milliseconds, no round trip to the authoritative servers required.
That cache is the prize. If an attacker can insert a forged record into a resolver's cache, they don't have to compromise the website, the certificate authority, or your device. They just have to convince one server that the wrong IP is the right one. Until that record's time-to-live runs out, every user of that resolver who asks for the poisoned name is steered to the attacker's machine.
Why the Original Design Was Forgeable
Classic DNS rides on UDP. A resolver sends a query and waits for a UDP packet in reply. The only things that bind a response to a request are: the source and destination IP addresses, the UDP ports, the question itself, and a 16-bit number called the transaction ID. If a forged packet arrives first, matches those fields, and answers the question, the resolver accepts it. There is no signature, no handshake, no proof that the responder is actually the authoritative server.
In the original design, the destination port of the resolver was often fixed and predictable, and the transaction ID was the main unknown. Sixteen bits means just 65,536 possible IDs. An attacker who can trigger a resolver to look up a name they control the timing of can then flood it with forged responses, each carrying a different guessed ID, racing the legitimate answer from the real authoritative server.
The attacker only needs one forged packet to land before the genuine reply, with the right transaction ID. If they lose the race, the real answer gets cached — but a clever attacker can simply force a fresh lookup and try again.
Kaminsky's Insight: Unlimited Retries
For years the limitation seemed to be that race. Guess wrong, the real record gets cached, and you're locked out until its TTL expires — possibly hours. In 2008, security researcher Dan Kaminsky showed why that comfort was false, and the result was serious enough to trigger a coordinated, industry-wide patch effort.
His insight was to attack nonexistent subdomains. Instead of poisoning www.bank.com directly, the attacker asks the resolver for random001.bank.com, random002.bank.com, and so on — names that aren't cached, forcing a fresh query every time. For each, the attacker floods forged replies. Crucially, those forged replies don't just answer the random subdomain; they include authority and "additional" records that say, in effect, "the authoritative name server for all of bank.com is at this IP I control."
Now the TTL no longer protects you. Each random subdomain is a fresh roll of the dice with no penalty for failure, and a single win poisons the entire zone's delegation, not one record. Kaminsky turned a slow, one-shot gamble into a fast, repeatable one.
The Defenses That Raised the Cost
No single fix made DNS unforgeable. Instead, a stack of mitigations each added entropy or authentication, and together they pushed the attack from "feasible in seconds" to "impractical for most adversaries."
| Defense | What it adds | Limitation |
|---|---|---|
| Source port randomization | ~16 more bits the attacker must guess alongside the transaction ID | Defeated if a side channel reveals the port |
| 0x20 encoding | Randomizes the case of letters in the query name; the reply must echo it exactly | Limited entropy for short names |
| DNSSEC | Cryptographic signatures on records — forged data fails validation | Incomplete deployment; protects integrity, not privacy |
| Encrypted transport (DoH/DoT) | Hides and authenticates the resolver channel from on-path attackers | Only protects the stub-to-resolver hop |
The first line of defense, source port randomization, was the emergency patch deployed after Kaminsky's disclosure. By randomizing the UDP source port as well as the transaction ID, resolvers raised the guessing space from about 16 bits to roughly 32 — turning a quick win into something computationally and bandwidth-prohibitive over a single race window.
The durable, cryptographic answer is DNSSEC, which signs DNS records so a resolver can verify they came unaltered from the zone's real operator. A forged record without a valid signature is simply rejected. DNSSEC closes the forgery hole at the protocol level — but its deployment is still partial across the internet, and it authenticates data without encrypting it.
DNSSEC and encrypted DNS solve different problems and people constantly confuse them. DNSSEC proves an answer is authentic but leaves it readable on the wire. Encrypted transport hides the question but doesn't prove the answer is genuine. You want both.
The Attack Keeps Adapting
Source port randomization only helps if the port really is unguessable. In 2020, researchers disclosed a family of attacks dubbed SAD DNS, which used a side channel in how operating systems rate-limit ICMP error messages to infer the resolver's open source port. Narrow the port down and the entropy collapses back toward the old 16-bit problem, reopening the door to off-path poisoning. Follow-up work kept finding variations as systems were patched.
This is the recurring shape of DNS security: the protocol's lack of built-in authentication means defenders pile on layers of unpredictability, and attackers look for any side channel that drains the unpredictability away. The only thing that ends the cat-and-mouse permanently is cryptographic authentication of the records themselves.
What It Means for You
As an individual, you don't operate a recursive resolver, but your choices still matter:
- Use a resolver that validates DNSSEC. Major public resolvers do; many ISP resolvers do too. Validation means forged records get dropped before they reach you.
- Prefer encrypted DNS — DNS over HTTPS or DNS over TLS — to stop an attacker on your local network from tampering with the resolver channel directly.
- Lean on TLS as the backstop. Even a successfully poisoned record sends you to the attacker's IP, but a valid HTTPS certificate for the real domain is far harder to forge. Certificate Transparency and strict TLS make a redirect noisy rather than silent.
That last point is the reassuring one. DNS poisoning is dangerous precisely because it operates a layer below the padlock in your browser. But it does not, by itself, defeat transport encryption. An attacker who redirects you still has to present a certificate your browser trusts for the real name — which is exactly why the modern web's defense-in-depth, encryption layered on top of an untrustworthy naming system, holds up even when the layer beneath it is lying to you.
The names you type were never meant to be trusted on their own. Treat DNS as a hint, verify with cryptography, and the forged phone book entry leads nowhere.