DNS Cache Poisoning: How Attackers Redirect Your Traffic Without Breaking In

How DNS caching works — and why it matters

When your computer needs to resolve a domain name, it asks a DNS resolver (usually operated by your ISP or a service like 1.1.1.1 or 8.8.8.8). The resolver queries the authoritative DNS servers, gets the answer, and returns it to you. To avoid repeating this process for every request, resolvers cache the answers for as long as the TTL (Time to Live) value specifies — often minutes to hours.

This caching is what makes DNS fast and scalable. It is also what makes DNS cache poisoning possible.

How the poisoning attack works

DNS was originally designed without authentication. When a resolver sends a query, any server that responds first with the right transaction ID can answer it — and the resolver will cache that answer.

An attacker who can observe or guess the transaction ID can send a forged response that arrives before the legitimate one. Once the resolver caches the poisoned answer, every user who relies on that resolver will be sent to the attacker's server for the duration of the TTL — even if the attacker never gains access to the actual web server or DNS zone.

The Kaminsky attack (2008)

In 2008, security researcher Dan Kaminsky discovered a critical flaw that made DNS cache poisoning dramatically easier than previously thought. The classic poisoning attack required guessing a 16-bit transaction ID — only 65,535 possibilities — but attackers had to time their attempt precisely between query and response.

Kaminsky's insight was to query for random subdomains of the target domain (e.g., random1234.example.com, random5678.example.com) in rapid succession. Each query triggered a new resolver request to the authoritative server. By flooding the resolver with forged responses — all claiming to be the authoritative answer and including a poisoned record for example.com itself — an attacker could poison the cache in seconds.

This vulnerability affected nearly every DNS implementation in the world. It was quietly coordinated across major vendors (BIND, Microsoft, Cisco) before public disclosure and patched via source port randomization, which added an effective 32 bits of entropy to transaction identification.

Real incidents caused by DNS poisoning

• Brazil (2011) — DNS cache poisoning attacks redirected users from major Brazilian bank websites to phishing pages that stole login credentials from hundreds of thousands of customers.
• Pakistan Telecom / YouTube (2008) — While not a poisoning attack in the classic sense, Pakistan Telecom accidentally leaked a poisoned BGP route that redirected YouTube traffic globally for two hours.
• AWS Route 53 attack (2018) — Attackers used BGP hijacking combined with DNS manipulation to redirect cryptocurrency service MyEtherWallet's traffic to a phishing server for two hours, stealing approximately $160,000.

How to defend against DNS cache poisoning

Several layers of defense exist:

• DNSSEC — DNS Security Extensions add cryptographic signatures to DNS records. A resolver with DNSSEC validation can verify that a response genuinely came from the authoritative server and has not been tampered with. This is the most complete defense against cache poisoning.
• DNS over HTTPS (DoH) / DNS over TLS (DoT) — Encrypts the DNS query transport, preventing attackers from seeing and racing against queries.
• Short TTLs — Reducing TTL values limits how long a poisoned record persists in the cache, containing the damage window.
• Use reputable resolvers — Resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8) implement modern anti-poisoning techniques including source port randomization and 0x20 encoding.