Skip to content

DNS amplification and reflection: turning open resolvers into weapons

· 18 min read
Copyright: MIT
ddos dns networking
Wordmark reading DNS amplification with an orange arrow showing a small query becoming a large reflected response

Send a 64-byte question to the right DNS server and it will hand back a 3,000-byte answer. Now lie about who asked. Put the victim’s address in the source field of that tiny UDP packet, and the server ships its fat reply to a machine that never spoke to it. Do this from a botnet, against tens of thousands of misconfigured resolvers at once, and you have turned a fraction of your own bandwidth into a flood pointed at someone else. The attacker never touches the target directly. The internet’s own infrastructure does the hitting.

That is the whole trick, and it has been known for more than two decades. The reason it keeps working is not subtle cryptography or a clever zero-day. It is two old design choices that nobody can fully unwind: UDP has no handshake, so a server cannot tell whether the return address on a query is real, and most networks still forward packets without checking that the source address belongs on the wire they arrived on. Everything else is arithmetic.

This post walks the mechanism from the bytes up. It covers why UDP makes reflection possible at all, where the amplification factor comes from and how large query types push it higher, the March 2013 attack on Spamhaus that put DNS amplification on the front page, the two mitigations that actually address the root cause (ingress filtering and response rate limiting), and where the threat has moved since, including IPv6 and the 2024 DNSBomb work that rebuilt amplification out of features rather than misconfiguration.

Reflection, amplification, and the difference between them

Two ideas get bundled into one phrase, and keeping them apart makes the rest clearer.

Reflection is the act of bouncing traffic off a third party. The attacker sends a packet to some server with the victim’s address forged into the source field. The server, having no reason to doubt it, replies to the victim. The attacker’s real address never appears in the traffic the victim sees. This buys anonymity and it buys distribution, because thousands of innocent reflectors are now sending packets and there is no single origin to block.

Amplification is the multiplier on top of reflection. It only matters because the reflected response is bigger than the request that triggered it. If a 64-byte query yields a 64-byte reply, reflection still hides the attacker but costs as much bandwidth as it delivers. The attack becomes economical when the reply dwarfs the request. DNS is a near-perfect amplifier because the protocol was built to answer small questions with potentially large answers, and over the years those answers got larger.

You need both halves. Reflection without amplification is a stealth trick with no leverage. Amplification without reflection just floods your own uplink. Put them together and a single machine on a modest connection can direct a multiple of its capacity at a target it never contacts.

Attacker spoofs src= victim IP Open resolvers resolver resolver resolver small queries (~64 B) Victim flooded large responses (~3,000 B each) *The attacker's only outbound traffic is small spoofed queries. The resolvers do the volume, aimed at a victim that never queried them.*

Why UDP makes this possible

The vulnerability lives in the transport layer, not in DNS itself. DNS rides primarily on UDP port 53, and UDP is connectionless. There is no SYN, no SYN-ACK, no three-way handshake to establish that the party claiming an address can actually receive traffic at it. A server gets a datagram, reads the source address, and replies there. It has no way, within the protocol, to confirm the source is genuine.

TCP closes this gap by accident. Before any meaningful data flows, the two ends complete a handshake, and an attacker who forges the source address never sees the SYN-ACK and so cannot complete it. (This is the same property the SYN flood abuses from the other direction, by leaving half-open connections to exhaust a server’s state table.) Reflection needs a protocol that answers before it verifies. UDP-based services fit: DNS, NTP, SNMP, SSDP, memcached, and others have all been pressed into reflector duty. DNS got there first and stayed prominent because resolvers are everywhere and answers can be large.

Paul Vixie, who has spent more time inside DNS internals than almost anyone, put the structural problem plainly in a 2014 ACM Queue essay: the internet’s stateless, best-effort packet model means any node can emit a packet claiming to be from any source, and nothing in the path is obligated to check. Reflection is a direct consequence of that. You cannot patch it out of UDP without making UDP into TCP.

