Category Archives: DDoS Vendors

Authoritative DNS DDOS Protection: A Buyer's Guide

Authoritative DNS DDOS Protection: A Buyer’s Guide

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.



DNS DDOS Attack Protection: 6 Gaps to Close

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Always-On vs On-Demand DDOS Protection: Which Fits Your Traffic (and Budget)

A UK retail platform takes a two minute burst of junk traffic at 19:40 on a Friday, another at 19:52, another at 20:06, each one heavy enough to fill the transit link and drop checkout sessions, and by the time the on-call engineer has read the alert, opened a ticket and asked the provider to divert the prefix, the traffic has stopped again. Nothing to mitigate. The provider’s report the following week shows three mitigation events, total duration eleven minutes, all of them starting after the bursts ended. That is the always-on vs on-demand DDoS question in its real form, and it is not the abstract “always-on is faster, on-demand is cheaper”trade-off that most vendor comparisons stop at.

The useful question is not which model is better. It is which model belongs on each surface you are protecting, and who is contractually on the hook to pull the trigger at 03:00.

What Each Model Actually Does To Your Traffic

Always-on: permanently behind the mitigation layer

Always-on means your traffic never touches the origin directly. In practice that is one of two architectures. Either a reverse proxy sits in front of your web estate, with your public DNS records pointing at the provider’s anycast addresses and TLS terminated at their edge, or the provider permanently announces your IP prefix over Border Gateway Protocol (BGP) and returns clean traffic to you over a GRE tunnel or a private cross-connect. Detection and mitigation happen in the same path the packets already take, so the decision to act is a policy change, not a routing change.

On-demand: direct to origin until something triggers diversion

On-demand leaves traffic flowing straight to your network on normal days. When an attack is identified, the path changes: you announce your prefix to the scrubbing provider (or ask them to announce it), or you update DNS records to point at their proxy, or you phone their security operations centre and ask them to do it. Clean traffic then comes back to you. The mitigation itself is usually identical to the always-on service. What differs is everything that has to happen before the first packet reaches a scrubber.

On-demand is not one product, and this is where buyers get caught

Three quite different things are sold under the same label:

  • Customer-triggered diversion. You notice, you decide, you call or click. Response time is your response time, plus propagation.
  • Provider-triggered diversion. Their SOC watches your links and acts under an agreed authority. Faster, but only if the authority is written down and does not require your sign-off per event.
  • Flow-monitored auto-diversion. NetFlow, sFlow or IPFIX exported from your border routers feeds a detector that announces the prefix automatically once thresholds trip. Fastest of the three, and the only one that has a chance against short attacks.

Flow-based detection has a floor built into it. Flow records are sampled and exported on a timer, commonly in the tens of seconds, and the detector then needs several intervals to distinguish an attack from a traffic spike. That floor is a property of the telemetry, not of the vendor’s marketing.

Where hybrid genuinely fits

“Hybrid”almost always means an on-premises mitigation appliance handling smaller floods locally, with a signalling channel to a cloud scrubbing centre when the attack exceeds your transit capacity. It suits organisations with their own address space, their own routers, staff who understand BGP, and a real reason to keep inspection on site (regulated traffic, latency-sensitive protocols, private interconnects). If you do not have engineers who can tune an appliance, a hybrid deployment becomes an expensive box that alerts.

Time To Mitigate: The Timeline Nobody Puts In The Sales Deck

Four gaps, not one

An on-demand response has four separate delays, and the marketing figure usually covers only the last one. Attack onset to detection. Detection to human decision. Decision to route change. Route change to stable sessions, because TCP connections and TLS handshakes have to re-establish through a new path.

The human decision step is the one vendors rarely quantify, and it is often the whole outage. Ask exactly where the SLA clock starts: at attack onset, at detection, or at the moment diversion is authorised. A promise of “mitigation within 15 minutes”measured from authorisation tells you nothing about how long authorisation takes at 02:30 on a bank holiday.

BGP minutes versus DNS TTL hostage-taking

BGP diversion is quick by internet standards and slow by attack standards. A new announcement propagates across the global routing table in minutes, subject to route dampening, upstream filtering and prefix-length policies (many networks will not accept anything longer than a /24, which quietly rules out diverting a single address).

DNS-based diversion is worse, and less predictable. Redirecting a hostname to a scrubbing proxy is limited by the record’s time to live, and by resolvers, application runtimes and browsers that cache well beyond it. Java’s default DNS caching behaviour has caught out more than one API integration. If DNS is your diversion mechanism, lower the TTLs on the relevant records now, while nothing is on fire, and accept that a stubborn tail of clients will keep hitting the old address for hours.

Where always-on wins outright

Short, repeated bursts. Imperva’s researchers labelled the pattern “pulse wave”DDoS in 2017 research, and it is designed precisely to defeat the on-demand cycle: bursts of a few minutes, gaps between them, no single event lasting long enough for detection, authorisation and propagation to complete. Against that pattern an on-demand layer never carries the attack traffic at all. It just documents it afterwards.

The Always-On vs On-Demand Decision Changes By Surface

Network and transport

Volumetric floods against a whole prefix, UDP reflection and amplification, SYN floods, garbage to random ports. This is the one place where on-demand BGP scrubbing is genuinely defensible: you own the address space, you have flow monitoring on the border, thresholds are tuned, and the traffic profile is stable enough that a real attack looks nothing like a busy Tuesday. If your addresses come from your hosting provider and you cannot announce them yourself, on-demand BGP is not available to you regardless of what the quote says.

Application layer

HTTP request floods, cache-busting query strings, credential-stuffing patterns from residential proxy pools. These attacks rarely move enough bits to trip a volumetric threshold, and they are frequently indistinguishable from a marketing email landing, which is exactly why on-demand detection handles them badly. Layer 7 mitigation also depends on state the provider has to build over time: request baselines, cookie and JavaScript challenge behaviour, bot classification, rate-limit tuning per endpoint. None of that exists if the proxy only sees your traffic during incidents. For web and API estates, always-on reverse proxy is normally the only honest answer.

Authoritative DNS

Authoritative DNS breaks the framing entirely. There is nothing to divert once resolution is already failing, because the diversion instruction is itself a DNS change that nobody can look up. The surface is either permanently hardened or it is not: anycast across multiple networks, several nameservers in different ASNs, response rate limiting, and a provider whose capacity you have actually asked about.

It is also the surface UK buyers most often leave on whatever their hosting or domain bundle included, while paying separately for network and application protection. An always-on proxy in front of the website does not help when the zone that resolves the hostname goes dark. Check who is authoritative for your domains today, then check whether that arrangement was a decision or an accident.

A mixed estate, sensibly split

A realistic answer for a mid-sized UK platform: always-on reverse proxy for the public web and API hostnames, on-demand BGP scrubbing for the wider /24 if you own it and have flow monitoring, permanently hardened anycast DNS with a specialist, and origin ranges locked so nothing reaches them except the proxy. Single-model decisions across a mixed estate are where buyers manage to overpay and stay exposed at the same time. Our comparison of how to judge vendor claims against real attacks goes further into the questions each surface demands.

Why Always-On Still Fails: Origin IP Leakage

Proxy bypass can cause more downtime than capacity exhaustion. The mechanism is dull: the attacker finds your real origin address and sends traffic straight to it, and the always-on layer you are paying for never sees a packet. Capacity is irrelevant when the traffic is not in the path.

Where origins leak

  • Outbound mail headers. Transactional email sent from the application server stamps its address in Received headers. Trigger a password reset, read the headers.
  • Historical DNS records. Passive DNS databases keep what your A records pointed at before onboarding, sometimes for years.
  • Certificate transparency logs. Every publicly trusted certificate is logged under the framework described in RFC 6962, so staging, admin and internal hostnames you never advertised are searchable.
  • Forgotten subdomains. vpn., mail., legacy., dev., cpanel., monitoring. Pointing straight at the origin because proxying them broke something once.
  • Direct-connect endpoints. Partner API integrations and payment callbacks whitelisted by IP address, bypassing the proxy by design.

The lockdown list

Onboarding that stops at “change your DNS records”leaves the subscription decorative. What it should include: origin firewall or security group rules that accept HTTP and HTTPS only from the provider’s published ranges; re-addressing the origin after cutover, because a leaked address is leaked permanently; authenticated origin pulls (client certificates or a shared secret header) so that anyone who does find the address still cannot get a response; outbound mail moved to a separate relay; and an inventory of every hostname in the zone with a decision recorded for each one. An always-on subscription with a leaked origin performs worse than a well-drilled on-demand setup, because it also gives you false confidence.

Cost, Latency And What You Are Really Buying

How UK pricing tends to be structured

Quotes usually price on a clean traffic commitment (megabits or gigabits of legitimate throughput, billed monthly, with overage), plus a count of protected prefixes or hostnames, plus service elements: onboarding and rule tuning, baselining, named escalation contacts. Always-on is typically a flat subscription. On-demand is typically a lower retainer with per-event mitigation charges. Figures move, so treat any number in a deck as current only on the day it was issued.

The costs on-demand contracts bury

Per-event fees are the visible one. The expensive ones are the minimum diversion windows, frequently measured in hours or even days rather than minutes, which means a two minute burst can bill as a day of scrubbing and can also hold your prefix on the scrubbing path (with its added latency) long after the attack ends. Then out-of-hours escalation charges. Then the cost of your own people. Our guide to managed DDoS protection pricing in the UK sets out what those service lines usually contain.

