A DNS provider outage attack is the one denial-of-service scenario your own capacity planning cannot touch: the origin is healthy, the load balancers are bored, the CDN edge is warm, and the domain is still dark because somebody else’s authoritative nameservers are drowning. Nothing in your rack is broken. There is no traffic to divert, no scrubbing centre to call in, no BGP announcement to shift, because the network under pressure belongs to a third party you pay a few hundred pounds a year and have probably never spoken to on the phone.

Most coverage of this topic retells the October 2016 Dyn attack and stops. That is a story, not a control. What follows treats authoritative DNS as what it actually is: an architecture and procurement decision that gets made once, usually by accident, and then sits unexamined until the day it fails.

What a DNS provider outage attack actually breaks

Authoritative DNS is the set of servers that hold the definitive answers for your zone. Recursive resolvers, run by ISPs, mobile networks, corporate estates and public services such as Google, Cloudflare and Quad9, ask those servers on behalf of users and cache the reply. Attack the authoritative layer and you have not touched a single one of your machines. You have simply removed the directory that tells the internet where they are.

Three patterns fail in different ways, and the distinction matters because the remedies differ:

• Straight query floods exhaust anycast capacity at the provider’s points of presence. Packets per second, not clever queries. The provider’s headroom is the only thing standing between you and a timeout.
• Pseudo-random subdomain floods, often called water torture, query names like a8f3k2.yourdomain.co.uk in volume. Every one is a genuine miss. No resolver cache can absorb them, so the load is funnelled through recursive resolvers onto the authoritative servers, and the resolvers themselves fill with useless negative entries. The attack borrows the legitimate resolver population as a delivery mechanism.
• Reflection and amplification using spoofed source addresses can point the reflected volume at the authoritative infrastructure, or at you, depending on which end of the spoof you are on.

Then comes the part that lengthens every DNS incident: retries. When answers time out, resolvers do not politely wait. They re-query, try the next nameserver in the set, and try again, which means legitimate traffic multiplies exactly when the provider is trying to recover. The IETF eventually wrote guidance about it. RFC 9520, published in December 2023, tells resolvers to cache resolution failures for at least one second and, as guidance, no longer than five minutes, specifically to damp down retry storms against servers that are already struggling.

Everything keyed to that zone goes at once. Not just the website: API endpoints partners depend on, MX records and so mail delivery, SSO and SAML metadata URLs, payment provider callbacks, monitoring checks, and, with grim regularity, the status page you were planning to update.

Why some users stay online and others see nothing

Resolver behaviour, not attack size, decides what your outage looks like from the outside. That is why the first twenty minutes of the incident call is usually spent arguing about whether there is an incident.

Anyone whose resolver fetched your A record ten minutes ago is still browsing happily until the time to live (TTL) expires. Anyone whose resolver missed is getting SERVFAIL. Negative caching under RFC 2308 keeps NXDOMAIN answers around for the lesser of the SOA minimum and the SOA record’s TTL, with the RFC recommending a cap of three hours, so a bad answer cached early can outlive the attack itself.

Stale-serving adds another layer of inconsistency. RFC 8767 (March 2020) permits resolvers to hand out expired records when the authoritative servers are unreachable, and software such as BIND and Unbound supports it as a configuration option. Some ISPs enable it. Plenty do not. Your customers in one region stay online for hours; your customers on a different network see nothing at all; your own office, whose resolver happens to have warm entries, insists everything is fine.

Third-party names drag you down too. If your checkout loads a payment script from a SaaS hostname whose provider is the one under attack, your zone resolves perfectly and your checkout still fails. Map those dependencies before you need them.

Ten minutes to a working diagnosis: provider, zone or you

Before anyone opens a ticket, establish which of three things is true: the provider’s network is failing, your zone data is wrong, or your delegation has gone.

