What is DNS Cache Poisoning?

You type your bank's web address exactly right. You've visited this site a hundred times. But today something's different, the page loads a little slower, the logo looks slightly off, and minutes later, your login credentials are in the hands of an attacker. You did nothing wrong. The internet's own navigation system was silently working against you.

That's the unsettling reality of DNS cache poisoning. Attackers can corrupt a single recursive DNS resolver and instantly redirect every user relying on it, no malware download required, no suspicious link to click. The Kaminsky vulnerability, discovered in 2008, showed just how devastating this can be: an entire domain could be hijacked within minutes by exploiting predictable transaction IDs drawn from a pool of only 65,536 possibilities. The risks go beyond stolen passwords, too. Think malware delivery, mass data interception, and even government-level censorship of national DNS caches.

You'll learn exactly how these attacks work, why DNS's trust-based design makes it so vulnerable, and what practical steps you can take to protect yourself and your organization before attackers exploit the gap.

What is DNS cache poisoning?

DNS cache poisoning is a cyberattack where an attacker injects forged DNS records into a resolver's cache, silently redirecting users to malicious sites instead of the legitimate ones they're trying to reach. It works because DNS relies on UDP, which has no built-in authentication. 

If a fake response arrives before the real one, the resolver accepts it. The Kaminsky vulnerability, discovered in 2008, showed just how dangerous this gets: attackers could poison NS records and hijack entire domains, not just single entries. Older DNS implementations used 16-bit transaction IDs, giving attackers a 1-in-65,536 chance per guess, bad enough that a full cache could be poisoned within minutes.

How does DNS cache poisoning work?

DNS cache poisoning tricks a recursive DNS resolver into storing a fake IP address for a legitimate domain. When your browser asks "where is example.com?", the resolver checks its cache first. If that cache has been poisoned, you get sent to an attacker's server, not the real site.

Here's the mechanism. Attackers flood a resolver with forged UDP responses while it's waiting for a legitimate DNS reply. Because UDP has no connection verification, the resolver accepts whichever response arrives first. Older DNS implementations used 16-bit transaction IDs, giving attackers a 1-in-65,536 chance per guess, low enough that rapid flooding works, and even infrastructure protected by a global CDN or a WAAP platform can face exposure if DNS layers aren't hardened.

The 2008 Kaminsky bug made this dramatically worse. Instead of targeting a single domain record, attackers manipulated NS records to poison entire domains at once, corrupting a cache within minutes. Post-Kaminsky patches added source port randomization, pushing the guessing complexity into the billions. But the underlying protocol weakness didn't disappear.

Once poisoned, the resolver serves that fake record to every user downstream until the TTL expires.

What are the main indicators of a DNS cache poisoning attack?

Signs of DNS cache poisoning can be subtle. Your traffic gets hijacked silently, often before you notice anything wrong. Here are the main indicators to watch for.

• Unexpected redirects: You try to reach a familiar website but land somewhere else entirely. The URL in your browser may look correct, but the page content doesn't match what you'd expect.
• SSL certificate mismatches: Your browser warns you that the certificate doesn't match the domain. When a poisoned resolver sends you to an attacker's server, the certificate it presents won't be valid for the legitimate site.
• Unfamiliar login pages: A site you use regularly suddenly looks slightly different, wrong logo, different layout, or an unusual login prompt. Attackers often clone real pages to steal credentials.
• DNS resolution inconsistencies: The same domain resolves to different IP addresses depending on which resolver you query. If your resolver returns an address that doesn't match authoritative records, that's a red flag.
• Sudden spike in phishing reports: If multiple users on the same network report being redirected to suspicious sites, a shared recursive resolver is likely poisoned. Everyone downstream from that resolver gets the same bad response.
• Expired or missing HTTPS padlock: Legitimate sites that always used HTTPS now load over HTTP, or the padlock disappears. Attackers controlling a spoofed destination may not have a valid TLS certificate for the domain.
• Unusual traffic patterns in DNS logs: Your DNS monitoring shows responses arriving faster than your authoritative server could have sent them, or from unexpected source IPs. That speed advantage is exactly what attackers exploit, they race the real response.
• Mismatched TTL values: Cached records show time-to-live values that don't align with what the authoritative server publishes. Injected records often carry TTLs set by the attacker, not the domain owner.

