DNS Poisoning (Cache Poisoning) Explained

What Is DNS Cache Poisoning?

DNS cache poisoning is an attack that corrupts the cache of a recursive DNS resolver by tricking it into storing a fraudulent DNS record. Once the resolver caches the forged record, it serves that wrong answer to every client that queries it for the TTL of the record — no further attacker interaction required. This is what separates poisoning from a one-off spoofed response: a single successful poisoning attempt against a busy ISP resolver can silently redirect thousands of users at once.

The core weakness the attack exploits is that DNS over UDP has no built-in way to verify that a response actually came from the authoritative server it claims to be from. A recursive resolver sends a query and accepts the first response that matches a small set of identifying values: the source/destination IP and port, and a 16-bit query ID (also called a transaction ID, or TXID). If an attacker can guess or brute-force those values and get a forged response back to the resolver before the real authoritative server's reply arrives, the resolver has no way to tell the fake from the real one.

Before 2008, the query ID was effectively the only unpredictable value in that check, and resolvers frequently reused a fixed or predictable source port. That gave attackers a search space small enough to brute-force with a flood of forged UDP packets — this is exactly what Dan Kaminsky demonstrated at Black Hat 2008, and it's why the attack still carries his name.

Poisoning matters because DNS sits underneath almost everything: web browsing, email routing, software update checks, and certificate validation all start with a DNS lookup. A poisoned A record for a bank's domain, or a poisoned MX record for a company's mail server, can silently redirect traffic to an attacker-controlled server for as long as the forged record stays cached — verify what a resolver is currently returning with the DNS Lookup tool.

How DNS Cache Poisoning Works: The Kaminsky Attack

The classic Kaminsky-style attack plays out in a predictable sequence, and understanding each step is what makes the defenses in the next section make sense.

1. Force a query. The attacker sends the target resolver a query for a name that doesn't exist yet in its cache, such as random123.example.com. This forces the resolver to go ask example.com's authoritative nameservers for an answer — creating a small window where the resolver is waiting for a legitimate reply.

2. Flood forged responses. While the resolver waits, the attacker fires a burst of forged UDP responses claiming to be from the authoritative server. Each forged packet guesses a different combination of source port and 16-bit query ID, and includes a fake record — often overreaching by injecting a fraudulent NS or glue record for the entire example.com zone, not just the one subdomain queried.

3. Win the race. If any forged packet matches the resolver's expected source port and query ID before the real authoritative response arrives, the resolver accepts it as legitimate and caches it. With only a 16-bit query ID (65,536 possible values) and a fixed or predictable source port, an attacker with enough bandwidth can realistically brute-force a match in seconds to minutes.

4. Poison propagates. Once cached, the forged record is served to every client using that resolver until the TTL expires — an attacker can set a long TTL on the forged record to extend the poisoning window well beyond a normal cache lifetime.

The reason this became an emergency in 2008 rather than a theoretical curiosity: Kaminsky showed that even resolvers with randomized query IDs were vulnerable if the source port stayed fixed, because 16 bits of entropy alone is not enough against a resolver connected to a fast attacker. The fix that shipped across BIND, Windows DNS, and every major resolver was source port randomization combined with query ID randomization — multiplying the effective search space from roughly 65,536 combinations to over 4 billion.

A related, more modern variant is SAD DNS (Side-channel AttackeD DNS), disclosed in 2020, which uses ICMP rate-limiting side channels to infer the open source port without brute-forcing it blindly — a reminder that source port randomization raises the bar but isn't an absolute guarantee on its own, which is why DNSSEC remains the only cryptographically complete defense.

DNS Poisoning vs. DNS Spoofing vs. DNS Hijacking

These three terms get used interchangeably, but they describe different attack surfaces, and mixing them up leads to picking the wrong defense.

DNS spoofing is the umbrella term for forging any DNS response, whether it's a single reply on a local network or a full resolver-cache attack. DNS cache poisoning is a specific type of spoofing that targets a recursive resolver's cache so the forged answer persists and spreads to many clients. DNS hijacking is different again — it doesn't forge responses at all; instead it changes what a resolver is, by compromising a router's DNS settings, a registrar account, or a device's local resolver configuration so it points at an attacker-controlled server outright. For the router- and registrar-level attack surface, see the DNS Hijacking & Spoofing Defense guide — this guide focuses specifically on the cache-injection mechanism and its protocol-level fixes.

Defense Reference Table

DNSSEC is the only control in this table that eliminates the underlying trust problem rather than just raising the cost of guessing — everything else narrows the attacker's window but is still probabilistic. Check whether a domain has DNSSEC enabled with the DNS Lookup tool.

