What is DNS cache poisoning, and why does one forged answer accepted by a recursive resolver affect many users?

## What a recursive resolver's cache is When a laptop looks up `www.example.com`, it usually asks a **recursive resolver** run by its network, its ISP or a service it chose. The resolver walks the DNS hierarchy on the laptop's behalf, gets the answer from the zone's **authoritative server**, and keeps a copy in its **cache** for the number of seconds the record's **TTL** allows. The next client that asks for the same name within that time gets the cached copy without any new query leaving the resolver. That sharing is the whole point of the cache - it makes DNS fast and keeps load off authoritative servers - and it is also why poisoning it is so valuable. ## What poisoning means **DNS cache poisoning** is causing a resolver to store a record that the zone's owner never published. Typical goals: - point `www.example.com` at an address the attacker controls, such as 192.0.2.66; - point the zone's `MX` target elsewhere, so mail is delivered to the attacker; - replace the zone's `NS` records, so every name under the zone is answered by the attacker's server. The forged record is served exactly like a real one. Nothing in a plain DNS answer tells the client, or the resolver, that it was forged. ## Why the blast radius is large | Property | Effect of one accepted forgery | |---|---| | Shared cache | Every client of that resolver asking for the name receives it | | TTL chosen by the forger | It can stay cached for as long as the forger's TTL and the resolver's own maximum allow | | Downstream caches | Forwarders and stub caches that fetched from the poisoned resolver hold their own copies | | Zone-wide records | A forged `NS` record hijacks every name under the zone, not one host | Compare that with forging an answer to a single laptop on a café network: one victim, one lookup. Poisoning the resolver turns one success into thousands of misdirected connections. There is a limit worth stating precisely. Redirecting a name does not hand the attacker a valid TLS certificate for it, so a client that checks the server's certificate against the name it asked for will see an error rather than a silent takeover. Plain-text protocols, and users who click through warnings, get no such protection. ## How a forged answer gets accepted Over classic DNS on UDP there is no connection, so the resolver decides whether a datagram is the reply it is waiting for by comparing fields. RFC 5452 section 9.1 says a resolver MUST match all of these: 1. the response's source address against the address the query was sent to; 2. the response's destination address against the query's source address; 3. the response's destination port against the query's source port; 4. the 16-bit query ID; 5. the query name; 6. the query class and type. A mismatch on any one of them makes the response invalid. An **on-path** attacker who can see the query copies these values and only has to answer first. An **off-path** attacker cannot see the query, so it must guess the unpredictable parts - the ID and the source port - and land its guess inside the short window before the genuine answer arrives. Making those values unpredictable is the resolver's first line of defence. ## What protects against it | Defence | What it does | What it does not do | |---|---|---| | Random query ID across 0-65535 | Makes a blind forger guess 16 bits | Not enough on its own against a forger who can retry quickly | | Random source port per query (RFC 5452) | Multiplies the guessing space by the number of ports in use | Is undone by a device in front that rewrites ports predictably | | DNSSEC validation | Rejects records whose signatures do not verify | Protects only zones that are signed | | Encrypted stub-to-resolver transport (DoT, DoH, DoQ) | Stops forgery on the client-to-resolver hop | Leaves the resolver's own onward queries as exposed as before | The randomisation defences raise the cost of guessing; only signature validation proves where the data came from. ## How this differs from other ways names go wrong Poisoning corrupts a cache while the real zone stays correct. A hijacked registrar account or a compromised authoritative server publishes the wrong data at the source, and every resolver fetches it faithfully - no cache was poisoned, and no randomisation helps. Keeping the two apart is what lets you pick the right defence.