What are the risks of DNS cache poisoning?

The risks go well beyond a simple redirect. If your DNS resolver gets poisoned, attackers can quietly intercept your traffic before you realize anything's wrong. Here's what's actually at stake:

• Phishing exposure: Poisoned DNS sends users to convincing fake versions of real websites. Victims enter credentials, payment details, or personal data without suspecting anything.
• Malware delivery: Attackers redirect legitimate software download sites to malicious ones. Your users download what looks like a trusted app but get malware instead.
• Data interception: Traffic routed through attacker-controlled servers can be captured and read. Even encrypted sessions can be compromised if the attacker serves a fraudulent certificate and the user bypasses or ignores browser certificate warnings.
• SSL certificate mismatch: A poisoned resolver can point your domain to a server with an invalid or self-signed certificate. That's often your first visible clue something's wrong.
• Widespread downstream impact: Recursive resolvers cache responses for every user they serve. One poisoned resolver doesn't affect one person, it affects everyone relying on it.
• Fake domain injection: Attackers don't just hijack real domains. They can insert mappings for entirely non-existent domains into your resolver's cache, creating invisible infrastructure for further attacks.
• Censorship and access blocking: Governments have poisoned national DNS caches to block specific websites. It's the same attack vector, just deployed at scale with political intent.
• Persistent exposure: Short TTLs mean poisoned records expire quickly, but attackers can re-poison caches repeatedly. Without DNSSEC validation, there's nothing stopping them from refreshing the fake record.

What is the difference between DNS cache poisoning and DNS spoofing?

DNS cache poisoning differs from DNS spoofing primarily in scope and method. Poisoning targets recursive resolver caches to affect many users at once, while spoofing is a broader term covering any attack that returns false DNS data to a victim.

Think of spoofing as the category and poisoning as one technique within it. Spoofing can happen at multiple points: intercepting traffic between a client and resolver, manipulating responses in transit, or injecting malware that alters local host files. Cache poisoning is more specific, it exploits weaknesses in the DNS protocol itself to corrupt a resolver's stored records.

The technical difference matters too. Cache poisoning relies on UDP's lack of authentication and predictable transaction IDs (historically 16-bit, giving only 65,536 possible values) to slip forged responses past a resolver before the legitimate answer arrives. Generic spoofing attacks don't always need that timing window, some simply intercept or redirect traffic at the network level.

The impact scales differently as well. A poisoned resolver affects every user who queries it, potentially thousands of people redirected to malicious sites without any individual action on their part. A spoofing attack targeting a single client affects only that device. That's why cache poisoning is considered the more dangerous variant, one successful attack poisons the well for everyone downstream.

Why are DNS cache poisoning attacks so effective?

DNS cache poisoning works because the DNS protocol was built on trust, not verification. When a resolver asks for an IP address, it accepts the first response it receives. There's no built-in way to confirm that response is legitimate.

The underlying weakness is UDP. Unlike TCP, UDP has no handshake, so attackers can send forged responses without establishing a real connection. If the fake response arrives before the genuine one, the resolver caches it. Older DNS implementations made this even easier: 16-bit transaction IDs gave attackers only 65,536 possible values to guess. The 2008 Kaminsky attack exploited this, poisoning entire domains in minutes by targeting NS records rather than individual entries.

Even after source port randomization raised the complexity to billions of guesses, the underlying protocol weakness didn't disappear. The attack surface remains for resolvers that haven't implemented these mitigations. DNSSEC adds cryptographic verification, but adoption remains low, leaving most resolvers still relying on that original trust-based design.

How to prevent DNS cache poisoning?

You prevent DNS cache poisoning by combining protocol hardening, cryptographic verification, and smart resolver configuration. No single fix is enough, you need layers.

