What is a DNS flood attack?

02DNS flood versus DNS amplification

The two are easy to confuse because both involve DNS and both are used for denial of service, but the mechanics are opposite. A flood sends the attacker's own query volume directly at a DNS server. DNS amplification instead sends small spoofed queries to open resolvers so that much larger replies land on a victim who may not run DNS at all. In short, a flood is about query volume at a name server; amplification is about reflected reply size at any target.

03The main variants: query, NXDOMAIN and water-torture floods

A plain query flood repeats requests for names that exist in the zone, forcing the server to answer each one. An NXDOMAIN flood asks for names that do not exist, which is often more damaging because every answer is a negative one the server must compute, and caches help less. The most effective form, the random-subdomain or water-torture attack, aims those non-existent names at a real zone: the attacker queries endless unique labels under a victim's domain, such as random strings prepended to it.

The random-subdomain variant is punishing because it routes through recursive resolvers. A resolver that has never seen a name cannot answer from cache, so it forwards the query to the zone's authoritative servers, and a flood of unique names turns a large pool of ordinary resolvers into an unwitting relay against one authoritative operator. The caching and DNSSEC defences that blunt it are in the recursive-operator section below.

04What a DNS flood looks like, with real numbers

The scale a flood can reach is best shown by documented incidents, because the same retry behaviour that keeps DNS resilient also multiplies load when something goes wrong. RFC 9520 records that during a six-hour outage of one large operator's authoritative servers in 2021, query traffic on the .COM and .NET infrastructure rose from about 7,000 to about 900,000 queries per second as resolvers worldwide retried. In a separate study, botnet query traffic that averaged roughly 50 queries per second against a normally configured zone climbed to about 60,000 per second once the authoritative servers were made to return SERVFAIL.

Neither figure was measured during an attack, but together they show how little it takes to push name servers far past their normal load, and why a flood that deliberately triggers failures and retries is so effective. On the wire, a DNS flood shows as a sustained wall of inbound queries to destination port 53, frequently for many distinct names.

• Inbound queries to destination port 53 far above your normal baseline, and staying there
• A distinct-name count close to the total query count under one zone: the random-subdomain signature
• A rising share of NXDOMAIN answers in the name server's own statistics
• Resolvers and external monitors reporting timeouts or SERVFAIL for your names while the web servers behind them are healthy

# Capture inbound DNS and look at the query names.
tcpdump -nn -c 5000 'udp dst port 53' -w dns.pcap

# Query types being asked for (A, AAAA, ANY, TXT ...).
tcpdump -nn -r dns.pcap 'udp dst port 53' \
  | awk '{ for (i=1;i<=NF;i++) if ($i ~ /\?$/) { print $i; break } }' \
  | sort | uniq -c | sort -rn

# Distinct names versus total queries: a high distinct-name count under one
# zone is the signature of a random-subdomain flood.
tcpdump -nn -r dns.pcap 'udp dst port 53' \
  | awk '{ for (i=1;i<=NF;i++) if ($i ~ /\?$/) { q++; seen[$(i+1)]=1; break } }
         END { printf "%d queries, %d distinct names\n", q, length(seen) }'

05Mitigations for authoritative operators

If you run authoritative DNS, the two structural defences are capacity and distribution. Serving a zone from many points of presence using anycast spreads a flood across the whole network instead of one server, and is the reason large zones survive attacks that would crush a single host. On top of that, response rate limiting (RRL) caps how many near-identical answers go to any one client block. Its main job is to stop the server being used for reflection, and during a flood it trims the outbound answers; it does not reduce the inbound queries the server must still receive and parse, which is why capacity comes first.

RRL is built into the common authoritative servers. In BIND it is a rate-limit clause with separate limits for normal answers, NXDOMAIN answers and errors, plus a slip value that turns some limited answers into truncated responses so genuine clients retry over TCP. Knot DNS ships an equivalent rrl module, and dnsdist (used in front of PowerDNS and others) can apply dynamic blocks keyed on query rate or on NXDOMAIN rate. Start in a log-only mode, watch what would have been limited, then enforce.

options {
    recursion no;                 // authoritative only: never an open resolver

    rate-limit {
        responses-per-second 10;  // identical answers per client block (/24 v4, /56 v6)
        nxdomains-per-second 5;    // caps random-name floods
        errors-per-second 5;
        window 15;
        slip 2;                   // every 2nd limited answer is truncated -> real clients retry over TCP
        log-only yes;             // observe first, then remove this line to enforce
    };
};

06Mitigations for recursive resolver operators

If you run a recursive resolver, the first and biggest control is to not be open: restrict recursion to your own clients, because an open resolver is both a reflection weapon and an easy flood target. Beyond that, caching is the defence. Negative caching (RFC 2308) and resolution-failure caching (RFC 9520) stop a resolver from hammering an authoritative server that is down or returning errors, which is precisely the retry storm that random-name floods try to provoke.

DNSSEC adds a further layer. Aggressive use of DNSSEC-validated cache (RFC 8198) lets a validating resolver answer many non-existent names directly from cached NSEC records instead of forwarding each one, and the RFC notes it can also blunt random-subdomain floods against signed zones; around 65% of queries to the root were NXDOMAIN at the time that RFC was written. Unbound implements this as aggressive-nsec and also offers per-IP and per-zone query limits, while BIND exposes synth-from-dnssec and fetches-per-zone. DNS Cookies (RFC 7873) give legitimate clients a lightweight way to prove they are not spoofed.

options {
    recursion yes;
    allow-recursion { 127.0.0.1; ::1; 192.0.2.0/24; };  // your own clients only
    dnssec-validation auto;
    synth-from-dnssec yes;        // RFC 8198: answer covered names from validated NSEC
    stale-cache-enable yes;        // keep expired records (BIND 9.18 default: no)
    stale-answer-enable yes;       // RFC 8767: serve them if the authority is unreachable
    fetches-per-zone 200;          // cap concurrent upstream fetches for any one zone
};

07What a reverse proxy or WAF can and cannot do

Putting a reverse proxy or a web application firewall in front of your site does nothing for a DNS flood. DNS resolution happens before any HTTP request is made, on a different service and often with a different provider, so the proxy is simply not in the path of the attack. A flood against your name servers takes your site down, for each visitor as soon as their resolver's cached answer expires, while the proxy sits idle waiting for requests that can no longer be resolved.

The defence for DNS is DNS-layer capacity: authoritative name service spread over anycast with response rate limiting, or managed DNS from a provider whose network can absorb the volume. A proxy protects the web tier; it does not protect the names that point at it. Treat the two as separate problems, confirm which one is actually under attack using the signs of a DDoS attack, and defend each in its own layer.