The DNS water torture attack, also called the random subdomain attack, sends many queries for different nonexistent names under a target domain. New labels can miss ordinary per-name caches and drive work toward its authoritative servers. NXDOMAIN cuts and aggressive validated denial caching can reduce some of that traffic, under the conditions described below.
I consider this one of the more insidious DDoS attack types because it exploits the fundamental architecture of DNS resolution. The attack traffic looks like legitimate DNS queries, comes from legitimate recursive resolvers, and targets the one server that must answer authoritatively for your domain.
Nameserver hostname count is not a capacity measure: two identities can represent a large anycast deployment. Evaluate provider/network independence, traffic capacity, and incident response. No provider makes overload impossible. For signed zones, RFC 8198 describes when validated denial data can answer further negative queries from cache.
How the Attack Works
-
The attacker generates random queries. A botnet sends DNS queries for subdomains like
randomstring1.example.com,randomstring2.example.com, etc. Each subdomain is unique and has never been queried before. -
Queries flow through recursive resolvers. The botnet devices send these queries to their local recursive resolvers (ISP resolvers, public resolvers like Google and Cloudflare). The resolvers check their cache, find no entry, and forward the queries upstream.
-
The authoritative server is overwhelmed. All queries ultimately reach the authoritative nameserver for
example.com. The server must process each one, look up the name, determine it does not exist, and return NXDOMAIN. -
Exact-name caching is bypassed. New random labels defeat ordinary per-name cache reuse. Validated denial ranges and NXDOMAIN cuts can still answer some queries without forwarding, as described below.
-
Collateral damage to resolvers. The recursive resolvers in the middle also suffer. They have outstanding queries waiting for responses from the overwhelmed authoritative server, consuming their resources and slowing down resolution for all their users.
Botnet → ISP Resolver 1 → ┐
Botnet → ISP Resolver 2 → ├→ Authoritative NS for example.com
Botnet → Google DNS → ┤ (overwhelmed)
Botnet → Cloudflare DNS → ┘
Queries: a7k9m2x.example.com, b3j8n1p.example.com, c5m2k7q.example.com...
All unique. All NXDOMAIN. All must be processed.
Why Traditional Defenses Fail
This attack is particularly effective because it circumvents several standard DDoS mitigation techniques:
Plain caching does not help. DNS's core defence, caching an exact name, is useless when every query is a name never seen before.
Two standardised mechanisms do bite, and they are worth deploying because they turn the recursive resolvers in front of you into a filter rather than a relay:
- Aggressive NSEC/NSEC3 use (RFC 8198). A validating resolver holding cached, validated NSEC or NSEC3 records can synthesize the NXDOMAIN for a name it has never seen, because the proof it already has covers a range of names rather than one name. RFC 8198 Section 6 lists exactly this as decreased recursive server load: the resolver answers from cache instead of sending a query and waiting. This requires your zone to be signed.
- NXDOMAIN cuts (RFC 8020). Once a resolver learns that a name does not exist, it can answer NXDOMAIN for names beneath it without asking you again, since nothing can exist below a nonexistent name.
Neither is under your sole control, since both depend on what the resolvers querying you implement. But signing your zone is what makes the first one possible at all, which is a concrete reason to do it beyond authenticity.
Rate limiting by source IP is difficult. The queries arrive from legitimate recursive resolvers, not directly from the botnet. Rate limiting these resolvers would block legitimate traffic from their users.
Query filtering is impractical. Each query is a syntactically valid DNS query for a real domain. There is no malformed packet to filter.
The attack is cheap for the attacker. Generating random strings and sending small UDP packets requires minimal bandwidth. The asymmetry favors the attacker. They send small queries but force the server to perform real lookups.
Real-World Impact
The water torture attack has been used against:
- Managed DNS providers: Shared authoritative infrastructure can expose many customers to an overload incident. Cloudflare documents random-prefix attacks as this particular query pattern; a DNS outage alone does not identify its attack vector.
- E-commerce sites during peak shopping periods: taking down DNS effectively takes down the entire online business
- Financial institutions where DNS disruption prevents customers from accessing online banking
- Gaming platforms where attackers combine water torture with ransom demands
The collateral damage is significant. When authoritative servers are overwhelmed, every recursive resolver waiting for responses is also affected, creating a ripple effect across the internet.
How Attackers Discover This Weakness
The attacker only needs to know your domain name. There is no vulnerability to discover, the attack works against any authoritative nameserver:
# The attacker just needs to verify the domain exists
dig example.com NS +short
# Returns nameservers — these are the targets
The effectiveness depends on:
- How many authoritative servers you have: more servers means more capacity to absorb
- Whether you use anycast: anycast distributes load across multiple locations
- Your server's capacity: how many queries per second it can handle before degrading
- Whether your provider has DDoS mitigation: managed DNS providers like Cloudflare and Route53 have built-in protections
How to Defend Against It
Use a Managed DNS Provider with DDoS Protection
The single most effective mitigation is to use an authoritative DNS provider with built-in DDoS absorption capacity. Providers like Cloudflare, AWS Route 53, Google Cloud DNS, and NS1 have globally distributed anycast networks designed to absorb volumetric attacks.
Self-hosting authoritative DNS for internet-facing domains is increasingly risky unless you have significant infrastructure.
Deploy Anycast
Anycast advertises the same IP address from multiple geographic locations. Queries are routed to the nearest server, naturally distributing attack traffic across your infrastructure:
Attacker traffic from Europe → European PoP
Attacker traffic from Asia → Asian PoP
Attacker traffic from US → US PoP
Instead of overwhelming one server, the attack must overwhelm all of them simultaneously.
Implement Aggressive NXDOMAIN Rate Limiting
Configure your authoritative server to detect and limit the rate of NXDOMAIN responses:
# BIND Response Rate Limiting
rate-limit {
responses-per-second 5;
nxdomains-per-second 3;
window 5;
};
This limits how fast your server responds to nonexistent subdomain queries from any single source. The key is nxdomains-per-second, which specifically throttles the response type that water torture generates.
Enable DNS Firewall / Response Policy Zones
DNS firewalls can detect patterns consistent with water torture, high volumes of NXDOMAIN queries for a single domain from many sources, and trigger mitigation automatically.
Monitor NXDOMAIN Ratios
Under normal conditions, the ratio of successful responses to NXDOMAIN responses is relatively stable. A sudden spike in NXDOMAIN percentage is a strong indicator of a water torture attack.
Set alerts for:
- NXDOMAIN response rate exceeding a threshold (e.g., more than 50% of responses)
- Query volume for a single domain exceeding normal baselines
- Response latency increasing on the authoritative server
Mitigation Checklist
- Authoritative DNS hosted on a provider with DDoS protection
- Anycast deployed for authoritative DNS
- NXDOMAIN rate limiting configured on authoritative servers
- Monitoring in place for NXDOMAIN ratio spikes
- DNS firewall deployed to detect random subdomain patterns
- Response latency monitoring on authoritative servers
- Upstream DDoS mitigation service in place
- Multiple geographically distributed nameservers configured
Common Misconfigurations
- Self-hosting authoritative DNS on a single server without DDoS protection or anycast
- No NXDOMAIN rate limiting: the server responds to every query at full speed regardless of volume
- Not monitoring NXDOMAIN ratios: the attack goes undetected until the server is completely overwhelmed
- Assuming nameserver count proves capacity: two identities may front a large anycast deployment; assess network independence, actual capacity, and response plans
- No separation between authoritative and recursive functions: an overwhelmed authoritative server also degrades recursive resolution for internal users
Ethical Note
Water torture attacks are illegal. They constitute a denial-of-service attack against infrastructure you do not own. Even testing against your own authoritative servers requires care, as the traffic passes through intermediate resolvers that are not under your control. For testing, use isolated DNS infrastructure in a lab environment where the entire resolution path is under your control.
This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Amplification Attack, NXDOMAIN Attack.