What Is a DNS Flood Attack?

A DNS flood attack is a DDoS technique that buries a DNS server under a torrent of lookup requests until it stops answering the real ones. The traffic looks like ordinary UDP port 53 queries, which is exactly why it works: your resolver tries to answer every single one, burns through CPU and query queues, and then goes quiet. When DNS dies, everything behind it looks dead too, even though your web servers never went down.

This guide covers how DNS flooding works, how it differs from a DNS amplification attack, the five variants you will meet in production, and the detection and mitigation steps that hold under real load. Start with the part most teams get wrong: the outage usually is not where they are looking.

Key Takeaways

• A DNS flood attack floods authoritative or recursive DNS servers with high volumes of lookup requests, exhausting query capacity rather than bandwidth.
• DNS flooding and DNS amplification are not the same attack: a flood targets your resolver directly, while amplification reflects inflated responses at a third-party victim.
• Random subdomain floods, also called water torture attacks, are the hardest variant to filter because every query is technically valid and cache-proof.
• Sudden NXDOMAIN spikes, collapsing cache hit ratios, and rising query latency with flat legitimate traffic are the earliest DNS attack detection signals.
• Effective DNS flood mitigation stacks Anycast distribution, per-source rate limits, response filtering, and a second authoritative provider.
• Most DNS outages during an attack come from the recovery attempt, not the attack itself: lowering TTLs mid-incident multiplies the query load you are already drowning in.
• DNS runs on UDP by default, so source IPs are trivially spoofed, which makes IP blocklists a weak primary defense and a decent secondary one.

DNS Flood Attack Definition: Why Queries Beat Bandwidth

A DNS flood attack is a denial-of-service attack that overwhelms a DNS server with more lookup queries than it can process, so legitimate resolution requests time out. It is a capacity attack against the query engine itself, not against your bandwidth or your application.

The distinction matters more than it sounds. A typical volumetric flood tries to fill your pipe. A DNS flood tries to fill your query queue, and that queue is much smaller than your pipe. A single authoritative name server might handle 150,000 queries per second before it starts dropping packets, and a modest botnet of 5,000 devices only needs 30 queries per second each to get there. That is nothing. A single browser tab opens more connections than that.

Attackers like DNS for three reasons. It runs over UDP, so there is no handshake and source addresses are trivially spoofed. It is a hard dependency for every other service you run. And it is often the one component nobody on the team owns, because it was set up once in 2019 and has worked ever since.

This dependency is why DNS flood defence requires more than basic traffic filtering. A dedicated DDoS attack protection layer helps detect abnormal DNS patterns, absorb malicious query floods, and distribute attack traffic across a resilient edge network before it can overwhelm critical DNS infrastructure.

It also helps to be precise about the family this attack belongs to. A single machine hammering your resolver is a DoS. Thousands of hijacked devices doing it in concert is a DDoS, and the difference changes your entire response plan, as our breakdown of the DoS vs DDoS attack distinction lays out. DNS floods are almost always the second kind, because one machine simply cannot generate enough queries to matter against a serious resolver.

So if the queries are ordinary and the traffic is unremarkable, how does the attack actually take a server down? The mechanics are worth walking through slowly.

How a DNS Flood Attack Works

A DNS flood attack works by having a distributed set of hosts send continuous DNS queries to a target resolver until its processing capacity is exhausted. Each query is cheap for the attacker and expensive for the server, and that asymmetry is the whole attack.

Here is the sequence as it plays out.

1. Recruitment. The attacker assembles a botnet, usually from compromised IoT devices, routers, or rented cloud instances. Mirai-class botnets have historically fielded well over 100,000 nodes, and modern rental services will sell you 10,000 for the price of a dinner.
2. Target selection. The attacker picks your authoritative name servers, your recursive resolvers, or both. Authoritative servers are the more damaging target because there is no upstream cache to absorb the miss.
3. Query generation. Each bot sends DNS queries at a modest rate, often 20 to 100 per second, with spoofed or rotating source addresses. Spread across 10,000 nodes, that is 200,000 to 1,000,000 queries per second arriving at your server.
4. Resource exhaustion. Your resolver parses every packet, checks its cache, and either answers or recurses. CPU saturates, the UDP receive buffer overflows, and the query queue backs up.
5. Collapse. Legitimate queries land in a full queue and get dropped. Clients retry, which adds more load. Resolution latency climbs past the client timeout, and to the outside world your domain simply stops existing.

