Your Resolver Is Someone Else's Weapon.

The anomaly: one name eating the whole resolver

It started as a glance at the query log. A public resolver serves a long tail of names: some Google, some CDN, some ads getting blocked, thousands of different domains. Ours, that morning, looked like this:

$ jq -r .QH /dev/shm/querylog.json | sort | uniq -c | sort -rn | head -3
3455950 cloudflare.com          ← 93.38% of all DNS traffic
   9124 www.google.com
   7733 googlevideo.com

Three and a half million queries for cloudflare.com in twelve hours, all of them TXT. Not A, not AAAA, not HTTPS: TXT, the record type that holds text and therefore holds a lot of bytes. No human browses to a TXT record. Nothing on a normal network asks for one three and a half million times.

This is the tell. When one qname and one qtype dominate a resolver's traffic, you are almost never looking at a client bug. You are looking at somebody standing behind your resolver and using it to hit something.

The mathematics of a weapon

Here is why cloudflare.com/TXT and not something else. Run it yourself, right now, against any resolver:

$ dig TXT cloudflare.com +bufsize=10000
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 26
;; MSG SIZE  rcvd: 2147

$ dig TXT samsung.com +bufsize=10000
;; flags: qr rd ra; QUERY: 1, ANSWER: 52
;; MSG SIZE  rcvd: 4131   ← 58× the query size

Big companies accumulate TXT records the way garages accumulate boxes: domain-verification tokens for every SaaS product they ever signed up for, SPF policies, DKIM keys, site-ownership proofs. Nobody ever deletes them. cloudflare.com carries 26 of them; samsung.com carries 52. To an attacker these are not corporate records, they are free ammunition: a huge, publicly resolvable, cacheable answer that any resolver on earth will hand out to anyone who asks. This is why the same handful of fat-TXT domains show up in reflection floods again and again. None of these companies did anything wrong, and their infrastructure is not the target - their record size is simply the payload.

Here is a sample of the ammunition, measured against the same 71-byte query. Run any of these yourself with dig TXT <domain> +bufsize=10000:

The attacker who hit us picked cloudflare.com, at 30×. They left the bigger guns on the table: cisco.com is a 96× amplifier, more than three times as loud. These figures were measured on 13 July 2026 against a public resolver; they tend to grow over the years as verification tokens pile up and nobody prunes them.

Now do the arithmetic that the attacker did. On our wire, during the flood:

• • The query: 71 bytes on the wire.
• • The answer: 2,257 bytes, too big for one UDP datagram, so it left as two IP fragments.
• • The ratio: 31.8×.

One reconciliation, because a careful reader will notice it: the table above lists cloudflare.com at 2,147 bytes, but our wire shows 2,257. The 110-byte difference is the DNSSEC signatures. A plain TXT query returns the 2,147-byte answer; set the DNSSEC-OK bit and the resolver also attaches the RRSIG records that authenticate it, and the answer grows to 2,257. The attack set that bit - buying an extra 110 bytes of amplification for free, and confirming this was a tuned tool rather than a stray misconfiguration.

The attacker forges the source address of each query to be the address of whoever they want to hurt. Our resolver, doing exactly what a resolver is built to do, sends 2,257 bytes to that address. The attacker spends 71 bytes; the victim receives 2,257. At the ~250 queries per second we were sustaining, that is roughly 4.6 Mbps of attack traffic leaving our server, aimed at people we had never heard of.

One more detail worth knowing, because it is how you confirm the diagnosis: every one of those queries carried a DNS transaction ID of 0x0000, advertised an EDNS UDP buffer size of 10000, and set the DNSSEC-OK bit. No real resolver does the first two. A real client randomises its transaction ID (that randomness is what makes cache poisoning hard), and modern software advertises 1232 bytes, not 10000. Every field was set to squeeze the largest possible answer out of us: the huge buffer to avoid early truncation, the DNSSEC-OK bit to pull in the signatures. This is a purpose-built tool, not a misconfigured device.

The trap: the obvious fix is the worst thing you can do

The reflex is immediate and it is wrong. You have a list of IP addresses hammering your resolver. Ban them. Firewall the /24s. Done.

We ran tcpdump and looked up who those addresses actually belonged to. Roughly 1,792 distinct IPs, packed into just eight /24 blocks:

These are not the attacker. These are the victims. The source addresses are forged; they are the addresses the flood is being aimed at. Somewhere in Brazil there is an ISP whose customers were drowning in DNS answers they never requested, and we were one of the machines drowning them.

