A DNS flood works by aiming a high volume of valid queries straight at a target's own name servers, rather than by borrowing a stranger's bandwidth the way a reflection attack does. It is one of the Layer 7 attack classes a thorough DDoS test is built to exercise, because every query is well formed, passes protocol validation, and still forces the server to do real work. Point enough of them at an authoritative or recursive resolver and resolution slows or stops for everyone, even though nothing about any single packet looks wrong.
How a DNS flood works
DNS runs mostly over UDP on port 53, with a TCP fallback for large answers, and it is connectionless by default: there is no handshake to complete before a query is answered. That makes it cheap to send queries from a botnet of real hosts, and it means the server has to parse and act on each one the moment it arrives.
The two server roles fail differently. An authoritative server answers only for the zones it owns, so a flood of queries for names it hosts (or a flood of junk names it must return NXDOMAIN for) burns CPU on lookups and response generation. A recursive resolver is more fragile under load: every query it cannot answer from cache opens an outstanding-query slot while it walks the delegation chain to an authoritative server, and those in-flight slots are finite. Flood a resolver with queries for names it must chase upstream and the outstanding-query table fills, at which point new lookups, including legitimate ones, are dropped.
That second pattern shades into DNS water torture, where the attacker prepends random labels to a real domain so every query misses the cache and forces a fresh recursion. A plain DNS flood does not need that trick; it wins on raw query rate. Either way, the measure that matters is queries per second the resolution tier sustains before it stalls, not bits per second on the wire, since a DNS query is small and a flood of them can be trivial on a bandwidth graph while a core saturates.
Why it matters under attack
DNS is a single point of failure that is easy to overlook. If name resolution stops, the application is unreachable even when every web and API server behind it is healthy and idle, because clients can no longer turn the hostname into an address to connect to. The October 2016 outage at a large managed-DNS provider took much of that provider's customer base offline for hours without any of those customers' own servers being touched, which is the shape of the risk in one incident.
The defenses are specific to DNS and worth naming because a test has to confirm each one actually engages. Response Rate Limiting (RRL) caps how often an authoritative server will send identical answers, which blunts both floods and the reflection abuse that rides on the same service. Anycast spreads the authoritative footprint across many sites so no single node absorbs the whole query rate, and it lets the nearest site soak regional load. Caching and negative caching shield the recursive tier by answering repeats without a fresh lookup, which is exactly the relief that random-subdomain queries are designed to deny. Each of these looks correct in a config file and can still fold when the query rate climbs past what it was sized for.
What a DDoS test measures
A DNS flood test characterizes the query rate at which the resolution tier saturates, and it does so per role, because the authoritative and recursive failure points are different numbers. It pushes valid queries at the authoritative servers to find where response generation pins CPU, and separately drives cache-missing queries at the recursive tier to find where the outstanding-query table fills, since that is usually the lower ceiling.
It then confirms the controls meant to hold under that load do their job: that RRL engages without dropping legitimate repeat traffic, that anycast actually distributes rather than concentrating on one site, and that rate limiting per source does not blackhole a busy recursive resolver that legitimately sends many queries on behalf of thousands of users behind it. The deliverable is a sustained QPS ceiling for each tier and the name of the resource, CPU, memory, or slot table, that gave out first. How the resolution tier is exercised alongside the rest of the attack surface is worked through in DNS infrastructure under DDoS.