A UK retailer can have its web front end behind a reverse proxy, a signed scrubbing contract with a named escalation matrix, a web application firewall tuned over months, and still go completely dark for two hours because two nameservers in the same rack stopped answering queries. The firewall logs will look healthy. The scrubbing dashboard will show nothing. Authoritative DNS DDoS protection is the part of the estate most buyers assume is included in something else, and it almost never is.

Authoritative DNS is the service that answers “what is the address for this name”for zones you control. Not the resolver your laptop talks to. The servers listed in your NS records, the ones every recursive resolver on the internet eventually has to reach. Take them offline and the name stops existing, whatever else is still running.

Why authoritative DNS fails differently from your website

What actually stops when the nameservers stop

A website outage is visible and bounded. A delegation outage is broader than most incident plans assume: inbound mail stops because sending servers cannot resolve your MX records; API clients fail on lookup rather than on connection; VPN concentrators become unreachable to remote staff resolving the endpoint hostname; SaaS single sign-on breaks in both directions as identity providers and service providers try to reach each other by name; and payment provider callbacks to your webhook endpoints fail silently, which usually surfaces later as a reconciliation problem rather than an alert.

Support desks feel it before monitoring does. Staff report “the internet is down”, which sends the first responders looking at connectivity instead of at the zone.

TTLs decide whether you notice in an hour or in a minute

Resolver caching is the only shock absorber you get. A record with a time-to-live (TTL) of 3600 seconds sits in resolver caches for up to an hour, so an authoritative outage may be invisible to a large share of users while you recover. Set the same record to 300 seconds because you wanted fast failover, and caches expire five minutes into the attack. Resolvers then come back for fresh answers, find nobody home, and the outage is immediate and total.

That is a genuine trade-off, not a best practice with one right answer. Long TTLs buy grace and take away your ability to move traffic quickly under pressure. Short TTLs do the reverse. Most estates end up with a split: 3600 seconds on stable A and MX records, 300 seconds only on the handful of records involved in a planned failover, with the low values set in advance of a change window rather than left permanently low.

The DNS version of origin IP leakage

Origin leakage is a familiar failure: the web estate hides behind a proxy, but the origin address is discoverable, so the attacker skips the proxy. The same pattern repeats one layer down, and it is more common than the web version. The front end is proxied and filtered. The NS records still point at ns1 and ns2 on the same unfiltered transit, frequently in the same rack, sometimes in the same /24. An attacker reading the delegation does not need to find the origin. It is published.

This is the single most useful check in the whole exercise, and it takes thirty seconds. Query your NS records, resolve the nameserver hostnames, and ask whether those addresses sit behind the same protection you bought for the website. If they do not, the scrubbing contract is protecting the part of the estate nobody needs to attack. Our earlier piece on the gaps that commonly remain open on DNS infrastructure covers the operational side of that audit.

The attack patterns authoritative DNS protection has to survive

Direct query floods over UDP and TCP

The straightforward case is volume: spoofed UDP queries crafted to resemble ordinary recursive traffic, aimed at your nameserver addresses. Because the source addresses are forged and the queries are well formed, signature matching helps less than capacity and per-source behavioural limits do.

TCP query floods get overlooked. DNS over TCP is a requirement, not an edge case, as set out in RFC 7766, and resolvers fall back to TCP routinely for large responses. An attacker opening connections and abandoning them exhausts connection state long before it exhausts bandwidth. Ask any prospective provider how it handles TCP query state separately from UDP volume. The vague answers are informative.

Random subdomain floods break the usual blocking reflex

Water torture attacks query nonexistent labels under your zone at high rates: a random string, then your domain. The queries arrive at your authoritative servers through legitimate recursive resolvers, because that is how the internet works. Your servers do the NXDOMAIN work, and if DNSSEC is in play, the negative answers cost more to produce.

The instinct is to block the sources. Do that and you have blocked BT’s resolvers, Sky’s resolvers and whichever public resolver a third of your customers use. The meaningful procurement questions are narrower: how does the platform absorb NXDOMAIN load, can it rate limit on label patterns rather than source addresses, and will it show you the top queried labels after the event so you can prove what happened? Response rate limiting in BIND, NSD and Knot helps on self-hosted servers, but it is a blunt instrument against traffic arriving via shared resolvers.

Your zone as somebody else’s weapon