So look at what banning them would have accomplished. The attacker's goal is to make those networks unreachable. If we had blocked those ranges at the firewall, our resolver would have stopped answering anyone at those addresses - including the real users behind them - while the attacker simply spun up a new list of forged victims and carried on. We would have completed the denial of service on the attacker's behalf, for free, and called it a fix.

This is also why "just block the attacker's IPs" advice you find on forums is actively dangerous for this attack class. It works fine for a direct flood. Applied to reflection, it turns your resolver into an accomplice twice over.

Why our rate limits never fired

We are not an unprotected box. There is a per-IP query cap and a per-subnet cap in nftables, sitting in front of everything:

# per-IP query cap -> auto-ban on excess
udp dport 53 \
    meter dns_qps_ip { ip saddr limit rate over 30/second burst 100 packets } \
    add @dns_bad_ip { ip saddr timeout 30m } counter drop

# per-/24 cap -> ban the whole subnet on a spray
udp dport 53 \
    meter dns_qps_24 { ip saddr & 255.255.255.0 limit rate over 150/second burst 400 packets } \
    add @dns_bad_24 { ip saddr & 255.255.255.0 timeout 30m } counter drop

Both counters were at zero through the entire flood. Not "low" - zero. The attack was calibrated to stay underneath them: each spoofed source sent only 1 to 5 queries, spread across ~1,792 addresses. Thirty per second per IP is a generous ceiling and the attack never came close to it, because it never needed to. The volume came from the number of forged sources, not from the rate of any one of them.

There was even a global ceiling of 300 queries/second. The flood sat at ~250. Coincidence is not the word I would use.

This is the structural lesson, and it applies to every rate limiter on every resolver including the one built into AdGuard Home (ratelimit, per client IP): a limiter keyed on the source address cannot see an attack that has no real source address. Spoofing makes the key meaningless. The attacker gets to choose a fresh key for every packet.

The self-inflicted wound

One rule did fire. Months earlier we had added a blunt instrument: drop small UDP/53 packets when they exceed 150 per second, on the theory that amplification queries are small.

udp dport 53 udp length 30-70 \
    limit rate over 150/second burst 300 packets \
    counter name "drop_short_dns_flood" drop

# counter: 2,930,000+ packets dropped. Some of them were the attack.
# Some of them were our users.

Look at what else lives in a 30-70 byte UDP/53 packet. ssl.gstatic.com is 41 bytes on the wire. api.epicgames.dev is 43. Ordinary A queries from ordinary people are exactly the same size as the attack's queries, because a DNS query for a short name is a short packet, whoever sends it.

So the rule had a single 150/second budget, and the flood was spending it at 250/second. Legitimate users' queries arrived, found the budget already exhausted by the attack, and were dropped. Real people's DNS was broken - by our own defence, on behalf of the attacker. We call this the shared fate failure: a filter that cannot distinguish attack from user, given a bucket they must share, will starve the user.

The fix was to stop asking a layer-4 rule to do a layer-7 job. A packet filter can see size and rate. It cannot see the query name, and it cannot see how big the answer is going to be - which are the only two facts that actually separate this attack from a person opening a website. So we demoted the rule to what it is honestly good at - a backstop against raw packet-rate exhaustion - and moved the real defence up to the resolver:

# Pure pps-exhaustion backstop. Fires only on a genuine packet flood,
# far above any legitimate aggregate. Amplification defence now belongs
# to the RRL layer, which can see the qname and the response size.
udp dport 53 udp length 30-70 \
    limit rate over 3000/second burst 6000 packets \
    counter name "drop_short_dns_flood" drop

# drops since the change: 0

If you have a rule like the first one in your firewall right now - and a lot of hardening guides recommend exactly that shape - it is worth checking its counter. It may be protecting you. It may also be quietly eating your own traffic.

The real fix: response rate limiting with a TC=1 slip

The proper defence for this attack has existed since 2012, when Paul Vixie and Vernon Schryver described Response Rate Limiting. BIND, Knot and PowerDNS all ship a form of it. Most operators never turn it on, and the DNS software most home users run - AdGuard Home, Pi-hole - does not implement it at all. We built it into our AdGuard Home fork. Here is the whole idea in three gates:

# Runs after the answer is resolved, before it is written to the wire.

GATE 1 - transport.  UDP only. DoH / DoT / DoQ / TCP are
                   connection-verified, cannot be spoofed, never touched.

GATE 2 - size.       Is the response bigger than 512 bytes?
                   If not, send it. This alone exempts 99.7% of real
                   traffic: an A record is tiny, and a small answer
                   cannot amplify anything.

GATE 3 - budget.     Charge two token buckets, 5 tokens/s, burst 20:
                     bucket A: (source /24, qname, qtype)   <- fairness
                     bucket B: (qname, qtype)               <- the killer
                   If either is empty -> SLIP.