Why does DNS stay on UDP at all, given the risk? Because the protocol is latency-sensitive and the queries are tiny. A recursive lookup might touch a root server, a TLD server, and an authoritative server before it can answer, and forcing a TCP handshake at each hop would add round-trips to an operation that needs to feel instant. DNS does support TCP, and falls back to it when a response is too large for a single UDP datagram or when a server signals truncation, but UDP is the default for the common case and will stay that way. The protocol traded verifiability for speed at its inception, and the reflection problem is the bill for that trade, payable by whoever the attacker points at.

Where the amplification comes from

A DNS query is small. The question section carries a name, a type, and a class, and the whole datagram for a typical lookup runs a few dozen bytes. The response carries the question back plus answer records, and depending on what is asked, those records can be much larger than the question.

The classic lever is the ANY query. Instead of asking for a single record type, ANY asks the server to return every record it holds for a name: the A and AAAA addresses, the MX mail records, the NS delegation, the TXT strings, and whatever else is on file. A zone with rich records answers an ANY query with a response many times the size of the question. Cloudflare’s own walkthrough of a real attack measured a 64-byte query producing a 3,223-byte response against a well-populated zone, a clean 50x.

Two extensions push the ceiling higher. EDNS0 lets a client advertise that it can receive UDP responses larger than the original 512-byte DNS limit, commonly up to 4,096 bytes, so the server is free to pack more into a single datagram instead of truncating. DNSSEC then fills that space. Signed zones attach cryptographic signature records (RRSIG, DNSKEY, and friends) to their answers, and those signatures are large. A signed zone queried over EDNS0 returns a response inflated by the very keys meant to secure it. The security mechanism becomes the amplifier. Measured factors for ANY queries against EDNS0 and DNSSEC-signed domains commonly land in the 40x to 60x range, and carefully chosen zones do better.

Response size vs a ~64-byte query A record ANY (rich zone) ANY + EDNS0 + DNSSEC ~90 B ~3,200 B ~4,000 B *Bars are illustrative of measured orders of magnitude, not a single benchmark. EDNS0 raises the UDP ceiling toward 4,096 bytes and DNSSEC signatures fill it.*

The economics fall out of the ratio. If an attacker controls a botnet pushing 6 Gbps of spoofed queries and the resolvers return 50x, the victim sees 300 Gbps. The attacker pays for the small side of the trade. Open resolvers, running on well-connected hardware with fat uplinks, pay for the large side without knowing it. Cloudflare’s description of them was apt: these are servers on big pipes, and used this way they are bazookas.

The resolver that should not answer

The reflector in a DNS amplification attack is almost always an open resolver: a recursive DNS server that will accept and answer queries from any client on the internet, not just from the network it was meant to serve. A correctly configured recursive resolver answers only for its own users (a home router serving a household, an ISP resolver serving subscribers). An open resolver answers for the world.

Most open resolvers are accidents. A home gateway with DNS forwarding exposed to the WAN side, an enterprise server installed with permissive defaults, a device that shipped with recursion enabled and never locked down. The operator gains nothing from answering strangers and usually does not know it is happening. The attacker enumerates the IPv4 address space looking for these, builds a list, and uses it.

The scale of the problem became measurable in early 2013, when network engineer Jared Mauch started the Open Resolver Project and scanned the entire IPv4 internet for hosts that would answer recursive queries. The count was staggering: roughly 27 million resolvers responded, of which around 25 million posed a real amplification threat by US-CERT’s reckoning in alert TA13-088A. Publishing that list, and giving operators a way to check their own ranges, is widely credited with starting the long decline in open-resolver counts. The number has fallen substantially since, but it has never reached zero, and a few thousand high-bandwidth reflectors are enough.

March 2013: the attack on Spamhaus

The textbook case arrived the same spring. Spamhaus is the anti-spam organization whose blocklists a large share of the world’s mail servers consult before accepting mail. In March 2013 it added the Dutch hosting provider CyberBunker to its lists. CyberBunker, a bulletproof host operating out of a former NATO bunker, took exception, and a campaign under the STOPhaus banner began hammering Spamhaus off the internet.

Spamhaus moved behind Cloudflare on 18 March. The attackers responded by escalating into DNS amplification. The recipe was exactly the one above. Spoof Spamhaus’s (now Cloudflare’s) addresses as the source, fire small queries at open resolvers around the world, and let the resolvers deliver the volume. Cloudflare’s writeup describes attackers requesting large zone data, with queries near 36 bytes returning responses near 3,000 bytes, a roughly 100x multiplier, and a frequently cited variant aimed ANY queries at the ripe.net zone for its large answer.

