DNS cache poisoning

What it is#

DNS cache poisoning (also called DNS spoofing) is an attack where a forged DNS response is injected into a recursive resolver's cache, causing the resolver to return an attacker-controlled IP address for subsequent queries. Once the poisoned entry is cached, every user relying on that resolver is silently redirected (to a phishing site, a malware distribution server, or an interception proxy) until the TTL expires. The attack is particularly dangerous because victims see the correct domain name in their browser; nothing appears wrong.

Understanding how DNS cache poisoning works requires familiarity with how DNS resolution operates and the trust model that standard DNS relies on.

The classic attack#

Traditional DNS queries use UDP, a connectionless protocol with no built-in authentication. A resolver sends a query and accepts the first response that matches the query name, query type, source port, and a 16-bit transaction ID. In the classic poisoning attack, the attacker floods the resolver with forged responses while a legitimate query is outstanding, racing the authoritative server. If the forged response arrives first with a correct transaction ID guess (1-in-65,536 odds per packet), the resolver caches it.

The original attack was considered impractical because the attacker needed to predict the transaction ID and could only attempt it once per query. Each failed attempt meant waiting for the cached entry to expire.

The Kaminsky attack (2008)#

Dan Kaminsky demonstrated a far more practical variant. Instead of querying for a name already cached, the attacker triggers queries for random, non-existent subdomains (e.g., aaa.example.com, aab.example.com). Since these names aren't cached, the resolver immediately sends a new query for each one, giving the attacker unlimited attempts in rapid succession. Each forged response includes a delegated referral (an authority section pointing example.com's NS record to the attacker's name servers). One successful injection poisons the resolver's record for the entire domain, not just a single hostname.

This attack was devastating because it required no privileged network position and could compromise a busy resolver in seconds.

Mitigations#

The security community responded with layered defenses:

• Source port randomization. Resolvers now use random source ports in addition to random transaction IDs, multiplying the entropy an attacker must guess (from ~16 bits to ~32 bits)
• DNSSEC. Cryptographically signed responses allow resolvers to reject forged data, though adoption remains incomplete
• DNS cookies. A lightweight authentication mechanism between resolvers and authoritative servers
• Response Rate Limiting (RRL). Reduces the volume of responses an authoritative server sends to any single source, limiting amplification

Despite these defenses, cache poisoning is not a solved problem. Research like SAD DNS (2020) demonstrated side-channel attacks that can infer a resolver's source port by probing ICMP rate limits, partially defeating port randomization. Resolvers that lack DNSSEC validation remain at elevated risk.

Real-world impact#

A successful poisoning is invisible to end users. Traffic to a bank, email provider, or internal corporate domain can be redirected to a server that presents a valid-looking page (potentially with a separately obtained TLS certificate) and harvests credentials. The 2018 DNSpionage campaign is sometimes cited alongside cache poisoning, but that operation primarily used DNS hijacking, compromising registrar accounts and authoritative DNS infrastructure to redirect resolution for government and telecommunications organizations in the Middle East. It illustrates how DNS manipulation at the authoritative level achieves the same redirection effect as cache poisoning, but through a different and more persistent mechanism.

Cache poisoning can redirect traffic away from legitimate domains without the domain owner being directly compromised; the attack targets the resolver infrastructure, not the domain itself. For defense in depth, deploying DNSSEC on owned domains and using DNS filtering to monitor for unexpected resolution results complement traditional domain monitoring.