Every connection you make starts with a question nobody thinks about: what IP is this name? Get that answer wrong — or let an attacker forge it — and TLS, your firewall, and your good intentions all point at the wrong server.
How a name actually resolves
Your machine runs a dumb stub resolver. It hands the whole job to a recursive resolver, which does the real legwork. That recursor walks the tree top-down: ask a root server who owns .com, ask the TLD server who's authoritative for example.com, then ask the authoritative server for the actual record. Three hops, one answer.
It helps to name the players precisely, because the security story hinges on the distinction:
- Stub resolver — the thin client in your OS. It knows nothing; it just asks the recursor and trusts the reply.
- Recursive resolver — does the tree walk, holds the cache, and is the component attackers most want to fool, because poisoning it poisons everyone behind it.
- Authoritative server — the source of truth for a zone, run by whoever owns the domain.
The record types you meet
A DNS answer is more than an IP. The common records:
- A / AAAA — the IPv4 / IPv6 address for a name.
- CNAME — an alias pointing one name at another.
- MX — where mail for the domain should go.
- NS — which servers are authoritative for the zone.
- TXT — arbitrary text, used for SPF, DKIM, and domain-ownership verification.
That last category matters for security beyond resolution: SPF and DKIM records in DNS are what let a receiving mail server decide whether an email claiming to be from your domain is forged.
Why caching exists (and why it bites)
Nobody wants to re-walk the tree on every lookup, so resolvers cache answers for the length of each record's TTL. Short TTLs mean fresh data and more traffic; long TTLs mean speed but slow propagation when you change records — which is why a migration you shipped an hour ago is still sending some users to the old server. That cache is also the attack surface: poison one entry and every client behind that resolver inherits the lie until the TTL expires. One successful forgery, thousands of victims.
The Kaminsky race
Classic DNS rides UDP with no authentication, so the resolver simply trusts the first reply whose transaction ID matches its query. An off-path attacker — one who cannot even see your traffic — doesn't need to intercept anything. They just flood the resolver with forged replies, each guessing that 16-bit transaction ID, racing the real authoritative server's answer. Win the race once and you've planted a bogus record in the cache.
A 16-bit ID is only 65,536 possibilities, but the naive attack had a catch: if you guess wrong, the real answer arrives and gets cached, and you're locked out until its TTL expires. Dan Kaminsky's 2008 insight removed that limit. Instead of attacking www.example.com directly, he had the attacker query random non-existent subdomains — a1b2.example.com, x9z8.example.com — each of which forces a fresh lookup with no cached answer to wait on. In the forged reply, the attacker didn't just answer the subdomain; they smuggled in a malicious record for the whole domain's authoritative server. Unlimited fast retries turned a theoretical 1-in-65,536 guess into a practical few-second attack.
Shutting the door
- Source-port randomization stacks another ~16 bits of entropy on top of the transaction ID. The attacker now has to guess both the transaction ID and the random source port — roughly 2^32 combinations, turning a feasible guess into a needle-in-a-haystack lottery. This was the emergency fix deployed after Kaminsky.
- DNSSEC signs records cryptographically with a chain of trust from the root down. A forged reply has no valid signature, so the resolver rejects it regardless of how well the attacker guessed the IDs. It fixes the root cause — unauthenticated data — rather than just adding entropy.
- DoH/DoT (DNS over HTTPS / TLS) wrap the whole exchange in TLS, which kills off-path forgery and on-path snooping in one move, because the attacker can no longer read the query or inject a reply into an authenticated channel.
None of these is a complete answer alone — DNSSEC authenticates but doesn't encrypt; DoH encrypts but doesn't prove the authoritative data is genuine. Layered, they cover each other's gaps.
The takeaway
- DNS is a recursive, cached tree walk — and that cache is exactly what attackers go after, because one poisoned entry hits every client behind the resolver.
- Off-path poisoning is a race against a 16-bit guess; Kaminsky's random-subdomain trick removed the retry limit and made it practical.
- Randomize source ports to raise the guessing cost, sign with DNSSEC to reject forgeries outright, and encrypt with DoH/DoT to shut out snooping — defense in depth, not one silver bullet.