DNS Query Flood

A DNS query flood has nothing clever in it. The queries are well-formed, the names are usually real, and each one asks a question the server is supposed to answer. There are simply more of them than the server can handle.

That plainness is the difficulty. There is no malformation to signature, no amplification factor to notice, and no protocol violation to point at — only volume that has to be separated from popularity.

At a glance

Appliance	Property	Query flood	Water torture	Amplification
Queries are for	Names that exist	Random names that do not	Anything with a large answer
Target	Your DNS server	Your DNS server and other resolvers	Somebody else, using DNS as the reflector
Cache behaviour	Cache absorbs much of it	Cache is structurally useless	Not relevant
Distinguishing signal	Rate and source spread	NXDOMAIN ratio	Response size and forged sources

Three attacks that arrive as DNS traffic and need three different responses. Treating them as one category is why DNS mitigation is so often mis-tuned.

What it exhausts

Query-handling capacity on the server: parsing, lookup and response generation, all of which happen per query.

Bandwidth, though usually less than expected. DNS messages are small, so a query flood can saturate a server long before it troubles a circuit — which means it is frequently a packet-rate problem rather than a volumetric one.

Upstream capacity for recursive resolvers, where a flood of names the resolver has not cached forces it to forward each one.

The consequence is disproportionate. DNS is a dependency of nearly everything else in an estate, so exhausting it produces a total outage from a partial attack.

How it differs from similar attacks

Three attacks arrive as DNS traffic and are routinely confused, which is why the table above separates them.

A query flood asks for names that exist. Caching absorbs a large share of it, so the load reaching an authoritative server is much smaller than the load sent.

Water torture asks for random names that do not exist, so caching cannot help by construction. The distinguishing signal is the NXDOMAIN ratio rather than the query rate.

Amplification does not target your DNS at all. It uses it to attack somebody else, and the giveaway is response size against forged sources.

Mitigating the wrong one wastes effort and sometimes makes things worse: response rate limiting tuned for the third case does little for the first.

Observable telemetry

• Query rate rising sharply against a stable NXDOMAIN ratio, which separates it from water torture immediately.
• Query name distribution: a flood aimed at one or a few names looks very different from legitimate demand.
• Response latency rising, then timeouts, then retries — which add load and make the curve steeper than the attack itself.
• Source distribution: few sources at high rate, or many at low rate, each of which changes which control will work.
• Cache hit ratio at a recursive resolver falling, indicating the queries are for things it has not seen.

Common false positives

A genuine traffic event. A campaign launch, a viral link or a news mention produces exactly this shape, and the feedback loop that follows is the classic self-inflicted outage: thresholds tightened during the busiest legitimate hour of the year.

A misbehaving client population. An application with a broken retry loop or an ignored TTL can generate query rates indistinguishable from an attack, from addresses that are entirely legitimate.

TTL expiry synchronisation. Where many resolvers expire the same record simultaneously, the authoritative server sees a spike that is real and periodic.

Mitigation by layer

Provision for the peak you actually have. DNS is cheap to scale relative to what it protects, and much of this problem is under-provisioning rather than defence. Establishing the legitimate peak is the first step in the sizing exercise.

Anycast, which is the structural answer. Distributing the service across many nodes means a distributed flood is divided among them rather than concentrated, and it improves ordinary latency at the same time — the mechanism is in anycast for DDoS mitigation.

Per-source query rate limits, derived from measured legitimate resolver behaviour rather than from a default. Large resolvers legitimately send a great deal, so whitelist them first.

Response rate limiting on authoritative servers, understanding that it addresses the reflection case primarily.

Truncation to force TCP for suspicious sources, which filters spoofing at the cost of a round trip and requires a TCP path provisioned for the fallback.

Separate authoritative from recursive. A resolver serving your users and an authoritative server serving the internet have different exposure and different failure consequences, and combining them means one attack takes both.

Operational pitfalls

Tightening limits during a real peak. The most expensive mistake available here, and it looks exactly like the correct action from the console.

Rate-limiting large resolvers. A handful of major resolvers carry a large share of legitimate queries, and a per-source limit set without them in mind refuses much of the internet.

Ignoring retry amplification. Once responses slow, clients retry, and the observed rate rises above the attack’s own rate. Reading that as escalation leads to over-correction.

Safe validation

Generate a flood of valid queries for existing names, at increasing rate, and record the query rate at which response latency degrades, the NXDOMAIN ratio throughout, and whether legitimate resolution continued from a control source.

Run the water torture variant separately and compare. The two produce different curves and different counters, and a team that has seen both side by side will classify the real event correctly in the first minute rather than the tenth.

Isolation and authorisation requirements are in the test lab guide and authorised testing.