Latency and point-of-presence coverage

Always-on proxying adds a hop and terminates TLS away from your origin. For a UK audience served from a UK or Northern European point of presence, the added round trip is small and often offset by edge caching and connection reuse. For a provider whose nearest PoP to your users is in Amsterdam or Frankfurt while your customers are in Leeds, it is not. Ask for the PoP list and peering arrangements relevant to your traffic, not the headline aggregate capacity figure. Aggregate terabits tell you what the network can absorb globally; they say nothing about where your packets go on a Tuesday.

Build the case on downtime cost, not fear

Work it from your own numbers. The figures that follow are a worked illustration with round numbers rather than survey data, so substitute your own: an ecommerce operation turning over £30,000 in a trading hour would put £120,000 of gross revenue at risk in a four hour outage, of which perhaps a third is contribution margin, so call it £40,000 of real loss, plus service credits owed to your own B2B customers under their contracts, plus six engineers and a comms lead working through the night, plus whatever the abandoned baskets never come back as. Set that against the annual premium of always-on over on-demand in the two quotes on your desk. If the premium is smaller than a single plausible incident, the finance conversation is short.

How To Choose, And What To Ask Before You Sign

A short decision path

  1. Revenue or safety exposure per hour of downtime. High, and always-on for the web estate stops being a debate.
  2. Attack history. Repeated short bursts, or extortion notes? Always-on. One volumetric event in five years against a prefix you control? On-demand BGP is arguable.
  3. Address ownership. No portable prefix, no BGP option.
  4. Staffing. No 24/7 rota with authority to trigger diversion, no viable customer-triggered on-demand.

Establish who actually owns the scrubbing capacity

Many UK offerings are resold, sometimes twice, and the chain often ends at a small number of underlying scrubbing networks. Consolidation has been running for years; Akamai’s acquisition of Prolexic, which we covered at the time, is one of the reasons the list of genuinely independent scrubbing platforms is shorter than the list of logos. Ask three plain questions: whose network scrubs the traffic, what your reseller can change without raising a ticket upstream, and whether the same underlying platform sits behind the “second opinion”quote you obtained for comparison.

Evidence, not the deck

Ask for a redacted post-attack report from a real customer incident, with vector breakdown and timestamps for onset, detection and mitigation. Ask for records of diversion drills, including the last date one was run. Ask for the escalation matrix with named roles, and ask who acts at 03:00 on a Sunday without waiting for your authorisation. The NCSC’s guidance on denial of service attacks is a reasonable neutral yardstick for the preparation questions a supplier should be able to answer without hesitation. If you are still shortlisting, our notes on choosing between mitigation providers and their trade-offs cover the rest.

One thing to hold firm on. On-demand only works if a named human is genuinely on the hook to trigger it. If the “managed”scope in the contract stops at a support inbox and business-hours monitoring, you have bought an on-demand product with an office-hours response, which is the worst possible combination for pulse attacks and ransom campaigns that deliberately start out of hours. Decide always-on vs on-demand DDoS protection surface by surface, insist on origin lockdown as part of onboarding, and read the SLA for where the clock starts before anyone signs.

Frequently Asked Questions

Is always-on DDoS protection always faster than on-demand?

For time to mitigate, yes, because the traffic is already in the mitigation path and there is no detection, authorisation or routing delay to absorb. The advantage disappears if your origin address has leaked and attackers can bypass the proxy entirely. A well-instrumented on-demand setup with automatic flow-triggered diversion beats a badly onboarded always-on subscription.

How long does on-demand DDoS mitigation take to activate?

Add four intervals: detection (sampled flow telemetry usually needs tens of seconds to a few minutes), human authorisation, route propagation, and session re-establishment. BGP diversion propagates in minutes; DNS-based diversion is limited by record TTL and by caching resolvers that ignore it. Ask each provider where their SLA clock starts, because that single definition can differ by the length of your whole outage.

Does always-on DDoS protection add latency to my site?

It adds a network hop and moves TLS termination to the provider’s edge, so there is measurable overhead. With a point of presence close to your users, edge caching and connection reuse frequently offset it, and some sites get faster. Ask for the PoP locations and peering relevant to your actual audience rather than relying on global capacity figures.

Can I use always-on for web traffic and on-demand for network protection?

That combination is the sensible default for a mixed estate: always-on reverse proxy for public web and API hostnames, on-demand BGP scrubbing for the wider prefix if you own the address space and export flow data. It only holds together if the origin accepts traffic solely from the proxy ranges and someone is contractually responsible for triggering the BGP diversion out of hours.

Which model is better for protecting authoritative DNS?

Neither, as the question is normally framed. Once resolution is failing there is nothing left to divert, so DNS has to be permanently hardened: anycast, nameservers spread across separate networks and ASNs, response rate limiting, and a provider you have actually questioned about capacity. Check who is authoritative for your domains before you renew anything else.



DDOS Time to Mitigate: What SLA Seconds Really Mean (And How to Verify Them)

A head of IT signs a mitigation contract with a 60 second time-to-mitigate figure on the front page, files it, and thinks the problem is handled. Eight months later the checkout page stalls for a quarter of an hour on a Friday evening, the provider’s portal eventually logs the event as mitigated, and the post-incident review finds no breach of contract anywhere. Both things are true. Understanding why is the whole point of reading a DDoS time to mitigate clause properly, because the figure vendors publish almost never covers the part of the attack that actually hurt you.

Time to mitigate, in plain terms, is the interval between a distributed denial-of-service (DDoS) attack affecting your service and countermeasures bringing traffic back to something usable. That definition sounds tight. In practice, every provider draws the start and end lines in a different place, and the wording in the service level agreement (SLA) is where the difference lives.

What time to mitigate actually measures, and where the clock starts

An attack does not go from launch to blocked in one step. The chain runs roughly: the attack begins; telemetry (flow records, proxy logs, appliance counters) crosses a threshold; a detection alert fires; someone or something decides to act; traffic is diverted or filtered; routes converge and the return path carries clean traffic; and finally countermeasures are tuned to the specific vector, whether that is a UDP reflection flood or an HTTP GET flood against a search endpoint.

Most published figures cover the last stretch only. They measure the automated countermeasure stage, applied to traffic that is already inside the scrubbing path. Detection thresholds, human authorisation and Border Gateway Protocol (BGP) convergence on an on-demand service sit outside the measured window. A 60 second SLA and a fifteen minute outage coexist comfortably.

Two acronyms get quoted interchangeably and should not be. Mean time to detect (MTTD) is how long the provider’s systems take to notice. Mean time to mitigate (MTTM) is how long countermeasures take once triggered. Vendors quote whichever flatters the product: an always-on proxy vendor happily quotes near-zero mitigation time because traffic is already in path, while an on-demand scrubbing vendor prefers to talk about detection speed and stays quiet about diversion.

Three questions belong in writing before signature, not in a kick-off call afterwards:

  • Does the clock start at attack onset, at detection by the provider’s monitoring, or at the moment your named contact raises a ticket? The third option is common and is by far the weakest for you.
  • What counts as the finish line: first countermeasure applied, or measured service restoration against a defined availability target?
  • Who supplies the timestamps used to judge compliance, and are those timestamps from the provider’s own systems only?

Define your own finish line separately for internal reporting. Mitigation started is a vendor milestone. Checkout completing inside two seconds again is your milestone. Track both, because the gap between them is the number your board will ask about.

Always-on versus on-demand: the real trade-off

Always-on reverse proxy

Traffic already traverses the scrubbing estate, so for in-scope traffic mitigation is effectively immediate. Nothing has to be switched on. The costs are real though: added latency on every request, Transport Layer Security (TLS) termination at the provider (which means handing over private keys or using a provider-managed certificate), and a hard dependency on your origin addressing staying hidden.

On-demand BGP scrubbing

Here the diversion itself is the delay. An illustrative but realistic sequence: detection threshold breached at T+2 minutes, human authorisation obtained at T+5, the more-specific prefix announced at T+6, then global BGP convergence taking a few more minutes as peers accept the change. Clean traffic starts flowing well after the “five minute mitigation”figure on the datasheet, and none of it is a breach.

The second cost nobody times in a demo is the return path. Generic Routing Encapsulation (GRE) tunnels or cross-connects have to be built, tested and kept warm. A return path that has not been exercised in twelve months is where the real delay appears, usually accompanied by a maximum transmission unit (MTU) problem that only shows up under load.

Hosting-level filtering

Included platform protection is fast against volumetric floods, because the hosting provider is defending shared infrastructure and has every incentive to act. The mechanism matters. Many platforms “mitigate”by null-routing the targeted IP address at the edge, which protects the platform and every other tenant on it. From your seat it is indistinguishable from being taken offline. The contract language to hunt for is whether blackholing counts as mitigation for SLA purposes. If it does, the response time figure tells you almost nothing about your own availability.

Hybrid patterns

A common UK arrangement puts always-on proxy protection in front of the web estate and keeps on-demand BGP diversion in reserve for the wider prefix. Sound design. The handoff is where minutes leak away, because someone has to recognise that the attack has moved off the proxied hostnames and onto the network itself, then authorise a routing change. Rehearse that decision. Write down who makes it.

