Build Your Defences Against DNS Cache Poisoning Attacks

Key Takeaways

• DNS cache poisoning forges a resolver’s cached DNS records so lookups for a real domain return an attacker controlled IP address, without touching the victim’s device.
• The technique became widely known after security researcher Dan Kaminsky disclosed a critical resolver flaw in 2008 (CVE-2008-1447), which forced an industry-wide, coordinated patch across DNS vendors.
• It remains an active risk. ISC disclosed BIND 9 cache poisoning flaws (CVE-2025-40778 and CVE-2025-40780) in October 2025, and researchers reported a DNS poisoning campaign by the Evasive Panda threat group in late 2025.
• No single control stops it. Source port randomization narrows the guessing window, DNSSEC authenticates responses cryptographically, and DoH/DoT encrypt the query path so on-path attackers cannot read or tamper with it.
• DNSSEC deployment is still uneven. APNIC Labs measured global DNSSEC validation at roughly 36 percent in 2025, which is progress from a decade ago but still leaves most resolvers unable to cryptographically verify what they cache.

Published: May 2022. Updated: August 2026. Reviewed by Encryption Consulting’s security team.

What Is DNS Cache Poisoning and How Does It Work?

DNS cache poisoning is an attack that injects a forged answer into a DNS resolver’s cache so that future lookups for a legitimate domain return an attacker controlled IP address instead of the real one. The Domain Name System (DNS) translates human readable domain names into IP addresses. A recursive resolver, the server type most affected by this attack, does that translation on behalf of a client and temporarily caches the answer so it does not have to repeat the lookup on every request.

DNS resolution relies on two server roles. Authoritative name servers hold the official records for the domains they are configured to answer for. Recursive resolvers perform the lookup on behalf of a client, querying authoritative servers as needed and caching the response. This article focuses on attacks against recursive resolvers, since a poisoned recursive cache affects every client that queries it.

In the classic attack, an off-path attacker (one who cannot see legitimate DNS traffic directly) tricks a resolver into issuing a query to an authoritative name server, then races to inject a forged response before the real one arrives. To be accepted, the forged response has to match the query’s source and destination IP, source and destination port (historically fixed at port 53), and a 16 bit transaction ID (TxID). With port fixed, an attacker only had to guess the 16 bit TxID, a space small enough to brute force with roughly 65,536 forged responses, and techniques like the birthday attack could narrow that further.

Cache poisoning versus DNS spoofing: the two terms describe the same underlying goal (getting a resolver or client to accept a false DNS answer) but differ in scope. DNS spoofing is the broader category, covering any forged DNS response, including man-in-the-middle interception on a local network. DNS cache poisoning specifically refers to getting that forged answer to persist in a resolver’s cache, so it keeps serving bad answers to every subsequent client until the cache entry expires.

What Is the History of DNS Cache Poisoning? Landmark Events and Recent Incidents

DNS cache poisoning is not a single incident, it is a longstanding attack technique with a history of landmark disclosures and ongoing real-world exploitation. Three events define its timeline.

1. 2008, the Kaminsky vulnerability (CVE-2008-1447). Security researcher Dan Kaminsky discovered a flaw in how DNS resolvers handled TxID randomness that made large-scale cache poisoning practical against nearly every DNS implementation in use. The disclosure was handled through a coordinated, multi-vendor patch release rather than a normal single-vendor advisory, which is still cited as one of the earliest large-scale coordinated disclosure efforts in Internet infrastructure security. Source port randomization became a near-universal default as a direct result.
2. October 2025, BIND 9 cache poisoning flaws (CVE-2025-40778 and CVE-2025-40780). The Internet Systems Consortium (ISC) disclosed vulnerabilities in BIND 9, one of the most widely deployed DNS resolver implementations, that allowed cache poisoning through unsolicited resource records. Proof-of-concept code was published shortly after, and security researchers estimated hundreds of thousands of internet-facing BIND resolvers were running vulnerable versions at disclosure time. This shows that cache poisoning is not just a 2008 problem, implementation-level flaws that enable it continue to surface in current DNS software.
3. Late 2025, the Evasive Panda DNS poisoning campaign. Kaspersky’s Securelist researchers reported that the China-linked threat group Evasive Panda used DNS poisoning alongside adversary-in-the-middle techniques to redirect targeted users toward malicious infrastructure delivering the MgBot backdoor. This is a documented example of cache poisoning being used operationally by a nation-state-linked actor, not just a theoretical protocol weakness.
4. Ongoing, the DNSSEC and encrypted-transport response. DNSSEC (DNS Security Extensions), standardized in IETF RFC 4033 through RFC 4035, cryptographically signs DNS records so a validating resolver can detect a forged answer instead of trusting whichever response arrives first. DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858) encrypt the query itself, closing off a different attack surface: on-path interception and tampering. These three defenses, source port randomization, DNSSEC, and DoH/DoT, are the current best-practice baseline, and none of them alone is sufficient.