1. Query every authoritative nameserver directly. dig @ns1.provider.net yourdomain.co.uk SOA +norecurse, then repeat for each NS in the set. All timing out points at the provider. Some answering and some not points at partial anycast failure, which is still the provider, but changes what you ask them.
2. Trace from the root. dig +trace yourdomain.co.uk shows whether the parent zone still delegates to the nameservers you expect. A delegation that has vanished is a registrar problem, not an attack.
3. Check the registration itself. Expiry date, registrar lock status, and whether a well-meant automated renewal failed. Domains still lapse. It looks exactly like an outage.
4. Validate DNSSEC. dig +dnssec against the provider, and compare the DS record at the parent with the current DNSKEY. An expired RRSIG or a rolled key with a stale DS produces SERVFAIL from every validating resolver while the provider’s network is entirely healthy.
5. Sample several vantage points. Public resolvers at 8.8.8.8, 1.1.1.1 and 9.9.9.9, plus a phone off Wi-Fi. Anycast means one vantage point tells you almost nothing about global reachability.

Rule out the self-inflicted causes first, because they mimic an attack and they are more common: a zone push that partially applied, a CI pipeline that overwrote the NS set, a CNAME added at the apex, a new provider onboarded but never added to the delegation.

When you escalate, ask closed questions. Which points of presence are affected, and are UK queries served from them? Is the target our zone or a co-tenant? What is the current query success rate by region? Should we prepare a delegation change, and will you support the transfer if we do? An honest provider will confirm within the first hour that they are under attack, even without a vector breakdown. Vague reassurance at hour two is itself information. Worth remembering: providers protect the estate, not the individual tenant. When EveryDNS suffered a sustained DDoS attack in 2010, the resolution was to stop serving the customer whose zone was attracting the traffic.

Dual-provider authoritative DNS: how it works and where it breaks

Two independent operators on one delegation is the only real answer to a provider-level flood. RFC 2182 has recommended diverse secondary nameservers, in different networks and topologies, since 1997. Resolvers already try every nameserver in the NS set, so if four of eight are unreachable, queries still get answered, more slowly.

Synchronisation comes down to two choices. A hidden primary distributing to both providers by AXFR and IXFR zone transfers keeps one source of truth and one place to make changes. API-driven pushes to both providers are easier to start with and drift silently the first time a deploy script only updates one side. Whichever you pick, monitor the SOA serial on both providers and alert when they diverge. That single check catches most of what goes wrong.

Two blockers get skipped in sales calls and discovered mid-incident.

DNSSEC is the first. Two providers each signing your zone with their own keys will produce answers the other cannot vouch for, and validating resolvers will return SERVFAIL. The fix is a multi-signer arrangement under RFC 8901, published in September 2020, where each provider serves the other’s zone-signing keys in the DNSKEY set. Both providers must support it. Many do not, or support it only on their higher tiers.

Vendor-specific record types are the second. ALIAS records, CNAME flattening at the apex, GeoDNS steering, weighted pools and health-check failover are proprietary. They do not replicate through a zone transfer, because they are not records in the standards sense. Failing over to a secondary that has no equivalent gives you a zone that resolves and an application that does not route.

Partial resilience still beats none. A warm secondary, loaded with a current zone and not in the live NS set, plus a written promotion runbook and registrar credentials that work, is a defensible position for a smaller estate. Test it quarterly. Discovering the registrar requires a fax during an outage is a genuine outcome.

Decisions to make before the outage, not during it

TTLs are the clearest example of a choice you cannot revisit once queries are failing. A 300-second TTL means most resolvers return within five minutes of mitigation and gives you almost no ride-through while the attack runs. An 86,400-second TTL keeps existing visitors resolving for a day, then delays any emergency nameserver change by the same day. Set them per record type: longer on NS and MX, moderate on stable A and AAAA, short only where you genuinely need agility, and document a lowering window (drop to 300 seconds at least a full old-TTL ahead) before any planned migration.

Three more decisions belong on the same page:

• Registrar account access, the NS change procedure and DNSSEC key material held by more than one named person, with multi-factor authentication that does not depend on an email address at the domain you may be about to lose.
• Status communications on a separate domain, at a separate DNS provider. Your status page on status.yourdomain.co.uk is decoration during this particular failure.
• A tested breakage order, ranked by revenue: checkout, API clients, mail, SSO. The incident call should prioritise by booked value per hour, not by whoever is loudest on the bridge.

