Skip to main content
DNS Checker(beta)
5 min read

DNS Water Torture Attack: How Random Subdomain Floods Overwhelm Nameservers

Ishan Karunaratne

Ishan Karunaratne

Software Architect & Infrastructure Engineer

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Frequently Asked Questions

This article was researched and structured by the author with AI assistance for drafting and technical verification.

About the Author

Ishan Karunaratne
Ishan Karunaratne

Software Architect & Infrastructure Engineer

US Army veteran with a B.S. in Information Technology, CompTIA A+, Network+, and Security+ certified. 20+ years building and securing web infrastructure.

B.S. Information Technology — Online SystemsCompTIA A+ (2009)CompTIA Network+ (2009)CompTIA Security+ (2009)US Army Veteran — Operation Iraqi Freedom

Share this article

Related Articles

145,061 Domains Delegated to a Misspelled Name Server — Here's How the Attack Works

A single typo in a name server hostname gives an attacker full DNS authority over your domain. I built a detection pipeline that scans 260 million domains daily and found that one missing character in ResellerClub's NS hostname has left 145,061 domains exposed to silent DNS hijacking.

What Happens When One DNS Provider Goes Down: The Hidden Fragility of TLD Ecosystems

The Dyn attack took down Twitter and Netflix because they shared a DNS provider. I analyzed 240 million domains and found 112 TLDs where a single provider controls over half the domains. The next Dyn-scale event isn't a question of if, but which TLD.

How Expired Name Servers Become Domain Hijacking Vectors

When a name server domain expires, every domain that still delegates to it becomes vulnerable to hijacking. I found 503,000 domains pointing to expired NS domains — and a single re-registration could compromise hundreds of thousands of them.

Why DNSSEC Is Still Failing: Lessons from 240 Million Domains

After 20 years, only 4.27% of domains have DNSSEC. I analyzed 240 million domains to understand why — the answer isn't technical, it's structural. Registrar defaults, invisible benefits, and operational fear are holding back the one protocol that could fix DNS authentication.