DNS Amplification Attack Explained: How Open Resolvers Enable Massive DDoS

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 in the tens are achievable for well-chosen query and response pairs, so a 1 Mbps attack stream can generate tens of Mbps hitting the target. The exact multiple depends heavily on which zone and server the attacker abuses, and on where you measure it (DNS payload versus full Ethernet frame).

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. That same lack of source verification is what makes cache poisoning possible. 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:

These are DNS payload sizes, not full frames, so the ratio you would measure on the wire is lower once Ethernet, IP, and UDP headers are counted on both sides. The ANY row in particular is no longer a safe assumption for the attacker: RFC 8482 specifically permits an authoritative server to answer an ANY query with a minimal response rather than every RRset it holds, precisely to remove this amplification vector, and modern implementations do exactly that. DNSSEC-signed responses remain the more dependable source of large answers.

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

An answer alone does not prove open recursion: an authoritative server can answer for its own zone, and some servers return cached data without offering recursion. On infrastructure you are authorized to assess, request a fresh unique name in a separate zone you control and confirm the upstream authoritative query in its logs. Inspect RA and RD flags, the result, and the server’s access policy together. RFC 1035 distinguishes recursion requested from recursion available.

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, and the Phantom Domain Attack that exhausts resolver resources instead of bandwidth.