An NXDOMAIN flood – sometimes called a “water torture” attack or random subdomain attack – throws millions of queries for nonexistent hostnames at a domain’s DNS infrastructure, and the damage rarely stays contained to the domain being targeted. Because every query looks unique to a resolver’s cache, the attack burns through recursive resolver capacity just as fast as it burns through the authoritative nameservers behind the scenes, and any other domain sharing that resolver – which in a shared ISP or corporate environment could be thousands of unrelated customers – slows down or times out right alongside the actual target.
How an NXDOMAIN flood actually works
The mechanics are simple, which is part of why the attack is still popular with botnet operators in 2026. An attacker generates random labels – strings like xj4k9z2.victimdomain.com or a1b2c3d4e5.victimdomain.com – and fires queries for them at open or semi-open recursive resolvers, often through a botnet of compromised IoT devices or misconfigured CPE routers.
Because each subdomain is randomly generated, the recursive resolver has never seen it before and can’t answer from cache. It has to walk the resolution chain: root, TLD, and finally the authoritative nameservers for victimdomain.com, which correctly respond NXDOMAIN since the name doesn’t exist. Multiply that by a few million queries a minute and two things happen at once – the authoritative nameservers get overwhelmed trying to answer garbage, and the recursive resolvers in between exhaust CPU, memory, and outbound query slots doing pointless work for names that were never going to resolve.
Why resolver capacity is the real casualty
Most writeups on this attack focus on the authoritative side going down, but the resolver-capacity angle is what actually causes collateral damage. A recursive resolver has a finite number of concurrent outstanding queries it can track, finite cache memory, and finite CPU cycles for parsing responses.
When 80-90% of that capacity gets consumed answering queries for one abused domain, legitimate lookups for every other domain routed through that same resolver start queuing behind them. An enterprise resolver serving 3,000 employees, or an ISP resolver serving 40,000 residential subscribers, can effectively go dark for everyone because of an attack aimed at one customer’s zone. This is the mechanism that made the Mirai-era DNS water torture attacks against Dyn’s infrastructure in October 2016 so disruptive – the queries targeted specific zones, but the blast radius hit unrelated services relying on the same resolver infrastructure.
The myth worth retiring
A common assumption is that NXDOMAIN floods only matter if you’re the direct target – if attackers are hammering somecompetitor.com, your domain is fine. That’s not how shared DNS infrastructure works. If your authoritative nameservers or your organization’s recursive resolvers are hosted on the same platform, same anycast network, or same upstream provider as the actual target, you absorb capacity loss as a bystander. This is one of the underappreciated arguments for understanding the security implications of using external DNS providers before assuming a shared platform insulates you from someone else’s incident.
Recognizing an attack in progress
A seasoned DNS engineer doesn’t wait for a help desk ticket flood to notice this. The telltale signs show up in query logs first: a sudden spike in the ratio of NXDOMAIN responses to total responses, query names with no linguistic pattern (random alphanumeric strings rather than real subdomains like api or staging), and a surge of queries originating from a wide spread of source IPs rather than a handful.
Watch these metrics specifically:
NXDOMAIN response ratio jumping from a typical baseline of 2-5% to 40% or higher within minutes. Query volume per second against your authoritative nameservers climbing 10-50x above normal traffic. Resolver latency for legitimate lookups increasing from single-digit milliseconds to several hundred. Cache hit ratio on recursive resolvers dropping sharply, since random names can’t be served from cache.
Mitigation steps that hold up under real load
Response Rate Limiting (RRL) on authoritative nameservers is the first line of defense – BIND 9.10+ and Knot DNS both support RRL natively, throttling identical or similar responses to a single source rather than answering every query at full speed. Set it conservatively at first (a common starting point is 10-15 responses per second per source), since overly aggressive RRL can drop legitimate traffic from resolvers serving many users behind one IP, like a large corporate NAT gateway.
Aggressive negative caching, as defined in RFC 2308 and extended by RFC 8198’s NSEC aggregation, lets resolvers infer that similarly-structured names don’t exist without a full round trip, which blunts water torture attacks specifically. Reviewing how DNS caching and TTL settings affect security posture is worth doing before an attack, not during one, since negative TTL values that are too low mean every retried random name re-triggers full resolution.
Anycast distribution across multiple points of presence spreads query load geographically, so a flood aimed at one region doesn’t saturate the whole authoritative fleet. And query name minimization (RFC 7816), now default in most modern resolver software including Unbound 1.9+ and BIND 9.14+, reduces the information leaked to upstream servers and marginally reduces the amplification surface for some flood variants.
Mistakes that make the damage worse
Three patterns show up repeatedly in post-incident reviews. Teams often set RRL thresholds only after the first attack, treating it as a one-time cleanup task rather than a permanent baseline control. Others trust NXDOMAIN spikes at face value without checking whether the source IPs correlate with a known botnet range or an internal misconfiguration – a broken application retry loop generating malformed subdomain lookups can produce an identical signature to a real attack, and blocking the wrong thing wastes the response window. And a fair number of organizations tune alerting around total query volume instead of the NXDOMAIN ratio, which misses attacks that stay under the raw volume threshold but still concentrate almost entirely on nonexistent names. Getting the thresholds right matters enough that it’s worth reviewing how alert thresholds reduce false positive noise rather than guessing at static numbers.
Frequently asked questions
Is an NXDOMAIN flood the same thing as DNS tunneling?
No. DNS tunneling encodes data inside queries and responses to exfiltrate information or maintain covert command-and-control channels, and it typically involves a small, sustained volume of unusual-looking queries rather than a sudden flood. An NXDOMAIN flood is a denial-of-capacity attack, not a data-exfiltration technique, though both abuse the same underlying trust in DNS query traffic – see the breakdown of how attackers exfiltrate data through DNS tunneling for the distinction in traffic patterns.
Can a small business with a managed DNS provider ignore this threat?
Not entirely. Most managed providers (Cloudflare, AWS Route 53, NS1) absorb the authoritative-side load with their own anycast and rate-limiting infrastructure, but if your organization runs its own recursive resolvers internally – common in on-prem or air-gapped environments – you’re still exposed on the resolver-capacity side regardless of who hosts your authoritative zone.
How quickly can an NXDOMAIN flood degrade service?
Faster than most teams expect. Documented incidents show resolver latency climbing from milliseconds to multiple seconds within 2-3 minutes of an attack starting, since cache exhaustion and outbound query saturation compound almost immediately once the flood exceeds normal query volume by an order of magnitude.
Resolver capacity is a finite, shared resource, and NXDOMAIN floods exploit exactly that fact rather than any single misconfiguration. The practical takeaway is to treat NXDOMAIN ratio as a first-class metric alongside uptime and latency, tune RRL and negative caching before an incident rather than during one, and remember that a flood aimed at someone else’s zone can still take down your own lookups if you share infrastructure with them.