Support Library
DNS Amplification Attacks
How DNS amplification reflects spoofed queries at a victim, and how to keep your servers from being used: no open recursion, RRL, BCP 38.
The short answer
A DNS amplification attack is a reflection attack. The attacker sends small DNS queries over UDP with the victim's IP address forged as the source, to servers that send much larger replies. The servers "answer" the victim, who is flooded with traffic they never asked for. A 60 byte query that returns a 3,000 byte answer amplifies the attacker's bandwidth about fifty times, and thousands of reflectors multiply it further.
Your DNS servers can be the reflector, or your network can be the target. The fixes differ.
What makes a good reflector
- Open recursive resolvers, which answer anyone on the internet for any name. They are the biggest problem, and there should be no reason to run one by accident.
- Large answers, such as ANY queries, big TXT records, and DNSSEC-signed DNSKEY sets.
- Authoritative servers without response rate limiting, which must answer everyone but need not answer the same forged source a thousand times a second.
- Networks that allow spoofed source addresses out of them, which is what makes the forged query possible in the first place.
Not being a reflector
| Measure | Where |
|---|---|
| Allow recursion only for your own clients (for example BIND's allow-recursion, Unbound's access-control) | Recursive resolvers |
| Turn recursion off entirely | Authoritative servers |
| Enable Response Rate Limiting (RRL), which slows identical replies to one source and switches some to truncated answers so real clients retry over TCP | Authoritative servers |
| Answer ANY queries minimally, as RFC 8482 allows | Both |
| Drop packets with spoofed source addresses at your network edge (BCP 38) | Network operators |
Test your own server from an external source that its policy should not authorize, using a fresh random name in a separate test zone whose authoritative logs you control. The ra flag advertises recursion availability; an answer may have come from cache and does not alone prove unrestricted recursion. Check the authoritative logs to verify that the server actually resolved the fresh name. REFUSED is an expected result for an unauthorized source; replace the illustrative name below with your controlled test name.
$ dig @203.0.113.53 example.com AWhen you are the target
Reflected DNS traffic arrives as UDP from source port 53, in replies to queries you never sent. Filtering on your own router is too late once your uplink is full, so large attacks are absorbed upstream: by your ISP, or by a DDoS mitigation or anycast network that can drop the traffic close to where it enters. Hosting your public DNS with a provider that runs a large anycast network also keeps your name servers reachable during an attack on them.
How DNS Panopticon helps
DNS Panopticon does not test servers for open recursion or measure response sizes, and it does not detect attacks. Domain Visualizer does report whether a domain has at least two name servers, which matters for staying reachable while one is under attack. Use the test above from an outside network to check your own servers.