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 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:

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 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.

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.

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