DNS DDoS Mitigation: The Three Attacks, Why Anycast Is the Answer, and What a Small Site Should Actually Do

DNS DDoS mitigation is the set of defences that keep a domain resolvable while someone floods its nameservers, and for almost every site the correct implementation is to not run the nameservers yourself. The three attacks that matter, direct query floods, reflection amplification, and random-subdomain floods that exhaust a resolver’s cache, are all defeated by the same properties: an anycast network with capacity far beyond any single link, response rate limiting that refuses to be a reflector, and an authoritative server that answers nonexistent names cheaply. Every large managed DNS provider has those properties and a self-hosted BIND on one virtual machine has none of them. The small-site plan is therefore two steps: put the zone on a managed anycast provider, and make sure the DNS is not the only thing standing between visitors and the origin.

DNS is the part of the stack that is attacked because it is the part that, when it fails, takes everything else down with it regardless of how well the web tier is protected. It is also the part where a small site can get enterprise-grade protection for nothing, which makes running your own authoritative servers in the year of writing an unusual choice that needs a reason.

Table of contents

• Why DNS is the target
• The three attacks
• The defences, and why they favour large providers
• What a small site should actually do
• The few settings that are still yours
• When running your own nameservers is still the right call
• How this fits the rest of the stack
• FAQ

Why DNS is the target

A site behind a hardened CDN, a web application firewall and an autoscaling origin is still one failed lookup away from being unreachable. If the authoritative nameservers for the domain stop answering, resolvers around the world hold the last answer until its TTL expires and then return SERVFAIL. Visitors see a browser error, not a slow page. The attacker never has to touch the web tier.

DNS is also cheap to attack. It runs over UDP, which has no handshake, so packets can be sent with forged source addresses. A query is a few dozen bytes and can produce a response many times larger. And an authoritative server has to answer every query for its zone or the zone stops working, so it cannot simply drop unfamiliar traffic the way a web server can.

The three attacks

1. Direct query flood. A botnet sends valid-looking queries for your domain at a rate the nameservers cannot sustain. No trickery; just volume. The defence is capacity and distribution: more servers in more places than the attacker can saturate.
2. Reflection and amplification. The attacker sends small queries with the victim’s address forged as the source to servers that answer with large responses. The servers do the work and the victim receives the flood. Your nameserver can be the reflector, used to attack someone else, or the victim. Open recursive resolvers are the classic reflectors, which is why a resolver must never be reachable from the internet, and authoritative servers limit the damage with response rate limiting.
3. Random-subdomain flood, sometimes called water torture. Queries for x7f2q.example.com, p91zz.example.com and millions of other names that do not exist. Each one misses every cache and lands on the authoritative server, and the recursive resolvers in between exhaust their capacity holding the outstanding requests. The defence is an authoritative server that answers NXDOMAIN fast and cheaply, and resolvers that use aggressive negative caching.

A fourth category is not a DNS attack at all but shows up as one: an attack on the network link in front of a self-hosted nameserver. A 10Gbps flood at a server on a 1Gbps port takes the DNS down without a single DNS packet being processed. This is the most common way a small operator’s DNS fails, and it is the one that capacity alone fixes.

The defences, and why they favour large providers

• Anycast. The same nameserver IP is announced from dozens of locations. Every query is routed to the nearest one, so attack traffic is split across the whole network instead of converging on one link, and a location that is overwhelmed drops out of routing while the rest keep answering. This is the single most effective defence and it requires owning address space and peering in many places, which is why it belongs to providers.
• Response rate limiting. The authoritative server tracks how many identical responses it has sent to a given address and starts dropping or truncating them past a threshold. A truncated response tells a real client to retry over TCP; a reflection victim never sends that retry. This stops your server being a useful reflector at almost no cost to legitimate traffic.
• Negative caching and NXDOMAIN synthesis. Answering nonexistent names from a signed zone’s structure without hitting the backend, and letting resolvers cache the absence, drains a random-subdomain flood of its effect.
• Traffic analysis and scrubbing. Large providers see attacks across many customers and can filter by signature before traffic reaches the authoritative servers. A single operator sees only their own traffic and learns about the attack when it is already succeeding.
• Redundancy across providers. A secondary provider serving the same zone by zone transfer means an outage at one operator does not take the domain down. This is the belt-and-braces step for domains where DNS downtime has a cost per minute.

