What Is DNS Cache Poisoning?

DNS cache poisoning (also called DNS spoofing) is an attack that tricks a resolving DNS server into storing a forged answer for a domain name — usually mapping a legitimate hostname to an attacker-controlled IP address — so that every subsequent query for that domain from anyone using that resolver gets the forged answer, without the attacker needing to touch the victims’ devices directly at all.

How normal DNS resolution works, briefly

When a client looks up a domain, it typically doesn’t ask the domain’s authoritative server directly. It asks a recursive resolver — often run by an ISP, a company, or a public service — which does the work of walking the DNS hierarchy on the client’s behalf and caches the result for a period set by the record’s TTL, so it doesn’t have to repeat that work for every request. See our fuller explanation of how DNS works for the resolution chain in detail. That cache is exactly what cache poisoning targets: corrupt the cached answer once, and every client relying on that resolver gets the bad answer until the cache entry expires or is corrected.

How the attack actually works

DNS traditionally runs over UDP, and a resolver matching a response to its original query relies on a handful of values: the source IP and port the response comes from, the destination port, and a 16-bit transaction ID included in both the query and its response. If an attacker can guess or observe all of these values, they can race a forged response to the resolver before the legitimate authoritative server’s real answer arrives. If the forged response gets there first and matches those identifying values, the resolver accepts it as genuine and caches it — even though it never actually came from the real authoritative server.

The core weakness attackers exploit is that a 16-bit transaction ID only has 65,536 possible values, which is a small enough space that a sustained, well-timed flood of guesses has a meaningful chance of hitting a match, especially against older or misconfigured resolvers that don’t sufficiently randomize the query source port alongside the transaction ID. Modern resolvers mitigate this significantly by randomizing both the source port and the transaction ID together, which multiplies the search space attackers have to cover, but the underlying protocol weakness — trusting a UDP response based on values an on-path or well-positioned attacker might predict — hasn’t fundamentally changed.

What a successful poisoning attack enables

Once a resolver’s cache holds a forged record, every client that queries that resolver for the affected domain is silently redirected to whatever IP address the attacker specified, for as long as the poisoned entry survives in the cache. That opens the door to a range of follow-on attacks: intercepting login traffic for a redirected banking or webmail domain, serving malware from a site pretending to be a legitimate software vendor, or simply performing a large-scale man-in-the-middle attack against everyone sharing that resolver, all without compromising a single victim device directly. Because the poisoning happens at the resolver rather than the client, victims typically see no warning signs at the DNS layer at all — their browser is resolving the domain name correctly according to what the resolver told it, and any indication that something is wrong depends entirely on protections layered on top of DNS itself.

Defenses: DNSSEC and encrypted DNS

DNSSEC is the direct fix for the underlying trust problem: it adds cryptographic signatures to DNS records, so a resolver can verify that a response genuinely came from the domain’s authoritative zone rather than accepting any response that merely matches the right transaction ID and ports. A resolver validating DNSSEC signatures rejects a forged record even if an attacker successfully guesses every other identifying value, because the forged record won’t carry a valid signature chain back to the domain’s actual owner. See our deep dive on DNSSEC for how that signature chain is built and verified.

Encrypted DNS — DNS over HTTPS or DNS over TLS — addresses a related but distinct problem: it stops an on-path attacker from observing or tampering with the query and response in transit, which removes one of the ways an attacker gathers the information needed to forge a convincing response in the first place. It doesn’t independently verify that the resolver’s own cache is uncorrupted the way DNSSEC does, but combined with a trustworthy resolver it closes off a significant class of poisoning vectors that rely on intercepting plaintext DNS traffic.

Poisoning vs other DNS-adjacent attacks

DNS cache poisoning is often confused with DNS hijacking, but they operate at different layers. Cache poisoning corrupts a specific resolver’s cached answer for a domain the attacker doesn’t control. DNS hijacking more broadly refers to redirecting DNS resolution through unauthorized means — compromising a domain registrar account, modifying a router’s configured DNS servers, or running a rogue DHCP server that hands out a malicious resolver address — and can be a more direct, more durable compromise since it doesn’t depend on a race condition or a cache TTL expiring. A VPN that routes DNS queries through its own trusted resolver can reduce exposure to router-level hijacking on untrusted networks, though it does nothing to protect against poisoning happening upstream at that VPN provider’s own resolver.

The takeaway

DNS cache poisoning exploits the fact that a traditional DNS resolver accepts a UDP response as genuine if it matches a handful of guessable or observable identifying values, letting an attacker inject a forged record into the resolver’s cache and silently redirect everyone who queries it afterward. DNSSEC closes the underlying trust gap by cryptographically verifying that records actually came from the claimed authoritative source, while encrypted DNS transports reduce an attacker’s ability to observe and tamper with queries in transit. Neither fully replaces the other, which is why current best practice for a resolver operator is to run both, layered on top of the TLS protections already securing the sites those DNS lookups ultimately point to.