What Technologies and Systems Are Affected by DNS Cache Poisoning?

Every layer of DNS caching in a modern resolution chain is technically exposed to poisoning, not just the recursive resolver most people picture.

• OS stub resolvers. The client operating system maintains its own DNS cache and forwards queries upward rather than resolving them iteratively. A poisoned stub cache affects a single device but is often overlooked in enterprise DNS monitoring.
• DNS forwarders. Commonly built into home and small-office Wi-Fi routers, forwarders maintain their own cache and pass queries to an upstream recursive resolver. A poisoned router cache affects every device on that network.
• Recursive resolvers, including ISP and public resolvers. This is the classic target, since a poisoned entry here is served to every client that queries it until the record’s TTL expires.
• Enterprise DNS infrastructure. Internal DNS servers that resolve for corporate networks, VPN clients, and cloud workloads are high-value targets, since a poisoned internal record can redirect authentication traffic, software update checks, or API calls.
• Authoritative DNS software. The BIND 9 case in 2025 showed that vulnerabilities in resolver software itself, not just protocol weaknesses, can reopen cache poisoning even after source port randomization and DNSSEC support exist.

What Is the Impact of a Successful DNS Cache Poisoning Attack?

A successful DNS cache poisoning attack gives the attacker control over where a victim’s traffic actually goes, without the victim changing anything on their own device.

• Traffic redirection. Users typing a legitimate domain name are silently sent to an attacker controlled server instead.
• Credential theft. Redirected traffic to a convincing lookalike login page can harvest usernames, passwords, and session tokens.
• Man-in-the-middle positioning. An attacker who controls DNS resolution for a target can intercept and, in some configurations, modify traffic between the client and the intended destination.
• Malware delivery. Poisoned records can point software update checks or download links at attacker infrastructure, as documented in the Evasive Panda campaign.
• Erosion of trust anchors that depend on DNS. Certificate domain validation, CAA record checks, and email authentication (SPF, DKIM, DMARC) all rely on DNS answers being trustworthy. A poisoned resolver used during domain control validation can, in specific circumstances, undermine the integrity of that validation step.

How Do You Detect DNS Cache Poisoning?

Detection combines DNS-specific monitoring with the same anomaly-detection discipline used elsewhere in the network.

1. Monitor for unexpected TTL or IP changes. A sudden change in a well-known domain’s resolved IP address, or an unusually short TTL on a record that normally changes rarely, is a common poisoning indicator.
2. Enable DNSSEC validation logging. A validating resolver will log and reject responses that fail signature validation, which is a direct signal of an attempted forgery.
3. Watch for abnormal query volume against a single name server. A spike in queries or query failures against one authoritative server can indicate an attacker attempting to “pin” a resolver to a single, more easily spoofed name server.
4. Cross-check resolution results from multiple vantage points. Comparing what internal resolvers, public resolvers, and third-party monitoring services return for the same domain can surface a localized poisoning event that a single vantage point would miss.
5. Track resolver and forwarder software versions against advisories. The 2025 BIND 9 flaws were exploitable specifically in unpatched versions, so version tracking against vendor advisories (ISC, in BIND’s case) is a detection and prevention control at once.

How Do You Remediate and Prevent DNS Cache Poisoning? A Numbered Checklist

No single control fully closes off DNS cache poisoning. The current best-practice defense is layered.