Three surfaces, three different clocks

Network and transport floods

Volumetric and protocol attacks (SYN floods, DNS and NTP reflection, carpet-bombing across a prefix) are high-volume and high-signal. Detection is straightforward, signatures are well understood, and automated countermeasures do most of the work. This is the surface the published time-to-mitigate figure was written for, and the one place it usually holds up.

Application layer

Low-rate HTTP floods are the awkward case. Consider an ecommerce checkout during peak trading, hit by a few thousand well-formed requests per second spread across residential proxies, each one hitting a database-heavy search or basket endpoint. Bandwidth looks normal. Volumetric thresholds never trigger. Mitigation depends on someone identifying a request signature (a header order, a JA3 fingerprint, a URL pattern, a behavioural anomaly against baseline) and writing a rule against it. That is a human timescale, and it is why the headline SLA rarely applies as advertised at layer 7. Ask specifically what the response commitment is for application-layer events, and whether it differs from the network figure. It nearly always does.

Authoritative DNS

Authoritative Domain Name System (DNS) service is the surface most commonly left outside the managed contract in UK buys. Buyers assume proxy protection covers name resolution. It does not, unless the contract says so. If your authoritative DNS sits with a separate registrar, an on-premises BIND pair, or a hosting control panel with no dedicated DNS DDoS attack protection, there is no time to mitigate at all. There is just an outage, and it takes every service down at once: web, mail, VPN, SaaS single sign-on, monitoring.

Options exist for organisations that cannot simply move zones to a large anycast platform. Akamai’s Shield NS53, for example, is designed to sit in front of on-premises and hybrid authoritative name servers rather than only the web tier. Whatever the choice, map every surface to a named owner, a named product and a named response time before anything goes wrong. Three columns on one page. If a row is blank, that is your next purchase order, and the same discipline applies whether you are comparing platforms or reading a vendor claim against how real attacks behave.

Why fast mitigation still fails: origin leakage and scope gaps

Origin IP leakage defeats a fast SLA more often than attack size does. Historical DNS records cached in passive DNS databases, mail servers sitting on the same range as the web origin, certificate transparency logs listing every hostname you have ever requested a certificate for, staging and legacy subdomains left unproxied, direct-connect API endpoints for partner integrations: any one of them hands an attacker a path straight to the origin.

When traffic reaches the origin directly, the provider’s clock never starts. Their proxy saw nothing. A sub-minute mitigation commitment on the proxy is worth precisely nothing in that scenario, and the provider is not in breach.

Other assets routinely fall outside scope entirely: VPN concentrators, SIP trunks and voice gateways, SMTP inbound, third-party APIs your application calls synchronously, and CDN origin pull addresses. Practical hardening is unglamorous and effective: firewall the origin so it accepts traffic only from the provider’s published address ranges, rotate origin addressing after onboarding so the pre-contract history is stale, and re-test scope after every migration, DNS change or new subdomain. The scope of protection drifts quietly. Attacks find the drift.

How to verify a time-to-mitigate claim before you sign

Datasheets are not evidence. Post-attack reports are. Ask for two or three real incident reports, redacted as needed, and read the timestamps rather than the headline scrubbing capacity in terabits per second. What you want to see: attack start, first alert, authorisation, first countermeasure, vector breakdown, and the point at which traffic profile returned to baseline. A provider who cannot produce that from real events, in a format you can read, is telling you something.

Then trace the resale chain. Whose network, whose scrubbing centres, whose engineers are on the clock at 03:00? A reseller cannot be faster than its upstream. Plenty of competent UK managed service providers sit on top of Akamai Prolexic, Cloudflare, Imperva or a carrier scrubbing platform, and that is a perfectly reasonable model, but it changes what the SLA means and where escalation actually goes. Asking is procurement hygiene, not an accusation. This site has covered the industry consolidation behind that pattern since Akamai’s acquisition of Prolexic.

Test the escalation path before you need it. A named out-of-hours contact, a phone number that a human answers, and a call drill during the trial period. Decide in advance who on your side is authorised to trigger diversion at 03:00, and what happens when that person is on a flight. Pre-authorisation for automatic diversion, within agreed limits, removes the single largest human delay in the chain.

Read the credit mechanics last and without optimism. Look at exclusions, the measurement window, whose data counts as evidence, and the claim deadline. A credit worth one month of fees rarely covers an hour of lost trading, and it is not a substitute for the technical controls. The credit is a footnote in a board pack. The outage is the meeting.

Turning minutes into money

Build the business case from cost per minute of downtime, not from vendor pricing. Transaction volume at peak multiplied by average order value, staff idle cost across the affected teams, contractual penalties you owe your own customers, and recovery effort including incident overtime and customer communications. Once that number exists, the price gap between an on-demand tier and an always-on tier usually resolves itself in one direction, and the conversation with finance gets shorter. Our guidance on managed DDoS protection in the UK, including what the tiers actually cost, sets out where those price bands typically sit, and the faster tier mostly buys the removal of the human authorisation step and the diversion delay, not better filtering.

Stakes vary by sector, and so should the design. An ecommerce checkout flood on Black Friday is a revenue event measured in minutes. Healthcare and public sector disruption is a service and reputational event with regulatory attention attached. A DNS outage is the worst case, because everything stops simultaneously and your status page is often unreachable too. Aviation offers a useful case study in interlinked dependencies, which the analysis of a DDoS attack against airline systems works through in more detail.

One attacker behaviour makes response speed strategic rather than merely operational. Ransom DDoS follows a pattern: a short demonstration burst of a few minutes against a public-facing site, then an email demand and a threat of something longer. A slow, visible first response tells the sender the target is worth returning to. Both the NCSC’s denial of service guidance for UK organisations and CISA’s joint guidance for defenders advise against paying and in favour of prepared, rehearsed response. Preparation is what makes the first response quiet.

The honest position on DDoS time to mitigate is this: treat the datasheet number as the vendor’s best case for the easiest surface, then spend your procurement effort on the parts it excludes. Where the clock starts, what happens to layer 7, who protects your authoritative DNS, and whether your origin is genuinely unreachable. Those four answers determine your real recovery time. The number on the front page does not.

Frequently Asked Questions

What is a good DDoS time to mitigate?

For network and transport-layer floods on an always-on service, effectively immediate is achievable because traffic is already in the filtering path, and commitments in the tens of seconds are common. For on-demand BGP diversion, anything under about ten minutes end to end including convergence is respectable. Layer 7 events are slower and should carry their own separate commitment. Judge the figure by what it includes, not by how small it is.

Does time to mitigate start when the attack begins or when it is detected?

That depends entirely on contract wording, and it is the single most valuable clause to negotiate. Many SLAs start the clock at detection by the provider’s systems, some at the point you open a ticket, and very few at attack onset. Get the definition in writing along with confirmation of whose timestamps are used to measure compliance.

Why is application layer DDoS mitigation slower than network layer mitigation?

Low-rate HTTP floods look like legitimate users. Bandwidth stays normal, so volumetric thresholds never fire, and separating attack requests from real traffic usually requires identifying a signature or behavioural pattern and writing a rule against it. Automated bot management helps, but the difficult cases still involve an engineer, which is a human timescale rather than a machine one.

How much slower is on-demand BGP scrubbing than always-on protection?

The gap is the sum of detection threshold, authorisation and route convergence. Working through a typical sequence, detection at a couple of minutes, human sign-off a few minutes later, then announcement and global BGP convergence, you are realistically looking at several minutes to low double digits before clean traffic flows. Always-on removes all of it for in-scope traffic. An untested GRE return path can add considerably more.

What evidence should I ask a provider for to check their mitigation times?

Redacted post-attack reports from real incidents with full timestamps, a written definition of clock start and finish, confirmation of whose scrubbing centres and network operations centre sit behind the badge, and a live out-of-hours call drill during the trial. Comparing that evidence across shortlisted suppliers, as set out in this guide to choosing between mitigation providers and their trade-offs, tells you more than any capacity figure.



DDoS Protection Service Comparison: How To Judge 6 Vendor Claims Against Real Attacks

Most buyers start a DDoS protection service comparison by asking vendors for a feature matrix, then discover that every matrix looks the same. Everyone claims multi-terabit capacity, sub-minute mitigation and layer 7 defence. The differences that decide whether your checkout stays up on a Friday afternoon are rarely in the datasheet at all: they sit in the protection model you buy, the assets that model can physically cover, and the contract clauses that govern what happens in hour 40 of a sustained attack.

This piece compares protection models rather than brand names, tests each model against attack patterns that have actually played out in the wild, and gives you a scoring framework you can run over a shortlist inside a week.

What you are actually comparing: five protection models, not five brands

Vendor names change ownership. Models do not. There are five ways DDoS traffic gets stopped before it reaches your infrastructure, and each has hard limits on what it can protect.

Always-on CDN or reverse proxy

Cloudflare, Fastly and Akamai sit in front of your web estate permanently. DNS points at their edge, they terminate TLS, they filter, and they forward clean requests to your origin. Strong for HTTP/S, strong for layer 7 rules and bot management, and mitigation is effectively instant because traffic never routes to you in the first place. The constraint is protocol: anything that is not web traffic needs a different answer, and your origin IP must be genuinely hidden for the model to hold.

On-demand or always-on BGP scrubbing

