What Is a DNS Amplification Attack?

Most denial-of-service attacks need the attacker to generate a lot of traffic. A DNS amplification attack lets them borrow it instead. By sending small DNS queries with a forged source address, an attacker tricks thousands of DNS servers into sending much larger responses to the victim. The victim gets buried under traffic from servers that are doing nothing wrong except answering questions — and if you run a misconfigured DNS server, yours could be one of them. The post on securing DNS against attacks gives a general overview; this article goes deep on amplification specifically.

We'll cover how reflection and amplification work together, why DNS is such a popular vector, how to tell whether your server is being abused or your network is being targeted, and the concrete configuration changes that stop your infrastructure from becoming part of the problem.

How a DNS Amplification Attack Works

The attack combines two techniques.

Reflection

DNS queries usually travel over UDP, which has no handshake to confirm the sender's address. An attacker can therefore send a query with the source IP address set to the victim's address. The DNS server has no way of knowing the address is forged, so it sends its reply to the victim. The server becomes an unwitting "reflector," and the victim sees traffic coming from legitimate DNS servers rather than from the attacker.

Amplification

On its own, reflection just hides the attacker. The damage comes from the size difference between query and response. A DNS query is small — typically well under 100 bytes. Some responses are far larger: answers containing many records, long TXT records, or DNSSEC signatures can run to several kilobytes, especially when the query advertises a large EDNS buffer size. The ratio of response size to query size is the amplification factor. US-CERT's advisory on UDP-based amplification has cited factors of roughly 28 to 54 times for DNS.

Put together, the attacker's bandwidth is multiplied by that factor and spread across thousands of reflectors:

1. The attacker (usually controlling a botnet) sends a steady stream of small queries to many DNS servers.
2. Every query carries the victim's IP address as its forged source.
3. Each DNS server sends its much larger response to the victim.
4. The victim's network link, firewall, or servers are saturated by inbound UDP traffic from port 53.

Because the traffic comes from many genuine servers around the world, simply blocking a few source addresses doesn't help, and filtering it upstream requires distinguishing attack responses from real DNS traffic.

Why DNS Is Such an Attractive Vector

Several properties make DNS particularly useful to attackers:

• It's everywhere. Millions of DNS servers are reachable on the internet, including many that shouldn't be.
• UDP is the default transport. No handshake means no source address verification, which is the prerequisite for reflection. Why DNS uses port 53 and when it switches to TCP explains the transport choices.
• Large responses are normal. EDNS raised the size of UDP responses beyond the original 512-byte limit, and DNSSEC added sizeable signatures. Both are legitimate, but they increase the potential amplification. The post on EDNS covers why the larger buffer was introduced.
• Open resolvers. A recursive resolver that answers anyone on the internet will fetch and return any record an attacker asks for, including ones the attacker set up specifically to be large.

Open resolvers vs authoritative servers

Both kinds of servers can be abused, but differently. An open resolver is the worst case because it will recurse for any name, so an attacker can choose the largest possible response. An authoritative server only answers for its own zones, so it's limited to the responses those zones produce — but it must answer the whole internet, so it can't simply refuse outside clients. That's why the defenses below differ by server role. If the distinction is unfamiliar, see authoritative vs recursive DNS servers.

Is Your Server Being Used as a Reflector?

Test whether you run an open resolver

From a machine outside your network (a cloud VM or a phone hotspot), send a recursive query for a domain your server isn't authoritative for:

dig @203.0.113.53 example.org A +recurse

Read the header of the response:

• status: REFUSED, or a timeout, means recursion is correctly restricted.
• status: NOERROR with the ra (recursion available) flag and an answer means the server is an open resolver and can be abused for amplification.

Run this test only against servers you own or are responsible for. Online open-resolver checkers can do the same test from the outside if you don't have another vantage point.

Look for signs of abuse in traffic and logs

A server being used as a reflector typically shows a sudden surge in queries from a small number of source addresses (which are actually the victims) for the same few names, often of type ANY, TXT, or DNSKEY, with large EDNS buffer sizes. On BIND, enable query logging briefly to see it:

sudo rndc querylog on
sudo journalctl -u named -f
# ...observe, then turn it off again, since query logging is verbose
sudo rndc querylog off

rndc querylog toggles per-query logging in a running BIND server; each line shows the client address, query name, and type. Depending on your configuration, logs may go to a file under /var/log rather than the journal. On Unbound, unbound-control stats_noreset gives aggregate counters, including queries by type and the number of rate-limited queries.

Is Your Network Being Targeted?

If you're on the receiving end, the signature is a flood of inbound UDP packets with source port 53, many of them large, from many unrelated DNS servers, arriving at hosts that never sent the matching queries. You can see this with tcpdump:

sudo tcpdump -ni eth0 'udp src port 53 and greater 1000' -c 200

This captures 200 UDP packets from source port 53 that are at least 1,000 bytes long. During normal operation, large DNS responses arriving at a web server are rare; a constant stream of them, especially at an address that doesn't run its own resolver, is a strong indicator of a reflection attack. Flow data (NetFlow, sFlow, or cloud VPC flow logs) shows the same pattern at higher volume with less overhead.

Defenses: Not Becoming a Reflector

1. Close open resolvers

