DNS Amplification and Cache Poisoning: How the Attacks Work and How to Defend

DNS amplification and cache poisoning are two of the most significant attacks against the DNS system — one threatens availability, the other integrity — and both have well-established defences. This guide explains, at a conceptual level, how each works and how to protect your infrastructure. It is written for administrators defending their own servers.

DNS amplification (a DDoS technique)

Amplification abuses the fact that a small DNS query can trigger a much larger response. In the attack pattern, a flood of queries is sent to misconfigured "open" resolvers with the victim's address forged as the source, so the large responses all pour onto the victim — overwhelming their connection. The "amplification" is the size ratio between the small request and the big reply.

How to defend against it

• Do not run an open resolver. Your recursive resolver should only serve your own clients, never the whole internet. This single step removes your server as a tool for these attacks.
• Separate authoritative and recursive roles so your authoritative servers do not offer open recursion.
• Enable Response Rate Limiting (RRL) on authoritative servers to cap how fast identical responses are sent.
• Support source-address validation (BCP 38) at the network level to make address spoofing harder.

Cache poisoning (a spoofing technique)

Cache poisoning aims to trick a recursive resolver into caching a forged record, so users are silently sent to the wrong server. Conceptually, the attacker tries to slip a fake answer to the resolver before the legitimate one arrives and have it accepted, after which the bad record is served from cache until it expires.

How to defend against it

• Deploy DNSSEC — signed records let resolvers reject forged answers because they fail validation. This is the strongest structural defence.
• Keep resolver software current — modern resolvers use source-port randomisation and query-identity checks that make forgery vastly harder.
• Use query-name case randomisation (0x20) where supported, adding entropy that forged replies must match.
• Encrypt the last mile with DoH or DoT so on-path attackers cannot tamper with queries between client and resolver.

The overarching principles

Run resolvers closed to outsiders, keep software patched, validate with DNSSEC, and monitor your DNS traffic for anomalies. A firewall like CSF and general WAF hygiene support this, but the DNS-specific measures above are what actually stop these attacks.

Frequently asked questions

How do I make sure my server isn't used in amplification attacks?

Do not run an open recursive resolver — restrict recursion to your own clients only, and keep authoritative and recursive roles separate. An open resolver is the key ingredient attackers abuse; closing it removes your server from the equation.

What actually stops cache poisoning?

DNSSEC is the strongest defence, since forged records fail signature validation. Alongside it, modern resolvers with source-port randomisation and up-to-date software make poisoning extremely difficult in practice.

Does DNSSEC protect against DDoS amplification?

No — DNSSEC protects integrity (against forged answers), not availability. Amplification is mitigated by not running open resolvers, rate limiting, and anti-spoofing measures. The two attacks need different defences.