Imagine asking a trusted librarian for directions to a specific address, and an imposter slips in to give you a fake answer before the librarian can respond. You follow the directions, confident they came from a reliable source, and end up somewhere completely different. That's DNS cache poisoning: an attacker injects false information into a DNS resolver's cache, causing everyone who uses that resolver to be sent to the wrong place.
Cache poisoning (also called DNS spoofing) is one of the most dangerous DNS attacks because it's invisible to the victim. The domain name in the browser looks correct. There's no obvious sign of compromise. But the IP address behind that name has been silently replaced, redirecting users to a malicious server that could harvest credentials, serve malware, or intercept communications.
This guide explains how cache poisoning works, the famous vulnerability that made it a serious threat, real-world consequences, and how DNSSEC and proper monitoring defend against it.
How DNS Caching Creates the Opportunity
To understand cache poisoning, you first need to understand DNS caching. When a recursive resolver looks up a domain name, it caches the answer for a period defined by the record's TTL (Time to Live). This caching makes DNS fast and reduces load on authoritative servers, as we explained in our authoritative vs recursive DNS guide.
The vulnerability is this: if an attacker can trick a resolver into caching a false answer, that poisoned entry is served to every user of that resolver until the TTL expires. One successful poisoning can affect thousands or millions of users, and it persists in the cache without requiring any further action from the attacker.
How Cache Poisoning Works
DNS over UDP was designed without strong authentication. When a recursive resolver sends a query to an authoritative server, it expects a response that matches two things:
- The query name and type (e.g., the A record for
yourbank.com) - A 16-bit transaction ID that the resolver included in its query
If a response arrives matching the query and the transaction ID, the resolver accepts it as legitimate and caches it. The attack exploits this:
- The attacker triggers a query by getting the resolver to look up a domain (for example, by causing the victim to load a page that references the target domain).
- The attacker floods the resolver with forged responses, each guessing the transaction ID and claiming to be from the authoritative server, but containing the attacker's malicious IP address.
- If a forged response arrives before the legitimate one and correctly guesses the transaction ID, the resolver accepts it and caches the malicious record.
- The poisoned entry is now served to all users of that resolver until the TTL expires.
The 16-bit transaction ID has only 65,536 possible values, which is a small enough number that an attacker flooding responses has a reasonable chance of guessing correctly before the real answer arrives.
The Kaminsky Vulnerability
In 2008, security researcher Dan Kaminsky disclosed a vulnerability that made cache poisoning dramatically more practical than previously believed. Before Kaminsky's discovery, the conventional wisdom was that cache poisoning was difficult because an attacker had a limited window: once the resolver cached the legitimate answer, the attacker had to wait for the TTL to expire before trying again.
Kaminsky's insight was that an attacker didn't need to wait. By querying for random, non-existent subdomains (random123.yourbank.com, random456.yourbank.com, and so on), the attacker could trigger endless fresh queries that weren't cached. For each query, the attacker could attempt to inject a forged response that not only answered the random subdomain but also included malicious authority records redirecting the entire domain.
This removed the timing limitation and made cache poisoning a practical, fast attack. The disclosure triggered a coordinated, industry-wide patching effort. The primary mitigation was source port randomization.
Source Port Randomization: A Partial Fix
The immediate response to Kaminsky's vulnerability was to add another piece of randomness that an attacker has to guess: the source port.
Before the fix, resolvers often used a predictable source port for their queries, so an attacker only had to guess the 16-bit transaction ID. After the fix, resolvers randomized the source port as well, adding another 16 bits of entropy. Now an attacker has to guess both the transaction ID and the source port correctly, expanding the space from about 65,000 possibilities to billions.
This made cache poisoning much harder, but not impossible. Source port randomization is a mitigation, not a cure. Attacks like SAD DNS (disclosed in 2020 and 2021) found ways to infer the source port through side channels, demonstrating that the underlying weakness still exists. The only complete solution is cryptographic authentication of DNS responses, which is what DNSSEC provides.
What Attackers Achieve With Cache Poisoning
A successful cache poisoning attack lets the attacker redirect traffic for a domain to a server they control. The consequences include:
Credential Harvesting
The attacker redirects yourbank.com to a pixel-perfect phishing clone. Users see the correct domain name in their browser, have no reason to suspect anything, and enter their credentials, which the attacker captures.
Malware Distribution
The attacker redirects a software update server or download site to a malicious server that serves malware instead of legitimate files. Users and systems that trust the domain download and execute the malicious payload.
Man-in-the-Middle Interception
The attacker redirects traffic through their own server, intercepting and potentially modifying communications before forwarding them to the real destination. This can capture sensitive data in transit.
Email Interception
By poisoning MX record lookups, an attacker can redirect email delivery to their own mail server, capturing messages intended for the target domain.
Widespread Impact
Because the poisoned entry lives in a shared recursive resolver, a single successful attack affects every user of that resolver. Poisoning a major ISP's resolver or a popular public resolver could affect millions of users simultaneously.
How DNSSEC Stops Cache Poisoning
DNSSEC (DNS Security Extensions) is the definitive defense against cache poisoning. It adds cryptographic signatures to DNS records, allowing resolvers to verify that a response genuinely came from the authoritative server and hasn't been tampered with.
With DNSSEC, even if an attacker successfully injects a forged response that matches the transaction ID and source port, the resolver checks the cryptographic signature. A forged response won't have a valid signature, because the attacker doesn't have the domain's private signing key. The resolver rejects the forged response and the poisoning fails.
The chain of trust works like this:
- The root zone vouches for the TLD (.com, .org, etc.) via DS records
- The TLD vouches for your domain via DS records
- Your domain's DNSKEY records validate the RRSIG signatures on your individual records
- A validating resolver checks this entire chain before accepting any answer
If any signature is invalid or missing, the validating resolver rejects the response. This makes injected forgeries cryptographically detectable. We cover the full mechanism in our guide to DNSSEC.
The Catch: DNSSEC Adoption
DNSSEC only protects domains that have it enabled, and only when resolvers validate it. Global DNSSEC adoption remains incomplete. Many domains aren't signed, and not all resolvers validate signatures. For domains without DNSSEC, cache poisoning remains a viable threat mitigated only by source port randomization and other partial defenses.
Enabling DNSSEC on your domains is the single most effective step you can take to protect them against cache poisoning.
Other Defenses
DNS over HTTPS (DoH) and DNS over TLS (DoT)
These protocols encrypt the connection between a client and its recursive resolver, preventing attackers on the network path from injecting forged responses at that stage. They protect the client-to-resolver link, while DNSSEC protects the resolver-to-authoritative link. They're complementary, addressing different parts of the resolution path.
Source Port and Transaction ID Randomization
Standard in modern resolvers. This raises the bar for attackers but doesn't eliminate the threat entirely, as side-channel attacks have shown.
Reducing TTLs Cautiously
Shorter TTLs limit how long a poisoned entry persists, but they don't prevent poisoning and they increase query load. This is a minor mitigation, not a primary defense.
Monitoring Your Authoritative Records
While cache poisoning happens at the resolver level (outside your direct control), monitoring your authoritative DNS lets you detect related attacks and verify your DNSSEC chain is intact and valid.
How DNS Assistant Helps
Cache poisoning exploits the gap between your authoritative records and what resolvers cache. DNS Assistant helps you maintain the defenses that close that gap:
- DNSSEC validation: DNS Assistant continuously validates your DNSSEC chain of trust, confirming that the cryptographic protection against cache poisoning is intact. If your DNSSEC breaks (expired signatures, broken chain), you lose your primary defense against poisoning, and DNS Assistant alerts you immediately.
- Record monitoring: DNS Assistant tracks your authoritative records and alerts on changes. By querying your records the way resolvers do, it confirms that resolution returns the values you expect.
- SOA serial tracking: Changes to your zone are reflected in the SOA serial. DNS Assistant tracks this, helping you detect unexpected zone modifications.
- Multi-channel alerting: Get notified of DNS issues via email, Slack, Microsoft Teams, webhooks, or SMS.
Ensuring DNSSEC is enabled and continuously validated is the most important defense against cache poisoning, and monitoring that protection is exactly what DNS Assistant provides.
Check Your Protection
Use the DNS lookup tool at dnsassistant.com/tools to query your DNSKEY and DS records and confirm DNSSEC is enabled. Run a Free Domain Risk Report to check your DNSSEC status alongside your full DNS configuration.
For continuous DNSSEC validation and DNS monitoring with real-time alerting, sign up at dnsassistant.com.
This article explains DNS cache poisoning for educational and defensive purposes. Understanding how these attacks work is essential for defending against them.
Start Monitoring Your DNS Today
Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.
Sign Up Free