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 forces the resolver to perform a full recursive lookup — querying root servers, TLD servers, and authoritative servers — only to receive an NXDOMAIN (non-existent domain) response. 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
• 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

Configure your resolver to cache NXDOMAIN responses aggressively. While each query is for a unique domain, patterns emerge — if all domains under a particular TLD are nonexistent, the resolver can infer that and reduce upstream queries.

# Unbound configuration
server:
    # Cache negative responses for longer
    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 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. This slightly reduces the resolver's work per query and limits information exposure.

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.