The numbers climbed past anything publicly reported before. Cloudflare absorbed around 120 Gbps at its own edge, and at least one Tier 1 provider reported seeing more than 300 Gbps of related traffic upstream as the attackers shifted to going after Cloudflare’s transit peers and internet exchanges directly. That 300 Gbps figure, and Cloudflare’s headline calling it “the DDoS that almost broke the internet,” is how the event lodged in memory. The number was real even if the title oversold the danger to the internet as a whole.

2000 BCP 38 published 2012 RRL released 2013 Spamhaus, ~300 Gbps Open Resolver Project 2016 Mirai era, vectors diversify 2024 DNSBomb *Two decades of DNS amplification: the mitigations predate the most famous attack, and the threat kept mutating after it.*

Attribution did not stay anonymous, which is unusual for a DDoS event. Sven Olaf Kamphuis, associated with CyberBunker, was arrested in Spain in April 2013 and extradited to the Netherlands. A UK teenager known online as Narko later pleaded guilty to carrying out the attack, and investigators found tens of thousands of pounds of DDoS-for-hire proceeds in his account. The reflection design hid the packets in flight. It did not hide the people who paid for them or bragged about them.

Fixing the root cause: ingress filtering and BCP 38

There is a clean fix for the entire reflection family, and it has existed since 2000. RFC 2827, published as BCP 38 by Paul Ferguson and Daniel Senie, recommends network ingress filtering: a provider should drop any packet whose source address could not legitimately have originated on the interface it arrived on. If a customer is allocated a specific address block, packets leaving that customer with a source address outside the block are forged by definition, and the provider should discard them at the edge.

Deploy this everywhere and spoofing stops working. The attacker can no longer put the victim’s address in the source field, because the first router that sees the packet drops it. No spoofing, no reflection, no amplification. The mechanism is simple and the standard is old.

Customer block: 203.0.113.0/24 customer network edge router src 203.0.113.7 forwarded src 198.51.100.4 (forged) dropped: not in /24 *BCP 38 in one picture. The router knows which prefix the customer owns; anything else in the source field is forged and discarded.*

So why is reflection still a daily event in 2026? Because filtering helps everyone except the network that deploys it. The operator who turns on ingress filtering protects the rest of the internet from spoofed packets leaving its customers, while gaining little direct benefit and taking on configuration and maintenance cost. It is a collective-action problem, the kind that is hard to solve without coordination or regulation. CAIDA’s Spoofer project has crowd-sourced measurements of source-address-validation deployment for years, and the picture improves slowly. The MANRS initiative pushes operators toward SAV and other routing hygiene, but only a small fraction of routed networks formally participate, and even among them outbound filtering lags inbound. The standard works. Getting it deployed is the unsolved part.

Mitigating at the reflector: response rate limiting

If you cannot stop spoofing across the whole internet, you can at least make the reflectors less useful. Response Rate Limiting, designed by Paul Vixie and Vernon Schryver and shipped in BIND from 2012 onward, is the standard tool. It targets a signature of amplification: under attack, an authoritative server sees a flood of near-identical queries that all appear to come from the same client (the spoofed victim), and it would otherwise answer every one with a large response.

RRL tracks, per client and per response type, a conceptual account that earns a fixed number of credits each second. Each response debits the account. When the account goes negative, the server stops sending full answers to that client and instead either drops the response or returns a truncated one with the TC bit set. A truncated reply tells a legitimate resolver to retry the query over TCP, which forces the handshake a spoofed source can never complete. Real clients absorb a brief, occasional delay. The spoofed victim stops receiving the amplified flood, because the server has decided that one client is asking for the same large answer far too often to be genuine.

Per-client credit account (RRL) earns N credits / sec credits each response debits 1 positive full answer sent negative truncated (TC=1), retry over TCP The spoofed victim never completes a TCP handshake, so the amplified flood stops. *RRL does not block clients; it caps how often it will hand the same large answer to the same source, then forces a TCP retry that spoofing cannot survive.*