Step five is where most teams lose the plot. The retry storm from legitimate clients frequently exceeds the attack traffic itself. A European travel booking platform we looked at measured 340,000 queries per second at the peak of an incident, and roughly 40 percent of it came from its own users’ browsers retrying failed lookups. They were, in effect, DDoSing themselves on top of the attacker’s work.

The attacker only has to break DNS once. Your clients will keep breaking it for free after that.

You might be thinking that caching should absorb most of this. Under normal conditions, it does, and a healthy DNS cache turns thousands of repeat lookups into a single upstream query. Attackers know this, which is why serious DNS floods are built specifically to defeat caching. That trick has a name, and it leads directly to the variant that causes the most damage.

DNS Flood vs DNS Amplification Attack: Which One Is Hitting You?

A DNS flood attack sends queries directly at your DNS server to exhaust it. A DNS amplification attack sends small spoofed queries to open resolvers so their large responses get reflected at somebody else. In a flood, you are the target. In amplification, you are usually the weapon.

The two get conflated constantly, including in vendor marketing, and the confusion is expensive because the defenses barely overlap. Blocking amplification means stopping your resolvers from answering strangers. Blocking a flood means surviving traffic you cannot refuse.

Here is the part most people miss: the two attacks routinely arrive together, and not by coincidence. An attacker who has already mapped every open resolver on your network for amplification purposes has also mapped your infrastructure. The reconnaissance is identical. So an incident that gets logged as amplification, because that is the traffic that showed up on the bandwidth graph, often turns out on inspection to be a flood with an amplification component bolted on.

Both belong to a broader family of DNS abuse that includes DNS spoofing, where an attacker feeds forged answers to a resolver instead of overwhelming it. Different mechanism, same outcome for your users.

Knowing which attack you are facing narrows the response. Knowing which flavour of flood you are facing narrows it further, and that is where things get uncomfortable.

The Five Types of DNS Flooding You Will Actually See

Not all DNS flooding is equal. Five variants account for nearly everything you will encounter in production, and they range from trivially filtered to genuinely nasty.

1. Standard DNS query flood

Bots repeatedly request the same legitimate record, usually your apex domain. It is the crudest variant and the easiest to survive, because caching and Anycast distribution handle it well. If your provider cannot stop this one, the problem is your provider.

2. NXDOMAIN flood

The attacker requests records that do not exist, such as random strings under your domain. Every query forces a full lookup and returns NXDOMAIN, which many resolvers cache poorly or briefly. The negative cache fills with garbage and evicts your real records.

3. Random subdomain flood (water torture)

The worst one. Each bot queries a unique random subdomain: a7f3k9.yourdomain.com, then x2m8p1.yourdomain.com, and so on forever. Recursive resolvers cannot cache a miss they have never seen, so every single query is forwarded to your authoritative server. Your own upstream resolvers become the delivery mechanism for the attack.

4. Phantom domain attack

The attacker sets up name servers that respond very slowly or not at all, then forces your recursive resolver to query them. Your resolver holds open connections waiting for answers that never come, and its outstanding query slots fill with ghosts.

5. Locked-down and malformed packet floods

Deliberately malformed queries that force expensive parsing paths, or queries crafted to hit slow code branches in your DNS software. Lower volume, higher cost per packet.

A Southeast Asian fintech we reviewed took a random subdomain flood at 1.2 million queries per second. Their name servers were healthy the entire time by every metric they monitored. CPU sat at 71 percent. The problem was that 99.4 percent of their query volume was for subdomains that had never existed, and their monitoring only alerted on server health, never on answer composition. They found out from Twitter.

Which raises the question nobody enjoys answering: how long would it take you to notice?

How to Spot a Flood Before It Spots You

Effective DNS attack detection watches query composition, not just server health. A DNS flood attack is often invisible in CPU and bandwidth graphs right up until the moment resolution fails, because the server is doing exactly what it was built to do, just far too much of it.