You advertise your own prefixes, and when an attack starts, routes are diverted to a scrubbing centre via BGP, with clean traffic returned over GRE tunnels or a dedicated connection. This protects entire /24s and everything inside them: mail, VPN concentrators, SIP and RTP for voice, game servers, database replication, odd-port APIs. The trade-offs are diversion time (minutes, not milliseconds, unless you run it always-on) and the requirement that you own routable address space and can influence BGP announcements.

On-premise appliance

A hardware or virtual appliance at your network edge, inspecting traffic with full visibility of your applications. Excellent for low-and-slow layer 7 detection and for state-based attacks, useless against a volumetric flood that saturates your upstream transit before packets ever reach the box. Appliances belong in hybrid designs, paired with cloud capacity that can be signalled when the pipe fills.

Hosting or data-centre level protection

Included filtering from your hosting provider, colocation facility or ISP. It is usually shared, usually tuned to protect the provider’s network rather than your specific application, and often carries a null-route policy: if your IP attracts enough traffic to threaten neighbours, it gets black-holed. That is protection for the data centre, not for you. Providers have been rolling out this tier for well over a decade, including data centre operators adding anti-DDoS as a standard facility service, and it has real value as a baseline. Treat it as a floor, not a ceiling.

DNS-layer defence

Authoritative DNS hosted on an anycast platform built to absorb query floods, or a hybrid arrangement that shields on-premise name servers behind a cloud tier (Akamai’s Shield NS53 is the reference implementation of that pattern). Ignored in most comparisons, and the fastest route to a total outage when it fails.

Mature setups are hybrids: proxy for web, scrubbing for the rest of the address space, hardened or dual-provider DNS, and an appliance where deep application visibility is needed. Managed DDoS protection in the UK is often delivered through this stack by an MSSP rather than direct, which is a model that has existed since vendors first built managed security service partner programmes around mitigation appliances. The partnership layer matters, because the party you phone at 3am may not be the party operating the scrubbing centre.

One check before you read any older comparison

The mitigation market has consolidated across generations. Prolexic’s scrubbing network now operates inside Akamai. IntruGuard’s technology was absorbed into Fortinet’s DDoS appliance line. Webscreen and netZentry were once fixtures on procurement shortlists and no longer exist as independent vendors. If you are working from a comparison written a few years ago, verify what the current entity actually operates today before you weight it.

The metrics vendors advertise, and the ones that decide your outcome

Advertised network capacity in Tbps tells you what the platform can absorb globally, across every customer, during the worst simultaneous event of the year. What matters to you is capacity and points of presence near your users. A 100Tbps global network with thin capacity in London and Manchester is worse for a UK retailer than a smaller network with dense European presence.

Time to mitigate is the metric most often quoted and most loosely defined. Ask what the clock measures. Detection? Route diversion complete? Or clean traffic restored to the customer? Ask whether mitigation is fully automated or requires a human in a NOC to approve a signature change, and what the escalation looks like at 02:00 on a bank holiday. An automated seconds-level response on a known attack vector is a different product from a 15-minute human-in-the-loop diversion, even when both appear in the same SLA table.

False positive rate is the metric nobody publishes. Aggressive challenge pages, JavaScript checks and CAPTCHA friction will protect your infrastructure and damage your conversion rate at the same time. During evaluation, ask for the tuning process: how quickly can a rule be relaxed, who can do it, and can you see the block decisions in your own logs?

Then separate the two attack classes properly. Layer 3/4 volumetric floods, reflection and amplification are a bandwidth and packets-per-second problem. Layer 7 request floods, credential stuffing and scraping are a request-economics problem, and they frequently sit inside your normal traffic envelope. A vendor scored purely on scrubbing capacity can win your comparison and still fail the incident.

Comparing providers against real attack patterns, not datasheets

DNS as the single point of failure

The clearest test in any comparison is what happens when the attack is not aimed at you. The October 2016 attacks on Dyn’s managed DNS infrastructure, driven by Mirai botnet traffic, took large numbers of unrelated customer sites offline simultaneously. Those sites were not attacked. Their web protection worked perfectly. They were unreachable because name resolution failed. Botnet-scale capacity of that kind has been a policy concern for years, with coordinated industry plans to reduce botnet activity running alongside enforcement work.

Which models survive it? An always-on proxy does not help if the DNS answering for your proxy hostname is down. Scrubbing does not help either. The only defences are DNS resilience by design: two independent authoritative DNS providers serving the same zone, or a hybrid arrangement shielding your own name servers behind cloud capacity. Put DNS resilience in the scoring grid as a weighted row, not a footnote.

Ransom DDoS with a deadline

The pattern is consistent: a 15 to 30 minute demonstration attack against a payment or checkout endpoint, followed by a note naming a cryptocurrency figure and a deadline measured in hours. Extortion has followed DDoS capability for as long as the technique has existed, and prosecutions do happen, as the jailing of Russian cyber-blackmailers who extorted UK bookmakers showed.

Now walk each model through that window. An existing always-on proxy needs a rule change and possibly a plan upgrade. Existing scrubbing needs a diversion request. If you have neither, you are onboarding a new provider under duress: DNS changes propagating against whatever TTL you set months ago, or a BGP announcement and tunnel build with an emergency onboarding fee attached. That is the moment long minimum terms get signed. Pre-agreeing an emergency onboarding path, with pricing, contacts and a tested runbook, costs far less than negotiating mid-attack. CISA, the FBI and MS-ISAC set out the reporting and non-payment position in their joint guidance, Understanding and Responding to Distributed Denial-of-Service Attacks (2024).

Hacktivist floods against public sector estates

In March 2024 the French Prime Minister’s office confirmed that multiple government websites had been hit by sustained DDoS attacks of what it described as unprecedented intensity, attributed publicly to hacktivist activity. Attention, not money, is the motive, which changes the profile: multiple targets across an estate, sustained over days, shifting vectors when one is blocked. Public sector buyers should test breadth of coverage across many small properties rather than depth on one flagship site, and should ask how billing behaves when 40 domains are simultaneously under load. Attackers pick symbolic targets, which is why even institutions with no commercial value get hit, as when a coordinated flood against the Vatican’s website failed to take it down.

Application-layer bot abuse on checkout and login

Credential stuffing against a login endpoint and inventory-hoarding bots on a checkout flow rarely register as bandwidth spikes. Requests are well-formed, come from residential proxy pools, and rotate user agents. Volumetric scrubbing will pass this traffic straight through. What stops it is bot management: device fingerprinting, behavioural scoring, rate limiting per credential rather than per IP, and the ability to serve a soft challenge to suspicious sessions without blocking genuine customers. Financial services have carried this load for years, from bank platforms knocked offline by flooding to the botnet operators behind the traffic being named and pursued.

Contract terms, pricing models and the clauses buyers regret

Pricing generally follows one of three shapes: pay-as-you-go clean bandwidth, flat-rate unmetered mitigation, or a committed tier with burst charges above it. Model the third one against a 72-hour attack before you sign. Ask explicitly whether overage is billed on clean traffic delivered to you or on total traffic absorbed, because the difference across three days of a large flood can be substantial.

Then read the definitions clause. What counts as an attack? Some agreements only trigger SLA obligations above a stated packets-per-second or bandwidth threshold, which conveniently excludes exactly the layer 7 events that hurt e-commerce. Check whether SLA remedies are service credits (a discount on a bill) or an actual time-to-mitigate commitment with a measurable start point.

Finally, run an asset coverage audit before you compare anything. List every internet-facing service: web, APIs on non-standard ports, SMTP and mail gateways, VPN and remote access, DNS, FTP or SFTP transfer endpoints, legacy IP ranges from acquisitions, staging and CI environments. Mark which model can protect each one. This is where most comparisons quietly fail, because the shortlist was built around web traffic and the estate is not.

A scoring framework you can run on a shortlist in a week

Weight the rows to your own risk, then score each shortlisted provider from 1 to 5. Suggested starting weights:

  • Asset inventory coverage (25%): percentage of your listed internet-facing services the provider can actually protect under the proposed design.
  • Layer 7 and bot handling (20%): rule granularity, bot scoring, rate limiting by credential or session, tuning turnaround.
  • Time to mitigate (15%): defined start point, automation level, out-of-hours escalation.
  • DNS resilience (10%): anycast authoritative DNS, secondary provider support, on-premise shielding options.
  • Reporting and forensics (10%): post-incident reports you can hand to a regulator or board, log export to your SIEM.
  • Escalation route (10%): named contacts, who can trigger mitigation at 3am, whether the MSSP or the platform owner answers.
  • Cost predictability under a 72-hour sustained attack (10%): modelled, in writing.

Demand proof rather than claims. Ask for an authorised load or attack simulation against a staging environment, with written permission from both parties. Ask for two reference calls in your own sector, not a logo wall. Ask for a redacted attack report from a real incident, which tells you more about reporting quality than any sample dashboard.

Sector weighting matters. Banks and payment operators should weight escalation and forensics higher, given operational resilience expectations. Healthcare and other essential service operators carry availability duties under the NIS Regulations, and availability sits inside the security obligations of UK GDPR. E-commerce should weight bot handling and cost predictability, with PCI DSS considerations for the checkout path. Legal firms usually weight confidentiality of traffic inspection and TLS key handling. For a broader view of the defensive options behind these scores, our overview of DDoS attacks and the possible solutions available covers the underlying techniques.

