An NXDomain attack floods DNS infrastructure with lookups for names that do not exist. Because each query is often unique, your resolver cannot reuse a cached answer. It has to contact upstream servers, track pending requests, and return an NXDOMAIN response. At enough volume, legitimate users start seeing slow lookups, timeouts, and complete failures.
The attack does not need massive bandwidth. Small requests can still consume CPU, memory, cache space, and network capacity.
Key Takeaways
- An NXDomain attack abuses normal DNS behavior by requesting nonexistent domains or subdomains at high speed.
- Random names defeat ordinary cache reuse, forcing recursive resolvers and authoritative servers to process fresh lookups.
- Strong warning signs include a rising NXDOMAIN ratio, unusual query-name diversity, cache misses, pending fetches, and DNS latency.
- Rate limiting helps, but reliable containment usually needs layered controls across resolvers, authoritative DNS, caching, network capacity, and response policies.
What Is an NXDomain Attack?
NXDOMAIN is the DNS response code for a name that does not exist. You normally see it after a typo, an outdated hostname, or a request for a removed service. A few such responses are normal. A huge generated stream is not.
In an NXDomain attack, the attacker sends many DNS queries for nonexistent names. These may be entirely fake domains, such as x7k91-invalid-example.test, or random subdomains attached to a real target, such as q8f2a.example.com. DNS systems then spend resources determining that the requested name has no valid record and returning an NXDOMAIN answer.
Akamai describes it as an application-layer resource-exhaustion attack that can slow or crash nameservers and supporting infrastructure. Example
The request flow looks simple:
- An infected device asks for a nonexistent name.
- A recursive resolver checks its cache.
- Without a cached answer, it performs additional lookups.
- The DNS hierarchy or authoritative server returns a negative answer.
- The resolver sends NXDOMAIN back to the client.
- The attacker repeats the process with another unique name.
That final step matters because DNS caching works best when requests repeat. It is far less useful when every query contains a new random label. A cached answer for abc123.example.com does not directly answer xyz789.example.com.
You also need to distinguish fake domains from fake subdomains. A completely nonexistent .com domain may be rejected by the .com top-level domain servers before the query reaches your authoritative DNS.
Random subdomains under your real domain are different. Recursive resolvers usually have to reach your authoritative nameserver to check each one, making random-prefix attacks especially dangerous for domain owners.
{{cool-component}}
How NXDomain Attacks Overwhelm DNS Resolvers
A recursive resolver does more than receive a question and send a reply. It checks cache entries, follows referrals, contacts upstream nameservers, waits for responses, validates DNSSEC where required, stores results, and tracks simultaneous requests.
An NXDomain attack makes that workflow expensive. Popular names normally repeat, allowing many requests to be answered from cache. A stream of unique random names lowers cache efficiency and forces more upstream fetches, memory allocation, timeout handling, and negative-response storage. Processing queues can fill even while bandwidth remains available.
Negative caching reduces this work. RFC 2308 allows resolvers to remember that a name or record does not exist, cutting repeated lookups and messages. Example
The attack weakens that protection by constantly changing the queried name:
- a91f.example.com
- b72k.example.com
- c83m.example.com
- d04q.example.com
Each name may require separate handling. Your server is not answering one bad question repeatedly. It is answering a stream of new bad questions.
Slow upstream responses keep requests open longer, spreading pressure across CPU, memory, caches, and authoritative DNS.
ISC’s recursive client rate-limiting guidance focuses on this problem. Large numbers of unresolved or slow queries can consume local resolver resources far beyond their value. Example
Websites may still work intermittently during the early stages. One DNS request finishes while another waits or fails, making the issue resemble a web server or application problem. The application may be running perfectly. Users simply cannot resolve the domain needed to reach it.
How NXDomain Attacks Differ From Other DNS Flood Types
People often group every DNS denial-of-service event under “DNS flood,” but the mechanics matter. You cannot tune the right defense if you are measuring the wrong attack.
A general DNS flood attack is direct. A botnet sends enough DNS queries to overwhelm a target or DNS provider. The queries may request valid records and resemble legitimate traffic.
Cloudflare describes it as request volume that exhausts DNS capacity and prevents normal resolution. Example
A DNS amplification attack is reflective. The attacker spoofs the victim’s IP address and causes third-party DNS servers to send larger replies to the victim, multiplying traffic and exhausting bandwidth. Example
In a DNS amplification attack, the DNS server is often used as a weapon against someone else. In an NXDomain attack, the resolver or authoritative DNS infrastructure may itself be the target.
A DNS water torture attack is usually a targeted form of random-subdomain or NXDomain flooding. Attackers send unique prefixes under a real domain through many recursive resolvers. Those resolvers become intermediaries, while the target’s authoritative DNS receives cache-busting questions.
These labels often describe the same attack family, and Akamai lists them together. Example
I would still keep the practical distinction in mind. A broad NXDomain flood may punish recursive resolvers with fake domains, while classic water torture usually concentrates random subdomains on one real zone.
The Infrastructure Signals That Reveal an NXDomain Attack Early
You rarely catch this attack by watching bandwidth alone. DNS packets are small, and performance may collapse before the network link looks full. You need resolver and authoritative-DNS telemetry.
Start with the NXDOMAIN response ratio. Compare negative answers with total DNS responses and your normal baseline. A jump from 4% to 40% matters even when overall traffic rises only modestly.
Next, measure query-name cardinality, the number of unique names requested during a short window. Normal DNS traffic repeats names. NXDomain attacks often generate huge numbers of one-time labels.
The strongest early indicators are:
- A sudden rise in NXDOMAIN responses per second
- Many unique query names with almost no repetition
- A falling cache-hit ratio
- More recursive fetches and outstanding queries
- Higher DNS latency, SERVFAIL responses, and upstream timeouts
- Random labels concentrated beneath one legitimate domain
- CPU growth that is much larger than the increase in bandwidth
Inspect the requested names too. Attack-generated labels often have high entropy, meaning they look unusually random and may contain long combinations of letters and numbers that never repeat.
That alone does not prove an attack. Legitimate platforms can generate dynamic hostnames, so compare volume, repetition, response codes, and zone concentration.
Source IP can also mislead you. Your authoritative server may see public recursive resolvers rather than the infected devices behind them. Blocking those resolvers can remove legitimate users along with attack traffic.
Cloudflare notes that random-prefix attacks commonly arrive through public resolvers, creating a high false-positive risk for source-based blocking. Example
Track query volume, NXDOMAIN percentage, unique-name rate, cache-hit ratio, recursion latency, top zones, and response codes. I would alert on combinations, especially random labels, extreme uniqueness, and rising upstream fetches.
{{cool-component}}
How DNS Rate Limiting and Response Policies Contain NXDomain Floods
Rate limiting is useful, but one global limit is usually too blunt. Set it too high and the attack still drains resources. Set it too low and real users fail during normal traffic spikes.
For recursive resolvers, controls should limit expensive work rather than merely count packets. You may restrict outstanding fetches per zone, fetches per upstream server, recursion per client, or unresolved requests from abusive clients.
ISC explains that these controls can prioritize good queries while limiting slow or unresolvable work. Example
For authoritative DNS, Response Rate Limiting can detect clusters of similar requests and reduce abusive reply volume, especially during reflection and amplification attacks.
However, traditional RRL mainly stops your server from helping amplify an attack against another victim. It does not remove the processing cost of unique random-subdomain queries. Example
Containment should therefore be layered:
- Protect recursion. Never expose open recursive resolution to the public. Restrict clients and apply per-client, per-zone, or per-upstream fetch limits.
- Detect random-name behavior. Identify zones with abnormal query diversity, high NXDOMAIN ratios, random labels, and poor cache reuse.
- Apply targeted response policies. Refuse, drop, or locally answer requests matching a confirmed malicious pattern. Keep rules narrow so legitimate dynamic subdomains still work.
- Use correct negative caching. Sensible negative TTLs reduce repeated work for the same missing names. They cannot stop random cache-busting queries, but bad caching makes the attack easier.
- Distribute authoritative DNS. Anycast and geographically separated nameservers spread traffic and reduce the chance that one location becomes the bottleneck. Akamai includes Anycast distribution among useful NXDomain defenses. Example
- Shield the authoritative origin. A managed DNS edge or DNS firewall can absorb traffic, cache answers, detect random-prefix behavior, and stop selected subdomain queries from reaching upstream nameservers. Cloudflare describes serving cached responses while withholding suspicious random-prefix requests from the origin. Example
- Preserve resources for valid traffic. Separate recursive and authoritative roles, reserve capacity for trusted clients, tune queue limits, and confirm that firewalls and load balancers can handle high DNS packet rates.
Match the policy to the attack. Use zone-aware controls for water torture, per-client limits for one source, and behavioral filtering plus distributed capacity for traffic relayed by public resolvers.
A simple IP blocklist will be incomplete and may block real users.
FAQs
How Does an NXDomain Attack Differ From a Water Torture Attack?
An NXDomain attack broadly floods DNS systems with lookups for nonexistent names. A DNS water torture attack usually targets one real domain with many random, nonexistent subdomains. The terms overlap, but water torture more specifically describes cache-busting queries that repeatedly force recursive resolvers to contact the target’s authoritative nameservers.
Can Response Rate Limiting Stop an NXDomain Flood?
Response rate limiting can reduce harmful reply volume, but it rarely stops the entire attack alone. Unique queries may still consume CPU, memory, and recursive fetch capacity before a response is limited. You normally need resolver fetch limits, anomaly detection, negative caching, distributed DNS, and targeted query policies alongside RRL.
How Does NXDomain Affect Recursive Versus Authoritative Servers?
Recursive servers spend resources checking caches, following referrals, tracking pending queries, and storing negative answers. Authoritative servers must answer fresh requests for random subdomains inside zones they host. Completely fake domains may stop at a registry or TLD server, while fake subdomains of your real domain usually reach your authoritative DNS.
