DNS Poisoning

DNS poisoning is an attack that corrupts that lookup process, redirecting users to malicious destinations without altering anything on the target server. This post breaks down how DNS poisoning works at a protocol level, why it remains a relevant threat, and what you can do to detect and defend against it.

How DNS Resolution Creates an Attack Surface

To understand DNS poisoning, you need to understand how recursive resolution works. When a client queries a domain, the request typically flows through a recursive resolver (your ISP's, Cloudflare's 1.1.1.1, or a self-hosted instance like Technitium). That resolver walks the delegation chain, including the root servers, TLD nameservers, authoritative nameservers, then caches the response according to the TTL value in the record.

The vulnerability is in that cache. DNS was designed in 1983 (RFC 882/883, later RFC 1035) with no authentication, and responses are matched to queries using a 16-bit transaction ID (TXID) and the source port of the outgoing query. If an attacker can predict or brute-force those values and deliver a forged response before the legitimate reply arrives, the resolver accepts and caches the poisoned record.

That cached lie then gets served to every client using that resolver until the TTL expires.

The Kaminsky Attack

Before 2008, DNS poisoning was considered impractical at scale because the attacker had to wait for a cached record to expire before attempting injection. Dan Kaminsky's research dismantled that assumption.

Kaminsky demonstrated that an attacker could trigger queries for random, non-existent subdomains that would never be cached (like abc123.example.com) and flood the resolver with forged responses. Each forged response included an authority section that delegated example.com itself to an attacker-controlled nameserver. Because the subdomains were unique, every attempt was a fresh race condition against the actual authoritative response.

This turned DNS poisoning from a low-probability single-shot into a repeatable attack. The TXID keyspace of 65,536 values could be exhausted in seconds. The coordinated patch that followed (source port randomisation RFC 5452) expanded the effective entropy by randomising the UDP source port, but it was only a mitigation, the lack of cryptographic authentication in DNS remained.

Attack Variants Beyond Classic Cache Poisoning

DNS poisoning isn't limited to racing responses against a recursive resolver. There are other adjacent techniques achieve similar outcomes.

Rogue DHCP/gateway attacks on local networks can push a malicious DNS server to clients directly. On shared or poorly segmented networks, ARP spoofing allows an attacker to intercept DNS queries at layer 2 and return arbitrary responses, basically a MITM at the resolution layer.

BGP hijacking has been used to redirect DNS traffic at the routing level. In 2018, attackers briefly hijacked Amazon's Route 53 IP space via a BGP leak at an IXP, redirecting DNS queries for a cryptocurrency wallet service to a phishing endpoint. This was not cache poisoning in the traditional sense, but achieved the same effect with users receiving valid-looking but attacker-controlled responses.

Compromised or malicious resolvers are another possibility. Public Wi-Fi captive portals, ISP-level interception, and nation-state DNS filtering all modify responses in transit. The user's resolver simply cannot be trusted in these environments.

Detection and Visibility

Detecting DNS poisoning may have some indicators:

• Unexpected TTL shifts: a record that normally carries a 3600s TTL suddenly appearing with a 60s or 86400s value can indicate injection.
• Authority section anomalies: responses containing delegation records pointing to unfamiliar nameservers.
• DNSSEC validation failures: if you're validating, SERVFAIL responses on domains that should resolve cleanly can indicate tampering upstream.
• Query log analysis: high volumes of NXDOMAIN responses for random subdomains of a single domain may indicate a Kaminsky-style attack in progress.

Tools like dnstap (passive DNS telemetry) and Zeek (aka Bro) with its DNS analyser module can capture and analyse DNS traffic at scale. For self-hosted resolvers, Technitium DNS Server provides built-in query logging and supports DNSSEC validation natively.

Defence in Depth

No single control eliminates DNS poisoning. As usual, effective defence is layered.

DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that a response genuinely originated from the authoritative zone.

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the transport layer, preventing on-path interception and modification. They don't replace DNSSEC but together they address both authentication and confidentiality.

Running your own validating resolver (Unbound, Knot Resolver, Technitium) gives you control over cache behaviour, DNSSEC policy, and query logging as you're no longer trusting a third party's cache integrity.

Thirty years of patches, extensions, and encryption layers have narrowed the attack surface, but the core protocol remains unauthenticated by default. Understanding where that trust breaks down is the first step toward building infrastructure that doesn't depend on it.