DNS spoofing / cache poisoning

DNS spoofing (also called cache poisoning) is an attack where someone gets a DNS resolver to cache a false answer. The resolver then serves the wrong IP to every user who asks for that name until the bad entry expires.

Different from DNS hijacking: hijacking takes over the authoritative records or routing; spoofing manipulates an intermediate resolver's cache without touching authoritative DNS at all.

How it works

DNS-over-UDP has historically been a single-packet protocol. The resolver sends a query to the authoritative server; the authoritative server replies; the resolver caches the result. If an attacker can predict the resolver's query parameters (source port, transaction ID) and respond before the real authoritative server does, the attacker's forged response gets cached.

The classic example: in 2008, Dan Kaminsky demonstrated that with predictable source ports and a 16-bit transaction ID, an attacker could fire ~32k forged responses per second and reliably poison a resolver in under 30 seconds. The fix was source-port randomization, expanding effective entropy from 16 bits to 32 bits and making the attack thousands of times harder.

Modern mitigations

• Source-port randomization. Every recursive resolver since 2008 uses a random source port per query.
• DNSSEC. Authoritative servers sign their responses cryptographically. Resolvers verify the signature. Forged responses fail signature validation and are rejected.
• DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). Encrypt the DNS query channel between resolver and authoritative (or between user and resolver). An attacker can't inject responses they can't see and sign.
• TCP fallback. Forging a TCP-based DNS response requires the attacker to be on-path, which is much harder than blind UDP spoofing.

Why this still happens

DNSSEC adoption is partial. Most top-tier ccTLDs sign their zones, most major brands sign theirs, but a long tail of zones doesn't. For unsigned zones, the attack surface is real but reduced to "be on the network path."

The remaining real-world cases:

• Captive portals. Hotel and cafe wifi can intercept and rewrite DNS responses for any unsigned zone. Often used to inject ads; sometimes used maliciously.
• State-level adversaries. Some governments operate DNS interception on user traffic. DoH bypasses this.
• ISP MITM. Some ISPs rewrite NXDOMAIN responses to point at their own search/ad pages. Not exactly malicious but a form of spoofing.

In a SaaS

For an end-user-facing app:

• Sign your zone with DNSSEC if possible. Free at Cloudflare, Route53, most modern DNS hosts.
• Don't make assumptions about resolver behavior. Cache poisoning attacks against your users' resolvers can affect their interaction with your site.
• Surface clear TLS errors to users; never bypass cert validation. The biggest risk from DNS spoofing is that a user lands on an attacker's IP and accepts a self-signed cert.

For a custom-domain platform:

• Encourage customers to enable DNSSEC on their zone. Most don't by default. It's a checkbox at Cloudflare and Route53.
• Use ACME with CAA records that pin the CA. CAA limits which CAs can issue for your domain; combined with DNSSEC, this makes cert-issuance hijacking very hard.