SLIP =             reply with the header only: TC=1 (truncated),
                   empty answer section, 32 bytes.

Bucket B is the one that kills the attack, and it is the piece that most rate limiters get wrong. The attacker's whole strategy was to vary the thing everyone keys on - the source address. So we key on the thing they cannot vary: the query itself. Every one of those 1,792 forged sources was asking for the same name and the same type, so all 1,792 of them converge on one bucket. The carpet-bomb collapses into a single budget of 5 answers per second. Spreading the attack across more IPs does not help them; it changes nothing at all.

And the slip is what makes it safe. We do not drop the query - dropping is indistinguishable from an outage, and a real client behind that /24 would just sit there timing out. We answer, with the truncation bit set, which is a completely standard DNS instruction meaning "too big for UDP, ask me again over TCP." A real client obeys it, opens a TCP connection, and gets its full answer, and we verified this works. A spoofed client cannot: to complete a TCP handshake you must receive the SYN-ACK, which goes to the address you forged, not to you. The very thing that makes the attack possible - lying about your address - is the thing that makes it impossible to follow the retry.

The result on the wire, measured with dig: the 2,257-byte answer becomes a 32-byte response. Against a 71-byte query that is 0.45× - our resolver now emits fewer bytes than it receives. As an amplifier, it is worse than useless. It is a net absorber.

Proving it before trusting it

A defence that truncates real users' answers is worse than the attack. So we did not flip it on. We ran the engine in shadow mode first - the full decision logic, running live against the real flood, deciding what it would do and writing that to a ledger, while the resolver kept answering normally.

Then the step that actually earns trust: parity. The shadow engine and the enforcement engine are two separate pieces of software - the policy brain lives in our Go WAF, the enforcement lives in the resolver fork - so we made them share one frozen hash of the query name and checked that, over the same 30 seconds of the same live flood, they reached identical verdicts: 98.0% slip, 5.0 answered per second, both of them, to the decimal. Only then did we flip enforcement on.

Across 67,905 shadow decisions the false-positive ledger stayed clean: not one legitimate query was ever slated for truncation. In the live packet capture taken minutes after enforcement went live, a real user's web.api.vk.com lookup was served in full, 190 bytes, while the flood around it was being reduced to 32-byte stubs.

The twist: success made us blind

Minutes after enforcement went live, our monitor reported the flood had stopped. Zero percent slip. Nothing happening. We had won so completely that the attack had apparently given up on the spot.

It had not. The monitor read the resolver's query log, and gated on response size - the same 512-byte gate as the engine. But enforcement truncates the response before it is written to that log. So the log now recorded a stream of harmless 32-byte answers, the monitor's size gate exempted every one of them, and the tool that had found the attack in the first place went completely blind to it. The flood was still running at full strength. The counters inside the enforcement engine were climbing by four thousand per window. On the wire, a six-second capture showed 632 truncated responses against 14 full ones.

The verdict

Enforcement went live at 15:46 on 12 July. The attack kept coming for another fifteen and a half hours, getting nothing but 32-byte stubs, and then - at 07:12 the next morning - it stopped, and has not come back. Reflection capacity is rented by the hour, and an amplifier with a 0.45× ratio is not worth the rent.

Twelve million reflected responses that never reached a victim, at a measured cost of 0.061 milliseconds each. No scrubbing appliance, no upstream provider, no traffic contract - a few hundred lines of Go, and a firewall rule that we made less aggressive, not more.

And the honest residual, because a defence you cannot state the limits of is a defence you do not understand: the budget of 5 answers per second gets spent on the attack, so roughly 90 kbps of full-size answers still reached those victims for as long as the flood ran. We killed 98.2% of it, not 100%. The remaining 1.8% is the price of not dropping queries - of leaving a door open so that a real client behind a victim's /24 can still resolve a name.

What this incident is actually about

We did not stop the attacker. We never saw them, we still cannot see them, and for all we know their queries will start arriving again tonight. We did not defeat a botnet, and any write-up claiming otherwise about an attack like this is selling something.

What we did was narrower and, I think, more useful: we refused to be the weapon. The packets still arrive. We simply stopped being willing to turn 71 bytes into 2,257 and post them to a stranger. And we did it without banning a single address - which mattered, because every address we could have banned belonged to somebody who was already being hurt.

If you take one thing from this: check your top-queried domain today. It takes ten seconds, it is the same check that found this, and the reason it matters is that an amplification attack running through your resolver is completely invisible from the inside. Nothing breaks. Nothing gets slow. No alert fires. Your resolver is working perfectly, exactly as designed, at full speed - for somebody else.