DNS Flood and PRSD Attacks | Defense with Authoritative Edge DNS

DNS is the invisible foundation of every digital presence. When an authoritative DNS server fails or becomes overloaded, no user can access the domain — regardless of how robust the application servers are. Attackers know this. DNS Flood and PRSD attacks exploit exactly that dependency: instead of attacking the service directly, they attack the infrastructure that makes it discoverable.

DNS Flood is a volumetric DDoS attack that exhausts the bandwidth and processing capacity of a DNS server with a massive volume of UDP queries on port 53. PRSD attacks (Pseudo Random Subdomain, also called DNS Water Torture or NXDOMAIN Flood) are a distinct and more sophisticated variant: instead of saturating bandwidth, they exhaust CPU through compulsory cache misses — each query targets a random, non-existent subdomain, forcing the authoritative server to perform real computational work without any possibility of reusing cached results.

Volumetric DNS Flood — bandwidth exhaustion on UDP port 53

A basic DNS Flood sends queries in massive volume to the same domain or to valid domains. Since DNS operates over UDP without a handshake, the attacker can generate and send hundreds of thousands of queries per second at minimal computational cost — and, with IP spoofing, without revealing the real source.

The impact is direct: the server’s UDP receive buffers overflow, the query processing queue saturates, and the server begins dropping queries by timeout. Legitimate users receive SERVFAIL or get no response.

The table below summarizes the operational characteristics of volumetric DNS Flood:

PRSD attack — CPU exhaustion by compulsory cache miss

The PRSD attack operates with radically different logic. Instead of overloading the network with volume, it eliminates the cache as a protection mechanism and forces the authoritative server to process each query individually.

The mechanism works as follows: the attacker generates queries for random subdomains of the target domain — for example, a7x9k2m.target.com, then b3p8q1n.target.com, then c5w7r4s.target.com. Each subdomain is unique and doesn’t exist in DNS. The recursive resolver checks its cache, finds no answer (cache miss), and forwards the query to the authoritative server. The authoritative checks its zone, finds no subdomain, and responds with NXDOMAIN. The result is never usefully cached for the next query, because the next query will use a different subdomain.

The contrast with DNS Flood is decisive:

Impact of PRSD on intermediate recursive resolvers

A frequently underestimated aspect of the PRSD attack is its impact on intermediate recursive resolvers — the DNS servers of ISPs, enterprises, and cloud providers that receive end-user queries before forwarding them to the authoritative server.

Each PRSD query passing through the recursive resolver generates the following cumulative effects:

UDP socket exhaustion: the recursive resolver opens a UDP socket for each pending query forwarded to the authoritative server. With tens of thousands of PRSD queries per second, the resolver’s available socket pool can saturate, preventing new queries — including queries for other domains — from being processed.

Pending query accumulation: the resolver maintains a pending query state while waiting for the authoritative server’s response. In an intense PRSD attack, the pending query table grows faster than it is drained by NXDOMAIN responses, consuming the resolver’s memory and CPU.

Risk of lame server marking: when an authoritative server fails to respond within the configured timeout (generally 1.5 to 5 seconds), the recursive resolver may mark it as a “lame server” — a server with authority delegation problems. A server marked as lame is temporarily removed from the list of consulted authoritatives, accelerating the propagation of unavailability to users who are not even being directly attacked.

These three cascading effects on the recursive resolver explain why PRSD can bring down DNS resolution for a domain even when the traffic volume is insufficient to saturate the authoritative server’s network link.

DNSSEC and the computational cost of NSEC3 during PRSD attacks

If the target domain uses DNSSEC, the PRSD attack becomes significantly more costly for the authoritative server in terms of CPU.

When a DNSSEC-validating recursive resolver receives an NXDOMAIN response, it needs cryptographic proof of non-existence — evidence that the subdomain genuinely doesn’t exist in the zone and that the absence of a record is authentic. Two DNSSEC mechanisms were designed to provide this proof:

NSEC (Next Secure): enumerates adjacent names in the sorted zone. An NXDOMAIN response with NSEC contains two records proving: “the name a7x9k2m.target.com doesn’t exist, and the closest names that do exist are x.target.com and z.target.com”. NSEC has a critical limitation: it allows complete DNS zone enumeration, which is considered a privacy concern.

NSEC3 (RFC 5155): solves the enumeration problem using cryptographic hashes (SHA-1 with salt and a configurable iteration count) of zone names instead of plain text names. An NXDOMAIN response with NSEC3 contains the hashes of the adjacent sorted names, proving non-existence without revealing the actual zone names.

The computational cost of NSEC3 during a PRSD attack is substantial for two reasons:

1. For each PRSD query, the authoritative server must calculate the NSEC3 hash of the non-existent subdomain to determine which adjacent NSEC3 records to include in the response. With tens of thousands of unique subdomains per second, this represents a massive volume of SHA-1 hash operations.

