NXDOMAIN Attack: How Nonexistent Domain Floods Exhaust DNS Resolvers

An NXDOMAIN attack is a form of DNS-based denial of service that floods recursive resolvers with queries for domain names that do not exist. Each query is a cache miss, forcing the resolver to do upstream work only to receive an NXDOMAIN (non-existent domain) response. That work is usually less than a full traversal from the root: a resolver starts matching from the closest delegation it already has cached (RFC 1034 Section 4.3.2), so in practice it reuses cached TLD delegations and nameserver addresses and only queries the authoritative servers for the zone in question. A cold cache is what forces the walk back to the root. At sufficient volume, this exhausts the resolver's resources: CPU, memory, open sockets, and cache capacity.

While similar to the water torture attack (which targets authoritative servers), the NXDOMAIN attack specifically targets recursive resolvers. The goal is to degrade resolution performance for all users of that resolver, not just the targeted domain.

How the Attack Works

1. The attacker generates queries for nonexistent domains. Unlike water torture (which uses random subdomains of a real domain), NXDOMAIN attacks query entirely nonexistent domains: randomstring.com, anotherstring.net, gibberish.org.

2. The resolver must perform full recursion. For each query, the resolver walks the full DNS hierarchy. It contacts a root server, gets a referral to the TLD server, contacts the TLD server, and receives an NXDOMAIN from the authoritative server (or from the TLD itself if the domain is not registered).

3. Resources are consumed at every step. Each outstanding query consumes a socket, a cache entry, and processing time. The resolver must wait for responses from upstream servers, holding state for each query.

4. Negative cache fills up. The resolver caches NXDOMAIN responses (negative caching), but each query uses a different nonexistent domain, so the negative cache fills with useless entries that displace legitimate cached records.

5. Legitimate users are affected. As the resolver's resources are exhausted, response times for legitimate queries increase. Queries may time out entirely, causing DNS failures for all users of that resolver.

Attacker sends:
  abc123xyz.com     → Full recursion → NXDOMAIN
  def456uvw.net     → Full recursion → NXDOMAIN
  ghi789rst.org     → Full recursion → NXDOMAIN
  ... millions more

Resolver resources:
  Open sockets: EXHAUSTED
  Cache: FILLED with NXDOMAIN entries
  CPU: CONSUMED by recursive lookups
  Legitimate queries: DELAYED or DROPPED

How It Differs from Water Torture

Both attacks exploit the NXDOMAIN response path, but they target different components of the DNS infrastructure.

Real-World Impact

NXDOMAIN attacks have been used to:

• Disrupt ISP resolvers: affecting DNS resolution for thousands or millions of subscribers
• Degrade corporate DNS: overwhelming internal resolvers and disrupting all internet-dependent services
• Create distractions: while security teams respond to the DNS disruption, attackers pursue other objectives, sometimes pairing the resolver flood with a bandwidth-saturating DNS amplification flood that abuses open resolvers
• Extortion: threatening DNS disruption unless a ransom is paid

The attack is particularly effective against organizations running their own resolvers without adequate capacity planning or rate limiting. You can look up DNS records for your domain to verify your resolver is responding correctly, and use the DNS propagation checker to confirm consistent resolution from nameservers worldwide during a suspected attack.

How Attackers Launch This Attack

The attack is simple to execute. The attacker generates random domain names and sends DNS queries at high volume:

# Conceptual (do NOT run against targets you do not own)
# Generate random domain queries
for i in $(seq 1 1000000); do
  dig $(cat /dev/urandom | tr -dc 'a-z' | head -c 12).com @target-resolver &
done

The attacker does not need to control any DNS infrastructure. They just need to send a high volume of queries to the target resolver. If the resolver accepts queries from the attacker's network (which is the case for ISP resolvers and public resolvers), the attack proceeds.

How to Defend Against It

Aggressive Negative Caching

