DNS Cache Poisoning: How Attackers Hijack Your DNS Traffic

What Is DNS Cache Poisoning?

DNS cache poisoning (also called DNS spoofing) is a cyberattack that introduces forged DNS records into a resolver's cache. Once poisoned, the resolver serves the malicious record to every user who queries it — directing them to an attacker-controlled IP address instead of the legitimate destination.

The attack exploits the fundamental trust model of traditional DNS: resolvers accept responses that appear to come from authoritative name servers, and once a record is cached, it's served without re-validation until the TTL expires.

A successful DNS poisoning attack is invisible to the victim. You type yourbank.com, your browser shows the correct URL in the address bar, and you're presented with a perfect clone of your bank's login page — hosted on an attacker's server. Everything looks normal until you enter your credentials.

To check whether your DNS is responding with expected results for known domains, run a DNS leak test and compare the resolver responses against known-good values.

How DNS Cache Poisoning Attacks Work

The classic DNS cache poisoning attack, demonstrated by researcher Dan Kaminsky in 2008, works like this:

1. Triggering a query: The attacker causes a recursive resolver to send a DNS query for a domain they want to poison — for example, by requesting thousands of subdomains of the target domain.
2. Flooding with forged responses: Before the legitimate authoritative server can respond, the attacker floods the resolver with fake DNS responses containing the malicious IP address.
3. Guessing the transaction ID: DNS queries include a 16-bit transaction ID. The attacker must match this ID in their forged response. With only 65,536 possible values and multiple attempts per second, this is feasible with a fast attack.
4. Cache injection: If a forged response arrives before the legitimate one and matches the transaction ID, the resolver caches the malicious record.
5. Traffic hijacking: All users of the poisoned resolver are now directed to the attacker's server for the poisoned domain until the TTL expires.

Modern attacks exploit additional entropy weaknesses, use DNS amplification, or target specific resolver software vulnerabilities. The NXNS attack (2020) and TuDoor attack (2022) are examples of post-Kaminsky DNS attack vectors.

Real-World DNS Poisoning Incidents

DNS cache poisoning is not theoretical — it has caused major real-world incidents:

Pakistan Telecom / YouTube (2008): Pakistan Telecom accidentally leaked a bogus route for YouTube's IP addresses during an attempt to block the site domestically. The poisoned routing spread globally, taking YouTube offline worldwide for hours.

Brazil DNS Poisoning (2011): Brazilian users were redirected from major websites including Google to malware-distributing clones. ISP-level DNS servers were compromised and served malicious records to millions of users for over a week.

MyEtherWallet Attack (2018): Attackers hijacked the BGP route for Amazon Route53's DNS servers and poisoned DNS for MyEtherWallet, a cryptocurrency wallet service. Users were redirected to a phishing site and lost over $150,000 in Ethereum within hours.

Government-Sponsored DNS Manipulation: Several nation-states have used DNS poisoning to censor internet content or redirect users to surveillance infrastructure. Iran's DNS infrastructure has been observed serving false records for international services.

These incidents illustrate that DNS poisoning can affect anyone using a compromised resolver — even users who have no interaction with malicious content themselves.

DNSSEC: The Defense Against DNS Poisoning

DNSSEC (DNS Security Extensions) is the primary cryptographic defense against DNS cache poisoning. It adds digital signatures to DNS records, allowing resolvers to verify that responses came from the legitimate authoritative server and haven't been tampered with.

How DNSSEC works:

• Each zone has a Zone Signing Key (ZSK) that signs all DNS records.
• A Key Signing Key (KSK) signs the ZSK, creating a chain of trust.
• The parent zone stores a DS (Delegation Signer) record — a hash of the child zone's KSK — creating an unbroken chain from the root zone to every signed domain.
• Resolvers that support DNSSEC validation (called "DNSSEC-aware" resolvers) can verify each link in this chain and reject unsigned or tampered records.

DNSSEC adoption is uneven. The root zone and most TLDs are signed, but many individual domains are not. According to ICANN data, roughly 35% of domains that could use DNSSEC validation actually do. Check a domain's DNSSEC status using our WHOIS lookup.

Important: DNSSEC does not encrypt DNS queries (that's what DoH/DoT is for). It only authenticates them — ensuring the record is genuine, not private.

How to Protect Yourself from DNS Attacks

While you can't control the security of DNS resolvers you use, you can take several steps to minimize your risk:

• Use a secure DNS provider: Major public resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8) implement DNSSEC validation and have hardened infrastructure far more resistant to poisoning than typical ISP resolvers. See our comparison of best public DNS servers.
• Enable DNS over HTTPS or DoT: DoH and DoT encrypt your DNS queries, preventing interception and response injection on your local network or at the ISP level.
• Use HTTPS everywhere: Even if DNS is poisoned and you're directed to a fake server, HTTPS certificate verification (and HSTS) will typically show a browser warning if the attacker doesn't have a valid certificate for the domain. Always pay attention to certificate warnings.
• Monitor for unexpected changes: If a website you visit frequently suddenly looks different or asks you to re-authenticate, be suspicious. Verify the SSL certificate details.
• Run a DNS leak test: Regularly check which resolver is handling your queries. If it's not the one you configured, investigate immediately.

Frequently Asked Questions