2. The hash iteration count is configurable (the iterations field of NSEC3PARAM). High iteration settings increase resistance to offline enumeration attacks but amplify per-NXDOMAIN-query CPU cost during PRSD attacks.

In practical terms, an authoritative server with DNSSEC and NSEC3 configured can saturate its CPU with a much lower PRSD query volume than a server without DNSSEC. The current recommendation (RFC 9276) is to use iterations=0 — no extra iterations beyond the base hash — to minimize computational cost without compromising security.

Cascading impact of DNS unavailability

DNS unavailability simultaneously affects all services depending on that domain:

Mitigation techniques

Response Rate Limiting (RRL) — slip mechanism with TC=1 flag

RRL limits the rate of identical or similar responses sent to the same destination IP address within a sliding time window. Implemented in BIND (since 9.9), Knot DNS, and PowerDNS, it is the primary protocol-specific defense against DNS Flood and reflection attacks.

The central mechanism of RRL is the slip policy: instead of simply dropping responses that exceed the rate limit (which could penalize legitimate ISP resolvers serving many clients), the server periodically responds using the truncation TC=1 flag.

The operation is as follows: when a response would exceed the configured rate limit, the server periodically sends a truncated response with TC=1 instead of silently dropping it. A legitimate client that receives TC=1 understands the response is incomplete and retries the query via TCP — a reliable channel that is practically impossible to spoof with IP spoofing. Attack tools and amplifiers that use pure UDP don’t implement this TCP fallback, and are therefore effectively blocked without receiving the complete response.

A typical configuration includes responses-per-second (limit for identical responses per window), window (time window duration, typically 15 seconds), and slip (frequency of TC=1 responses instead of drops, typically 2 — one in every two rate-limited responses receives TC=1).

Negative caching (NCACHE) and the role of SOA MINIMUM TTL

For PRSD attacks, each query results in NXDOMAIN. RFC 2308 defines the negative caching (NCACHE) mechanism: recursive resolvers can cache NXDOMAIN responses for the time defined in the MINIMUM field of the zone’s SOA record, up to a maximum of 10,800 seconds (3 hours).

The SOA MINIMUM TTL acts as the zone’s negative cache TTL. When the authoritative responds NXDOMAIN for a7x9k2m.target.com, the resolver caches that response for up to SOA MINIMUM seconds. If the same subdomain is queried again within that period, the resolver responds from cache without contacting the authoritative server.

The critical limitation for PRSD attacks is that this mechanism only works for repeated subdomains. PRSD generates completely random and unique subdomains with each query — a7x9k2m, b3p8q1n, c5w7r4s, and so on — ensuring the resolver never encounters the same subdomain twice. Negative caching therefore offers minimal protection against PRSD when subdomains don’t repeat.

DNS wildcards (*.target.com) can partially help: if the authoritative has a wildcard, the response for any subdomain will be a valid record (not NXDOMAIN), enabling normal caching. However, the first cache miss for each unique subdomain still generates a query to the authoritative.

BGP Anycast — distributing load across multiple PoPs

BGP Anycast is the most effective architecture for resisting DNS Flood and PRSD at scale. The principle is simple: the same DNS server IP address block is announced via BGP from multiple geographically distributed Points of Presence (PoPs).

BGP routing automatically directs each query to the PoP closest to the source, with no additional client configuration. For volumetric attacks, malicious traffic is divided among all PoPs, proportionally reducing the load on each one:

For PRSD attacks, Anycast distributes not only the query volume but also the CPU cost of NXDOMAIN processing (and NSEC3 hash calculation in DNSSEC zones) across the PoPs. A European PoP absorbs queries from European botnets; an Asian PoP absorbs Asian queries. The origin server is completely isolated from the attack load.

IP spoofing filtering (BCP38)

DNS over UDP is especially vulnerable to IP spoofing. Implementing BCP38 at ISPs — which drops packets with impossible or invalid source addresses — prevents attackers from sending queries with spoofed IPs, eliminating an entire class of reflected attacks and making it more difficult to distribute PRSD attacks from a single source.

Per-source-IP rate limiting (ACLs)

Configuring query rate limits per source IP on the authoritative server blocks concentrated botnets without impacting legitimate recursive resolvers. A recursive resolver at an ISP typically sends queries on behalf of thousands of users, so limits must be calibrated to avoid blocking legitimate high-volume resolvers.

Authoritative DNS at the edge vs. centralized DNS

Detection signals

Common mistakes and solutions

Mistake: Relying on a single centralized authoritative DNS server without geographic redundancy. Solution: A single authoritative server is both a single point of failure for the entire digital presence and a concentrated target for attacks. Use at least two servers in different locations — ideally with BGP Anycast for automatic load distribution.