1. Deploy DNSSEC on your domains. DNSSEC digitally signs DNS records so resolvers can verify authenticity before caching anything. It's been available since 2005, but adoption remains low, which means attackers still find plenty of unprotected targets. Signing your zones closes that gap.
2. Randomize source ports and transaction IDs. Older DNS implementations used predictable 16-bit transaction IDs, giving attackers roughly a 1-in-65,536 chance per guess. Post-Kaminsky patches introduced source port randomization, pushing the odds into the billions. Make sure your resolver software reflects these updates.
3. Keep your DNS software patched. The 2008 Kaminsky vulnerability exposed how quickly cache poisoning can succeed, attackers could poison a resolver within minutes using probability-based spoofing. Unpatched software leaves those doors open.
4. Use a hardened, security-focused recursive resolver. Don't rely on default ISP resolvers, which often lack poisoning defenses. Choose resolvers that validate response sources and support DNSSEC validation end to end.
5. Enable rate limiting on your DNS servers. Rate limiting slows down the flood of forged UDP responses attackers use to win the spoofing race. It won't stop a determined attacker alone, but it raises the cost significantly.
6. Monitor for anomalous DNS behavior. Unexpected redirects, mismatched SSL certificates, or unusual resolution results from the same resolver are all warning signs. Set up monitoring so you catch poisoning attempts early, before users hit a phishing page.
7. Validate SSL certificates on all your services. Even if an attacker poisons a cache and redirects traffic, a valid certificate mismatch gives users a visible warning. It's not a DNS fix, but it's a meaningful safety net.

The key thing is not to treat any one of these steps as sufficient on its own. DNSSEC handles authentication, port randomization raises attack complexity, and monitoring catches what slips through. Together, they make cache poisoning attacks far harder to pull off successfully.

How can Gcore help protect against DNS cache poisoning?

Gcore helps protect against DNS cache poisoning through a global anycast network and DNS infrastructure that reduces the attack surface and limits the propagation of forged records. Gcore's 210+ Points of Presence mean DNS queries resolve closer to the user, reducing the attack window where spoofed UDP responses can intercept legitimate traffic.

If a resolver gets poisoned, the distributed architecture limits propagation across your user base, each PoP works independently, which can help contain the blast radius compared to a centralized resolver. That's a meaningful difference when you're dealing with attacks that can poison a cache within minutes.

Frequently asked questions

What is the difference between DNS cache poisoning and DNS hijacking?

DNS cache poisoning targets the resolver's cache by injecting false records through protocol weaknesses, while DNS hijacking directly compromises the DNS server, router, or user's device to reroute traffic. Both redirect users to malicious sites, but poisoning exploits UDP vulnerabilities whereas hijacking requires gaining control of actual infrastructure.

How long does a DNS cache poisoning attack last?

A poisoned cache stays corrupted until the fake record's TTL expires. Attackers may try to set injected TTLs as high as the resolver will accept to increase the attack window, though resolvers often cap or ignore excessively high TTL values. Once the TTL runs out, the resolver fetches a fresh (legitimate) record and the poisoning ends.

Can DNSSEC fully prevent DNS cache poisoning?

No, DNSSEC significantly reduces the risk by cryptographically signing DNS records, making forged responses detectable, but it doesn't protect against every attack vector, and its low adoption rate means many resolvers still work without it.

How do attackers benefit from DNS cache poisoning?

DNS cache poisoning lets attackers silently redirect your traffic to malicious sites without you ever knowing, enabling phishing, credential theft, and malware delivery at scale. Because the poison lives in the resolver's cache, every user relying on that resolver gets redirected, multiplying the attacker's reach with a single successful exploit.

Is DNS cache poisoning illegal?

Yes, DNS cache poisoning is illegal in most jurisdictions, typically prosecuted under computer fraud and unauthorized access laws. Attackers face serious criminal penalties, though governments have used the same technique for censorship purposes.

What tools can detect DNS cache poisoning?

Tools like dig, nslookup, and Wireshark let you spot suspicious DNS responses by comparing resolved IP addresses against known-good records. If you're seeing unexpected redirects or mismatched SSL certificates, those are your clearest real-world indicators that a resolver's cache may be compromised.

How does DNS cache poisoning affect end users?

When your DNS resolver's cache gets poisoned, you're silently redirected to a fake site without any warning, your browser thinks it's the real destination. That means your credentials, payment details, or sensitive data go straight to an attacker.