DNS DDoS Attack: When Your Nameservers Go Down

Picture the support queue on a bad afternoon: customers say the site is gone, but the server dashboard is green, the database is idle and an uptime check against the IP returns 200. Nine times out of ten in that situation, the problem is DNS.

What a DNS DDoS attack actually hits

Every visit starts with a lookup. A recursive resolver, run by the visitor’s ISP or by a public service, asks your domain’s authoritative nameservers for the address of www.example.com. Those authoritative servers are the target in a DNS DDoS attack.

When they stop answering, the resolver retries, times out and hands the browser an error. Your web server could be idling at 2% CPU; nobody will reach it.

That multiplier is why attackers like DNS. A single DNS provider often serves hundreds of thousands of zones, so one successful flood affects many unrelated sites at once. The best-known example is the attack on DNS provider Dyn on 21 October 2016, launched from the Mirai botnet, which left a long list of major websites unreachable for parts of Europe and North America for hours. Their own infrastructure was fine.

Three ways DNS gets attacked

The defences differ, so it helps to know which pattern you are facing.

Random subdomain attacks are the nasty ones. Every query names something no resolver has seen before, so caching cannot help, and every single one ends up at your authoritative servers. To the resolver it looks like ordinary traffic, there is just far too much of it.

Reflection is covered in depth in DNS amplification attacks. For the wider picture beyond DNS, see types of DDoS attacks.

How to tell your DNS is under attack

The first test is simple: do all of your nameservers still answer?

dig example.com NS +short

for ns in $(dig example.com NS +short); do
  echo "== $ns"
  dig @"$ns" example.com A +short +time=2 +tries=1
done

A line reading ;; connection timed out; no servers could be reached means that server is not answering from where you sit. If every server times out, your domain is effectively offline.

Other signs:

• External monitoring reports “DNS resolution failed” while checks against the raw IP pass.
• Your DNS provider’s analytics show NXDOMAIN responses jumping from a small share to the majority of all answers. That is the signature of a random subdomain flood.
• On self-hosted nameservers, CPU and inbound UDP packets on port 53 spike sharply.

For a broader method of telling attacks apart from normal load, read how to detect a DDoS attack.

Your TTL is a cushion

Resolvers cache answers for as long as the TTL allows. While a record sits in cache, nobody needs your nameservers. That window is the only buffer you have when they fail.

Real life is messier. Caches expire at different times, some resolvers cap TTLs, and popular records are refreshed more often. Some large resolvers implement RFC 8767, “serve-stale”, and keep handing out expired answers when the authoritative servers do not respond. Treat that as a bonus rather than a plan.

Two networks, not just two servers

Many registries require at least two nameservers. Plenty of domains meet that rule with ns1 and ns2 at the same provider, in the same data centre, on the same upstream network. That covers a dead disk. It does not cover a flood aimed at the provider.

Real resilience comes from diversity:

• Anycast nameservers. The same IP is announced from many locations, so attack traffic is spread across sites. The mechanics and limits are explained in anycast DNS.
• A second, independent DNS provider. Provider A holds the zone and provider B mirrors it through zone transfers. If A goes dark, B keeps answering. The setup is in secondary DNS.
• Different networks and different parent domains. ns1.provider-a.net and ns2.provider-b.com sitting on separate networks will not fall together.

All of this is configured at your registrar, so pick one whose nameserver management lets you list servers from several providers without fuss.

A checklist for your domain

• At least two nameservers on different networks
• At least one provider using anycast
• NS records at the registrar match the NS records inside the zone
• TTL of 3,600 seconds or more for stable records
• Monitoring that tests name resolution separately from HTTP
• Self-hosted nameservers: recursion off, response rate limiting on
• DNSSEC enabled with the correct DS record at the registrar
• Two-factor login on the registrar account

That last item belongs here. If you need to add an emergency nameserver during an attack, you need to get into the registrar account quickly and securely.

Where DNSSEC fits

DNSSEC signs your records so resolvers can reject forged answers, for instance if someone tries to redirect visitors while your team is busy fighting a flood. It does not add capacity and it will not keep you online.

Signed responses are bigger, which makes them more attractive for reflection. That is a reason to turn on response rate limiting, not a reason to skip DNSSEC. With a registrar that supports DNSSEC, signing a .com zone and publishing the DS record takes a few minutes.

If the attack is happening now

1. Run the dig loop above to see which nameservers still respond.
2. Contact your DNS provider with timestamps and the affected domains.
3. If you have a prepared secondary at another provider, add it at the registrar.
4. Do not bother raising TTLs mid-attack; the new value only spreads once resolvers can reach you again. Do it afterwards.
5. Keep a log of times and error messages for your own review and for reporting the attack.

General first-response steps for attacks on web servers are in DDoS attack: what to do.

The single biggest improvement is a second nameserver provider on a separate network. Before setting one up, check where your domains live and who can change them. If you are starting a new project, you can search for an available name and spread its nameservers across two providers from day one.