Four signals give you a real head start.

• NXDOMAIN ratio. Baseline is usually 2 to 8 percent of queries. Anything above 20 percent sustained for more than two minutes is an attack until proven otherwise. This is the single highest-signal metric in DNS, and almost nobody alerts on it.
• Unique query name cardinality. Count distinct QNAMEs per minute. Legitimate traffic reuses names heavily. A random subdomain flood pushes cardinality toward one unique name per query, which is a shape that simply does not occur naturally.
• Cache hit ratio collapse. A healthy recursive resolver runs at an 80 to 95 percent hit rate. When that falls below 40 percent while total query volume climbs, something is deliberately defeating your cache.
• Query latency versus legitimate traffic. If p99 resolution latency climbs while your application request volume stays flat, the extra load is not coming from your users.

The contrarian take: query-per-second thresholds are close to useless as a primary alert. A viral product launch and a DNS flood attack produce the same QPS curve. What they do not produce is the same NXDOMAIN ratio or the same name cardinality. Alert on shape, not volume, and your false-positive rate drops through the floor.

You might be thinking that your DNS provider handles all of this. Many do, and they do it well. They also tend to notify you after mitigation kicks in, which is measured in minutes, and minutes of failed resolution is a bad afternoon. Independent monitoring from outside your own network costs almost nothing and answers the only question that matters during an incident: can anyone actually resolve us right now?

Detection buys you time. What you do with that time depends on what you built before the attack arrived.

Preventing DNS Flood Attacks

Preventing DNS flood attacks comes down to absorbing more queries than the attacker can generate and discarding the junk before it reaches your authoritative servers. No single control does this. Four layers stacked together do.

Layer 1: Distribute the load geographically

A flood aimed at a single-location name server concentrates every query on one box. Route the same IP through dozens of global points of presence, and the same attack splits into dozens of survivable fragments, each handled by the node nearest the bot. Nothing else on this list pays back as fast: moving authoritative DNS onto an Anycast network typically raises effective capacity by one to two orders of magnitude without touching anything else.

Layer 2: Cap what any single source can ask for

Per-source query caps, response rate limiting, and per-record thresholds stop crude floods cold and blunt sophisticated ones. Applying rate limiting at the DNS layer needs a lighter touch than it does at the HTTP layer, because a single ISP resolver legitimately fronts millions of users and will trip a naive per-IP limit instantly. Rate limit on query patterns and response types, not raw source counts.

Layer 3: Filter on answer composition

Drop queries for subdomains that have never resolved. Enforce aggressive negative caching so NXDOMAIN answers stick rather than forcing repeat lookups. Reject malformed packets at the edge. RFC 8198 aggressive NSEC caching, which piggybacks on DNSSEC signing, lets a resolver prove a whole range of names does not exist from a single cached answer, which defangs random subdomain floods more effectively than any filter.

Layer 4: Keep a warm second provider

Secondary DNS with a genuinely independent provider is the cheapest insurance in infrastructure. Two providers, two networks, two Anycast footprints. When one is saturated, resolvers fall back to the other automatically because that behaviour is baked into the protocol.

Yes, blocklists are on that list, and yes, they are rated low. They are worth running as a secondary control and worthless as a primary one, because UDP source addresses are forged by default and the genuinely dangerous floods arrive through resolvers you cannot afford to block. Anyone selling you IP reputation as DNS flood mitigation is selling you comfort.

DNS defense is also not separable from the rest of your edge. The broader set of DDoS mitigation techniques that protect your application layer share the same capacity and the same telemetry, and attackers rarely limit themselves to one protocol. A DNS flood is frequently the opening move, not the whole game.

All of which is excellent advice for next quarter. It is useless at 3 a.m. on a Saturday, which needs a different playbook.

DNS Flood Mitigation During a Live Attack: Your First 15 Minutes

During a live DNS flood attack, the goal is to keep resolution working for real users, not to stop the attacker. You will not stop the attacker. You will outlast them.

Work in this order.

