DNS Cache Poisoning: How It Works and How DNSSEC Stops It

## What Is DNS Cache Poisoning? DNS cache poisoning (also called DNS spoofing) is an attack in which an adversary injects forged DNS records into a resolver's cache. When a user's device subsequently queries that resolver for a domain's IP address, the resolver returns the poisoned (false) record — pointing the user to an attacker-controlled server instead of the legitimate one. The attack is particularly dangerous because it is invisible to the user. The browser shows the correct domain name in the address bar. The user types the correct URL. Nothing appears wrong. But all traffic is flowing to the attacker's server. ## How DNS Works (Brief Recap) To understand the attack, recall how DNS resolution works: 1. A client queries a **recursive resolver** (often operated by an ISP or a public service like Cloudflare `1.1.1.1`). 2. The resolver checks its cache. If the record is cached and not expired, it returns it immediately. 3. If not cached, the resolver queries the **root servers**, then the **TLD name servers**, then the **authoritative name servers** for the domain. 4. The authoritative answer is cached by the resolver (for the TTL duration) and returned to the client. The cache exists for efficiency — without it, every DNS query would require a full trip up the hierarchy, adding latency to every page load. ## The Attack Mechanism In a cache poisoning attack, the adversary's goal is to have the resolver accept a forged DNS response before (or instead of) the legitimate authoritative response. **Classic Kaminsky-style attack (2008)**: DNS queries use a 16-bit transaction ID to match requests with responses. An attacker who can send many rapid forged responses — each with a different guessed transaction ID — has a reasonable probability of guessing correctly before the real response arrives. Once the forged response is cached, all subsequent clients receive the poisoned record until the TTL expires. Security researcher Dan Kaminsky disclosed a refined version of this attack in 2008, demonstrating that the core DNS protocol was fundamentally fragile. The immediate mitigation was **source port randomization** (adding another 16 bits of entropy to each query), making blind attacks vastly harder. But source port randomization is not a cryptographic defence — it only raises the cost of the attack. **On-path (man-in-the-middle) attacks**: An attacker with network-level access to a resolver's upstream path — through BGP hijacking, compromised infrastructure, or physical network access — can intercept legitimate DNS responses and substitute forged ones. Source port randomization does not help here: the attacker sees the real transaction ID and can craft a matching forged response. ## Impact of a Successful Poisoning Once a resolver's cache is poisoned, every user querying that resolver for the affected domain is silently redirected to the attacker's server. The attacker can: - **Serve a phishing site** that harvests credentials. - **Perform SSL stripping**, downgrading HTTPS connections to HTTP. - **Intercept email** by replacing MX records. - **Conduct further attacks** from a position of trust inside the user's expected connection. The scale of impact depends on how widely the poisoned resolver is used. A poisoned ISP resolver can affect millions of users simultaneously. ## DNSSEC: The Definitive Countermeasure DNSSEC solves cache poisoning by adding cryptographic authentication to DNS records. Every DNS response for a DNSSEC-signed zone is accompanied by a digital signature. Resolvers that validate DNSSEC (called **validating resolvers**) verify this signature against the domain's published public key. A forged response — whether from a blind attack or an on-path adversary — will not carry a valid signature. The validating resolver will reject it and return a `SERVFAIL` error rather than the forged record. This is a cryptographic guarantee, not a statistical one. Even an attacker with full visibility into the query transaction cannot forge a valid signature without the zone's private signing key. ## Practical Protections for Domain Owners **Enable DNSSEC on your domain.** See DNSSEC: Why You Should Enable It for implementation steps. Once your zone is signed and a DS record is published in the parent TLD zone, validating resolvers will reject any forged answers for your domain. **Use HTTPS / SSL/TLS.** Even if a resolver is not DNSSEC-validating, SSL/TLS provides a second layer of defence. An attacker who redirects users to their server needs a valid certificate for your domain name — which they generally cannot obtain from a legitimate CA (CAA records help restrict this further). See SSL/TLS and Domain Security. **Use HTTPS with HSTS** to prevent downgrade attacks that might exploit a brief window between DNS resolution and certificate verification. **Use a DNSSEC-validating resolver** for your own infrastructure. Public resolvers like Cloudflare `1.1.1.1` and Google `8.8.8.8` perform DNSSEC validation by default. ISP resolvers vary — check your resolver's capabilities. ## Limitations DNSSEC protects DNS data authenticity. It does not: - Encrypt DNS queries (DNS-over-HTTPS/TLS addresses this). - Protect against compromised authoritative servers. - Help users whose resolvers do not perform DNSSEC validation (though adoption is growing). As part of a layered security strategy, DNSSEC is combined with SSL/TLS, HSTS, and the broader controls in Domain Security Checklist to address the full threat landscape.