The other direction matters for reputation and for your own capacity. Large ANY or TXT responses make your nameservers a useful reflector: an attacker spoofs a victim’s address, sends small queries, and your servers deliver the amplification. RFC 8482, published in January 2019, defines minimal-sized responses to ANY queries precisely to close that down. Check whether your provider implements it, and check what your TXT records have accumulated over the years. Old SPF fragments and abandoned verification strings add up.

Delegation failures that look like an attack

Some DNS outages are control failures wearing an attack costume. Hijacked NS records after a registrar account compromise. A domain that expired because the renewal invoice went to a departed employee. A DNSSEC key rollover where the DS record at the registrar no longer matches the signing key at the provider, which makes validating resolvers return SERVFAIL for a zone that is publishing perfectly good answers.

For generic top-level domains, registrar-level EPP statuses such as clientUpdateProhibited and clientTransferProhibited are the cheapest control you can apply. Nominet runs.uk under its own rules, so ask your registrar what lock equivalents it supports rather than assuming the gTLD status codes apply. And remember where the DS record lives: at the registrar, in the parent zone, not with your DNS provider. That split is what turns provider migrations into multi-day incidents.

Deployment models compared: where each one fits

Managed anycast DNS as a hosted service

You hand over the zone and inherit a global anycast footprint immediately. Capacity gain is the fastest available. What you give up is granularity: you rarely choose the rate-limiting thresholds, you get the logging the platform offers, and your ability to change records during an incident depends entirely on that provider’s portal and application programming interface (API) staying up.

Self-hosted nameservers behind BGP scrubbing or hosting-level filtering

Full control of software versions, response policy, rate limiting and logs. The catch is timing. On-demand mitigation fits nameservers badly, and diversion time is only half of the problem. If your records carry 300 second TTLs, resolvers come back for answers during the exact window you are still moving routes and settling the scrubbing path. Always-on is usually the honest answer for the DNS surface, whatever you decide for web traffic. The wider trade-off is covered in our comparison of always-on and on-demand mitigation models, and the measurement problem in our piece on what time-to-mitigate figures in an SLA really mean.

Dual-provider authoritative DNS with a hidden primary

The stronger architecture, and the one most organisations with real availability obligations end up at: a primary server you control, not published in the NS set, transferring the zone by AXFR and IXFR to two independent public secondary networks. Both providers answer queries. Neither one holds your only copy of the zone or your only editing path.

It costs discipline. Transfer monitoring, TSIG key management, DNSSEC handled either by signing at the hidden primary or by keeping both providers aligned, and a habit of checking that both NS sets serve the same serial. Compare that with the common single-provider setup where one portal outage removes both resolution and your ability to change anything. October 2016 is still the reference case: the Mirai-driven DNS provider outage attack pattern that hit Dyn took large numbers of otherwise healthy sites off the internet, and Dyn’s own incident write-up, published later that month, described tens of millions of discrete IP addresses associated with the botnet traffic. The sites were fine. The delegation was not.

Matching the model to the estate

Single-site ecommerce with one zone and a small team: managed anycast, always-on, with the registrar locked. Multi-tenant hosting or a data centre carrying customer zones: dual-provider or self-hosted with always-on filtering, because your customers’ NS records are your reputation. Healthcare, government services and anyone with regulatory availability expectations: dual-provider with a hidden primary, and a tested delegation rollback, because “our supplier was attacked”is not a defence that survives an availability review.

What ‘managed’ actually buys on the DNS surface

Pin down four things in writing, because sales decks cover none of them properly: onboarding and zone import, including who validates parity after the import; tuning of rate limits and query filters, and whether you can request changes; the escalation path during an attack, with named contacts and out-of-hours cover; and who is permitted to change records while an attack is in progress.

That last point is where recovery actually stalls. If the portal is degraded, is there an API? If there is an API, what is its rate limit when you need to push forty record changes at 02:00? Will the provider act on your behalf without sign-off, and is that authority written down? If nobody on their side can change policy or a record out of hours without your director’s approval, you have bought monitoring, not management.

Reporting quality is the second tell. A one-line “we mitigated 40Gbps for you”is useless on DNS. Ask to see a sample report before you sign, and look for queries per second over time, NXDOMAIN ratio against baseline, top queried labels, query type breakdown and a source resolver breakdown. If the provider cannot produce that shape of report, it cannot diagnose a water torture attack either.

Then trace the network. Provider diversity is frequently illusory. Two separately branded DNS services can resolve back to the same anycast footprint or the same upstream scrubbing partner, which means your carefully designed redundancy shares a single failure domain. Ask which network operates the points of presence, which autonomous system numbers announce the anycast prefixes, and whether any part of the mitigation is subcontracted. Resale is not a scandal, but you should know you are buying it. Our guide to choosing managed DDoS protection in the UK goes further into how those resale chains are structured and priced.

