← DNS SecurityThreat / High

NXDOMAIN Attacks

Flooding recursive resolvers with queries for nonexistent domains to exhaust their resources — degrading DNS service for all legitimate users on the same infrastructure.

The Attack

Targeting Resolver Resources

Every DNS query for a nonexistent name (NXDOMAIN) requires the resolver to complete a full recursive lookup — querying root, TLD, and authoritative nameservers — before it can cache the negative response. This costs CPU cycles and memory at both the resolver and the authoritative nameserver.

The random subdomain attack (also called "water torture" or "DNS flood") is the most effective variant: an attacker generates queries for random subdomains under a real domain (e.g., xk3jf9.thedns.guru, mn8pw2.thedns.guru). Because each subdomain is unique, the cache never helps — every query triggers a fresh recursive lookup.

The target can be the resolver (to slow DNS for users of that resolver) or the authoritative nameserver (to overwhelm a specific domain's DNS provider). Authoritative nameservers for popular domains have been effectively DDoSed by attackers directing millions of bots to query random subdomains.

Water Torture Attacks on Authoritative DNSIn a water torture attack, the authoritative nameserver receives millions of queries for random subdomains. It must process each one, respond with NXDOMAIN, and maintain state for the transaction — eventually exhausting its query processing capacity. Legitimate queries for the real domain time out.

300s

SOA min TTL (negative cache)

Cache hits (random labels)

Defenses

Mitigating NXDOMAIN Attacks

Negative Caching (RFC 2308)

RFC 2308 defines how NXDOMAIN responses are cached. The SOA record's minimum TTL controls the negative cache TTL. When a resolver caches an NXDOMAIN, subsequent queries for the same name are answered from cache. However, random-label attacks bypass this since each query is for a unique name.

; SOA minimum TTL controls negative caching
@ IN SOA ns1.example.com. admin.example.com. (
    2024041201  ; serial
    3600        ; refresh
    900         ; retry
    604800      ; expire
    300 )       ; min TTL — NXDOMAIN cached 300s

DNSSEC NSEC/NSEC3 Records

DNSSEC NSEC records allow resolvers to cache authenticated denial of existence for an entire range of names — not just one specific NXDOMAIN. A single NSEC response can cover thousands of potential query names, dramatically reducing authoritative server load for attacks in that namespace range.

; NSEC — proves no names exist
; between "a.example.com" and "c.example.com"
a.example.com. NSEC c.example.com. A RRSIG NSEC

; NSEC3 — hashed NSEC for zone walking prevention
; Used by most modern DNSSEC implementations

Resolver Query Rate Limiting

Recursive resolvers can rate-limit queries per client IP. If a single source is generating thousands of NXDOMAIN queries per second, the resolver can throttle or block that source. Tools: BIND's rate-limit, Unbound's ratelimit module.

# Unbound resolver rate limiting
server:
  # Max queries per second per IP
  ip-ratelimit: 1000
  ip-ratelimit-factor: 10
  # Slip every N queries (return truncated)
  ip-ratelimit-slip: 2

Authoritative Server Response Rate Limiting

Authoritative nameservers can implement RRL specifically for NXDOMAIN responses. When the same NXDOMAIN pattern appears at high volume, responses are rate-limited or dropped. This reduces CPU and bandwidth consumption without affecting legitimate traffic.

# BIND RRL for NXDOMAIN responses
rate-limit {
  responses-per-second 5;
  nxdomains-per-second 5;
  errors-per-second 5;
  window 5;
  log-only no;
};

Additional Defenses

Infrastructure-Level Protections

Anycast nameservers

Distributing authoritative nameservers via anycast spreads attack traffic across many nodes. An attack that overwhelms a single server is absorbed by a global anycast network with aggregate capacity of hundreds of Gbps.

Wildcard NXDOMAIN suppression

Some DNS providers deploy wildcard records to suppress NXDOMAIN responses for high-volume attacks against nonexistent subdomains. The wildcard returns a controlled response (e.g., a "parked" IP) instead of querying all the way to authoritative.

DNS firewall / RPZ blocking

Response Policy Zones can be configured to immediately return NXDOMAIN for known attack sources or patterns — before the query ever reaches the recursive resolution pipeline, saving resolver CPU.

Upstream DDoS scrubbing

For large-scale volumetric attacks, upstream scrubbing centers (Cloudflare, Akamai, Radware) absorb and filter attack traffic before it reaches resolver infrastructure. Essential for ISP-scale resolvers.

# Measure NXDOMAIN rate on your resolver
# (dig + shell loop to simulate)
for i in $(seq 1 10); do
  dig +short RAND${RANDOM}.thedns.guru A @YOUR-RESOLVER
done

# Monitor resolver statistics
# BIND: rndc stats && tail /var/named/named_stats.txt
# Unbound: unbound-control stats | grep nxdomain

NXDOMAIN Attacks

Targeting Resolver Resources

Mitigating NXDOMAIN Attacks

Infrastructure-Level Protections

Related Topics