DNS Spoofing and Cache Poisoning

DNS spoofing is the act of supplying a forged DNS response so the victim resolves a name to an attacker-controlled IP. Cache poisoning is a specific form where the forged answer is accepted and stored by a recursive resolver, infecting every client that uses it.

The goal is usually traffic redirection: sending users to phishing pages, malware drops, or man-in-the-middle proxies.

When a resolver sends a query, an attacker tries to inject a forged reply before the legitimate authoritative server answers. If the forgery arrives first and matches the expected fields, it wins the race and gets cached.

This is why latency, packet ordering, and the resolver outbound port all matter so much in attack and defense.

For a forged UDP response to be accepted, the attacker must match:

• The source IP (the authoritative server).
• The destination port (the resolver outbound port).
• The query name and type.
• The 16-bit transaction ID (TXID).

Without protections, the only real secret is the TXID, giving roughly 1 in 65,536 odds per packet.

Dan Kaminsky 2008 disclosure showed poisoning was far easier than thought. Instead of one race per record, the attacker queries many non-existent subdomains (aaa.bank.com, aab.bank.com...) and floods forged answers containing a malicious NS or glue record for the whole domain.

Each attempt is a fresh race with no caching penalty for a miss, so the attacker can grind until a guess lands and poison the entire zone.

The primary post-Kaminsky mitigation was source port randomization. Instead of a fixed outbound port, the resolver picks a random ephemeral port for each query.

Now the attacker must guess both the TXID (16 bits) and the source port (~16 bits), expanding the search space to roughly 2^32. This makes blind off-path poisoning impractical, though not impossible on weak entropy implementations.

An off-path attacker cannot see the query and must blindly guess the TXID and port. An on-path attacker (rogue Wi-Fi, compromised router, ISP) can read the query directly and trivially craft a matching answer.

On-path spoofing defeats port randomization entirely, which is why encrypted transport and DNSSEC validation are needed for strong assurance, not just entropy.

Attackers do not always forge packets. A rogue DHCP server can hand clients a malicious DNS resolver address, so every lookup is answered by the attacker. Malware similarly rewrites /etc/resolv.conf or router settings.

Historic threats like DNSChanger malware silently repointed victim DNS to fraudulent servers for years. Validate which resolvers your fleet actually uses.

Resolvers enforce bailiwick rules: a response can only supply records for names within the zone it is authoritative for. An answer for bank.com cannot smuggle in a record for unrelated.com.

This limits Kaminsky-style injections to the queried domain and prevents one poisoned answer from polluting unrelated zones. Verify your resolver enforces strict bailiwick filtering.

Signs of an in-progress or successful poisoning:

• A spike of queries for random, non-existent subdomains.
• Duplicate or out-of-order DNS responses for the same TXID.
• Resolved IPs that suddenly point to unexpected ASNs or geographies.
• Mismatch between resolver answers and a trusted out-of-band lookup.

No single control is enough. Combine:

• Source port + TXID randomization to raise off-path cost.
• DNSSEC validation so forged answers fail signature checks.
• DoT/DoH to deny on-path attackers visibility and tampering.
• 0x20 encoding (random case in query names) for extra entropy.
• Monitoring for NXDOMAIN floods and answer anomalies.

In practice, blind off-path cache poisoning is rare today on patched resolvers, but it resurfaces through side channels (for example UDP fragmentation and ICMP-based port inference attacks like SAD DNS). Keep resolvers patched and prefer validating, encrypted resolvers.

Remember: the highest-impact DNS compromise is often not a clever poisoning race but a stolen registrar account. Protect both ends.

Check your grasp of the Kaminsky technique.

DNS spoofing forges responses; cache poisoning persists them in a resolver. Acceptance hinges on matching source IP, port, query name, and TXID. Source port randomization and bailiwick checks raised the bar against off-path attackers, but on-path attackers and side channels remain.

Defense in depth (entropy, DNSSEC validation, encrypted transport, and monitoring) is essential. Next we look at how attackers abuse DNS to move data: tunneling and exfiltration.