The basics of DNS cache poisoning
Every time a user visits a website, a DNS query resolves the domain name to an IP address. This process relies on caching, where recursive resolvers store previous lookup results to speed up future requests.
DNS cache poisoning exploits this by injecting forged records into a resolver’s cache, redirecting users to attacker-controlled infrastructure without altering anything on the target’s servers. The domain still appears correct in the browser, but the traffic is going somewhere else entirely.
How DNS cache poisoning works
DNS resolution is a chain of trust. A user’s device trusts the recursive resolver to return the correct IP address, and the recursive resolver trusts that the response it receives from the authoritative nameserver is genuine. Cache poisoning breaks that chain by inserting a forged response into the DNS lookup process before the real one arrives.
When a user types a domain into their browser, the operating system checks its local DNS cache. If there is no stored result, the query goes to a recursive resolver, which queries the DNS hierarchy on the user’s behalf: first root servers, then TLD (top-level domain) nameservers, and finally the authoritative nameserver for the target domain. The authoritative server responds with the correct IP address, and the resolver caches that result for the duration of the record’s TTL (time to live). Every subsequent query for the same domain gets the cached answer instead of triggering a fresh lookup.
Cache poisoning targets the gap between the outgoing query and the incoming response. While a legitimate query is in flight, an attacker floods the resolver with spoofed DNS responses, each mapping the queried domain to an IP the attacker controls. If one of those forged responses arrives before the real answer and matches the expected 16-bit transaction ID and UDP source port, the resolver accepts it as legitimate. The forged DNS record gets cached and served to every subsequent user for the entire TTL duration.
Common DNS cache poisoning attack techniques
There are several well-documented techniques attackers use to win this race.
1. Classic response spoofing
The simplest form relies on brute force. The transaction ID is only 16 bits, meaning 65,536 possible values. In older resolver configurations where source ports were static or predictable, an attacker could guess both values at a reasonable success rate. Modern resolvers randomise source ports, but the fundamental race condition remains exploitable through more advanced techniques.
2. The Kaminsky attack
First demonstrated in 2008, the Kaminsky attack elevated cache poisoning from a single-record attack to a domain-wide compromise. Instead of targeting a cached record, the attacker queries the resolver for a random, non-existent subdomain. Because the resolver has no cached answer, it must query the authoritative server. The attacker races a spoofed response with a forged authority section, delegating the entire domain zone to an attacker-controlled nameserver. If the spoofed response wins, the attacker controls resolution for every record under that domain.
3. SAD DNS (side-channel port inference)
After the Kaminsky disclosure, source port randomisation became standard. SAD DNS (Side-channel AttackeD DNS), published in 2020, demonstrated that this defence could be bypassed. The attack exploits ICMP rate-limiting behaviour in the Linux kernel to infer which ephemeral port a resolver is using for a given query. By sending crafted UDP probes and observing ICMP “port unreachable” responses, the attacker narrows the source port guessing space from tens of thousands to a handful. Combined with transaction ID brute-forcing, this makes off-path cache poisoning practical again.
4. Fragmentation-based injection
DNS responses over UDP can be fragmented when they exceed the path MTU (Maximum Transmission Unit). The attacker forces a legitimate response to split into multiple IP fragments, then injects a forged second fragment containing a malicious answer section. Because fragment reassembly relies on offset and identification fields rather than cryptographic verification, the resolver reconstructs a response combining the legitimate header with the attacker’s payload. The transaction ID and port checks pass because those fields sit in the genuine first fragment.
5. Local network poisoning
On shared networks like public Wi-Fi or corporate guest networks, an attacker with local access can intercept DNS queries directly using ARP (Address Resolution Protocol) spoofing or rogue DHCP (Dynamic Host Configuration Protocol) responses. This bypasses the need to guess transaction IDs or source ports entirely, because the attacker effectively sits on the network path between the client and the resolver. The attacker intercepts the query and returns a forged response before the real resolver can answer.
How to prevent DNS cache poisoning
The most direct countermeasure is DNSSEC, which adds cryptographic signatures to DNS records so resolvers can verify that a response came from the authoritative nameserver and has not been modified in transit. Any forged DNS record without the correct signature gets rejected. The limitation is that both the domain owner and the resolver must support DNSSEC for validation to work, and adoption remains incomplete, standing at about 35% due to significant operational and deployment challenges.
Encrypting DNS traffic with DNS over HTTPS (DoH) or DNS over TLS (DoT) prevents on-path attackers from spoofing queries between the client and resolver. This is especially relevant on untrusted networks where local poisoning is most practical. Reducing TTL values for sensitive records limits the damage window if poisoning succeeds. Monitoring DNS traffic for anomalies, such as sudden query spikes, unexpected source addresses, or elevated NXDOMAIN rates, provides early warning of a cache poisoning attack in progress.
Frequently asked questions
DNS cache poisoning sits at the intersection of protocol design, network architecture, and resolver configuration. These are some of the most common questions security teams ask when evaluating their exposure.
What is the difference between DNS cache poisoning and DNS spoofing?
DNS spoofing is the broader term for any technique that returns a forged DNS response. Cache poisoning is a specific type that targets a recursive resolver’s cache, meaning one successful attack redirects every user on that resolver. Other spoofing techniques, like man-in-the-middle attacks on a local network, typically affect only the individual device being targeted.
How many users can one DNS cache poisoning attack affect?
It depends on the resolver. A poisoned corporate resolver might affect a few hundred employees. A poisoned ISP or public DNS resolver could redirect thousands or millions of users. The forged DNS record persists for the entire TTL, so a long TTL on a popular resolver creates the largest blast radius.
How to detect cache poisoning?
Forged records look legitimate to end users, so detection relies on network-level DNS monitoring. Indicators include sudden query spikes for a specific domain, responses from unexpected source addresses, mismatched TTL values, or elevated NXDOMAIN rates. Regularly comparing cached records against authoritative responses can catch poisoned entries early.
Does DNSSEC prevent cache poisoning?
DNSSEC adds cryptographic signatures to DNS responses so resolvers can verify they came from the authoritative nameserver. Forged records without a valid signature get rejected. The limitation is that both the domain owner and the resolver must support DNSSEC for validation to work, and adoption remains incomplete.
How does secondary DNS help?
A secondary DNS service on a distributed anycast network removes the single point of failure. If the primary server is hit by a DDoS attack designed to force resolver timeouts (which create the conditions for poisoning), the secondary service keeps answering queries. Combined with DNSSEC validation, resolvers receive both available and cryptographically verified responses.