Migration and operational traps that neutralise good protection

The most common failure in this field is scope, not capacity. An organisation puts its web estate behind a proxy, leaves mail, VPN and an API on port 8443 outside it, and then finds the origin IP is still discoverable. Check DNS history archives, MX records that point straight at your network, certificate transparency logs (which publish every hostname you have ever requested a certificate for), and forgotten staging subdomains. Attackers query those sources first.

After cutover, lock the origin firewall to the provider’s published IP ranges. Skipping this step leaves a direct path around every control you just bought. Keep the outgoing provider live in parallel for a defined window, lower DNS TTLs well before the migration date so you can move quickly, and rehearse a failover during business hours rather than discovering the gaps during an incident.

Align the runbook with published guidance. The NCSC’s denial of service guidance collection covers preparation and response for UK organisations, and the CISA joint guide sets out reporting expectations. On the legal position, denial-of-service attacks are criminal offences in the UK under the Computer Misuse Act 1990, following the amendments made by the Police and Justice Act 2006 that put unauthorised acts impairing the operation of a computer beyond doubt. Report incidents; do not pay ransoms; and note that UK police forces have been building specialist e-crime capability for years, including dedicated regional e-crime units.

Run the comparison this way and it stops being a datasheet exercise. A useful DDoS protection service comparison ends with a scored grid tied to your own asset inventory, a modelled cost for a three-day attack, a tested emergency onboarding path, and DNS resilience treated as its own line item rather than an assumption.

Frequently Asked Questions

What should a DDoS protection service comparison actually measure?

Coverage of your real asset inventory first, then layer 7 and bot capability, defined time to mitigate, DNS resilience, reporting quality, escalation route and cost predictability during a long attack. Advertised network capacity in Tbps is a weak differentiator on its own, because it describes the platform’s global ceiling rather than what it will do for your specific traffic mix.

Is an always-on CDN proxy better than on-demand BGP scrubbing?

Neither is better in the abstract. A proxy gives near-instant mitigation and strong application-layer controls, but only for HTTP/S traffic, and only while your origin IP stays hidden. BGP scrubbing protects whole prefixes including mail, VPN, voice and non-standard ports, at the cost of diversion time unless you run it always-on. Most mature estates use both.

How much does managed DDoS protection cost in the UK?

Entry-level proxy plans are published openly by some vendors, while scrubbing and managed enterprise contracts are quoted case by case, so avoid budgeting from headline figures. The variables that move the price are protected bandwidth, number of protected prefixes or domains, always-on versus on-demand, bot management inclusion, and support tier. Ask every bidder to price the same 72-hour attack scenario so the quotes are comparable.

Does my hosting provider’s included DDoS protection count as enough?

It is a reasonable baseline against commodity floods, but it is usually shared, tuned to protect the provider’s network, and may include a null-route policy that black-holes your IP to protect other tenants. Check the terms for that clause specifically, and check whether it covers application-layer attacks at all.

How do I protect DNS as well as my website?

Use an anycast authoritative DNS platform built for query floods, and consider running two independent DNS providers for the same zone so a single provider outage does not remove you from the internet. If you must keep name servers on-premise, use a shielding tier in front of them, the pattern Akamai implements with Shield NS53.

What time-to-mitigate SLA is realistic to ask for?

For always-on proxy or always-on scrubbing, mitigation of known vectors should be effectively automatic and measured in seconds. For on-demand BGP diversion, a few minutes from detection to clean traffic restored is a reasonable ask, provided the contract defines which of those two events starts the clock and what the out-of-hours escalation looks like.

Can I test a provider’s mitigation before I sign?

Yes, with written authorisation from both parties and a booked window, usually against a staging environment or a dedicated test prefix. Unauthorised testing against infrastructure you do not control is an offence under the Computer Misuse Act 1990, so keep the scope, permissions and timings documented before anything is generated.

Best DDoS Mitigation Providers: How to Choose (With Trade-Offs)

Shortlists of the best DDoS mitigation providers tend to rank vendors by brand recognition and advertised scrubbing capacity. Incident archives rank them differently. What decides whether an organisation stays online is narrower and less glamorous: whether authoritative DNS was covered, whether the old origin IP was still reachable after the proxy migration, whether anyone answered the phone within the first ten minutes, and whether the layer 7 rules blocked the botnet without blocking the checkout.

This guide works backwards from the attack patterns that actually cause outages, then maps each one to what a provider has to demonstrate before it belongs on a shortlist. It also covers the vendor landscape as it really is: a set of acquisitions rather than a fresh market, which matters more during procurement than most buyers expect.

What actually separates DDoS mitigation providers

Advertised capacity versus usable capacity near your users

Headline figures for network capacity describe the sum of a vendor’s edge, not the capacity of the point of presence that will absorb an attack aimed at your users in London, Manchester or Dublin. A platform with enormous global capacity but thin UK and Western European peering can still deliver added latency on clean traffic and slower convergence during a diversion. Ask for the PoP and peering list for the geographies your traffic actually comes from, and for the second and third nearest sites, because that is where traffic lands when the nearest one is saturated or under maintenance.

Always-on proxy, BGP diversion or DNS redirection

Three deployment models dominate, and each has a different realistic time to mitigate.

  • Always-on reverse proxy. HTTP and HTTPS traffic passes through the provider permanently. Mitigation starts in seconds because there is nothing to switch. The trade-off is that every request depends on the proxy, and TLS termination sits with a third party.
  • BGP on-demand diversion. The provider announces your prefixes and pulls traffic into scrubbing centres, then returns clean traffic by GRE tunnel or private interconnect. Suitable for whole /24s and non-HTTP services. Realistic activation covers detection, decision, announcement and BGP convergence, so the honest number is minutes, not seconds, unless the announcement is permanent.
  • DNS redirection. Records are repointed to the provider. Speed is governed by your TTLs and by resolver behaviour, and some resolvers ignore short TTLs. Anyone relying on this model should already be running low TTLs as standing configuration.

Volumetric floods versus application-layer floods

Layer 3 and 4 volumetric attacks are the ones that generate the headline numbers. Layer 7 floods are the ones that quietly take e-commerce and portal estates offline. A distributed bot network sending well-formed requests to search, login or basket endpoints does not need much bandwidth to hurt. An origin sized for roughly 500 requests per second can be exhausted by a few thousand requests per second against expensive database-backed endpoints, at a traffic volume that never crosses a volumetric detection threshold. That arithmetic is why per-endpoint rate limiting and bot management matter more than terabit claims for most web estates.

Who runs the mitigation on the night

Three operating models exist: your team drives the console, the vendor’s security operations centre drives it under a managed service, or a partner MSP drives it on your behalf. Self-service is cheaper and worse at 03:00 on a bank holiday. Managed services cost more and need clear authority to act without waiting for a change approval. Decide which model you are buying before you compare prices, because the same platform sold three ways produces three very different incidents.

Map your attack surface before you shortlist

Everything with a public address, not just the website

The inventory that matters includes the public web estate, APIs and mobile back ends, authoritative DNS, VPN concentrators, mail gateways, and anything else with a routable address. Origin exposure is where most proxy-based deployments quietly fail. Teams move DNS behind an anycast provider and leave the previous origin IP reachable, still visible in historic DNS records, mail headers, certificate transparency logs or a forgotten staging hostname. Attackers look there first.

Treat origin lock as a hard requirement rather than optional hardening. Ask exactly how the provider enforces it: IP allow-lists at the edge firewall permitting only the provider’s ranges, authenticated pull between edge and origin, or private interconnect. Then verify it from outside your network, not from the change ticket.

Sector patterns

Attack motivation shapes the pattern. Financial services see credential-stuffing and layer 7 floods aimed at login and payment paths, sometimes as cover for fraud, as in incidents like the DDoS disruption at National Australia Bank. Airlines and travel platforms carry expensive search endpoints that make cheap layer 7 attacks effective, which is why carriers have invested heavily in automated defences at the edge. Public sector estates fail collectively: the March 2024 disruption of French government services, which officials described as an attack of unusual intensity, showed how dozens of domains sharing DNS and hosting go dark together, and how hacktivist campaigns arrive in waves around political events. Healthcare and law firms tend to be hit for extortion or reputational leverage rather than volume records.

Hosting and data centre protection, and the blackholing clause

For many organisations the real first line is the hosting provider’s upstream filtering, and plenty of providers do invest properly in it, as with the anti-DDoS platforms rolled out by regional data centre operators. The problem sits in the acceptable use policy. Under attack, many providers will null-route the targeted IP to protect other tenants. That counts as mitigation for the provider and as a total outage for the customer. Read the clause, get the threshold in writing, and know whether an escalation path exists to filtering rather than blackholing.

Price the downtime first

Budget follows the cost of an hour offline, and so does the acceptable failure mode. An estate where an hour costs six figures should buy always-on protection with a managed SOC and separate DNS coverage. A brochure site can accept DNS redirection and a slower clock. Working out that number before vendor calls stops the conversation being driven by whichever feature the account manager is targeted on.

The main DDoS mitigation providers and where each one fits