The single most effective thing operators can do is make sure recursive resolvers only serve their own clients. In BIND:

// named.conf
acl "trusted" { 192.0.2.0/24; 198.51.100.0/24; localhost; localnets; };

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

This ACL limits recursion, cache access, and queries to your own networks; outside clients get REFUSED. In Unbound, the equivalent is:

server:
    access-control: 0.0.0.0/0 refuse
    access-control: ::0/0 refuse
    access-control: 192.0.2.0/24 allow
    access-control: 127.0.0.0/8 allow

Unbound evaluates the most specific matching rule, so the allow lines override the default refusal for your networks. If you run a resolver at home, for example with Pi-hole, make sure port 53 isn't forwarded from your router to the internet.

2. Separate authoritative and recursive roles

An authoritative server should never offer recursion. Set recursion no; on authoritative-only BIND servers so they answer only for their own zones. Running both roles on one server makes it far harder to apply the right policies to each. The guide on running your own DNS server with BIND covers this setup.

3. Enable Response Rate Limiting on authoritative servers

Authoritative servers can't refuse the internet, so they need to limit how many identical responses they send to any one address. BIND's Response Rate Limiting (RRL) does exactly that:

// named.conf options for an authoritative-only server
options {
    recursion no;
    minimal-any yes;
    rate-limit {
        responses-per-second 10;
        window 5;
        slip 2;
    };
};

rate-limit caps identical responses to the same client network at 10 per second. When the limit is hit, slip 2 makes BIND send every second dropped response as a tiny truncated reply instead of nothing; a legitimate resolver then retries over TCP, which can't be spoofed, while the attack's victim receives almost nothing. minimal-any makes the server return only one record set for ANY queries instead of everything at the name. Validate with named-checkconf before reloading.

Unbound offers similar controls for resolvers:

server:
    ratelimit: 1000
    ip-ratelimit: 100

ratelimit caps queries per second toward any single zone, and ip-ratelimit caps queries per second from any single client address. Tune both to your normal traffic levels so legitimate clients aren't affected.

4. Minimize ANY and keep responses sensible

RFC 8482 allows servers to answer ANY queries with a single small record set rather than every record at a name, and most modern DNS software and providers now do this by default. Also keep the advertised EDNS UDP buffer at the community-recommended 1232 bytes, which limits how large a UDP response can be before the client must retry over TCP.

5. Use DNS cookies where supported

DNS cookies (RFC 7873) let a server recognize clients it has talked to before. Combined with rate limiting, they allow servers to treat cookie-less, likely-spoofed traffic more strictly. Current BIND and Unbound versions support them.

Defenses: Stopping Spoofing at the Source

Amplification only works because spoofed packets can leave some networks. BCP 38 (RFC 2827) describes ingress filtering: networks should drop outbound packets whose source address doesn't belong to them. If every network did this, reflection attacks would be impossible. You can't force the rest of the internet to comply, but you can make sure your own network does — on edge routers and in cloud security groups, only allow traffic sourced from your own address ranges to leave. Router features like unicast reverse path forwarding (uRPF) implement this automatically.

Defenses: Surviving an Attack

If you're the target, the traffic arrives faster than your own link can carry it, so the effective mitigation has to happen upstream:

1. Use a DDoS mitigation or scrubbing service. Large anycast networks absorb and filter reflection floods before they reach you. Anycast DNS and anycast CDN fronting spread the load across many locations.
2. Ask your upstream provider for filtering. ISPs and hosting providers can drop or rate-limit UDP source port 53 traffic toward hosts that don't need it.
3. Filter at the edge for hosts that don't do DNS. Servers that don't resolve names directly (or only talk to specific resolvers) can drop inbound UDP from port 53 except from those resolvers.
4. Keep your own DNS resilient. If the attack targets your authoritative servers, a provider with large anycast capacity, plus secondary providers, keeps your names resolving.

---

DNS Amplification Attack FAQ

Conclusion

DNS amplification attacks turn ordinary DNS servers into weapons by exploiting two facts: UDP doesn't verify source addresses, and some DNS responses are far larger than the queries that trigger them. Spoofed queries sent to thousands of servers become a multiplied flood aimed at a single victim, delivered by infrastructure that's doing nothing wrong except answering whoever asks.

Most of the fix lies with server operators. Don't run open resolvers, keep authoritative and recursive roles separate, enable Response Rate Limiting, minimize ANY responses, and keep EDNS buffers at sensible sizes. Network operators should implement BCP 38 so spoofed packets never leave their networks. And if you're a potential target, plan ahead with upstream DDoS mitigation and anycast capacity, because by the time a reflection flood reaches your own firewall, your link is already full.

These references cover amplification attacks and their mitigations in more detail:

1. CISA: UDP-Based Amplification Attacks — the advisory listing amplification factors for DNS and other UDP protocols.
2. RFC 2827: Network Ingress Filtering (BCP 38) — the best practice for preventing source address spoofing.
3. RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY — the standard for minimal ANY responses.
4. Cloudflare Learning Center: DNS amplification DDoS attack — an accessible explanation of how amplification attacks work.
5. BIND 9 Administrator Reference Manual: bind9.readthedocs.io — documentation for Response Rate Limiting, recursion ACLs, and minimal-any.