While you have the zone open, audit it for origin exposure. Legacy A records, mail., vpn., dev. and old staging hostnames publish the addresses sitting behind your proxy. An attacker who cannot beat the reverse proxy will happily take the IP your own DNS handed them. It is the same blind spot as origin leakage, dressed differently.

Buying DNS resilience: the evidence to demand and the business case

Authoritative DNS is the surface most often left unmanaged. Teams buy a reverse proxy for the website, arrange BGP scrubbing for their prefixes, sign a sensible contract, and leave the zone on a bundled hosting or registrar nameserver with no capacity claim, no attack reporting and no escalation path. Read your contract and find the words. If the scope stops at your prefixes and HTTP, authoritative DNS is not covered, whatever the cover sheet says. Our guidance on the gaps that leave DNS exposed goes into the specific clauses worth checking.

Trace the resale chain. Several DNS and protection offerings are white-labelled or resold, so two providers can look independent on paper while sharing upstream transit, anycast footprint or scrubbing centres. Ask who owns the network, how many points of presence answer UK queries, and who is actually on the escalation bridge at 03:00. Those questions apply just as much when you are choosing a managed DDoS protection provider in the UK as when you are buying DNS.

Judge capacity claims on evidence, not adjectives: query-per-second headroom per point of presence, redacted post-incident reports from real events, and SLA credit mechanics set against your genuine cost per hour of downtime. Credits are usually a fraction of one month’s fee. Multiply your hourly revenue or booked value by a realistic four-hour DNS incident, compare that to the annual cost of a second authoritative provider, and the procurement case tends to write itself. Judging vendor claims properly is a discipline of its own, covered in our breakdown of how to test six common vendor claims.

One framing does not transfer. The always-on versus on-demand debate is about when you divert traffic into mitigation and how fast. Against a provider-level DNS flood there is nothing to divert and no time-to-mitigate you own. The capacity under pressure belongs to someone else. Delegation diversity across two genuinely independent operators is the equivalent control, and it is bought in advance or not at all.

Dyn remains the reference case for concentration risk. Three waves of attack traffic in October 2016, driven by Mirai-infected consumer devices, took well-engineered sites offline while their own infrastructure ran normally. Dyn’s own post-incident analysis, published within days, described tens of millions of discrete IP addresses associated with the botnet and pointedly declined to confirm the 1.2Tbps figure circulating in the press. The scale was never the lesson. The dependency was.

Frequently Asked Questions

Does a second DNS provider really help when one is under attack?

Yes, provided the two are genuinely independent and both are live in the NS set. Resolvers try each nameserver listed, so queries still resolve when half the set is unreachable, though users may see added latency. The benefit disappears if both providers share upstream transit, anycast infrastructure or the same parent company.

Will lowering TTLs protect my site during a DNS provider outage attack?

No, and it can make things worse. Short TTLs mean caches empty faster, so more users hit the failing authoritative servers sooner. Low TTLs help you move quickly during a planned migration or a nameserver change; longer TTLs give more ride-through during an outage. Either way, changing them after queries start failing has no effect, because the change has to propagate through the servers that are already unreachable.

Is authoritative DNS covered by a standard managed DDoS protection contract?

Often not. Many contracts scope cover to your IP prefixes and to HTTP traffic through a reverse proxy, which excludes a zone hosted on a third party’s nameservers entirely. Check the service description for an explicit reference to authoritative DNS, query-per-second protection and DNS-specific attack reporting, and treat silence as exclusion.

How long does recovery take once the DNS provider mitigates the attack?

Longer than the mitigation itself. Cached negative answers persist for their full negative TTL (capped under RFC 2308 guidance at three hours), resolution failures may be cached for up to five minutes under RFC 9520 guidance, and resolver retry backlogs take time to clear. Expect a tail of inconsistent user reports for a period roughly matching your negative caching settings, not a clean switch back on.

Can I run DNSSEC across two DNS providers?

Only with a multi-signer setup as described in RFC 8901, where each provider publishes the other’s zone-signing keys so answers from either validate correctly. Both providers must support the model and be willing to operate it together. Without it, one provider’s signed answers will be rejected as bogus by validating resolvers, which turns your resilience investment into an outage of its own.