Support Library
DNS Cache Poisoning
How DNS cache poisoning works, from the Kaminsky attack to SAD DNS, and the defences: DNSSEC, randomisation and validating resolvers.
The short answer
Cache poisoning gets a forged record into a recursive resolver's cache, so every user of that resolver is sent to the attacker's address until the forged entry expires. Classic DNS over UDP checks only a 16-bit query ID and the source port, so an attacker who can guess them and answer before the real server wins. Modern resolvers make that guessing hard, and DNSSEC makes it useless for signed zones looked up through a validating resolver, because a forged answer cannot carry a valid signature.
How the attacks work
| Attack | Idea | Main defence |
|---|---|---|
| Kaminsky (2008) | Trigger lookups for many random names under a domain and flood forged replies that also carry a fake NS record for the whole domain | Source port randomisation, which multiplies the guessing space |
| SAD DNS (2020) | Use an ICMP rate-limit side channel to discover the resolver's source port, then guess only the query ID | Kernel ICMP fixes, DNSSEC |
| Fragmentation attacks | Make the real answer fragment and inject a forged second fragment, which carries no query ID | Smaller EDNS buffers (about 1,232 bytes), DNSSEC |
| Out-of-bailiwick records | Include records for unrelated domains in the additional section | Resolvers discard data they did not ask for and that the server is not authoritative for |
| Rogue resolver or on-path attacker | Answer directly from a network position between client and resolver | DoH or DoT to a trusted resolver, and DNSSEC validation |
Defences, by role
- Domain owners: sign the zone with DNSSEC and publish the DS. This is the only defence that does not depend on guessing being hard, but it protects only users whose resolver (or device) validates DNSSEC. Behind a non-validating resolver, a forged answer is still accepted.
- Resolver operators: validate DNSSEC, randomise source ports and query IDs, use 0x20 case randomisation where supported, keep EDNS buffers small, and do not run an open resolver.
- Everyone: HTTPS with valid certificates limits the harm, since a poisoned record alone cannot produce a trusted certificate for your domain. CAA records narrow who could issue one.
Checking your exposure
| Check | Command |
|---|---|
| Is the domain signed? | dig +short example.com DS |
| Does a resolver validate it? | dig @1.1.1.1 example.com A, look for the ad flag |
| Does your resolver validate at all? | dig dnssec-failed.org A should return SERVFAIL |
How DNS Panopticon helps
Domain Visualizer checks whether your domain publishes DS and DNSKEY records and whether the resolver validated them, and reports DNSSEC as absent, broken, not confirmed, or valid. It also checks for CAA records. It cannot test any particular resolver for poisoning, and it does not look for forged records in caches.
Sources and further reading
- RFC 5452: Measures for Making DNS More Resilient against Forged Answers
- RFC 3833: Threat Analysis of the Domain Name System
- CERT/CC VU#800113: Multiple DNS implementations vulnerable to cache poisoning: the 2008 Kaminsky disclosure
- SAD DNS: the 2020 side-channel research
- RFC 4033: DNS Security Introduction and Requirements