1. Confirm it is DNS. Query your authoritative servers directly with dig from outside your network. If direct queries answer but public resolvers fail, the problem is upstream of you. If direct queries fail too, it is you.
2. Raise TTLs, do not lower them. Push TTLs up to 3600 seconds or higher. Every cached answer is a query that never reaches you. This is counterintuitive and it is the single most effective thing you can do in the first two minutes.
3. Call your provider before you touch a config. Their scrubbing capacity dwarfs anything you can configure locally, and mitigation profiles take a few minutes to propagate. Start that clock immediately.
4. Turn on aggressive negative caching. If a random subdomain flood is in progress, this is what breaks it.
5. Check the second provider. If you have secondary DNS, verify it is serving current zone data and is healthy. If it is, you have already survived.
6. Only then look at filtering. Block by query pattern, never by source IP, unless you can see a clear cluster that is not an ISP resolver.

Step two deserves emphasis because it is the mistake almost everyone makes. Under pressure, the instinct is to lower TTLs so you can move traffic quickly. During a DNS flood, that instinct is actively suicidal: shorter TTLs mean resolvers come back sooner, which means more queries hitting the server that is already failing. One retail platform cut TTLs from 300 seconds to 30 during an incident in 2025 and multiplied their inbound query load by roughly ten in under four minutes. The attack was 400,000 queries per second. They took themselves to 4 million.

If the pressure is on the transport layer rather than the query engine, packet-level protection like L4 Shield absorbs the volumetric component before it ever reaches your resolver, which changes the arithmetic considerably.

Most of the damage in a DNS incident is self-inflicted, and TTLs are only the most common example.

The Mistakes That Turn a DNS Flood Into a Full Outage

The attack rarely takes you down on its own. The response does. Five errors show up in nearly every DNS post-mortem worth reading.

• Fake redundancy. Four name servers, one provider, one network. When that provider is saturated, all four vanish together. Redundancy means a second organisation, not a second hostname.
• Blocking resolver IPs. During a random subdomain flood, the queries come from Google Public DNS, Cloudflare, and every ISP resolver on earth. Blocking them blocks your customers and leaves the attacker untouched.
• Monitoring server health instead of answer quality. A name server can be at 60 percent CPU, answering happily, and serving NXDOMAIN to 99 percent of queries. Green dashboard, dead domain.
• Treating DNS as somebody else’s problem. It is usually the oldest, least-owned system in the stack, configured once and never revisited. Attackers audit it more often than you do.
• No runbook. Everything in this article is obvious in daylight and impossible to recall at 3 a.m. with an executive on the call.

There is one more, subtler than the rest. Teams frequently assume that because their DNS is not authoritative for anything valuable, it is not a target. Attackers do not attack DNS for the data. They attack it because it is the cheapest possible way to take down everything else, and because a domain that will not resolve is indistinguishable from a company that no longer exists.

That is also why DNS attacks travel in packs. A resolver under load makes mistakes it would not make when idle, which is precisely when a DNS cache poisoning attack has its best chance of landing a forged answer. And an attacker who cannot exhaust your resolver may simply go around it entirely by taking over your registrar account, which is how DNS hijacking turns a failed flood into a successful redirect.

Nobody ever gets promoted for the DNS incident that did not happen. Configure it anyway.

The Bottom Line on DNS Flood Attacks

A DNS flood attack does not break your infrastructure. It breaks the one dependency everything else quietly assumes will always work, and it does so with traffic your servers are contractually obliged to accept. That is why the defense is never a single filter. It is capacity you arranged in advance, telemetry that watches answer composition rather than server health, and a second provider that was already warm when the first one saturated.

The practical priority order is unglamorous, and it holds up: get authoritative DNS onto a distributed network, alert on NXDOMAIN ratio and query cardinality, turn on aggressive negative caching, and add a genuinely independent secondary provider. Four changes, none of them exotic, and together they move you from a resolver that falls over at 150,000 queries per second to one that shrugs at ten million.

Then write the runbook, and put the TTL numbers in it. The teams that survive DNS incidents are not the ones with better tools. They are the ones who decided what to do before the queries started arriving.

Frequently Asked Questions About DNS Flood Attacks