What a small site should actually do

Two steps, and the first is free.

1. Delegate the zone to a managed anycast provider. Every major DNS host and every CDN with a DNS product runs an anycast network with rate limiting and scrubbing built in. Moving a zone is changing the nameservers at the registrar. There is no configuration for the mitigation because the mitigation is the network.
2. Make sure DNS is not the only shield. Put the web tier behind a CDN or proxy so the origin address is not published, and use a hosting platform whose edge absorbs volumetric traffic. DNS mitigation keeps the name resolving; it does nothing for what the name points at.

What a small site should not do is run BIND or another authoritative server on the same virtual machine as the website, with the zone’s NS records pointing at that machine. It is the configuration that fails first, fails completely, and fails in the way that hides the cause, because the attack that takes it down may not be aimed at DNS at all.

The few settings that are still yours

Even on a managed provider, a handful of zone-level choices affect how well the domain rides out an attack.

• TTLs. A longer TTL on stable records means resolvers keep serving the last answer for longer if the authoritative servers become unreachable. Five minutes is a reasonable floor for records you change often; an hour or more for records that do not change.
• No wildcard you do not need. A wildcard record turns every random subdomain into a valid answer, which defeats negative caching and makes a water-torture flood more expensive to serve.
• DNSSEC, with care. Signing lets resolvers verify answers and lets the authoritative server synthesise NXDOMAIN cheaply. It also makes responses larger, which is what amplification attackers want; rate limiting covers that, and it is the reason to only enable DNSSEC on a provider that implements it.
• Monitoring from outside. A check that resolves the domain from several regions every minute tells you the DNS is failing before the support inbox does.

When running your own nameservers is still the right call

There are organisations for which this post’s advice is wrong: those with a legal requirement to control the authoritative infrastructure, those with private address space and split-horizon zones that no public provider can serve, and those large enough to own the anycast network themselves. They have DNS operators on staff and this article is not for them. For everyone else, the exercise is the same as running your own email: technically possible, occasionally justified, and the wrong use of a small team’s attention.

How this fits the rest of the stack

The name is one layer; what it resolves to is the other, and both need to hold up. Custom domains on RunxBuild point at a platform that serves static sites and services from its own edge with the certificate handled, which covers the second step above for the site itself. For the origin behind it, the RunxBuild hosting calculator is where the service and the bandwidth line appear together, and bandwidth is the number a volumetric event actually moves.

Useful related references:

• DNS Resolution Error: 6 Causes and the Right Fix
• What Does Flushing DNS Do? Clearing the Local Cache of Stale Answers
• Secure DNS Provider: Choosing a Resolver and Protecting Your Own Domain
• Custom domains and certificates on RunxBuild

FAQ

What is a DNS DDoS attack?

An attack that floods a domain’s authoritative nameservers, or the resolvers in front of them, so the domain stops resolving. The main forms are direct query floods, reflection amplification using forged source addresses, and random-subdomain floods that exhaust caches. If the name does not resolve, the site is unreachable regardless of how well the web tier is protected.

How does anycast protect DNS from DDoS?

The same nameserver address is announced from many locations, so queries route to the nearest one. Attack traffic is spread across the whole network rather than concentrating on one link, and an overwhelmed location drops out of routing while the others keep answering. It is the most effective single defence and requires a provider-scale network.

What is DNS response rate limiting?

A feature of authoritative servers that limits how many identical responses are sent to one address per second, dropping or truncating the excess. Real clients retry over TCP when truncated; reflection victims do not. It stops the server being used as an amplifier for attacks on others.

Should a small website run its own DNS server?

No. Delegating the zone to a managed anycast provider is free or nearly so, requires only a nameserver change at the registrar, and provides capacity, rate limiting and scrubbing that a self-hosted server on one machine cannot. Running authoritative DNS yourself is justified only by specific legal or network requirements.

Does DNS DDoS mitigation protect the website itself?

No. It keeps the domain resolvable. The web tier needs its own protection: a CDN or proxy in front of the origin, an unpublished origin address, and a hosting platform whose edge absorbs volumetric traffic. Both layers are needed.