A DNS amplification attack is a reflection-based DDoS technique where an attacker sends small, spoofed DNS queries to open resolvers, which then send oversized responses to a victim whose IP address was forged in the request. The attack exploits the difference between the size of a DNS query and the size of its response, allowing attackers to generate much larger volumes of traffic with limited resources.
This guide breaks down how DNS amplification attacks work, why they scale so effectively, how to identify an attack, and the controls organizations can implement to reduce the risk. The concerning reality is that misconfigured DNS servers can unknowingly become part of the attack infrastructure.
Key Takeaways
- A DNS amplification attack is a volumetric DDoS that abuses open DNS resolvers to reflect and enlarge traffic toward a spoofed victim.
- The core mechanics are IP spoofing, forging the victim’s address, and amplification, a small query that returns a huge response, often multiplying traffic 50 times or more.
- DNS ANY queries and DNSSEC-signed responses produce the largest amplification, which is why attackers favor them.
- Symptoms include sudden inbound UDP floods on port 53, DNS responses you never requested, and saturated upstream bandwidth.
- Prevention combines closing open recursion, source IP validation (BCP38), DNS Response Rate Limiting, and upstream scrubbing.
- You can be a victim or an unwitting amplifier. Securing your own resolvers protects the wider internet, not just you.
How Does a DNS Amplification Attack Work?
A DNS amplification attack works in three moves: spoof the victim’s IP, send tiny queries to open resolvers, and let those resolvers flood the victim with large responses.
- Reconnaissance. The attacker scans the internet for open resolvers, DNS servers that answer recursive queries from any source. Millions exist.
- Spoofing. Using a botnet, the attacker crafts DNS queries with the source IP forged to the victim’s address.
- Query selection. They choose request types that return the biggest answers, such as ANY or DNSSEC records.
- Reflection. Each resolver sends its large response to the spoofed source, which is the victim.
- Amplification at scale. Thousands of resolvers reply at once, and the combined bandwidth overwhelms the target.
The victim’s servers, firewalls, and upstream links choke on traffic that looks like ordinary DNS replies. Because the responses come from legitimate resolvers, simple IP blocklists are close to useless.
A regional gaming platform we reviewed was knocked offline by roughly 90 Gbps of reflected DNS traffic sourced from more than 20,000 distinct resolvers. Not one packet came from the actual attacker.
The mechanics are only half the story. The reason this attack is so feared is the sheer multiplier behind it.
Why DNS Amplification Attacks Hit So Hard
DNS amplification hits hard because a tiny request produces a massive reply, letting attackers multiply their firepower 50 times or more without extra resources.
The amplification factor is the ratio between response size and request size. A 60 to 80 byte query that triggers a 3,000 to 4,000 byte answer gives an attacker roughly 50 to 70 times leverage. A botnet pushing 1 Gbps of spoofed queries can generate 50 Gbps or more against the victim.
| Query Type | Typical Response | Amplification Factor |
|---|---|---|
| A record | Small | About 1x (no gain) |
| ANY record | Large record set | About 28x to 54x |
| DNSSEC-signed | Signatures and keys | About 50x and up |
| TXT / large records | Variable | Up to about 60x |
The Spamhaus incident, one of the largest reflection attacks of its era, peaked near 300 Gbps and was powered largely by open DNS resolvers. It briefly congested parts of the wider internet, not just the target.
Most teams pour budget into inbound scrubbing and forget the cheaper win. The single most effective thing you can do is make sure your own resolvers cannot be recruited as amplifiers. Every locked-down resolver is one less weapon on the internet.
Because the flood arrives as raw volume rather than crafted application requests, it belongs in the same bucket as other layer 4 DDoS events, where the goal is to exhaust bandwidth and connection capacity rather than trick your application logic.
If the numbers are this lopsided, how do you tell an amplification attack apart from a plain DNS flood? The distinction changes how you respond.
DNS Amplification vs DNS Flood: What Is the Difference?
A DNS amplification attack reflects enlarged traffic off third-party resolvers toward a spoofed victim, while a DNS flood sends a direct storm of queries straight at your DNS server.
The two get confused because both hammer DNS infrastructure, but they attack different weak points. Amplification is about borrowed bandwidth and reflection. A flood is about raw query volume aimed at exhausting your resolver’s CPU and memory.
- Source: amplification uses innocent open resolvers, while a flood usually comes straight from a botnet.
- Spoofing: amplification always spoofs the victim’s IP, while floods often do not need to.
- Target: amplification aims at the victim’s bandwidth, while a flood aims at the DNS server itself.
- Fix: amplification needs upstream absorption and resolver hygiene, while a flood needs rate controls at the server.
One managed hosting provider we audited spent a week fighting what they called a “DNS attack.” It turned out to be two problems at once: a direct query flood against their authoritative servers, and a separate reflection campaign using their misconfigured recursive servers against a third party.
If your DNS server itself is buckling under query volume rather than reflected replies, you are likely dealing with a DNS flood attack, which calls for a different playbook centered on the server, not your bandwidth.
Naming the attack is progress, but you cannot defend against what you cannot see. So what does an amplification attack actually look like on your monitoring?
What Are the Symptoms of a DNS Amplification Attack?
The clearest symptom is a surge of inbound DNS responses on UDP port 53 that your systems never requested, paired with saturated upstream bandwidth.
- Inbound UDP traffic on port 53 spikes far above baseline, and most of it is responses, not queries.
- Your links saturate while CPU on application servers stays oddly normal.
- Packet captures show large DNS answers arriving from many different resolver IPs.
- Legitimate users report timeouts and slow or failed page loads.
- NetFlow data reveals a small set of query types dominating, often ANY.
The tell is direction. In amplification, you receive replies you never asked for. In a normal DNS problem, you would see outbound queries failing. Watch the response-to-query ratio: if inbound responses dwarf your outbound requests, reflection is the likely cause.
You might assume your CDN or hosting provider would catch this automatically. Some do, but many only react once your bandwidth is already saturated, by which point users are already seeing errors.
Spotting the attack fast matters, but the real goal is making sure it never lands. That comes down to a short list of controls.
How to Prevent DNS Amplification Attacks
You prevent DNS amplification attacks by closing open resolvers, validating source IPs, rate limiting DNS responses, and absorbing volume with a distributed, scrubbed network.
No single setting stops amplification. Defense works in layers, from your own DNS configuration outward to your upstream provider.
Close open recursion
Restrict recursive resolvers so they only answer clients you control. Authoritative servers should never offer open recursion to the internet. This one change removes your servers from the global pool of amplifiers.
Validate source IPs (BCP38)
Network operators should implement ingress filtering (BCP38 and uRPF) so packets with forged source addresses get dropped at the edge. Spoofing is the fuel, and filtering starves it.
Rate limit DNS responses
Enable DNS Response Rate Limiting (RRL) so a resolver will not repeatedly send identical large answers to the same target. Broader Rate limiting at the network edge caps how much any single source or destination can consume.
Distribute and absorb with Anycast
Spread DNS across many points of presence so no single node is a chokepoint. An Anycast network routes queries to the nearest healthy location and dilutes attack traffic across your entire footprint.
Filter at the edge
A properly tuned firewall solution can drop malformed packets, throttle UDP 53 from suspicious ranges, and enforce response-size sanity checks before traffic reaches your servers.
A fintech we worked with cut its exposure to near zero with two changes: disabling recursion on three misconfigured internal resolvers, and enabling RRL on their authoritative platform. The next reflection attempt that tried to use their servers simply failed to amplify.
Configuration gets you most of the way, but the platform you run DNS on decides how much of this you have to manage yourself.
Choosing DNS Infrastructure That Resists Amplification
The most resilient setup runs authoritative DNS on a distributed, managed platform that includes rate limiting, spoofing protection, and DDoS attack protection by default.
Self-hosting a single authoritative server gives you control and a single point of failure. A distributed managed platform spreads risk, absorbs volume, and stays patched without a 3 a.m. call.
- Anycast distribution across many global points of presence.
- Built-in DNS Response Rate Limiting and response-size controls.
- Automatic DDoS absorption at the network layer.
- No open recursion by design, with strict source validation.
- Clear visibility into query patterns and anomalies.
A media company that moved from two self-managed name servers to a managed anycast platform saw reflection attempts against their domains become non-events. Attack traffic was absorbed across dozens of locations instead of crushing one box.
For most teams, offloading this to a hardened DNS cloud service is faster and safer than hand-tuning resolvers, because the amplification defenses are already in place and maintained.
Get the platform right, and the attack that once threatened your uptime becomes background noise.
Final Thought on DNS Amplification Attack
DNS amplification succeeds for one reason: the internet is full of resolvers willing to answer strangers and forward big replies to forged addresses. Take away either the open resolver or the spoofed packet, and the attack collapses. The strongest defense is not a single product but layered discipline, from locking down your own DNS to leaning on a distributed network that can absorb whatever slips through.
Treat your resolvers as part of the internet’s shared safety, not just your own uptime. Securing them keeps your infrastructure from being conscripted into the next attack. Do the boring configuration work first, then let a resilient platform handle the volume you cannot.
Frequently Asked Questions About Amplification Attack
What is the difference between a DNS amplification attack and DNS spoofing?
DNS spoofing, or cache poisoning, falsifies DNS records to redirect users to malicious sites. DNS amplification uses IP spoofing to reflect large responses at a victim for a DDoS. Both abuse trust in DNS, but their goals differ.
Can I stop my servers from being used as an amplifier?
Yes. Disable open recursion so your resolvers only answer trusted clients, enable DNS Response Rate Limiting, and apply source IP validation. These steps remove your servers from the attacker’s toolset.
How big can DNS amplification attacks get?
Reflection attacks have exceeded 300 Gbps by abusing open resolvers. Because amplification multiplies traffic 50 times or more, even a modest botnet can generate crippling volume.
