Skip to main content
DNS Checker(beta)
How DNS amplification attacks turn open resolvers into massive DDoS floods
5 min read

DNS Amplification Attack Explained: How Open Resolvers Enable Massive DDoS

Ishan Karunaratne

Ishan Karunaratne

Software Architect & Infrastructure Engineer

A DNS amplification attack is a type of distributed denial-of-service (DDoS) attack that exploits open DNS resolvers to flood a target with massive volumes of traffic. The attacker sends small DNS queries with a spoofed source IP address (the victim's IP) to open resolvers, which respond with much larger replies directed at the victim. Amplification factors of 50x to 70x are common, meaning a 1 Mbps attack stream can generate 50-70 Mbps of traffic hitting the target.

This attack is devastatingly effective because it requires minimal bandwidth from the attacker while overwhelming the victim with traffic that appears to come from legitimate DNS servers around the world.

How DNS Reflection and Amplification Work

The attack relies on two properties of DNS:

Reflection: DNS is a UDP-based protocol, and UDP does not have a handshake mechanism. The source IP address in a UDP packet can be forged (spoofed), and the receiving server has no way to verify it. When the resolver sends its response, it sends it to the spoofed address — the victim.

Amplification: Certain DNS queries produce responses much larger than the query itself. The attacker crafts queries that maximize this ratio:

Query TypeQuery SizeResponse SizeAmplification Factor
ANY~40 bytes~3,000 bytes~75x
DNSSEC-signed TXT~50 bytes~2,500 bytes~50x
Large TXT record~40 bytes~2,000 bytes~50x

The attacker sends thousands of these small queries per second to open resolvers worldwide, each with the victim's IP as the source. The resolvers dutifully send their large responses to the victim, creating a massive flood.

Anatomy of an Attack

  1. Reconnaissance. The attacker scans the internet for open resolvers — DNS servers that accept recursive queries from any source IP.

  2. Weaponization. The attacker compiles a list of open resolvers and identifies domains with large DNS responses (often by querying for ANY records on domains with many record types).

  3. Execution. The attacker sends spoofed DNS queries to the open resolvers. Each query is small (~40 bytes), but each response is large (~3,000 bytes). With thousands of resolvers, the aggregate bandwidth directed at the victim is enormous.

  4. Impact. The victim's network is saturated with incoming DNS responses. Legitimate traffic cannot get through. The victim's servers, firewalls, and upstream links are overwhelmed.

The Spamhaus Attack (2013)

The most famous DNS amplification attack targeted Spamhaus, a spam-fighting organization, in March 2013. The attack peaked at 300 Gbps, making it one of the largest DDoS attacks in history at the time.

The attackers exploited tens of thousands of open resolvers worldwide, sending spoofed queries for domains with large DNS responses. The attack was so large it caused noticeable congestion on internet exchange points in London and Amsterdam, affecting unrelated internet services.

The Spamhaus attack demonstrated that DNS amplification could threaten not just individual targets but the broader internet infrastructure itself.

How Attackers Discover This Weakness

Finding open resolvers is straightforward. An attacker scans IP ranges on port 53 — you can scan for open ports on your own infrastructure to check if port 53 is exposed — and sends a recursive query:

dig @target-ip example.com A +recurse

If the server responds with an answer (rather than refusing the query), it is an open resolver and can be used for amplification.

Attackers also search for domains that produce the largest possible responses to maximize amplification. Domains with many record types, DNSSEC-signed zones with large RRSIG records, and domains with large TXT records are preferred. You can inspect DNS records for any domain to see how large its response payloads are.

How to Test Your Own Infrastructure

Check if your DNS server is an open resolver:

# From an external IP (not your own network)
dig @your-dns-server-ip example.com A +recurse

If the server resolves the query, it is acting as an open resolver and can be weaponized in amplification attacks. This is the single most important test you can run.

Check if your network allows IP spoofing:

The Spoofer Project (https://spoofer.caida.org/) provides tools to test whether your network properly implements BCP38 egress filtering. If your network allows outbound packets with spoofed source IPs, you are enabling amplification attacks.

Check Response Rate Limiting on your authoritative servers:

Send rapid identical queries from the same source and observe whether the server begins truncating or dropping responses. If it responds to every query at full rate indefinitely, RRL is not enabled.

How to Defend Against It

If You Run a DNS Resolver

The most important step is to restrict recursion to only your own networks:

# BIND example
options {
    allow-recursion { 10.0.0.0/8; 192.168.0.0/16; };
};

If your resolver does not need to serve the public internet, it should not accept queries from the public internet.

If You Run Authoritative DNS

Enable Response Rate Limiting (RRL) to throttle the rate of identical responses:

# BIND example
rate-limit {
    responses-per-second 5;
    window 5;
};

This limits the damage your server can do if it is targeted as a reflector for the response portion of the attack.

At the Network Level

  • Implement BCP38/BCP84 ingress filtering to prevent IP spoofing at your network edge
  • Use anycast for DNS services to distribute traffic across multiple points of presence
  • Deploy upstream DDoS mitigation (Cloudflare, AWS Shield, Akamai) for critical services

Mitigation Checklist

  • Recursive resolvers restricted to internal networks only
  • Response Rate Limiting enabled on authoritative servers
  • BCP38 egress filtering implemented to prevent outbound spoofed packets
  • DNS servers monitored for unusual query volume patterns
  • Anycast deployed for public-facing authoritative DNS
  • DDoS mitigation service in place for critical infrastructure
  • ANY query type disabled or minimized on authoritative servers

Common Misconfigurations

  • Running a recursive resolver on a public IP without ACLs restricting who can query it
  • Hosting authoritative and recursive DNS on the same server with recursion enabled globally
  • Not implementing RRL on authoritative servers, allowing unlimited response rates
  • ISPs not implementing BCP38, enabling spoofed traffic to originate from their networks

Ethical Note

Running DNS amplification attacks is illegal, even for testing purposes against your own infrastructure, because it involves sending spoofed traffic through third-party resolvers. To test your DDoS resilience, use legitimate load testing tools against your own servers, or work with a DDoS simulation provider that operates within their own infrastructure.

You can and should test whether your own servers are open resolvers or lack RRL — those tests are safe and important. If your server has already been used in amplification attacks, check if your IP is blacklisted to assess the damage to your reputation.


This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Water Torture Attack, NXDOMAIN Attack.

Frequently Asked Questions

This article was researched and structured by the author with AI assistance for drafting and technical verification.

About the Author

Ishan Karunaratne
Ishan Karunaratne

Software Architect & Infrastructure Engineer

US Army veteran with a B.S. in Information Technology, CompTIA A+, Network+, and Security+ certified. 20+ years building and securing web infrastructure.

B.S. Information Technology — Online SystemsCompTIA A+ (2009)CompTIA Network+ (2009)CompTIA Security+ (2009)US Army Veteran — Operation Iraqi Freedom

Share this article

Related Articles

145,061 Domains Delegated to a Misspelled Name Server — Here's How the Attack Works

A single typo in a name server hostname gives an attacker full DNS authority over your domain. I built a detection pipeline that scans 260 million domains daily and found that one missing character in ResellerClub's NS hostname has left 145,061 domains exposed to silent DNS hijacking.

What Happens When One DNS Provider Goes Down: The Hidden Fragility of TLD Ecosystems

The Dyn attack took down Twitter and Netflix because they shared a DNS provider. I analyzed 240 million domains and found 112 TLDs where a single provider controls over half the domains. The next Dyn-scale event isn't a question of if, but which TLD.

How Expired Name Servers Become Domain Hijacking Vectors

When a name server domain expires, every domain that still delegates to it becomes vulnerable to hijacking. I found 503,000 domains pointing to expired NS domains — and a single re-registration could compromise hundreds of thousands of them.

Why DNSSEC Is Still Failing: Lessons from 240 Million Domains

After 20 years, only 4.27% of domains have DNSSEC. I analyzed 240 million domains to understand why — the answer isn't technical, it's structural. Registrar defaults, invisible benefits, and operational fear are holding back the one protocol that could fix DNS authentication.