What is DNS Cache Poisoning?
DNS cache poisoning is one of the oldest and most dangerous attacks on the internet's naming system. It works by tricking DNS resolvers into storing fake records, silently redirecting users to malicious websites.
Quick Answer
DNS cache poisoning (also called DNS spoofing) happens when an attacker injects false DNS records into a resolver's cache. When users query that resolver for a domain like yoursite.com, they receive a fake IP address and get sent to a server controlled by the attacker instead of the real one. The attack exploits the fact that DNS was built on trust, with no built-in way to verify that a response is genuine. Defenses include DNSSEC, encrypted DNS (DoH/DoT), using trusted resolvers like Quad9 or Cloudflare, and enforcing HTTPS on your website.
How DNS Caching Works (And Why It Can Be Exploited)
Every time you visit a website, your device asks a DNS resolver for the IP address behind that domain name. The resolver finds the answer and stores it temporarily in its cache so it can respond faster next time someone asks the same question. This cached copy is kept for a duration set by the record's TTL (Time to Live).
This caching system makes the internet faster, but it also creates a vulnerability. DNS was designed in the 1980s for a much smaller, more trusted network. It uses UDP (User Datagram Protocol) for communication, which has no built-in handshake or identity verification. A DNS resolver has no reliable way to confirm that a response actually came from the server it asked. If an attacker can send a fake response that arrives before the real one, the resolver accepts it and stores it in the cache.
That poisoned cache entry then gets served to every user who queries that resolver for the same domain, until the TTL expires or the cache is manually flushed.
How a DNS Cache Poisoning Attack Works
The core idea is simple: race the legitimate DNS response. When a resolver sends a query to an authoritative server, the attacker floods it with forged responses, each guessing the transaction ID and source port that the resolver used. If one of those forged responses matches before the real answer arrives, the resolver treats it as legitimate and caches the fake record.
Step 1: Trigger a DNS query
The attacker sends a request to the target resolver for a domain, forcing the resolver to query the authoritative nameserver.
Step 2: Flood with fake responses
Before the real nameserver can reply, the attacker sends thousands of forged UDP packets to the resolver. Each packet claims to be the answer and contains a fake IP address pointing to a server the attacker controls.
Step 3: Match the transaction ID
Each DNS query has a 16-bit transaction ID. The forged response must match this ID exactly. With only 65,536 possible values, the attacker can guess it by sending many packets rapidly.
Step 4: Cache is poisoned
If a forged response arrives first and matches the transaction ID and port, the resolver caches the fake record. Every user querying that domain through this resolver now gets redirected to the attacker's server.
The Kaminsky Attack (2008)
In 2008, security researcher Dan Kaminsky discovered a flaw that made DNS cache poisoning far easier than anyone realized. Before his discovery, an attacker had to wait for a cached record to expire before attempting to replace it. Kaminsky found a way to bypass this limitation entirely.
His technique involved querying the resolver for random, non-existent subdomains (like abc123.example.com). Since these subdomains were never cached, the resolver had to query the authoritative server every time. In each forged response, the attacker included a fake NS record for the entire parent domain, effectively taking control of all DNS resolution for that domain.
This discovery led to an emergency coordinated patch across DNS software vendors worldwide. It also pushed for stronger randomization of source ports and transaction IDs, making the attack harder but not impossible.
What Attackers Can Do With It
| Attack Type | How It Works |
|---|---|
| Phishing | Redirect users to a fake version of a banking or email site that captures login credentials |
| Malware distribution | Serve malware downloads from a server that looks like a legitimate software update site |
| Email interception | Poison MX records to redirect incoming email to an attacker-controlled mail server |
| Man-in-the-middle | Sit between the user and the real server, intercepting and modifying traffic in both directions |
| Censorship | Some ISPs have used DNS manipulation to block access to specific websites or inject advertisements |
In 2018, attackers poisoned DNS records for MyEtherWallet (a cryptocurrency wallet), redirecting users to a fake site that stole over $17 million in Ethereum. The users typed the correct URL, their browser showed the right domain name, but the DNS resolution pointed to the attacker's server.
Signs Your DNS Might Be Poisoned
Unexpected website redirects
You type a familiar URL but the page looks different, has a different layout, or asks you to log in when it normally wouldn't.
SSL certificate warnings on trusted sites
Your browser shows a certificate error for a site you visit regularly. The attacker's server won't have the legitimate SSL certificate, triggering this warning.
DNS results differ across locations
When you check your domain with a propagation checker and one or two servers return a completely different IP than the rest, that resolver may have been poisoned.
Sudden drop in website traffic
If visitors using a specific ISP or region suddenly stop reaching your site, their DNS resolver may be serving a poisoned record for your domain.
How to Protect Against DNS Cache Poisoning
Use trusted DNS resolvers
Switch to major public resolvers like Cloudflare (1.1.1.1), Google (8.8.8.8), or Quad9 (9.9.9.9). These providers use source port randomization, DNSSEC validation, and other hardening measures that make poisoning attacks significantly harder.
Enable DNSSEC on your domain
DNSSEC adds cryptographic signatures to DNS responses, allowing resolvers to verify that a record actually came from the authoritative server. If you use Cloudflare for DNS, enabling DNSSEC is a one-click setting. This is the most effective defense against cache poisoning.
Enforce HTTPS on your site
Even if DNS is poisoned and users get redirected, HTTPS ensures the attacker's server can't present a valid SSL certificate for your domain. Visitors will see a browser warning instead of unknowingly entering credentials. Use HSTS headers to prevent HTTP fallback.
Use encrypted DNS (DoH or DoT)
DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries between your device and the resolver, preventing attackers from intercepting or modifying queries in transit. Most modern browsers support DoH.
Flush your DNS cache regularly
If you suspect poisoning, flush your local DNS cache to clear any stored fake records and force fresh lookups.
Monitor your DNS records
Regularly check your domain's DNS records from multiple global locations. If a resolver returns unexpected results, investigate immediately.
Check Your DNS Records Globally
Verify your domain resolves correctly across 21 global DNS servers. Inconsistent results could indicate a poisoned resolver.