What is a DNS amplification DDoS attack?

A DNS amplification attack is a type of distributed denial-of-service (DDoS) attack in which an attacker sends small DNS queries to many DNS servers with the source IP address forged to be the victim's. The servers send their much larger replies to the victim, so a modest amount of attack traffic becomes a flood that can overwhelm the victim's network link. It's a reflection attack, because the servers unknowingly bounce traffic at the target, and an amplification attack, because each reply is many times bigger than the query that triggered it.

These attacks have been behind some of the largest DDoS incidents on record, and they rely on two weaknesses that are still common: networks that allow spoofed source addresses, and DNS servers that answer anyone. In this article you'll learn exactly how amplification works, why some queries amplify more than others, how to tell if your own servers are being abused, and the configuration changes and network controls that defend against it, whether you run DNS servers or you're on the receiving end.

How a DNS Amplification Attack Works

The attack has three ingredients: a way to spoof the source address, a large number of DNS servers willing to reply, and queries that produce big responses.

1. The attacker controls a set of machines, usually a botnet of compromised devices or rented servers on networks that don't filter spoofed traffic.
2. Each machine sends DNS queries over UDP with the source IP address set to the victim's address. UDP has no handshake, so the DNS server can't tell the source is fake.
3. The DNS servers reply to the victim, because that's where the queries appear to have come from.
4. The replies are much larger than the queries, so the victim receives many times more traffic than the attacker sent.
5. The victim's link or upstream router saturates, and legitimate traffic can't get through.

The victim doesn't need to run DNS at all. Any IP address can be targeted, and the flood arrives as unsolicited UDP traffic from source port 53.

Why Reflection Helps the Attacker

Reflection hides the attacker's real location, because the victim only sees traffic from legitimate DNS servers. It also spreads the attack across thousands of sources, which makes simple blocking by IP address impractical. And because the reflecting servers are often well-connected infrastructure, they can deliver a great deal of traffic.

What Makes a Query Amplify?

The amplification factor is the size of the response divided by the size of the query. A typical DNS query is around 40 to 80 bytes. If the response is 3,000 bytes, the amplification factor is roughly 40 to 75.

You can see the response size for any query in dig's output:

dig example.com A | grep "MSG SIZE"

;; MSG SIZE  rcvd: 56

A simple A record lookup barely amplifies at all. Responses that include DNSSEC signatures or many records are a different story:

dig example.com DNSKEY +dnssec | grep "MSG SIZE"

;; MSG SIZE  rcvd: 1182

Several factors make responses large:

• DNSSEC records: DNSKEY and RRSIG records add hundreds of bytes per record set.
• TXT records: Long TXT records, or many of them on one name, produce large answers.
• ANY queries: Historically, an ANY query returned every record at a name, which could be very large.
• EDNS(0): The EDNS extension lets clients advertise that they accept UDP responses much larger than the original 512-byte limit. Without it, large answers would be truncated and the client would have to retry over TCP, which can't be spoofed.

The Decline of ANY

Because ANY was so useful for amplification, the DNS community reduced its value. RFC 8482, published in 2019, allows authoritative servers to answer ANY queries with a minimal response, such as a single record set, rather than everything at the name. Many large providers now do this, and some resolvers refuse or minimise ANY too. Attackers have shifted to other query types and to domains with deliberately large responses, but the overall effect has been to make DNS less attractive for amplification.

Open Resolvers and Authoritative Servers

Any DNS server that answers queries from the internet can be used as a reflector, but two kinds matter most.

Open Resolvers

An open resolver is a recursive resolver that answers queries from anyone, not just its intended users. They're often the result of misconfiguration, such as a home router that answers DNS on its WAN interface, or a company resolver without access controls. Attackers like them because they'll look up and return any record, including large ones from domains the attacker controls.

There's rarely a good reason to run one. Public resolver services do operate open resolvers deliberately, but they invest heavily in rate limiting and abuse detection.

Authoritative Servers

Authoritative nameservers have to answer queries from anyone for the zones they host, so they can't simply be closed. Attackers can still abuse them by asking for large records in those zones. Defending them relies on rate limiting and keeping responses compact, rather than access controls.

Is Your Server Being Used in an Attack?

If you run DNS servers, signs that they're being abused include:

• A sudden rise in outbound traffic from the server, much larger than inbound.
• Many queries for the same name and type from a small number of source addresses, often for ANY, DNSKEY or TXT.
• Queries for domains your server has no reason to resolve.
• Abuse complaints from your hosting provider or the victim's network.

With BIND, you can turn on query logging temporarily and look at the pattern:

sudo rndc querylog on
sudo tail -n 1000 /var/log/named/queries.log |
  awk '{for (i = 1; i <= NF; i++) if ($i == "query:") print $(i+1), $(i+3)}' |
  sort | uniq -c | sort -rn | head

    912 example.org ANY
     41 www.example.com A
     12 example.com MX

The exact log format depends on your logging configuration, so adjust the field positions if needed. Remember to switch query logging off again with rndc querylog off, because it adds load.

Check From Outside Whether You Run an Open Resolver

From a machine outside your network, ask your server to resolve a name it isn't authoritative for:

dig @203.0.113.53 www.example.org A

A properly closed resolver refuses:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 50211
;; WARNING: recursion requested but not available

If you get a full answer with the ra (recursion available) flag set, your server is an open resolver and should be locked down.

How to Defend Your DNS Servers