A resolver cannot infer nonexistence from traffic patterns. What it can do is reuse cryptographic denial-of-existence proofs it already holds. That is what aggressive negative caching means: when the cache contains validated NSEC or NSEC3 records that cover the queried name, the resolver synthesizes the NXDOMAIN itself instead of asking upstream. RFC 8198 Section 5 is explicit that this applies only when the cache has sufficient information to validate the query, and that otherwise the resolver must fall back to querying the authoritative servers. It therefore requires DNSSEC validation and a signed zone to help at all, which limits how much of a random-subdomain flood it absorbs.

Unbound implements this as aggressive-nsec, normally on by default. Note that cache-min-negative-ttl is a different lever: it just imposes a floor on how long negative answers stay cached.

# Unbound configuration
server:
    # Synthesize denial from cached, validated NSEC/NSEC3 proofs
    aggressive-nsec: yes
    # Floor on how long negative responses stay cached
    cache-min-negative-ttl: 60
    # Limit cache size to prevent memory exhaustion
    msg-cache-size: 128m
    rrset-cache-size: 256m

Per-Client Query Rate Limiting

Limit the number of queries a single client can send per second. This prevents any single source from consuming disproportionate resolver resources:

# Unbound rate limiting
server:
    # Rate limit per client IP
    ip-ratelimit: 100

Legitimate clients rarely exceed 50-100 queries per second. Anything significantly higher is suspicious.

NXDOMAIN Ratio Monitoring

Monitor the ratio of NXDOMAIN responses to total responses. Under normal conditions, this ratio is relatively stable (typically 5-15% depending on the user population). A spike to 50% or higher strongly suggests an attack.

Set alerts for:

• NXDOMAIN ratio exceeding 30-40%
• Total query volume exceeding baseline by more than 2-3x
• Response latency increasing beyond normal thresholds

Resolver Capacity Planning

Ensure your resolver infrastructure has sufficient capacity to handle both normal load and attack surges:

• Deploy multiple resolver instances behind a load balancer
• Use anycast for resolver addresses
• Ensure sufficient memory for cache and outstanding query state
• Monitor resource utilization trends and scale before reaching capacity

Use QNAME Minimization

QNAME minimization (RFC 9156, which obsoletes the earlier RFC 7816) reduces the information sent to upstream servers during recursion. Instead of sending the full query name to every server in the chain, the resolver only sends the minimum labels needed at each step.

Deploy it for the privacy benefit, not as a load reduction. The cost runs the other way: RFC 9156 Section 2.1 notes that a cold resolver using QNAME minimization sends more queries, potentially one per label, converging with a traditional resolver only once the cache is warm. The RFC treats that amplification as an attack vector in its own right, which is why implementations cap the number of iterations.

Mitigation Checklist

• Per-client query rate limiting is configured on resolvers
• Negative caching parameters are tuned for aggressive caching
• NXDOMAIN ratio monitoring and alerting is in place
• Resolver cache size is adequate for the user population
• Multiple resolver instances are deployed for redundancy
• QNAME minimization is enabled
• Resolver access is restricted to authorized networks
• Resource utilization monitoring is configured (CPU, memory, sockets)

Common Misconfigurations

• No per-client rate limiting: a single attacker can consume the entire resolver's capacity
• Insufficient cache memory: the resolver runs out of memory under attack, causing crashes or evicting legitimate cached entries
• Not monitoring NXDOMAIN ratios: the attack goes undetected until users complain about slow DNS
• Open resolvers: accepting queries from the entire internet dramatically increases the attack surface
• Single resolver instance: no redundancy means a single overwhelmed resolver takes down DNS for all users

Ethical Note

NXDOMAIN flood testing should only be performed against resolvers you own in an isolated environment. Even testing against your own production resolver can cause service degradation for legitimate users. Set up a test resolver in a lab environment for experimentation.

This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Water Torture Attack, Phantom Domain Attack.