Why is it called water torture?

Because the individual queries are unremarkable and the accumulation is what does the damage. Nothing about any single query looks wrong — it is a well-formed request for a name under your zone, which your authoritative server is obliged to answer.

Why does it hurt resolvers that are not the target?

Because the queries usually arrive through recursive resolvers belonging to ISPs and public providers. Those resolvers cannot cache a negative answer usefully when every name differs, so their own outstanding-query capacity fills up with work for your zone. Your attack becomes their outage, which is why this class attracts operator attention quickly.

Does NXDOMAIN caching help?

Only partially. Aggressive negative caching lets a resolver answer for a whole non-existent range rather than one name at a time, which helps the resolver considerably. It does not help the authoritative server, which still has to answer the first query for each range.

Is anycast the answer?

It disperses the load across sites, which is genuinely valuable for authoritative DNS and is why almost all serious authoritative operators are anycast. It does not reduce the total work, so a large enough attack still requires rate limiting and capacity.

Attack class

DNS Water Torture and Random Subdomain Attacks

Last updated: August 2026 · The cache cannot help you here · Reading time ~8 min

Many distinct inputs arriving at one point with nothing repeated, standing for queries that can never be served from cache because no name occurs twice.

A random subdomain attack queries names that do not exist under a zone you own — a8f3k2.example.com — so no cache can answer them and every query reaches your authoritative servers. It exhausts the authoritative infrastructure and the recursive resolvers in the middle at the same time, which is why it damages parties who are not the target.

Network topology showing where an application-layer attack does its damage: the marker sits on the servers, because every request is well-formed and the work it asks for is real. — Sharp version (SVG)

What it exhausts

Authoritative DNS server capacity, and the outstanding-query slots of every recursive resolver in the path.

The mechanism is elegantly nasty. Caching is what makes DNS survivable at internet scale, and caching works because names repeat. Query a different random name every time and the cache is structurally useless — every single query has to travel to the authoritative servers for the zone.

How it differs from similar attacks

A DNS amplification attack uses DNS servers as reflectors against a third party; the DNS infrastructure is the weapon rather than the target. Here the DNS infrastructure is the target, and no reflection is involved.

A plain DNS query flood repeats names and is therefore absorbable by caching. Removing the repetition is the whole innovation.

Observable telemetry

Query rate for one zone rising while the cache hit ratio for that zone collapses.
A very high proportion of NXDOMAIN responses.
Query names with high entropy in the leftmost label and a constant parent domain.
Recursive resolvers — not end clients — as the apparent source, because that is the path.
Outstanding-query counters on your own resolvers climbing if you also run recursion.

Common false positives

Some legitimate systems generate high-entropy subdomain queries by design: certain CDN implementations, telemetry systems, and DNS-based service discovery. Anti-spam DNSBL lookups also produce large volumes of unique names under a constant parent, which is exactly the signature described above.

A rule that keys purely on entropy will catch all of them.

Mitigation by layer

Authoritative infrastructure. Anycast to disperse (why that helps and what it does not fix), plus response-rate limiting tuned specifically on NXDOMAIN responses rather than on total queries.

Zone design. A wildcard record changes the answer from NXDOMAIN to a real response, which removes the negative-caching problem and introduces a different one — every random name now resolves. That is a deliberate trade and occasionally the right one.

Recursive side, if you operate resolvers: aggressive negative caching, and outstanding-query limits per zone so one zone under attack cannot consume the whole resolver.

Transport. TCP support is an operational requirement rather than an option RFC 9210, and rate limiting that suppresses UDP answers without accounting for the resulting TCP retries can make behaviour worse rather than better.

Operational pitfalls

Rate limiting the parent zone globally, which throttles legitimate queries for real names alongside the random ones.

Blocking the resolvers. They are the visible source and they are not the attacker; blocking a major public resolver removes a large fraction of your legitimate users.

Adding a wildcard under pressure without thinking through what now answers — including for names that should have failed.

Safe validation

Against your own zone and your own authoritative servers, with authorisation. Generate queries for non-existent names under a test zone and measure at what rate NXDOMAIN handling degrades, then confirm that queries for real names in the same zone still resolve at that rate. The second measurement is the one that matters and the one usually skipped.

Sources

Frequently asked questions

Why is it called water torture?: Because the individual queries are unremarkable and the accumulation is what does the damage. Nothing about any single query looks wrong — it is a well-formed request for a name under your zone, which your authoritative server is obliged to answer.
Why does it hurt resolvers that are not the target?: Because the queries usually arrive through recursive resolvers belonging to ISPs and public providers. Those resolvers cannot cache a negative answer usefully when every name differs, so their own outstanding-query capacity fills up with work for your zone. Your attack becomes their outage, which is why this class attracts operator attention quickly.
Does NXDOMAIN caching help?: Only partially. Aggressive negative caching lets a resolver answer for a whole non-existent range rather than one name at a time, which helps the resolver considerably. It does not help the authoritative server, which still has to answer the first query for each range.
Is anycast the answer?: It disperses the load across sites, which is genuinely valuable for authoritative DNS and is why almost all serious authoritative operators are anycast. It does not reduce the total work, so a large enough attack still requires rate limiting and capacity.

Sources

RFC 9210 — DNS Transport over TCP: Operational Requirements
IETF · 2022-03 · standard · accessed 2026-08-15

Published: August 2026 · Last reviewed: August 2026

Reviewed means the sources above were re-read on that date; the text is only reissued when something material changed.

This guide is updated as vendors release new models and pricing. How we compare vendors