Evidence to demand before you sign

• Capacity in queries per second, not just Tbps. Terabits describe a pipe; nameservers fall over on query rate and on NXDOMAIN work. Ask for the qps figure, how it was measured, and whether that headroom is per customer or shared across the platform.
• An SLA that covers query response availability. Portal uptime is not resolution uptime. Read what the credit pays against, then compare it with your own downtime cost per hour. Most credits are rounding errors by that measure.
• Time-to-mitigate stated for the DNS layer specifically, with always-on versus on-demand made explicit and your TTL values factored into the conversation.
• Control checks. Registrar lock status, who holds the DNSSEC signing keys, whether the provider supports a hidden primary and inbound zone transfers, and a documented, tested rollback of the delegation.

Costs, business case and a safe cutover

UK pricing on this surface tends to follow one of three shapes: per zone with a query allowance, per million queries with overage, or bundled into an existing scrubbing or proxy contract at a marginal rate. Overage is where the surprises live, because an attack generates query volume you did not plan for. Ask whether attack traffic is billable. Pricing on managed DNS moves, so confirm current figures directly with the provider rather than working from anything published last year.

Build the case from your own numbers, not from headline attack sizes. Lost orders per hour from your own order data, staff hours idled, SLA credits you would owe your own customers, and the support volume an outage generates for weeks afterwards. Set that against annual protection spend plus plausible overage. The first-hour ecommerce response playbook is a useful companion for working out what an hour actually costs you.

The cutover itself breaks more zones than attacks do. A sequence that works: run a full record parity check between old and new providers and diff the output; lower TTLs on the records you are moving several days ahead, and wait out the old TTL; add the second NS set at the registrar while keeping the first; watch resolution from several independent networks and public resolvers, not from your office; then restore longer TTLs once things are stable. If DNSSEC is signed, plan the DS record change separately and do not remove the old keys until validating resolvers have picked up the new chain.

Afterwards, keep three checks running: external resolution from multiple networks, zone transfer health and serial agreement between providers, and DS record consistency against what your provider is publishing. Authoritative DNS DDoS protection is bought once and verified continuously, and the verification is what separates an estate that stays reachable from one that discovers its delegation problem during the incident. More background on attack infrastructure and defender priorities is collected across the DDoSInfo archive.

Frequently Asked Questions

What is the difference between protecting authoritative DNS and protecting recursive DNS?

Authoritative DNS answers queries about zones you own, so an outage makes your domain unreachable to everyone on the internet. Recursive DNS is the resolver service your users and servers query, so an outage there affects your own people’s ability to reach anything. Both need protection, but the blast radius and the buying decision are different: authoritative is a public-facing availability problem, recursive is an internal service problem.

Does a reverse proxy or CDN already give me authoritative DNS DDoS protection?

Only if you have moved your authoritative nameservers to that provider as well. A proxy in front of your web origin does nothing for queries aimed at the addresses in your NS records. Check the delegation: resolve your nameserver hostnames and confirm those addresses sit behind filtering. If they point at self-hosted servers on ordinary transit, the protected front end is not the exposed surface.

Is always-on mitigation necessary for nameservers, or will on-demand do?

For authoritative DNS, always-on is usually the right answer. On-demand requires detection plus diversion time, and if your records carry short TTLs for failover, resolver caches expire during that window and the outage becomes immediate rather than gradual. On-demand can be defensible for a web estate with long cache lifetimes; it fits the delegation badly.

Do two DNS providers actually make me safer, and how do I check they are independent?

Two providers remove single-provider dependency for both resolution and record editing, which is the failure the October 2016 Dyn incident illustrated. They only help if they are genuinely separate. Ask each provider which network operates its anycast points of presence, which autonomous systems announce the prefixes, and whether mitigation is subcontracted to a third party; shared upstreams mean shared failure.

How does DNSSEC affect DDoS protection and failover between providers?

DNSSEC adds signing work and larger responses, which raises the cost of NXDOMAIN floods against your zone, and it makes key handling part of your availability design. The DS record lives at the registrar in the parent zone, not at your DNS provider, so a mismatch between the published DS and the active signing key causes validating resolvers to fail the zone outright. Multi-provider DNSSEC works, most reliably with signing done at a hidden primary you control, but treat every key rollover as a change with its own rollback plan.