A retailer can spend two years and a five-figure annual contract getting its web estate right, with every hostname behind a reverse proxy, always-on scrubbing across the origin range and an escalation matrix taped to the wall of the NOC, and still go completely dark because the nameservers answering for its domain arrived free with the domain registration. DNS DDoS attack protection is the surface almost nobody in the org chart actually owns. The proxy contract has a signatory. The scrubbing centre has an account manager. Authoritative DNS usually has a login someone set up in 2019.
What follows is a review of your own setup rather than a product explainer: six specific gaps, the deployment models that close them, the contract questions that separate real capacity from resale, and an audit you can run this week.
Why authoritative DNS is the protection surface most contracts quietly skip
Distributed denial-of-service (DDoS) protection is worth assessing across three distinct surfaces, not one. Network and transport (volumetric floods, SYN floods, UDP reflection aimed at your IP ranges). Application layer (HTTP floods, expensive search queries, credential-stuffing traffic that looks like customers). And authoritative DNS, which is the system that answers the question “where is www.yourdomain.co.uk?”for every recursive resolver on the internet.
Buyers routinely assume the third is covered by the first two. It rarely is, for a mundane reason: DNS sits with the registrar or the hosting control panel, not the security vendor. A content delivery network protects the traffic that reaches its edge. If your zone is served by four nameservers on a shared platform bundled with a reseller hosting account, nothing in your scrubbing contract touches them.
How the zone ends up unmanaged
Three patterns account for most of it. The domain was registered years ago and the registrar’s free nameservers were never changed, because they worked. DNS was set up in a cPanel or Plesk instance and inherited by whoever bought the hosting company. Or there is a legacy secondary nameserver from a previous supplier still listed in the delegation, on a box nobody has logged into since the last account manager left.
None of these are negligence exactly. DNS is the one part of the stack that keeps working with no attention at all, right up until it does not.
The reachability chain, and where a single weak link ends it
User to resolver, resolver to your authoritative nameserver, client to the proxy edge, edge to origin. Every one of those hops has to work. Break the second and the other three are irrelevant, which is what makes the failure so slow to diagnose: origin monitoring stays green, the scrubbing dashboard shows a healthy baseline, the edge reports no anomaly, and the phones start ringing anyway. Synthetic checks that resolve once and cache the answer will lie to you for the length of their TTL. If you want the mechanics of that failure at length, our piece on DDoS on DNS and how blackouts happen covers it.
The attack types your DNS protection has to survive
Direct query floods. Straightforward volumetric pressure against the IPs of your authoritative servers, in packets per second rather than gigabits. DNS servers fall over on query rate long before the pipe fills.
Pseudo-random subdomain attacks, often called water torture. The attacker generates names like a8f3k2.yourdomain.co.uk, which have never existed and cannot be in any cache. Recursive resolvers worldwide have no choice but to forward every one of them to you. The global resolver population becomes an unwitting amplifier, and the traffic arrives from thousands of legitimate resolver IPs you cannot simply block without blocking real customers behind them.
Reflection and amplification against your zone. Spoofed queries with your victim’s address as the source, aimed at open resolvers, requesting responses far larger than the query. ANY queries were the classic vehicle, which is why the IETF published RFC 8482 in January 2019, standardising minimal-sized responses to QTYPE=ANY. Note the direction of the harm here: your zone is the ammunition, not the target. DNSSEC-signed zones return larger answers by design, which raises the amplification factor available to whoever points a reflector at them. Preventing your own resolvers from being used this way is the subject of BCP 140.
TCP-based DNS floods. Cheaper to defend at the network layer, but they exhaust connection state on nameservers tuned for UDP, and truncation behaviour means legitimate large responses need TCP to work.
Collateral damage. On a shared DNS platform, an attack aimed at another customer’s zone lands on the same anycast prefixes serving yours. In December 2010, EveryDNS terminated DNS service for wikileaks.org, stating that the attacks directed at that domain threatened the stability of the infrastructure serving its other customers. The 21 October 2016 attack on Dyn, which Dyn confirmed involved Mirai botnet traffic, took down name resolution for a long list of well-known services that had done nothing to attract attention. Your risk on a shared platform is not only your own threat profile. It is everyone else’s.
Six gaps to close in your DNS DDoS attack protection
Gap 1: one authoritative provider, no genuinely independent secondary
Two nameservers on the same anycast network, in the same account, sharing the same control plane, are one nameserver with a redundant hostname. Provider-wide events are the ones that hurt, and they are not rare. A real secondary means a different company, a different anycast footprint, separate BGP announcements and separate billing. The test question: if this provider’s entire platform disappeared for 90 minutes, would your domain still resolve? If the answer needs a caveat, you have one provider.
Gap 2: marketing uptime figures instead of capacity evidence
“100% DNS uptime SLA”is a credit policy, not a capacity statement. Ask for queries per second the platform sustains, how many anycast points of presence serve UK and Western European traffic, whether those PoPs are owned or leased, and what happens to a single PoP under load (does it withdraw the route and shift traffic to the next site, and what is the resulting latency for a resolver in London?). Rate limiting matters too: response rate limiting, implemented in BIND since 9.9.4, will drop repeated identical responses, but it does nothing against randomised subdomains because no two responses are identical. Ask specifically what they do about that vector.
Gap 3: TTLs set for convenience rather than failover
A record at 86400 seconds means a failover decision takes up to a day to reach most of the resolver population. At 300 seconds, emergency re-pointing is realistic within minutes, at the cost of higher query volume against your nameservers and a marginally higher bill on per-query pricing. Most revenue-carrying records belong at 300 to 900 seconds as a standing posture, not lowered in a panic during the incident (by then it is too late, the old value is already cached).
The subtler trap is negative caching. Under RFC 2308, how long a resolver remembers an NXDOMAIN is governed by the SOA MINIMUM field and the SOA record’s own TTL, so an SOA minimum of 86400 can leave “this name does not exist”cached long after your zone is healthy again. And TLD delegation NS records commonly carry TTLs measured in days, which means switching providers at the registrar is a planned migration, never an emergency lever.
Gap 4: registrar and zone accounts with no MFA and stale delegation hygiene
A hijacked registrar account achieves everything a DDoS does, faster and quieter. Multi-factor authentication on the registrar, registry lock where the registry supports it, and a role account rather than a departed engineer’s personal email. Then check the delegation itself: do the NS records in your zone match the NS set at the parent, are the glue records pointing at IPs you still control, and is there a fifth nameserver in the list that has not answered since 2021? Stale glue is not a theoretical problem. It is an IP someone else can eventually be allocated.
Gap 5: nobody named as the person who acts during a DNS incident
The dividing line is simple. If no human on the provider’s side is empowered to change a rate limit or push a response policy at 03:00 without a change board, you have bought monitoring, not management. Same test for your side: name the person who can lower a TTL, add a secondary, or re-point a record out of hours, and confirm they hold the credentials to do it. Our first-60-minutes playbook for ecommerce incidents assumes that person exists. Frequently they do not.
Gap 6: the origin IP is still published somewhere in your DNS
This is the one that undoes the entire proxy investment. The leak almost always lives in DNS: an mail.yourdomain A record pointing straight at the same server the website runs on, an ftp or webmail host auto-created by a control panel, an SPF record with the origin’s IP in a mechanism, a dev or staging name that was never proxied. Historic passive DNS and certificate transparency logs preserve the rest. Attackers do not need to beat your edge if a five-year-old record hands them the address behind it. Enumerate every record in every zone, and treat any that resolves to origin as an open door.
Deployment models, and where each one fits
Managed anycast DNS from a specialist. Absorption capacity you cannot replicate in-house, plus operational responsibility for the query layer. You give up control of tuning and you inherit the provider’s blast radius when someone else’s zone attracts a botnet.
Self-hosted nameservers behind BGP scrubbing. Viable if you run your own AS and have the on-call depth to support it. The diversion trade-offs are the same as for web traffic, and worth reading against the always-on versus on-demand comparison. The consequence differs, though: a few minutes of unanswered queries outlast the attack itself, because resolvers cache the failure and clients retry unevenly. Web traffic recovers when the flood stops. DNS recovers when the caches do.
Registrar or hosting-panel DNS. Fine for a parked brand-defence domain or an internal tool. Rarely defensible for a domain that carries revenue, because you have no capacity evidence, no incident contact and no ability to influence mitigation.
Multi-provider DNS with AXFR/IXFR or API-based sync. The pattern that actually survives a provider-wide event: two independent platforms, both authoritative, both listed in the delegation. The operational cost is real. Zone drift between platforms, DNSSEC key management across two vendors (usually solved by keeping signing with one and transferring signed data, or running multi-signer per RFC 8901), and a change process that pushes to both. Most organisations that skip this cite complexity. Most that adopt it do so the week after an outage.
How to verify a provider’s claims before you sign
A great deal of DDoS and DNS capacity is resold. Ask explicitly whose anycast network it is, whose scrubbing centres handle the traffic, how many points of presence serve UK queries, and whether the party on your contract can change mitigation policy directly or can only raise a ticket with the upstream. The answer to that last question determines your real time to mitigate.
“Managed”is a contract word, not a technical one. For DNS it should name who performs zone onboarding, who tunes rate limits, who is authorised to push a response policy or TTL change mid-incident, and what the out-of-hours escalation path is by name and number. If nobody is named, the answer during an attack is you.
Read the service level agreement for what it measures rather than what it promises. Is authoritative DNS covered by the same time-to-mitigate commitment as web traffic, or is it excluded in a schedule? Is the clock started by your ticket or by their detection? The arithmetic on service credits is usually unflattering once you compare it with an hour of lost trading, and what those SLA seconds actually represent deserves a closer look than the sales deck gives it. Then ask for a redacted post-incident report from a real DNS event: vector breakdown, query rates, time to detection, actions taken. A dashboard screenshot is not evidence.
A DNS resilience review you can run this week
- Inventory. Every domain the business owns, including the ones marketing registered for a campaign; who is authoritative for each; who holds the registrar login; and the expiry date. Expiry is not a DDoS problem, but it takes sites down just as effectively.
- Delegation and record audit. Compare the parent NS set with the zone’s own; check glue; list every A and AAAA record and flag anything resolving to origin; check MX and SPF for leaked addresses; record current TTLs and the SOA minimum; confirm DNSSEC status and who holds the keys.
- Failover rehearsal. Write down what you would change, who has permission, and how long propagation genuinely takes at today’s TTL values. Rehearse it on a low-stakes domain. Most teams discover the credentials problem before they discover the technical one.
- Business case. Downtime cost per hour against the annual cost of a secondary DNS provider or a managed contract. UK pricing is generally structured around clean bandwidth or protected IP ranges for network mitigation, with DNS charged per zone and per million queries; our guide to how managed DDoS protection is priced in the UK sets out the variables to compare. Secondary DNS is usually the cheapest resilience you will buy all year.
Sound dns ddos attack protection is less about buying a bigger scrubbing pipe than about removing the assumption that someone else already covers the query layer. Check who answers for your domain, and check tonight rather than during the incident.
Frequently Asked Questions
What is a DNS DDoS attack and how does it differ from a website flood?
A DNS DDoS attack targets the nameservers that translate your domain into an IP address, rather than the web servers that return pages. The difference matters operationally: during a web flood the site is slow or erroring, while during a DNS attack the site is simply not found, and origin monitoring can stay green throughout because the origin is fine. Nobody can reach it.
Does my CDN or scrubbing provider already cover authoritative DNS?
Sometimes, but never assume it. Many CDN plans include managed DNS as an option that must be enabled and delegated to, and plenty of customers proxy their web traffic while leaving the zone with the registrar. Check the NS records for your domain right now; whoever appears there is the party responsible, whatever the security contract says.
Do I need a second DNS provider, or is anycast enough on its own?
Anycast handles volumetric absorption well and is the right baseline. It does not protect you from a provider-wide control plane failure, a routing mistake, a billing suspension or a sustained attack on a neighbouring customer. For revenue-carrying domains, two independent providers is the pattern that survives those events.
Does DNSSEC protect against DDoS attacks?
No. DNSSEC authenticates responses and defends against cache poisoning and spoofing; it has no bearing on whether your nameservers can answer under load. Signed responses are larger than unsigned ones, which can increase the amplification factor available in a reflection attack that uses your zone, so DNSSEC and capacity planning need to be considered together rather than treated as the same control.
What TTL values make DNS failover realistic during an attack?
For records you might need to move in a hurry, 300 to 900 seconds is a workable standing value; at 86400 seconds a failover decision can take most of a day to reach the resolver population. Lower the TTL well before you need it, since the old value is already cached by the time an incident starts, and check the SOA minimum as well, because negative caching under RFC 2308 governs how long an NXDOMAIN sticks around.