1. Confirm source port randomization is active. Modern resolver software enables this by default, but it is worth confirming on any legacy or custom-configured DNS infrastructure. This raises the guessing space an off-path attacker faces from 16 bits to roughly 32 bits.
2. Deploy DNSSEC on authoritative zones you control. Signing your own domains lets any validating resolver detect a forged answer for your domain. This protects your organization’s domains even before every resolver on the internet validates.
3. Enable DNSSEC validation on resolvers you operate. Signing alone does not help if the resolvers your organization uses do not validate signatures. Both sides of DNSSEC, signing and validation, need to be in place.
4. Move internal and client DNS traffic to DoH or DoT. Encrypting the query path prevents on-path attackers from reading or tampering with DNS traffic between the client and the resolver.
5. Patch DNS server and resolver software on a defined schedule. The 2025 BIND 9 cache poisoning flaws are a direct reminder that patching resolver software is a cache poisoning control, not just general hygiene.
6. Restrict which name servers your domains use, and monitor them. Fewer, well-monitored authoritative name servers reduce the attack surface an off-path attacker can target with query-failure “pinning” techniques.
7. Add CAA records to your DNS zones. CAA (Certification Authority Authorization) records limit which certificate authorities can issue for your domain, which reduces the impact if DNS trust is briefly undermined during certificate issuance.
8. Log and alert on DNS anomalies continuously. Feed resolver logs, DNSSEC validation failures, and TTL/IP change alerts into monitoring so a poisoning attempt is caught quickly rather than discovered after impact.

What Has Changed in DNS Security Since This Article Was Published? Update Log

This article was first published in May 2022 and substantially updated in August 2026. Since the original publication, the following developments changed the DNS security landscape:

• ISC disclosed and patched BIND 9 cache poisoning vulnerabilities CVE-2025-40778 and CVE-2025-40780 in October 2025, showing that implementation flaws, not just protocol-level weaknesses, still enable cache poisoning in widely deployed resolver software.
• Security researchers documented the China-linked Evasive Panda group using DNS poisoning operationally, alongside adversary-in-the-middle techniques, to deliver the MgBot backdoor, moving cache poisoning from a theoretical protocol risk to an actively exploited technique in nation-state-linked campaigns.
• Global DNSSEC validation rose to roughly 36 percent by 2025 according to APNIC Labs measurements, meaningful progress from the low single digits this article originally cited, but still leaving most resolvers unable to cryptographically verify what they cache.
• DNS over HTTPS and DNS over TLS moved from emerging proposals to mainstream defaults in major browsers and operating systems, adding an encrypted-transport layer of defense that the original 2022 version of this article did not cover.
• The CA/Browser Forum’s move toward shorter TLS certificate validity periods (a 200-day cap starting March 2026, tightening to 47 days by March 2029) increases how often domain control validation runs, which raises the stakes of DNS integrity during that validation window.

Which DNS Cache Poisoning Defense Should You Deploy First?

Each defense addresses a different part of the problem. Use this table to sequence deployment rather than treating any single row as sufficient on its own.

Defense Mechanism	What It Protects Against	Deployment Complexity
Source port randomization	Off-path TxID guessing (the classic Kaminsky-style attack)	Low, default in modern resolver software
DNSSEC (signing your zones)	Forged answers for your own domains, validated cryptographically by resolvers that check signatures	Medium to high, requires key management and zone signing
DNSSEC (validating on your resolvers)	Accepting forged answers for any signed domain you query	Medium, mostly a resolver configuration change
DNS over HTTPS (DoH)	On-path eavesdropping and tampering with the DNS query itself	Medium, needs client and resolver support
DNS over TLS (DoT)	Same as DoH, encrypted query transport	Medium, needs client and resolver support
0x20 encoding	Adds limited extra randomness via letter case, partial mitigation only	Low, but inconsistent authoritative server support
DNS monitoring and anomaly detection	Detects poisoning attempts and unexpected record changes after they occur	Medium to high, needs logging and alerting infrastructure

Limitations of DNS Cache Poisoning Defenses

No control on this list is a complete fix on its own, and organizations should plan for defense in depth rather than a single silver bullet.

• DNSSEC only protects domains that are signed, and only when the querying resolver actually validates. With global validation still around a third of resolvers as of 2025, most DNS traffic worldwide is not cryptographically checked.
• DoH and DoT protect the query in transit, but they do not authenticate the content of the answer the way DNSSEC does. An attacker who compromises the resolver itself, rather than the network path, is not stopped by encryption alone.
• Source port randomization raises the cost of an attack, it does not make it impossible, and implementation bugs in resolver software (as with the 2025 BIND 9 flaws) can reopen poisoning paths regardless of port randomization.
• Client-side stub resolvers and consumer routers are frequently the weakest link, since enterprise DNS hardening efforts often stop at the recursive resolver and do not extend to every forwarder on the network.

What Would Encryption Consulting Recommend?