One point worth carrying into every vendor call: this is a market built from acquisitions. Prolexic, founded in 2003, has sat inside Akamai since 2014. Earlier appliance and scrubbing names from the previous generation, including netZentry, Webscreen and IntruGuard (whose DDoS technology went to Fortinet), were absorbed into larger vendor and carrier portfolios years ago. A “proven since 2003″claim may describe technology that has changed hands and architecture more than once. Ask which platform your traffic will traverse today, in which data centres, and under whose engineering roadmap.

Global anycast CDN and reverse proxy platforms

Cloudflare, Akamai and Fastly all operate large anycast networks that terminate HTTP and HTTPS at the edge, with WAF, rate limiting and caching alongside DDoS filtering. For web and API-heavy estates this is the strongest default: mitigation is always on, layer 7 controls sit where the traffic arrives, and caching absorbs a large share of junk requests. The limits are equally clear. Proxy platforms protect what resolves through them, so non-HTTP services, mail and VPN need separate cover, and origin lock has to be enforced rather than assumed.

Routed network-level protection for whole prefixes

Akamai Prolexic and equivalent scrubbing services from carriers and specialists protect entire /24 announcements, including non-HTTP protocols, on-prem data centres and colocation footprints. This is the right choice where the estate is not simply a website: SIP trunks, game servers, financial market connectivity, industrial protocols. Two questions decide quality here. First, is the announcement always on or on demand, and what is the measured convergence time. Second, how is clean traffic returned, and what happens to that return path when it is itself attacked.

DNS protection as its own line item

DNS remains the most under-bought layer in the stack. An attack on authoritative nameservers takes out every service behind them at once, however well the web tier is defended. Organisations that hand DNS to a managed anycast provider inherit that provider’s capacity. Those keeping their own authoritative nameservers, often for internal integration or compliance reasons, need dedicated cover in front of them. Akamai Shield NS53 exists for exactly that case, sitting in front of on-prem and hybrid authoritative DNS, and competing providers offer similar hybrid arrangements. If DNS does not appear as a separate item on the quote, it is probably not protected.

Bot management, bundled or licensed separately

Automated layer 7 abuse sits at the boundary between DDoS, scraping and credential stuffing, and vendors increasingly sell it separately. Fastly Bot Management and its peers apply behavioural scoring, fingerprinting and challenge logic that generic WAF rules miss. For retail, ticketing and any estate with a login wall, this is usually the difference between staying up and staying up profitably. Establish early whether it is included in the platform price or licensed on request volume, because the second model changes the total cost under attack. Botnet supply itself has been a policy target for years, from industry takedown initiatives to named prosecutions, but attackers rebuild capacity faster than it is removed.

ISP, transit, protected hosting and managed DDoS protection in the UK

Buying through a transit provider, a DDoS-protected host or a UK managed security partner suits organisations without a 24/7 network team. Filtering happens upstream before congestion reaches the access circuit, and the partner holds the runbook. The channel model behind this is long established: DDoS vendors have offered managed security service partner programmes for well over a decade, including the early appliance-based MSSP schemes that shaped today’s managed offerings. Weaknesses to test: whether the partner can act without your sign-off, whether their SOC covers UK out-of-hours properly, and whether they simply resell a platform they cannot tune. A broader view of the defensive options, including on-premises and hybrid designs, is set out in this rundown of DDoS attacks and the available solutions.

Comparing providers on the things that break during a real attack

Time-to-mitigate SLAs. Most are measured from vendor detection, not from the moment your users stop being able to load the site. Get the measurement start point in writing, along with the out-of-hours escalation clock and who is authorised to declare an incident. Then check the credit: it is often a fraction of one month’s fee, which is not a remedy, it is an apology. Ask for the distribution of mitigation times across recent incidents rather than a headline average, because the tail is what hurts.

False positives. The first journeys to break under aggressive rules are checkout, login and password reset, precisely the ones that generate revenue and support tickets. Ask how the provider tunes for logged-in traffic, how quickly a rule can be relaxed mid-incident, and who has authority to do it at 2am.

Challenges and accessibility. JavaScript challenges and CAPTCHA reduce automated load but also block screen readers, older clients, legitimate API consumers and price-comparison partners. Public sector buyers with accessibility obligations should test challenge pages against assistive technology before go-live, not after a complaint.

The first 30 minutes. Named contacts, a phone number that is answered, a shared channel that does not depend on your own mail domain, and an agreed authority to act. Vendors that only offer a ticket queue at silver tier are fine for a brochure site and unacceptable for a payment platform.

Contract shape. Watch burst pricing, clean-traffic overage, attack-time surcharges, per-request bot management fees and 12 to 36 month lock-ins. Insist on knowing what an unusually large attack costs, because a bill arriving after an incident is a poor way to discover the pricing model.

Procurement questions and a proof-of-value test plan

Twelve questions that separate capability from marketing:

  1. Which PoPs will serve our UK and EU users, and who do you peer with there?
  2. Is protection always on, BGP on demand or DNS-based, and what is the measured activation time for each?
  3. What exactly is in scope for DNS: managed authoritative, hybrid, or nothing?
  4. How is origin lock enforced and verified after go-live?
  5. Is bot management included or licensed separately, and on what metric?
  6. From what event does the time-to-mitigate clock start, and what is the credit?
  7. Show the distribution of mitigation times over the last 12 months, not the average.
  8. Who runs mitigation out of hours, from which location, and under what delegated authority?
  9. What is the policy on null-routing our addresses, and at what threshold?
  10. Which platform will our traffic traverse, and what is its acquisition history?
  11. What are burst, overage and attack-time charges in cash terms?
  12. Can you provide two references in our sector at a similar traffic profile?

Ask for anonymised incident reports rather than case-study prose. A report showing detection time, mitigation time, rule changes and residual impact tells you more than any capacity figure. Then run a controlled proof of value: staged failover into the mitigation path during a low-traffic window, a runbook rehearsal with the people who will actually be on call, synthetic load against a non-production endpoint if the provider permits it, and a documented, tested rollback. If a vendor will not support a rehearsal, that answer is itself the result.

Getting value from the provider you choose

The runbook is the deliverable that matters. Switchover steps agreed in advance, standing low TTLs on the records you may need to move, credentials held outside the affected estate, and an out-of-band communications channel so nobody is trying to edit DNS through a saturated VPN. CISA, the FBI and MS-ISAC set out the same fundamentals in their joint guidance on understanding and responding to distributed denial-of-service attacks (October 2024): baseline normal traffic so anomalies are visible, layer defences, and rehearse the response. Baselining is the step most often skipped, and without it nobody can tell whether 3,000 requests per second is an attack or a marketing email.

Ransom DDoS: the response order

The pattern is consistent. A short demonstration attack, often aimed at a checkout or login path so the impact is unmistakable. Then an extortion email with a payment deadline in cryptocurrency. Then a larger follow-up if the deadline passes. Payment rarely ends it, because a paying target is a proven target and the same group, or another using its name, tends to return.

The order that works: preserve logs, packet captures and the full email headers of the demand; notify the mitigation provider’s SOC and confirm rules are tightened on the endpoints hit in the demonstration; brief the executive and communications teams with a holding statement; report to Action Fraud and, for organisations in scope, to the NCSC; do not pay. Extortion campaigns are prosecuted, and have been for two decades, including custodial sentences for cyber-blackmail gangs that attacked online businesses. In the UK, denial-of-service attacks fall within the Computer Misuse Act 1990 as amended by the Police and Justice Act 2006, which put attacks that impair the operation of a computer clearly inside the criminal law.

Quarterly reviews

Attack logs, false positive reports, rule tuning and a re-test after every significant change to the estate: new domain, new API, new payment provider, new data centre. Most protection gaps found during incidents were created months earlier by a routine change that nobody put through the mitigation review. A short quarterly session with the provider’s engineers, not just the account manager, catches them.

Choosing among the best DDoS mitigation providers comes down to matching deployment model, layer 7 capability, DNS scope and support behaviour to the way your own estate fails, then proving it with a rehearsal rather than a data sheet. Further background on attack techniques and defensive options is collected across DDoSInfo’s archive of DDoS incidents and vendor coverage.

Frequently Asked Questions

Who are the best DDoS mitigation providers for UK businesses?

For web and API estates, the global anycast platforms (Cloudflare, Akamai and Fastly) are the usual shortlist because mitigation is always on at the edge. For whole prefixes, non-HTTP services and on-prem data centres, routed scrubbing such as Akamai Prolexic or a carrier equivalent fits better. Organisations without a 24/7 network team often get more from managed DDoS protection bought through a UK partner or protected host than from buying a platform direct.

What is the difference between always-on and on-demand DDoS mitigation?

Always-on means all traffic passes through the provider permanently, so filtering begins immediately and there is nothing to activate. On-demand means traffic is diverted only when an attack is detected, usually via BGP or DNS changes, which is cheaper but adds detection, decision and convergence time. On-demand can be entirely adequate if the acceptable outage window is measured in minutes, not seconds.

How much does DDoS mitigation cost, and what drives the price up?

Pricing varies too widely across estate size and deployment model for a single figure to be useful, so treat published list prices as a starting point only. The main cost drivers are clean traffic volume, number of protected prefixes or hostnames, whether bot management is licensed separately, managed SOC coverage, and burst or attack-time terms. Always ask what an unusually large attack costs under the contract before signing.

Do I still need DDoS protection if my hosting provider says it is included?