How to Defend Against DNS Cache Poisoning

If you run a recursive resolver (ISP, enterprise DNS server, self-hosted BIND/Unbound):

1. Confirm source port and query ID randomization are active. Modern BIND (9.5+), Unbound, and Windows Server DNS all randomize both by default — but verify on hardened or legacy builds, since a static source port silently reintroduces the Kaminsky-era weakness.

2. Enable DNSSEC validation. A validating resolver rejects any response that fails signature verification, regardless of how convincing the spoofed packet looks. This is the single control that stops both classic poisoning and its side-channel variants like SAD DNS.

3. Restrict recursion to trusted networks. An open resolver that answers recursive queries from the whole internet is both a poisoning target and, if compromised, an amplification tool for other attacks.

4. Keep TTLs reasonable, not maximal. A very long TTL extends how long any successfully poisoned record stays cached — balance caching efficiency against blast-radius if a record is ever forged.

If you run an authoritative zone (a domain owner):

1. Sign your zone with DNSSEC. This protects everyone who looks up your domain through a validating resolver — without it, your users are relying entirely on the resolver's own defenses.

2. Monitor what resolvers are actually returning. Periodically check your own records from multiple vantage points with the DNS Propagation Checker to catch stale or forged answers before customers report them.

How to Check If a DNS Record Has Been Poisoned

Poisoning is local to whichever resolver got tricked — it doesn't change the authoritative record, so the fastest diagnostic is comparing what different resolvers return for the same name.

# Query the domain's actual authoritative nameservers directly (bypasses any poisoned cache)
dig @ns1.example.com example.com A

# Query a public resolver the same way and compare
dig @1.1.1.1 example.com A

# Check whether the zone is DNSSEC-signed
dig example.com DNSKEY +dnssec

If the authoritative answer and the public resolver's answer disagree — different A record, different NS set, or an unexpectedly short TTL you didn't set — that resolver's cache may be poisoned. Run the same lookup through the DNS Lookup tool and cross-check nameservers with the NS Lookup tool; if a record resolves to an IP you don't control, that's the signal to escalate, not assume it's a caching glitch.

Common Mistakes When Defending Against DNS Poisoning

Assuming DNSSEC alone is "done." Signing a zone protects lookups against validating resolvers — but if the client-side resolver doesn't validate DNSSEC, the protection never applies. Confirm your DNS provider's resolvers actually validate, not just that your zone is signed.

Treating a slow-to-update record as poisoning. A record that hasn't changed everywhere yet is far more often ordinary TTL-driven propagation delay than an attack — see what DNS cache actually is before assuming compromise, and rule out a DNS server not responding issue first.

Relying only on encrypted DNS (DoH/DoT). Encrypting the stub-resolver-to-recursive-resolver hop stops eavesdropping and on-path tampering on that leg, but it does nothing to protect the recursive resolver's own queries to authoritative servers further upstream — that leg still needs DNSSEC or RFC 5452 mitigations.

Running an outdated resolver. Pre-2008 DNS server versions and some embedded/router firmware still ship with fixed or weakly randomized source ports. If a router's DNS forwarder hasn't been updated in years, it's a poisoning target regardless of what upstream resolver it forwards to.

Key Takeaways

• ✓ DNS cache poisoning forges a resolver response and wins a race against the real authoritative answer, corrupting the cache for every downstream client.
• ✓ The 2008 Kaminsky attack showed that query ID randomization alone (16 bits) wasn't enough entropy; source port randomization per RFC 5452 multiplies the search space to over 4 billion combinations.
• ✓ DNSSEC is the only defense that closes the trust gap cryptographically rather than just raising the guessing cost.
• ✓ DNS poisoning, DNS spoofing, and DNS hijacking are related but distinct — hijacking changes resolver configuration, poisoning corrupts resolver cache contents.
• ✓ Compare authoritative vs. public-resolver answers with dig or the DNS Lookup tool to spot a poisoned cache fast.

Frequently Asked Questions

Next Steps

DNS cache poisoning is a resolver-level problem, so the fastest way to catch it is comparing what different resolvers actually return. Run a lookup through the DNS Lookup tool and check propagation consistency across global resolvers with the DNS Propagation Checker. For a deeper look at how caching itself works before you assume an attack, read What Is DNS Cache?; for router- and registrar-level attacks rather than cache injection, see DNS Hijacking & Spoofing Defense; and for the cryptographic fix that closes the gap entirely, read DNSSEC Explained.