Close Recursive Resolvers to the Internet

Restrict recursion to the networks you serve. In BIND:

acl internal {
    192.0.2.0/24;
    2001:db8:100::/48;
    localhost;
};

options {
    recursion yes;
    allow-recursion { internal; };
    allow-query-cache { internal; };
};

On an authoritative-only server, turn recursion off completely:

options {
    recursion no;
};

In Unbound, the access-control setting defaults to refusing everything except localhost, so only add the networks you actually serve:

server:
    interface: 0.0.0.0
    access-control: 127.0.0.0/8 allow
    access-control: 192.0.2.0/24 allow
    access-control: 2001:db8:100::/48 allow

Also make sure resolvers listen only on internal interfaces where possible, and that firewalls don't expose UDP port 53 to the internet unnecessarily.

Enable Response Rate Limiting

Response Rate Limiting (RRL) limits how many identical responses a server sends to the same client network per second. Because a reflection attack sends lots of identical replies to one victim, RRL cuts the flood down while barely affecting normal clients. For legitimate clients that hit the limit, BIND can send occasional truncated responses (the slip setting), which tell real clients to retry over TCP, something a spoofed source can't do.

In BIND, enable RRL in the options block or per view:

options {
    rate-limit {
        responses-per-second 10;
        window 5;
        slip 2;
    };
};

Here, the server sends at most 10 identical responses per second to each client netblock, and every second dropped response is replaced by a small truncated reply. Start with values like these on authoritative servers and tune them based on your traffic. Knot DNS, NSD and PowerDNS offer similar features.

Unbound has its own rate limiting options, aimed at protecting both the resolver and the servers it talks to:

server:
    # Limit queries per second per client IP address
    ip-ratelimit: 100
    # Limit queries per second sent to each authoritative zone
    ratelimit: 1000

Minimise ANY Responses

Modern BIND, Unbound and other servers answer ANY queries over UDP with minimal responses, in line with RFC 8482. Unbound also has an explicit option:

server:
    deny-any: yes

With deny-any, Unbound returns an empty answer to ANY queries rather than looking up every record.

Keep Responses Compact

• Return only what's needed. In BIND, minimal-responses yes; stops the server adding unnecessary records to the authority and additional sections.
• Keep TXT records tidy, and remove verification records you no longer need.
• Use smaller DNSSEC keys where appropriate. ECDSA (algorithm 13) keys and signatures are much smaller than RSA ones, which reduces response sizes for signed zones.
• Use a sensible EDNS buffer size, such as the 1232 bytes recommended by DNS Flag Day 2020, which also helps avoid fragmentation.

options {
    minimal-responses yes;
    edns-udp-size 1232;
    max-udp-size 1232;
};

Network-Level Defences: Stopping Spoofing at the Source

The root cause of reflection attacks is that some networks let packets leave with source addresses that don't belong to them. BCP 38, published as RFC 2827, describes ingress filtering: networks should drop outgoing packets whose source address isn't one of their own. If every network did this, spoofed-source reflection attacks would be impossible.

If you operate a network, you can implement source address validation on your edge routers. On Linux routers, reverse path filtering is a simple version of the same idea:

sudo sysctl -w net.ipv4.conf.all.rp_filter=1
sudo sysctl -w net.ipv4.conf.default.rp_filter=1

With strict mode (value 1), the kernel drops packets arriving on an interface if the route back to their source address wouldn't use that same interface. It's not suitable for every multi-homed setup, so test it on your topology. On larger networks, unicast reverse path forwarding (uRPF) on routers and ACLs that only permit your own prefixes outbound achieve the same goal.

Defending a Victim of Amplification

If you're the target, the problem is volume. Once the flood is bigger than your link, filtering on your own server can't help, because the traffic has already filled the pipe. Options include:

1. Upstream filtering: Ask your hosting provider or ISP to filter or rate-limit UDP traffic from source port 53 towards your addresses, particularly if you don't run DNS on those addresses.
2. DDoS mitigation services: Cloud-based scrubbing services and CDNs absorb large floods across their networks and pass only clean traffic to you.
3. Anycast and spare capacity: Spreading services across an anycast network dilutes attack traffic across many locations.
4. Local filtering for smaller attacks: Drop unsolicited DNS responses on hosts that don't need them.

For a web server that doesn't run DNS and only uses an upstream resolver, a simple nftables rule drops DNS responses that don't come from that resolver:

table inet filter {
    chain input {
        type filter hook input priority 0; policy accept;
        ct state established,related accept
        udp sport 53 ip saddr != 192.0.2.53 drop
    }
}

Replace 192.0.2.53 with your actual resolver's address. Replies to your own lookups are accepted by the connection tracking rule, and unsolicited DNS traffic from anywhere else is dropped. This reduces load on the host, but it can't help if the attack already saturates the network link.

---

FAQ: DNS Amplification Attacks

---

Conclusion

A DNS amplification attack turns other people's DNS servers into weapons. The attacker spoofs the victim's address, sends small queries to many servers, and lets the large replies converge on the target. It works because UDP doesn't verify sources, some networks still allow spoofed packets, and many DNS servers answer anyone with large responses.

If you run DNS servers, close recursion to your own networks, enable response rate limiting, minimise ANY and other oversized responses, and keep DNSSEC keys compact. If you run a network, filter spoofed source addresses at the edge. And if you might be a target, arrange upstream filtering or a mitigation service before you need it, because by the time a flood arrives your own server can't help.