Mistake: Not configuring RRL on the authoritative DNS server. Solution: By default, servers like BIND don’t limit responses. Configure RRL with slip (TC=1) to protect against reflective amplification without penalizing legitimate resolvers. Tune responses-per-second according to the normal traffic profile of the zone.

Mistake: Relying on NCACHE as complete protection against PRSD. Solution: Negative caching only protects against repeated queries to the same subdomain. PRSD generates unique subdomains per query, making NCACHE ineffective for active attack queries. Combine NCACHE with Anycast and RRL.

Mistake: Ignoring PRSD because volumetric protection is active. Solution: PRSD can operate below volumetric thresholds while saturating the authoritative’s CPU. Use DNS protocol-specific defenses (RRL, Anycast, NSEC3 with iterations=0) in addition to volumetric protection.

Mistake: Configuring NSEC3 with a high iteration count in zones at risk of PRSD. Solution: High iterations increase CPU cost per NXDOMAIN query. Follow RFC 9276 and use iterations=0 to minimize the attack surface without compromising zone security.

Frequently asked questions

What is the fundamental difference between DNS Flood and PRSD? DNS Flood aims to exhaust the server’s network bandwidth and UDP I/O with a massive query volume. PRSD aims to exhaust the server’s CPU through compulsory cache misses — each query generates new, non-reusable computational work because it targets a unique, non-existent subdomain. DNS Flood is detectable by volumetric spike; PRSD can operate at modest network volume while saturating the processor.

How does PRSD affect intermediate recursive resolvers? PRSD overloads recursive resolvers in three simultaneous ways: it exhausts the UDP socket pool available for pending queries; accumulates a pending query table that consumes memory and CPU; and can cause lame server marking of the authoritative if timeouts are exceeded, accelerating the propagation of unavailability to users who aren’t even directly being attacked.

Why does DNSSEC worsen PRSD impact? With DNSSEC enabled and NSEC3 configured, each NXDOMAIN response requires calculating SHA-1 hashes to generate cryptographic non-existence proofs (RFC 5155). With tens of thousands of random subdomains per second, this hashing cost multiplies the authoritative server’s CPU usage. Use iterations=0 in NSEC3PARAM to minimize cost without compromising security.

What is the RRL slip mechanism and how does it protect legitimate resolvers? Slip is RRL’s policy of periodically responding with TC=1 (truncated response) instead of silently dropping. A legitimate client that receives TC=1 retries via TCP — a reliable channel resistant to IP spoofing. Attack tools that use pure UDP don’t implement this TCP fallback and are effectively blocked. Slip ensures RRL doesn’t penalize ISP resolvers that genuinely need high response rates.

Is DNS Flood the same as DNS Amplification? No. DNS Flood overwhelms the target DNS server with a massive query volume — the target is the DNS server itself. DNS Amplification uses open DNS servers as reflectors to amplify UDP traffic against a different victim. They are distinct vectors with different targets and mechanisms.

Why is PRSD called “Water Torture”? The name comes from the drip water torture — each query individually causes limited but real work on the server, accumulating until it generates unavailability through gradual CPU overload. It is more insidious than brute volumetric flood because it can operate at modest network volume and is difficult to distinguish from legitimate traffic.

Does a low DNS TTL help or hurt during a PRSD attack? It hurts. Low TTLs force resolvers to query the authoritative more frequently even for existing records, increasing the baseline load. During PRSD attacks, higher TTLs on existing records are beneficial — resolvers cache responses longer, reducing pressure on the authoritative for legitimate traffic.

How to implement on Azion

Azion protects against DNS Flood and PRSD with a distributed authoritative Edge DNS architecture via global BGP Anycast:

1. Edge DNS with BGP Anycast across 100+ PoPs: Azion’s authoritative DNS operates with the same IP announced from 100+ data centers via BGP Anycast. Attack traffic is automatically distributed by BGP routing across the PoPs closest to the source, without manual configuration. No individual PoP receives a significant fraction of the total attack. The origin server is completely isolated — queries arrive at Azion’s PoPs, never at the origin backend.
2. Native Response Rate Limiting with slip: Azion’s Edge DNS implements RRL by default with the slip (TC=1) mechanism, protecting against reflection and amplification attacks without penalizing legitimate recursive resolvers.
3. Protection against NSEC3 flood in DNSSEC zones: The distributed infrastructure distributes the NSEC3 calculation cost across PoPs, preventing a single authoritative server from saturating its CPU with hashing operations during intense PRSD attacks against DNSSEC zones.
4. IP spoofing protection: Azion’s network implements packet filtering that discards queries with impossible source addresses, reducing the impact of DNS Flood attacks based on IP spoofing.

Learn more in the Azion Edge DNS documentation.