DNS poisoning, also called DNS cache poisoning or DNS spoofing, is an attack that corrupts the stored address records in a DNS resolver so that users who type in a legitimate website address get silently redirected to a server controlled by the attacker. Because the Domain Name System acts as the internet’s phone book, translating human-readable domain names into numerical IP addresses, corrupting even a single entry can reroute thousands of people to a convincing fake site without anyone realizing something has gone wrong. The attack exploits trust rather than brute force, and its consequences range from stolen login credentials to fraudulently issued security certificates.
How the Internet’s Phone Book Gets Tampered With
Every time you visit a website, your device asks a DNS resolver for the IP address that matches the domain name you typed. To avoid repeating that lookup every single time, resolvers store (or “cache”) the answer for a set period. DNS poisoning targets this caching step. An attacker sends forged responses to the resolver, pretending to be the authoritative server that actually knows the correct address. If the forged response arrives before the real one and matches enough identifying details, the resolver accepts it, stores the fake IP address, and hands it out to every subsequent visitor who asks for that domain.
The identifying details that a forged response needs to match are fairly limited in classic DNS. The response has to arrive on the right port, reference the correct transaction ID number, and appear to come from the expected authoritative server. Transaction IDs are only 16 bits long, which gives attackers a realistic chance of guessing the right one if they can flood the resolver with enough forged packets in a short window. Source port randomization, which modern resolvers now use, adds more guessing entropy, but the fundamental design of plain DNS was never built to verify that responses are authentic.
The Kaminsky Vulnerability and Why It Mattered
In 2008, security researcher Dan Kaminsky disclosed a flaw that made DNS cache poisoning dramatically easier than anyone had appreciated. Before Kaminsky’s disclosure, an attacker had to wait for a cached record to expire before trying to poison it again. Kaminsky showed that by querying for random, nonexistent subdomains of the target domain (like “abc123.example.com”), an attacker could force the resolver to issue a fresh lookup each time, giving the attacker unlimited attempts to inject a forged answer. Instead of one shot every few hours, the attacker could try thousands of times per second.
Academic research following the Kaminsky disclosure split into two broad camps. One focused on encrypting DNS communications to prevent spoofed responses from being accepted at all. The other relied on challenge-response mechanisms that reused existing fields in the DNS protocol to verify authenticity without requiring entirely new infrastructure.1ScienceDirect. Study on the latent state of Kaminsky-style DNS cache poisoning: Modeling and empirical analysis Both approaches have real trade-offs. Encryption adds processing overhead and requires coordinated deployment. Challenge-response tricks are lighter weight but often address only part of the attack chain. That same research noted that many early defenses focused on preventing forged referral records (like NS records used as intermediate stepping stones) from entering the cache, but overlooked the subsequent domain-hijacking phase, leaving a gap that more sophisticated attackers could still exploit.
What Happens After a Resolver Is Poisoned
The immediate effect of a poisoned cache is straightforward: everyone who relies on that resolver gets sent to the wrong server. But the downstream consequences vary depending on what the attacker wants to accomplish.
- Credential theft: The attacker’s server hosts a pixel-perfect copy of a bank login page, email provider, or social media site. Users enter their passwords without suspecting anything because the URL in their browser looks correct.
- Malware distribution: Software update checks that rely on DNS can be redirected to a server that delivers trojanized installers instead of legitimate patches.
- Fraudulent TLS certificates: If an attacker poisons the DNS cache used by a Certificate Authority during domain validation, the CA’s verification request gets redirected to the attacker’s server, allowing them to obtain a genuine-looking HTTPS certificate for a domain they do not own.2IETF Internet-Draft. Extended Security Considerations for the Automatic Certificate Management Environment (ESecACME) – Section: DNS Cache Poisoning Attacks That certificate then lets the attacker run a fake site with a reassuring padlock icon in the browser.
- Email interception: Poisoning the MX (mail exchange) records for a domain can silently reroute incoming email to the attacker’s mail server, giving them access to password-reset links, business communications, and two-factor authentication codes.
The certificate-issuance scenario is particularly concerning because the entire HTTPS trust model depends on Certificate Authorities reaching the right server during validation. The Automatic Certificate Management Environment (ACME) protocol, which powers services like Let’s Encrypt, performs automated domain-validation checks that resolve DNS records in real time. Poisoning the CA’s resolver at just the right moment can compromise the validation step without any involvement from the legitimate domain owner.
Local Device Attacks and Newer Vectors
Classic DNS poisoning is a network-level attack: the attacker floods a remote resolver with forged packets. But recent research has demonstrated that a malicious application running locally on your own device can make the attack far easier. A study covering multiple operating systems showed that a malicious app installed on the same device can collaborate with a remote attacker to infer sensitive connection details, including the UDP source ports used by the local DNS stub resolver. Once those ports are known, the guessing problem that makes remote poisoning difficult largely disappears.3arXiv. Cross User/App Network Attacks – Hijacking TCP Connections and DNS Cache Poisoning via a Malicious User/App (Extended Version)
The researchers demonstrated DNS cache poisoning against Windows, Android, and the widely used systemd-resolved stub resolver in Linux. They also showed TCP connection hijacking across Linux, Android, Windows, macOS, and iOS, meaning that a single malicious app with no special permissions could undermine both DNS integrity and active connections. This matters because the traditional advice of “use a trusted resolver” does not help if the poisoning happens between your device and that resolver, at the stub-resolver level on your own machine.
Why DNS Proxies Make Things Worse
Many internet service providers, corporate networks, and consumer routers run DNS proxies, which are middlemen that sit between your device’s resolver and the upstream recursive resolver. These proxies cache DNS responses locally to reduce latency and bandwidth. The problem is that poisoning a proxy can affect every device behind it. A compromised home router proxy poisons DNS for every phone, laptop, and smart TV on the network. A poisoned ISP proxy can redirect traffic for thousands of subscribers.
Research on the quality of DNS service through proxies has highlighted that these intermediaries play a critical role and are therefore prime attack targets. One approach proposed to counter this is cooperative cross-referencing between DNS proxies, where proxies compare their cached answers with peers to detect inconsistencies.4ACM Transactions on Internet Technology. A Proxy View of Quality of Domain Name Service, Poisoning Attacks and Survival Strategies The idea is that if one proxy has been poisoned, neighboring proxies will hold different (correct) answers for the same domain, and the disagreement raises a flag. In practice, this kind of cooperative defense has not been widely deployed, leaving most DNS proxies to fend for themselves.
Defenses That Exist Today
Several layers of defense have been developed since DNS poisoning first became a recognized threat. None of them is a silver bullet on its own, but together they raise the bar considerably.
Source port randomization was the emergency fix deployed across the internet in the immediate wake of the Kaminsky disclosure. By randomizing the UDP source port for each outgoing query, resolvers force attackers to guess both the transaction ID and the port number, multiplying the number of forged packets needed for a successful attack by orders of magnitude. Virtually all modern resolvers use this, but it is a probabilistic defense, not an absolute one.
DNSSEC (Domain Name System Security Extensions) takes a fundamentally different approach. Instead of relying on guessing entropy, DNSSEC adds cryptographic signatures to DNS records. A resolver that supports DNSSEC validation can check whether a response was actually signed by the domain’s authoritative server. If the signature does not match, the response is rejected. DNSSEC, when fully deployed, makes cache poisoning extremely difficult because the attacker would need to forge a cryptographic signature, which is computationally infeasible with current algorithms. The catch is that DNSSEC adoption has been slow and uneven. Configuring it correctly is error-prone, and misconfigured DNSSEC can break legitimate DNS resolution entirely, which discourages operators from turning it on.
DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the communication channel between your device and the resolver. Encryption prevents an attacker sitting on the network path from reading or tampering with DNS queries and responses in transit. These protocols protect against on-path interception but do not directly prevent cache poisoning at the resolver itself. If the resolver’s cache has already been poisoned, DoH and DoT will faithfully deliver the poisoned answer over an encrypted channel. They are complementary to DNSSEC, not a replacement for it.
Detecting Poisoning in Real Time
Because no single preventive measure is foolproof, detection systems have become an important second line of defense. One approach treats the DNS cache like a physical environment that can be continuously monitored with sensors. A system described as DNS-Sensor works by continuously scanning cached DNS records and comparing them against authoritative data to flag discrepancies with high precision.5PubMed Central. DNS-Sensor: A Sensor-Driven Architecture for Real-Time DNS Cache Poisoning Detection and Mitigation If a cached record says example.com points to one IP address but the authoritative server says it should point to a different one, the mismatch is flagged for investigation or automatic correction.
A different mitigation strategy focuses on identifying attack traffic before it enters the cache. One system designed for this purpose achieved an attack success rate of just 0.0076% by identifying and dropping malicious packets after only a handful had been observed, while maintaining a false-positive rate around 1 to 2 percent on mixed benign and malicious traffic.6arXiv. DNS-CPM: DNS Cache Poisoning Mitigation – Section: 6 Results That kind of near-zero success rate for attackers represents a major improvement, though real-world deployment is always messier than lab conditions. The false-positive rate matters too: if a defense system occasionally blocks legitimate DNS responses, it disrupts normal browsing, which creates pressure on operators to loosen the filtering.
How to Reduce Your Own Risk
You cannot single-handedly fix DNS poisoning across the internet, but a few practical steps reduce your exposure considerably.
Choosing a reputable public DNS resolver like those operated by Cloudflare, Google, or Quad9 gives you the benefit of infrastructure teams that actively deploy DNSSEC validation, rate limiting, and anomaly detection. Your ISP’s default resolver may or may not have the same protections. Switching is usually a matter of changing one or two settings on your router or device.
Enabling DNS over HTTPS or DNS over TLS on your device or browser encrypts your queries in transit, preventing local network attackers from tampering with them on the way to the resolver. Most major browsers now support DoH, and Android has built-in DoT support. This does not protect you from poisoning at the resolver itself, but it eliminates the on-path attack vector.
Keeping software updated matters more than it might seem. The local-device attack vector described earlier relies on a malicious app inferring stub-resolver port numbers. Operating system patches that randomize these values more aggressively or restrict inter-process network visibility close that attack path.7arXiv. Cross User/App Network Attacks – Hijacking TCP Connections and DNS Cache Poisoning via a Malicious User/App (Extended Version) Avoiding sideloaded apps from untrusted sources also reduces the chance that a malicious application ends up on your device in the first place.
Paying attention to certificate warnings in your browser is a last-resort safety net. If an attacker has poisoned DNS but does not have a valid TLS certificate for the site they are impersonating, your browser will display a warning. Clicking through that warning defeats the one protection still standing between you and the fake site. The fraudulent certificate scenario described earlier is specifically dangerous because it removes even this warning, but it requires a more complex and targeted attack.
Common Misconceptions
One widespread misunderstanding is that HTTPS by itself prevents DNS poisoning from doing any harm. HTTPS encrypts the data between your browser and the server and verifies the server’s identity through certificates, but it does nothing to ensure you reached the right server in the first place. If DNS is poisoned and the attacker has obtained a fraudulent certificate, the connection will appear fully secure. The padlock icon in your browser means the connection is encrypted to whatever server you reached, not that you reached the right server.
Another misconception is that DNS poisoning is a relic of the early internet, fully solved by modern defenses. Source port randomization raised the difficulty of the attack substantially, and DNSSEC can prevent it outright when properly deployed. But DNSSEC deployment remains incomplete across much of the internet, and the local-device attack vectors demonstrated on modern operating systems show that new paths to poisoning keep appearing as software architectures evolve. The threat has changed shape, but it has not gone away.
People also tend to conflate DNS poisoning with DNS hijacking, but they are distinct. DNS hijacking involves an attacker taking control of the authoritative DNS server itself or the domain registrar account, changing the actual records at the source. DNS poisoning corrupts cached copies of those records downstream, without touching the authoritative server. The authoritative records remain correct the entire time; it is only the copies stored closer to the user that are wrong. The distinction matters for remediation. Hijacking requires reclaiming control of the compromised account or server. Poisoning is resolved by flushing the corrupted cache and preventing the attack from succeeding again.
When Flushing Your DNS Cache Actually Helps
You may have seen advice to “flush your DNS cache” as a troubleshooting step. On your own device, this clears locally stored DNS records and forces fresh lookups. If your device’s stub resolver was holding a poisoned record, flushing removes it. On Windows, the command is “ipconfig /flushdns”; on macOS, variants of “dscacheutil -flushcache” or “sudo killall -HUP mDNSResponder” apply depending on the OS version; and on Linux with systemd-resolved, “resolvectl flush-caches” does the job.
The limitation is that flushing your local cache does nothing about upstream poisoning. If the ISP’s resolver or your router’s DNS proxy is holding a poisoned record, your freshly flushed device will immediately re-fetch the poisoned answer from that upstream source. Flushing is a useful diagnostic step and clears stale records, but it is not a cure when the poisoning lives further up the chain. In those cases, switching to a different resolver entirely is the more effective response.