DNS Cache Poisoning Attacks

DNS cache poisoning works because DNS was built on trust.

When your computer asks "what's the IP address for bank.com?", it sends that question to a resolver. The resolver asks the authoritative nameserver. And here's the vulnerability: the resolver believes whoever answers first. No verification. No cryptographic proof. Just: whoever gets there first, wins.

An attacker who injects a forged answer before the legitimate response arrives can redirect your traffic anywhere. And because resolvers cache answers, that lie persists—poisoning every subsequent request until the cache expires. A single successful attack can redirect thousands of users for hours.

The Race Condition

Every DNS query creates a race. The moment a resolver sends a question to an authoritative nameserver, two runners sprint toward the finish line: the legitimate answer traveling back from the real server, and any forged answer an attacker can inject.

The resolver accepts whichever arrives first—if it looks legitimate.

For a forged response to pass, it must match specific criteria. The transaction ID (a 16-bit number the resolver chose) must be correct. The response must appear to come from the expected IP address. It must target the correct port on the resolver.

Early DNS implementations made this easy. Resolvers used predictable transaction IDs and a fixed source port (usually port 53). Attackers only needed to guess a 16-bit number—65,536 possibilities. With modern network speeds, spraying thousands of forged responses during a single query window became trivial.

Kaminsky's Discovery

In 2008, Dan Kaminsky found something that turned cache poisoning from a theoretical nuisance into an immediate crisis.

The traditional attack had a limiting factor: you could only poison a record that wasn't already cached. If bank.com was cached for 24 hours, you had to wait 24 hours between attempts. This made attacks slow and unreliable.

Kaminsky realized you could bypass this entirely by attacking siblings.

Instead of attacking bank.com directly, query for randomgarbage1.bank.com. That's a cache miss—the resolver has to ask the authoritative server. Query for randomgarbage2.bank.com. Another cache miss. You can trigger unlimited queries, immediately, with no waiting.

Here's the genius: you're not trying to poison the garbage subdomain. DNS responses have an "additional section" where servers can include helpful extra information. Kaminsky's forged responses answered the garbage query but included a poisoned nameserver record: "by the way, the nameserver for all of bank.com is actually ns.attacker.com."

You attack the child to poison the parent.

Once that nameserver record gets cached, the attacker controls all DNS resolution for the entire domain. Every subdomain. Every service. Everything.

Kaminsky contacted Paul Vixie, who described the severity: "everything in the digital universe was going to have to get patched."¹ The disclosure triggered the largest coordinated security patch in Internet history—81 vendors releasing fixes simultaneously on July 8, 2008.

Source Port Randomization

The immediate fix added another variable attackers must guess: the source port.

Traditional resolvers sent all queries from port 53. Attackers only needed to guess the 16-bit transaction ID. Source port randomization sends each query from a random port between 1024 and 65535—adding roughly another 16 bits of uncertainty.

The math changes dramatically. Instead of 65,536 combinations, attackers face approximately 4 billion. Instead of hundreds of attempts for a 50% success rate, you need millions.

This is now standard in every modern resolver. But it's a probabilistic defense, not a guarantee. Network devices that rewrite ports predictably, firewalls that restrict outbound port ranges, or simply enough time and bandwidth can still enable successful attacks.

Source port randomization makes cache poisoning hard. It doesn't make it impossible.

The Attacks Keep Evolving

Researchers continue finding new angles. SAD DNS (2020) demonstrated that ICMP rate limiting in Linux could be exploited to narrow down which source port a resolver was using, cutting the attack space significantly. At least 38% of resolvers remained vulnerable.²

MaginotDNS (2023) found that DNS servers acting as both recursive resolvers and forwarders have exploitable weaknesses in how they check response validity. The attack could take over entire DNS zones—including top-level domains like .com and .net. Measurement studies found 35.5% of such servers vulnerable.

As recently as 2025, critical vulnerabilities in BIND 9 (the most widely deployed DNS software) were discovered that enable cache poisoning by predicting source ports and query IDs.³

The cat-and-mouse game continues.

DNSSEC: The Actual Solution

DNSSEC replaces trust with cryptography.

Every DNS zone gets a signing key. Responses include digital signatures. Resolvers verify those signatures against public keys published in the parent zone, forming a chain of trust extending to the DNS root.

When a DNSSEC-validating resolver receives a response, it checks the signature. Valid signature with an unbroken chain of trust? Accept the answer. Missing signature, invalid signature, or broken chain? Reject it.

This makes traditional cache poisoning impossible. Even if an attacker wins the race, even if they guess the transaction ID and source port correctly, they cannot forge the cryptographic signature. Without the zone's private key, the forged response fails validation and gets discarded.

DNSSEC transforms DNS from "believe whoever answers first" to "believe whoever can prove they're authorized to answer."

Detecting Attacks

Cache poisoning attempts leave traces.

Multiple responses to single queries. When a resolver receives several answers to one question, someone is racing. Modern resolvers log these anomalies.

Floods of random subdomain queries. Kaminsky-style attacks generate distinctive patterns—rapid queries for subdomains that have never existed, like xk7f9.bank.com, m3pq2.bank.com, thousands per second.

Resolution inconsistencies. If your resolver returns a different IP for bank.com than Google's resolver does, something is wrong. Either you've been poisoned or they have.

When poisoning is detected, flush the affected cache entries immediately. Enable DNSSEC validation if it isn't already active. Restrict your resolver to only accept queries from your own network—don't let attackers trigger queries remotely.

This Has Happened

In 2010, the Great Firewall of China accidentally leaked beyond its borders.⁴ China's DNS servers return false answers for blocked sites like Facebook, YouTube, and Twitter—that's intentional censorship. But when an ISP outside China fetched records from Chinese DNS servers and cached the poisoned responses, users in Chile and the United States suddenly couldn't reach those sites. The censorship machinery escaped its intended boundaries.

In 2016, attackers poisoned DNS at Brazilian ISPs, redirecting banking customers to pixel-perfect phishing sites. Thousands of accounts were compromised before anyone noticed. The attack persisted for hours.

In 2023, attackers targeted a major ISP's DNS resolvers, injecting false records that redirected thousands of users to phishing sites for several hours before detection.⁵

DNS cache poisoning isn't theoretical. It's happening. The only question is whether your infrastructure is defended.

Sources