Read the acceptable use policy first. Many hosts protect the platform rather than the individual tenant, and will null-route an attacked IP address to keep other customers online, which is a complete outage for you. Included protection is genuinely useful for volumetric floods, but rarely covers application-layer attacks or your authoritative DNS.

How is DNS DDoS protection different from protecting a website?

Web protection filters HTTP and HTTPS requests at a proxy; DNS protection defends the authoritative nameservers that tell the world where your services live. If DNS goes down, everything behind it becomes unreachable regardless of how well the web tier is defended. Anyone running their own authoritative nameservers should price DNS mitigation separately, for example a hybrid service such as Akamai Shield NS53 sitting in front of on-prem DNS.

What should I do if I receive a ransom DDoS demand?

Preserve the demand with full email headers, along with logs and captures from any demonstration attack, then alert your mitigation provider’s SOC and tighten controls on the endpoints that were targeted. Report it to Action Fraud, and to the NCSC if your organisation is in scope. Do not pay: it marks you as a paying target and rarely ends the campaign.

Is a CDN with WAF enough, or do I need separate bot management?

A CDN with a tuned WAF handles volumetric floods and known exploit patterns well. It is weaker against distributed bot traffic that sends well-formed, individually plausible requests to expensive endpoints, which is how many application-layer outages happen. Estates with logins, search, basket or ticketing flows generally need dedicated bot management alongside the WAF, plus per-endpoint rate limits.


Managed DDoS Protection UK: How to Choose a Provider (With Costs)

Buying managed DDoS protection in the UK is less about picking the biggest scrubbing network and more about proving three things to whoever signs the contract: that the service covers every surface an attacker can reach, that it can actually be deployed on your IP addressing, and that the SLA and the billing schedule agree with each other. Those are the points that decide whether an incident becomes a footnote in a board pack or a week of recovery.

This guide takes the buyer’s side of that conversation: what “managed”should mean in scope, where UK estates are routinely left uneven, how pricing is built, and what to do in the first hour if an attack has already started.

What the word “managed”actually buys you

The dividing line is simple. A self-service plan gives you a dashboard, a rate-limiting engine and a set of rules you write, tune and troubleshoot yourself. A managed service means a 24/7 security operations centre watches your traffic, declares an incident, applies mitigation on your behalf and tells you afterwards what it did. If a human on the provider’s side is not empowered to change policy at 03:00 without your sign-off, you have bought monitoring, not management.

A defensible scope of work includes onboarding and initial rule tuning, always-on traffic baselining, alerting to named contacts, mitigation without waiting on your approval, attack reporting with vector breakdowns, in-event change requests (whitelisting a payment partner, loosening a rate limit for a genuine campaign spike), and a written post-incident review. Ask for the escalation matrix in the contract: named engineers, an out-of-hours bridge number, and a maximum time to human contact rather than a maximum time to automated email.

Follow the resale chain before you sign

Many offers badged as managed DDoS protection are partner-programme wrappers around somebody else’s scrubbing capacity. That pattern is old and persistent: hosting providers layered their brand over specialist mitigation appliances and networks in the mid-2000s (Layered Technologies with netZentry, and the wave of Prolexic-era hosting partnerships that followed), and vendors have long run formal channel schemes such as IntruGuard’s managed security services partnership programme to let service providers resell mitigation under their own name.

Reselling is not a fault. Opacity is. Three questions settle it: who staffs the SOC you reach at 3am, whose network physically filters the packets, and who holds authority to change policy mid-attack. If the answer to the second question is a third party, ask what the reseller’s own SLA is against theirs, because you can only be covered to the depth of the weakest link in that chain.

The three surfaces UK buyers protect unevenly: network, application and DNS

Volumetric layer 3/4 floods (UDP reflection, SYN floods, carpet bombing across a whole prefix) are the surface everyone buys for. They are also the easiest for a scrubbing centre to absorb. The harder problem is application-layer traffic and automated bots that arrive at human-plausible request rates against expensive endpoints: search, basket, login, API pagination. That behaviour sits under the volumetric alarm thresholds entirely, which is why bot-management capability (Fastly Bot Management, Cloudflare Bot Management, Akamai Bot Manager and comparable tooling) belongs in the requirements list alongside raw capacity.

Authoritative DNS: the surface most often left unmanaged

An attack on your authoritative DNS produces a total blackout even when every web server is healthy, because nothing resolves. The EveryDNS episode of December 2010 made the point plainly: a DDoS aimed at a single hosted domain led the provider to drop that domain to protect the rest of its customer base, and the site went dark despite its web tier being untouched. Hybrid designs that shield on-premise and cloud DNS together, the design intent behind Akamai Shield NS53, exist precisely because organisations keep their own resolvers for internal reasons and then expose them to the internet.

Practical requirement: either two independent authoritative DNS providers with matched zones, or a shielded/anycast authoritative service with its own DDoS posture. Do not accept “our CDN covers DNS”without confirming which nameservers actually answer for the zone.

Origin IP leakage defeats proxies more often than volume does

Proxy-based protection fails most commonly because the attacker never touches the proxy. The origin address leaks through mail records on the same host, stale A records for old subdomains (dev, staging, cpanel, legacy VPN), historical DNS archives, and certificate transparency logs that publish every hostname you ever requested a certificate for. Onboarding is incomplete until the origin firewall only accepts traffic from the provider’s published ranges, mail is moved off the web address, and the leftover records are cleaned out.

Before shopping, map the exposure: every public IP range you announce or are assigned, API endpoints, VPN and remote access gateways, payment and login paths, mail, and any third-party service that hard-codes your origin. The count of protected domains and IPs is what you will be quoted against, and coordinated hacktivist campaigns hit estates rather than single hostnames. The March 2024 attacks that disrupted multiple French government services, confirmed by the Prime Minister’s office and claimed by a hacktivist group, targeted a spread of state platforms at once.

Deployment models compared: reverse proxy, BGP scrubbing and hosting-level filtering

Reverse proxy / DNS-based mitigation. You point your DNS at the provider, which terminates and filters HTTP(S) at the edge. Fast to deploy (hours, not weeks), strong for web and API traffic, weak for non-web protocols, and only as good as your origin hygiene.

BGP diversion to a cloud DDoS scrubbing service. The provider announces your prefix during an attack (or permanently) and returns clean traffic over GRE tunnels or direct connectivity. This protects every protocol, not just web. The constraint that sales decks skate over: you must be able to announce your own /24 or larger, with your own ASN and an RIR allocation. Most UK SMEs sit on provider-assigned addresses inside somebody else’s aggregate and cannot divert at all. Establish which model your IP situation permits before you start comparing SLAs, because otherwise you are comparing capabilities you cannot buy.

Hosting and data centre included protection. Upstream filtering and blackholing bundled with colocation or cloud hosting is genuinely useful, and some UK managed service providers wrap it into a wider network contract, as with Claranet’s DDoS protection offering. The question to ask in writing is what happens at threshold: does the provider filter your traffic, or null-route your IP to protect its other tenants? A null route is a successful outage from the provider’s perspective and a total outage from yours. Whether that threshold works for or against you often hinges on always-on versus on-demand DDoS protection, a distinction worth weighing against your own traffic and budget before signing anything.

Always-on or on-demand

On-demand diversion is cheaper and adds no steady-state latency, but you pay for it in detection-to-diversion time, typically measured in minutes once BGP convergence is included. Short repeat bursts, the hit-and-run pattern favoured by extortion crews, punish that model: each burst lands, mitigation engages, traffic reverts, and the next burst lands again. Always-on removes that gap, at the cost of routing all traffic through the provider. For UK-facing services, check for a London point of presence and ask where clean traffic re-enters your network, since a mitigation path via Amsterdam or Frankfurt shows up in page timings.

How to compare UK DDoS mitigation providers without relying on the sales deck

Read the SLA clock and the billing clause together. A 60-second time-to-mitigate is close to worthless if the clock starts when you raise a ticket rather than when the provider’s detection fires, and a clean mitigation is a hollow win if attack traffic or the post-event burst lands on your bandwidth invoice. Get answers on:

  • Clock start and remedy. Time to notify, time to mitigate, whether measurement is from detection or from your ticket, and whether the remedy is a service credit worth a few days’ fees or something proportionate.
  • Capacity and architecture. Aggregate and per-PoP scrubbing capacity, PoP locations, behaviour under simultaneous multi-vector attack (layer 3 flood plus layer 7 request flood plus DNS query flood), and whether mitigation is automated or analyst-triggered.
  • Data residency and logging. Where request logs and TLS termination sit, retention periods, and how that reconciles with your UK GDPR position and any sector rules.
  • Billing. Whether attack traffic is unmetered, how clean-traffic overage is charged, per-protected-IP and per-domain counts, and whether burst charges can be triggered by an incident you did not cause.
  • Evidence. Sample attack reports, a redacted post-incident review, references in your sector, and a pre-agreed onboarding and failover test rather than a promise to test “at some point”.

Run the failover test before go-live and again annually. It is the only way to know whether the runbook, the contact list and the tunnels still work, and it is the artefact that satisfies auditors and boards.

What managed DDoS protection costs in the UK, and how pricing is structured

