Cache poisoning: winning a race against the real answer

When a resolver queries an authoritative server, nothing cryptographically proves the reply is genuine — only a 16-bit transaction ID and, defensively, a randomized source port stand between an attacker's guess and a resolver believing a forged answer. Get the guess right before the real answer arrives, and the resolver caches the attacker's answer for the TTL's entire duration.

Press the button to attempt an attack.

DNSSEC: a chain of signatures, not certificates

DNSSEC's trust model mirrors TLS's certificate chain almost exactly: instead of one root CA's key being pre-installed as a trust anchor, a resolver has the DNS root zone's public key built in, and validates a chain of signatures down to the record you actually asked for.

DoH/DoT vs. DNSSEC: two different problems

These get confused constantly because both sound like "DNS but secure" — they secure completely different things.

DNSSECDoH / DoT
SolvesAuthenticity — is this answer genuine and untampered?Confidentiality — can anyone on the path see what I looked up?
Does NOT solvePrivacy — the query is still sent in the clearAuthenticity — it only encrypts the hop to whichever resolver you chose; that resolver could still lie to you
Closest analogyA signed documentA sealed envelope

DNS amplification: spoofing meets a small-request-big-response ratio

This is the IP spoofing pattern applied specifically to DNS: an attacker sends a small query with a victim's spoofed address as the source to an open resolver, requesting something with a large reply (like an ANY record or a large EDNS0 buffer). The resolver dutifully sends that large reply — to the victim, not the attacker. A 60-byte query producing a multi-kilobyte reply gives an attacker tens of times their original bandwidth for free.

Defenses: don't run resolvers that answer recursive queries for the whole internet — restrict recursion to known clients — and rate-limit identical responses to repeated sources.

Common gotchas