The DNS water torture attack, also called the random subdomain attack, targets authoritative DNS servers by flooding them with queries for randomly generated subdomains that do not exist. Each query like a7k9m2x.example.com forces the authoritative server to look up the name and return an NXDOMAIN response. Because every query is unique, DNS caching provides no protection — each query must be processed individually.
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.
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. -
Caching is useless. Because each subdomain is unique, the NXDOMAIN response is cached for that specific name only. The next query uses a different random string, so the cache never helps.
-
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:
Caching does not help. The core defense of DNS — caching — is rendered useless because each query is unique.
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:
- Major DNS providers — Dyn (now part of Oracle) suffered a massive water torture attack in 2016 that disrupted DNS resolution for many high-profile websites including Twitter, Netflix, and Reddit
- 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
- Using only two nameservers (the minimum required by most registrars) — insufficient capacity to absorb attacks
- 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.
