DNS Amplification Attacks and Response Rate Limiting

DNS amplification is one of the most abused techniques in volumetric denial-of-service attacks, and it works because of two properties baked into classic DNS: it runs over UDP, which is trivial to spoof, and a small query can trigger a large answer. An attacker sends tiny forged requests that appear to come from a victim, and servers around the world dutifully blast big replies at that victim. This guide explains the mechanics of reflection and amplification, the amplification factor, how open resolvers and certain record types make it worse, and the two main defenses operators deploy: closing open resolvers and turning on Response Rate Limiting (RRL) on authoritative servers.

Reflection plus amplification

Two ideas combine into the attack. Reflection means bouncing traffic off a third party by spoofing the source address so the reply lands on the victim rather than the real sender. Amplification means the reply is much larger than the request, so the attacker spends little bandwidth to generate a lot. DNS is ideal for both: UDP has no handshake to prove the sender's address, and features like DNSSEC produce answers many times larger than the query that asked for them.

The flow looks like this:

1. The attacker controls a botnet or a few high-bandwidth hosts.
2. Each host sends UDP DNS queries with the source IP forged to the victim's address.
3. The queries target open resolvers or misconfigured authoritative servers.
4. Those servers send large responses to the victim, who never asked for them.
5. The victim's link saturates under the flood of unsolicited replies.

The amplification factor

The amplification factor is simply the size of the response divided by the size of the request. The higher it is, the more leverage the attacker gets. A classic abuse is the ANY query, which asks a server to return every record it has for a name, and queries for large signed record sets.

You can see the raw size difference yourself. The response is far bigger than the query that produced it:

# Compare the bytes sent versus received
dig ANY isc.org @some-resolver +ignore

;; Query time: 31 msec
;; MSG SIZE  rcvd: 2301      <-- the reply
;; (the question was roughly 45 bytes)

Open resolvers: the fuel

An open resolver is a recursive DNS server that answers queries from anyone on the internet rather than only its intended clients. There are millions of them, often home routers or forgotten appliances, and they are the engines that make reflection attacks easy. A properly configured recursive resolver should only serve its own network.

Test whether a resolver you run is open:

# From OUTSIDE your network, try to make the server recurse for you
dig @203.0.113.53 google.com A +short

# A closed resolver returns REFUSED or nothing.
# An OPEN resolver answers with an address = misconfigured.

In BIND, you close recursion to the public by scoping it:

// named.conf: only recurse for trusted networks
acl trusted { 192.0.2.0/24; 203.0.113.0/24; localhost; };

options {
    recursion yes;
    allow-recursion { trusted; };   // not the whole internet
    allow-query-cache { trusted; };
};

Defending authoritative servers with Response Rate Limiting

Authoritative servers must answer the public, so you cannot simply close them. The problem is that during an attack they emit many near-identical large responses to a spoofed victim. Response Rate Limiting, pioneered in BIND and available in other servers, tracks how often it is about to send the same answer to the same client subnet and throttles the excess. The insight is that a legitimate client rarely needs the identical answer dozens of times per second, but a reflection attack does.

RRL does not drop traffic blindly. When a bucket exceeds its limit, the server can either drop the surplus or, better, return a small truncated response with the TC bit set. A real client then retries over TCP, which cannot be spoofed because it requires a handshake, while the spoofed flood simply evaporates because the victim never completes a handshake it did not start.

// BIND Response Rate Limiting on an AUTHORITATIVE server
options {
    rate-limit {
        responses-per-second 10;   // identical answers per client /24
        window 5;                  // sliding window in seconds
        slip 2;                    // every 2nd dropped reply -> TC (truncate)
        ipv4-prefix-length 24;     // group clients by /24
        ipv6-prefix-length 56;
        // nxdomains-per-second 5;  // separately cap NXDOMAIN floods
    };
};

Tuning RRL safely

• responses-per-second is per client prefix, not global, so set it above what a busy legitimate resolver behind a shared NAT might need.
• slip controls how often a limited client gets a truncated answer instead of a silent drop. A slip of 2 lets honest clients recover over TCP while still cutting attack volume.
• Watch logs before and after. RRL that is too aggressive can briefly starve legitimate recursive resolvers that share an IP block with an attack source.
• RRL belongs on authoritative servers. For recursive servers, the right fix is access control, not rate limiting the public.

Defense in depth checklist

The single most effective internet-wide fix is BCP 38 source address validation at the network edge, because an attacker who cannot spoof a source IP cannot reflect at all. Until that is universal, operators layer the controls above.

A note on ANY queries

Because ANY is such a convenient amplifier and has little legitimate use, many large authoritative providers now answer ANY with a minimal synthesized response (for example a single HINFO record) rather than dumping every record. That alone collapses one of the highest amplification factors available to attackers.

If you operate authoritative DNS, confirm your records resolve correctly from many networks after you enable RRL or change ANY handling, so you do not accidentally throttle real traffic. The Valla DNS propagation checker lets you verify answers from resolvers worldwide, and the Valla DNS learning hub has companion guides on anycast, TTL strategy, and DNSSEC that round out a resilient, abuse-resistant setup.