Pricing splits into four recognisable shapes:

  1. CDN entry tiers, per domain. Published list pricing at the time of writing includes Cloudflare’s Pro plan at $20 per month and Business at $200 per month per domain. Self-service, not managed, and priced per zone, so a 30-domain estate multiplies quickly.
  2. Fixed monthly platform subscriptions. AWS Shield Advanced is published at $3,000 per month per organisation on a 12-month commitment, plus data transfer charges; Microsoft’s Azure DDoS Network Protection is published on a similar fixed monthly basis covering a set number of public IP resources. Check current vendor pricing pages, as these change.
  3. Clean-bandwidth commits. Scrubbing providers and carriers commonly price on committed clean Mbps/Gbps plus a per-prefix or per-protected-IP charge, with attack traffic excluded from metering (confirm that in writing).
  4. Enterprise annual contracts with a managed service fee. A platform licence plus a separate SOC/managed line item, usually on 12 to 36 month terms.

Licence cost is rarely the whole spend. Budget separately for onboarding engineering, ASN and GRE tunnel work if you are diverting via BGP, DNS migration, WAF and bot rule tuning (the phase where false positives get found, and the one most often under-scoped), and any retained incident response hours.

Emergency onboarding while an attack is running is the most expensive way to buy. Providers price it as incident work, contract lengths get longer, and the tuning that normally takes two weeks happens under load. The rapid-response arrangements publicised in the market, including Cloudflare’s partnership with Booz Allen Hamilton to assist organisations already under attack, exist for exactly that scenario, and they illustrate the premium and the constraints attached to it.

Building the business case

Boards respond to downtime cost per hour, not attack sizes in gigabits. The arithmetic is straightforward: divide annual online revenue (or the cost of the service being unavailable) by realistic trading hours. An operation taking £12m a year online across roughly 4,000 effective trading hours carries about £3,000 an hour in gross order value at risk, before support cost, chargebacks and reputational effects. Set that against annual protection spend and the case usually writes itself. Financial services teams have a shorter path still, given the availability expectations that follow incidents like the DDoS attack that disrupted National Australia Bank’s online services.

Under attack now: the first hour, ransom demands and the UK legal position

Confirm it is a DDoS before you escalate. A capacity limit, an expired certificate, a bad deployment or a DNS misconfiguration all look like an outage. Check upstream interface counters, request rates versus error rates, and whether the traffic profile is plausible. Then work the sequence: notify your ISP and upstream hosting provider, since filtering closest to the source is the most effective option available, apply rate limiting where you can, and trigger the provider escalation path with a named contact rather than a web form. CISA’s guidance on understanding and responding to denial-of-service attacks sets out the same priorities, including engaging your service provider early and pre-planning the response.

If a ransom note arrives, do not pay. Preserve the demand with full email headers, keep flow data and logs, and report it: Action Fraud for the crime report (Police Scotland in Scotland) and the NCSC’s reporting route for significant incidents. Extortion crews test for payers, and the pattern of hit, demand and repeat has been prosecuted for two decades, as the Russian cyber-blackmail gang jailed for attacks on bookmakers demonstrated. Attack capacity itself remains a botnet supply problem, which is why coordinated botnet reduction initiatives keep reappearing on national agendas. The FBI and CISA have also issued joint public warnings about denial-of-service activity degrading access to public-facing critical infrastructure services, including their September 2020 advisory on DDoS against election infrastructure.

The legal and regulatory frame

Launching a DDoS attack is a criminal offence in the UK under the Computer Misuse Act 1990, section 3, as amended by section 36 of the Police and Justice Act 2006 to cover unauthorised acts intended to impair the operation of a computer. Custodial sentences are on record: Daniel Kaye was sentenced to two years and eight months at Blackfriars Crown Court in January 2019 over attacks that disrupted a Liberian telecoms operator.

Three regulatory duties shape requirements more than most procurement teams expect. Operators of essential services and relevant digital service providers carry security and incident-reporting obligations under the NIS Regulations 2018. FCA-regulated firms have to identify important business services and impact tolerances under the operational resilience regime (PS21/3), with firms required to be operating within those tolerances from 31 March 2025. And availability is a security requirement under UK GDPR, not just a commercial one, so a prolonged outage affecting personal data systems can carry regulatory questions alongside the revenue loss.

The decision, in the end, rests on fit rather than brochure capacity. Confirm which deployment model your addressing allows, cover network, application and authoritative DNS to the same standard, lock the origin, and make sure the SLA clock and the billing clause tell the same story. Managed DDoS protection bought on those terms in the UK is defensible in front of a board; a plan bought on peak-gigabit figures alone usually is not.

Frequently Asked Questions

What is managed DDoS protection, and how is it different from a self-service plan?

Managed protection means a provider’s SOC monitors your traffic, declares incidents, applies and tunes mitigation on your behalf, and reports afterwards. A self-service plan gives you the same filtering platform but leaves detection thresholds, rule writing and in-event decisions to your team. The practical test is whether the provider can change policy during an attack without waiting for your approval.

How much does managed DDoS protection in the UK typically cost?

Pricing follows four models: per-domain CDN tiers (Cloudflare publishes $20 and $200 per month for Pro and Business), fixed monthly platform subscriptions (AWS Shield Advanced is published at $3,000 per month per organisation on an annual commitment), committed clean-bandwidth pricing, and enterprise annual contracts with a separate managed service fee. Add onboarding engineering, DNS migration, tunnel setup and rule tuning to the licence cost, and treat any figure as a placeholder until you hold a written quote.

Does the DDoS protection included with my hosting or data centre cover me?

Partly. Bundled upstream filtering handles routine volumetric noise well, but ask what happens when the attack exceeds the platform threshold: many providers null-route the targeted IP to protect other tenants, which ends the attack and your availability at the same time. Get the threshold, the response action and the notification commitment in writing.

Do I need separate DNS DDoS protection if I already use a CDN?

Only if the CDN is genuinely authoritative for your zone and its DNS service carries its own mitigation and SLA. Plenty of organisations proxy their web traffic while leaving authoritative DNS on a small provider or an on-premise resolver, which leaves a single point of total failure. Either use two independent authoritative providers with matched zones, or a shielded anycast DNS service.

Can I get managed DDoS protection set up while an attack is in progress?

Yes. DNS or proxy-based onboarding can be completed quickly, and specialist rapid-response arrangements exist for organisations already under attack. Expect premium pricing, longer contract terms and imperfect tuning, and expect to fix origin exposure under load, which is why pre-contracting is materially cheaper.

Are DDoS attacks illegal in the UK, and can I take legal action after one?

They are criminal offences under section 3 of the Computer Misuse Act 1990 as amended by section 36 of the Police and Justice Act 2006, and UK courts have imposed custodial sentences. Report through Action Fraud (Police Scotland in Scotland) and the NCSC, preserve logs, flow data and any ransom correspondence with headers intact, and take separate legal advice on civil claims, which are usually difficult where attackers are overseas or unidentified.

Should we ever pay a ransom DDoS demand?

No. Payment marks you as a paying target, offers no guarantee the attack stops, and funds further activity, and there may be sanctions exposure depending on who is behind the demand. Report it, keep the evidence, and put the money into mitigation capacity and a tested runbook instead.

Akamai Shield NS53 protects on-prem and hybrid DNS infrastructure

Akamai launched Akamai Shield NS53, a product that protects on-premises (on-prem) Domain Name System (DNS) infrastructure from resource exhaustion attacks. These attacks overwhelm servers to the point that they can no longer respond to valid DNS queries. The new offering complements Akamai Edge DNS, which is a comprehensive cloud-based DNS solution, and Akamai Prolexic, a distributed denial-of-service (DDoS) protection platform for Layer 3 and Layer 4 attacks. Over the past three years, there has been … More ? The post Akamai Shield NS53 protects on-prem and hybrid DNS infrastructure appeared first on Help Net Security .

More:
Akamai Shield NS53 protects on-prem and hybrid DNS infrastructure

Cloudflare partners with Booz Allen Hamilton to guide organizations under attack

Cloudflare announced a collaboration with Booz Allen Hamilton to support enterprises under attack by providing expedited Under Attack as a Service (UAaaS) with 30-Day Rapid Response DDoS Mitigation, including continuous monitoring and protection. Under this new agreement, Booz Allen’s Global Commercial clients facing a cyber-attack will be connected to Cloudflare for immediate Incident Response. Now, Booz Allen clients that may fall victim to cyber-attacks have a fast track to support when they need it most. … More ? The post Cloudflare partners with Booz Allen Hamilton to guide organizations under attack appeared first on Help Net Security .

Excerpt from:
Cloudflare partners with Booz Allen Hamilton to guide organizations under attack

Fastly Bot Management protects websites, apps, and valuable data from malicious automated traffic

Fastly introduced Fastly Bot Management to help organizations combat automated “bot” attacks at the edge and significantly reduce the risk of fraud, DDoS attacks, account takeovers, and other online abuse. Fastly Bot Management represents an important cybersecurity milestone for the company, building on its proven bot mitigation expertise and capabilities currently available in its Next-Gen WAF. “Organizations increasingly are delivering more enhanced digital experiences to their users at the edge. Not surprisingly, cyber adversaries have … More ? The post Fastly Bot Management protects websites, apps, and valuable data from malicious automated traffic appeared first on Help Net Security .

Follow this link:
Fastly Bot Management protects websites, apps, and valuable data from malicious automated traffic