We treat DNS integrity as a trust anchor problem, not just a networking problem. DNS answers feed directly into decisions that matter for cryptographic trust, including domain control validation for TLS certificate issuance and CAA enforcement. Our baseline recommendation for clients is to sequence the checklist above: confirm source port randomization is already in place (it almost always is on current software), then prioritize DNSSEC signing on externally facing zones, validation on internal resolvers, and DoH or DoT for client traffic, in that order. Patch cadence for DNS server software should be tracked with the same discipline as any other internet-facing service, given how recently the BIND 9 flaws showed that resolver software itself is still a live attack surface.

Because DNS resolution underpins domain control validation, organizations managing their own certificate authority infrastructure or relying on public CAs should treat DNS hardening as part of their PKI trust chain, not a separate workstream. If your team is evaluating how DNS-based validation, CAA enforcement, and certificate issuance fit together, our PKI-as-a-Service team and Encryption Advisory services can help assess where DNS integrity gaps could weaken certificate trust in your environment. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified, and we recommend talking to an advisor rather than treating this as a one-time configuration checklist, since resolver software and DNS threat activity both continue to change.

Frequently Asked Questions

What is the difference between DNS cache poisoning and DNS spoofing? DNS spoofing is the broad category of forging a DNS response, including local network man-in-the-middle attacks. DNS cache poisoning is a specific type of spoofing where the forged answer gets stored in a resolver’s cache, so it keeps affecting every client that queries that resolver until the cached record expires, not just the one client targeted in the initial attack.

Can DNSSEC alone stop DNS cache poisoning attacks? No. DNSSEC only protects domains that are signed, and it only helps if the querying resolver actually validates signatures. With global DNSSEC validation still covering roughly a third of resolvers as of 2025, unsigned domains and non-validating resolvers remain exposed regardless of DNSSEC’s existence as a standard.

How do I know if my DNS resolver has been poisoned? Watch for a well-known domain suddenly resolving to an unfamiliar IP address, an unusually short TTL on a record that normally changes rarely, DNSSEC validation failures in resolver logs, or user reports of certificate warnings on sites that normally load without them. Cross-checking resolution results across internal, public, and third-party resolvers is the fastest way to confirm a localized poisoning event.

Do DNS over HTTPS (DoH) and DNS over TLS (DoT) replace DNSSEC? No, they solve different problems. DoH and DoT encrypt the DNS query in transit, which stops on-path eavesdropping and tampering. DNSSEC cryptographically signs the DNS answer itself, which stops a resolver from accepting a forged record even if it arrives over an otherwise secure channel. Organizations need both, not one instead of the other.

How often should we audit our DNS infrastructure for cache poisoning risk? At minimum, review DNS server and resolver software versions against vendor advisories every time a security update is released, and run a full configuration review (source port randomization, DNSSEC signing and validation status, CAA records, encrypted transport support) at least twice a year or after any DNS infrastructure change.

Conclusion

DNS cache poisoning has been a known, exploitable weakness since long before the 2008 Kaminsky disclosure made it impossible to ignore, and it has not gone away. The 2025 BIND 9 flaws and the Evasive Panda campaign both show that this is a live, current risk, not a solved problem from an old textbook. Source port randomization is table stakes. DNSSEC and encrypted DNS transport (DoH/DoT) are the current best-practice layer on top of it, and neither one is optional if DNS integrity matters to your organization’s security posture, including the domain validation that your TLS certificates depend on. Build the layered defense described above, patch resolver software on a real schedule, and monitor for the anomalies that signal an attempt in progress.

References

• ISC Knowledge Base, “CVE-2008-1447: DNS Cache Poisoning Issue (the Kaminsky bug)”: https://kb.isc.org/docs/aa-00924
• ISC Knowledge Base, “CVE-2025-40778: Cache poisoning attacks with unsolicited RRs”: https://kb.isc.org/docs/cve-2025-40778
• IETF RFC 4033 through RFC 4035, “DNS Security Introduction and Requirements” and related DNSSEC specifications: https://datatracker.ietf.org/doc/html/rfc4033
• IETF RFC 8484, “DNS Queries over HTTPS (DoH)”: https://datatracker.ietf.org/doc/html/rfc8484
• IETF RFC 7858, “Specification for DNS over Transport Layer Security (TLS)”: https://datatracker.ietf.org/doc/html/rfc7858
• APNIC Labs, “Towards an industry best practice for DNSSEC automation” (2025 DNSSEC validation measurements): https://blog.apnic.net/2026/02/25/towards-an-industry-best-practice-for-dnssec-automation/
• Kaspersky Securelist, “Evasive Panda APT poisons DNS requests to deliver MgBot”: https://securelist.com/evasive-panda-apt/118576/