DNS Cache Poisoning vs. Spoofing: Risks and Prevention

DNS was originally designed without any way to verify that a response actually came from the nameserver it claimed to come from. That gap enables spoofing: an attacker positioned to intercept or race a DNS query can send back a forged response pointing the victim at an address of the attacker's choosing -- often used to redirect traffic toward a malicious server impersonating a legitimate site.

Cache poisoning: the same idea, at scale

Cache poisoning takes the same forged-response idea and targets a shared resolver rather than a single victim. If an attacker can slip a forged answer into a widely used recursive resolver's cache, every subsequent user of that resolver gets the poisoned answer until it expires -- turning a single successful forgery into an attack against everyone who happens to share that resolver, without needing to intercept each of their individual queries.

How modern DNS defends against it

None of these defenses are universally deployed -- DNSSEC adoption in particular remains partial across the domains that make up the internet. Using a well-run, security-conscious public resolver, and treating an unexpected or suspicious resolution result as worth double-checking from a second, independent resolver, remains a reasonable practical precaution even where DNSSEC isn't in play.

The bug that changed how seriously this is taken

Cache poisoning stopped being a theoretical concern in 2008, when security researcher Dan Kaminsky disclosed a fundamental flaw affecting nearly every DNS resolver in use at the time: the space of possible transaction IDs and source ports an attacker had to guess was small enough to brute-force in seconds over a fast connection, letting an attacker poison a resolver's cache for an entire domain, not just one record. The disclosure led to an unusually coordinated, simultaneous patch release across every major DNS software vendor -- source port randomization became standard almost overnight -- and is a large part of why the specific defenses listed above exist in their current form.

Why DNSSEC adoption still lags despite the fix being twenty years old

DNSSEC solves the underlying trust problem far more completely than port randomization alone -- it's cryptographic proof, not just a harder guessing game. Its slow rollout has more to do with operational complexity than doubt about its value: signing a zone correctly, rotating keys on schedule without breaking validation, and keeping the whole chain of trust intact from the root down to a specific domain is meaningfully harder to get right than adding an unsigned A record. A single mistake in that process produces the exact SERVFAIL failure mode covered elsewhere in this series, which is itself a deterrent for smaller domain operators without dedicated DNS expertise on staff. The gap between "solved in theory" and "deployed everywhere in practice" is common across security infrastructure, and DNSSEC is a clear example of it.