RRL is recommended for authoritative servers, where the query mix is predictable enough that a flood of identical large responses to one client reads clearly as abuse. It is a probabilistic defense and it accepts a cost: a small fraction of legitimate transactions during an attack get the truncate-and-retry treatment and pay a round-trip penalty. That tradeoff is deliberate. Vixie’s framing of the design was that an operator should be willing to drop the slice of input flow statistically likely to be attack traffic, accepting rare collateral delay to deny the amplifier its leverage.

Open resolvers have their own fix, which is simply to stop being open: disable recursion on authoritative servers, restrict recursion to known clients on resolvers, and close the WAN-side DNS on home gateways. None of these is exotic. The persistence of the problem is operational, not technical.

This is the same defensive arithmetic that shows up in rate-limiting algorithms at the application layer, where a token bucket decides how often a given client may be served before the system assumes abuse.

Where the threat went after 2013

DNS amplification did not stop in 2013; it stopped being special. The volumetric record kept moving to other reflectors. NTP’s monlist command briefly produced higher amplification factors than DNS and drove the 2014 records. Then memcached, a database cache that should never face the public internet, turned out to amplify enormously when exposed, and the 1.3 Tbps GitHub attack of 2018 used it. The pattern is identical each time: a UDP service that answers before it verifies, a large response relative to the request, and enough exposed instances to enumerate. DNS was the first famous instance of a general flaw.

The flood model also shares the stage now with botnet-driven attacks that do not need reflection at all. The Mirai botnet of 2016 marshalled hundreds of thousands of IoT devices to generate raw traffic directly, no amplifier required, and took out the DNS provider Dyn. When you control enough endpoints, you can skip the reflection step entirely.

Two more recent developments matter for anyone tracking the current state. The first is IPv6. A 2025 study warns that IPv6 is becoming fertile ground for reflection amplification, for a structural reason: source-address-validation deployment lags even further behind on IPv6 than on IPv4, and the enormous address space frustrates the enumerate-and-filter approaches that helped on IPv4. The reflector population that took a decade to shrink on IPv4 is being rebuilt on a protocol where the same mistakes are easier to make and harder to find.

The second is DNSBomb, presented at IEEE S&P 2024. It rebuilds amplification out of standard, correct DNS behavior rather than misconfiguration. By exploiting query timeout, query aggregation, and fast response returning, an attacker accumulates queries sent at a low, innocuous rate and arranges for all the responses to arrive at the victim in a single concentrated pulse. The measured bandwidth amplification factor exceeded 20,000x, with pulse magnitudes near 8.7 Gb/s in small-scale tests, and the pulsing pattern degrades both stateless and stateful connections. It drew eleven CVE assignments, with patches from BIND, Unbound, PowerDNS, Knot, and others. The significant point is that DNSBomb does not depend on open resolvers in the classic sense. It abuses features working as designed. That is a harder thing to filter than a misconfiguration, and it is the direction the research is heading.

What two decades of this teaches

The durable lesson of DNS amplification is that the fix and the attack have lived side by side for the entire history of the problem. BCP 38 predates the Spamhaus attack by thirteen years. Response rate limiting shipped a year before it. The Open Resolver Project measured the reflector population the same spring. None of that prevented 300 Gbps of reflected traffic, because the defenses that work depend on operators who gain little from deploying them acting anyway, and most do not until something forces the issue.

The arithmetic at the center has not changed. A connectionless transport that answers before it verifies, plus a response larger than the request, plus an unfiltered path, equals leverage. Every named variant since (NTP, SSDP, memcached, and now the IPv6 reflector population and DNSBomb’s feature-abuse) is the same equation with different terms. You can attack the spoofing (ingress filtering), the reflector (rate limiting and closing open resolvers), or the absorption (anycast and CDN scrubbing that spreads the flood across hundreds of points of presence until no single one is overwhelmed). The most effective of those, ingress filtering, is also the one that asks each operator to act for everyone else’s benefit. That is why the cleanest fix is the least deployed, and why a 64-byte question will still, somewhere on the internet right now, be returning a 3,000-byte answer to a machine that never asked.

Sources & further reading

Further reading