Tag Archives: cloud ddos scrubbing service

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.

Botnet DDOS Attack Explained: What Defenders See

A UK retailer’s monitoring goes amber at 09:12 on a Tuesday: origin CPU is fine, cache hit ratio has fallen from the high nineties to about sixty per cent, and the search endpoint is queuing. No single source IP address stands out. Nothing has tripped a rate limit. Twenty minutes later the site is timing out and the phone lines are busy. Most explanations of a botnet DDoS attack explained the attacker’s side of this and stopped there: infected devices, command and control, a big flood. That is the easy half. The half that decides whether you stay online is what that traffic looks like when it lands on your network edge, your application and your authoritative domain name system (DNS) servers, and why the same botnet produces three completely different sets of symptoms.

What a botnet is, and how a pile of infected devices becomes an attack

A botnet is a collection of compromised internet-connected machines under the control of one operator. Three parts make it work. Infection, usually through default credentials, unpatched firmware or a commodity malware loader. Command and control (C2), the channel the operator uses to issue instructions, which may be an internet relay chat channel, an HTTPS endpoint or a peer-to-peer mesh. And the herder, the person or crew who owns the panel and decides where the traffic goes.

Scale here is not theoretical. Botnets have historically been measured in the hundreds of thousands of compromised hosts, with some estimates reaching a million zombies, and the population turns over constantly as devices are cleaned, rebooted or replaced.

Most attacks are rented, not built

Very few of the attacks that hit UK organisations come from someone who wrote the malware. They come from booter and stresser services, where the buyer picks a target, a vector and a duration from a dropdown. That changes the shape of the incident. Rented attacks tend to run in bursts of minutes to an hour rather than days, because the buyer is paying by time. Target selection is often opportunistic, or driven by a grudge, a competitor or an extortion campaign rather than by any strategic value in your estate. And the person on the other end is frequently not technically sophisticated, which matters when a ransom note arrives.

Botnet floods versus reflection and amplification

The two get conflated constantly. A botnet flood is traffic generated by compromised machines and sent directly at you. A reflection attack sends spoofed requests to third-party services (open DNS resolvers, network time protocol servers, memcached instances, connectionless lightweight directory access protocol endpoints) with your address in the source field, so the responses land on you. Amplification is the multiplier: a small query producing a much larger answer.

Reflection needs almost no bots at all. A handful of hosts on networks that permit source address spoofing can generate hundreds of gigabits per second by borrowing other people’s bandwidth. That is why the distinction is operationally useful: reflection traffic comes from a limited set of identifiable service ports and can often be dropped upstream on protocol and port alone, while genuine botnet traffic arrives from real addresses, over real TCP sessions, and increasingly with a valid transport layer security (TLS) handshake attached.

Node count is the wrong headline number

Vendors and journalists quote node counts because they are dramatic. What actually determines whether you fall over is aggregate request rate, the protocol chosen, and the cost of the thing being requested. Ten thousand cloud instances doing full TLS handshakes against a login page will hurt far more than half a million home routers sending malformed UDP packets that your upstream drops for free.

The device mix has changed, and the old blocking reflexes broke with it

The 2016 generation of botnets was overwhelmingly consumer hardware. US-CERT’s alert TA16-288A, published in October 2016, described Mirai as scanning for internet-of-things devices still running factory default credentials, principally digital video recorders, IP cameras and routers. Huge node counts, low output per node, spread across almost every country with broadband.

Compromised cloud and hosting instances are a different animal. Fewer nodes, but each with a gigabit or more of egress, modern CPUs capable of thousands of TLS handshakes per second, and an IP address that belongs to a reputable provider rather than a residential range. Reputation lists do not help you. Blocking the autonomous system means blocking a major cloud, which is where a good deal of your legitimate API traffic also lives.

Then there are residential proxy networks. Some are outright criminal, some are commercial services whose users consented in a software development kit buried in a free app. Either way, the attacker rents exit nodes on real consumer broadband lines, in the country of your choosing, driving real browser engines. IP reputation scoring, country blocking and simple JavaScript challenges all degrade badly against them.

Which brings us to the reflex every incident call reaches for at minute fifteen: block the bad countries. Against a 2016 IoT botnet it bought you something. Against a device mix that includes UK residential exits and instances in Ireland and Frankfurt, geo-blocking removes customers and leaves the attack broadly intact. Worse, it feels like action, so people stop looking for the real signature.

What one botnet looks like on each of your three surfaces

Network and transport

SYN floods that exhaust connection state, UDP floods that fill the pipe, ACK floods designed to look like established sessions to a stateful firewall. The variant that catches people out is carpet bombing: instead of hammering one host, the traffic is spread thinly across every address in your /24 or across several prefixes. No single destination crosses the per-IP threshold that triggers detection, but the aggregate saturates the upstream link or the edge router’s packet-per-second ceiling. Flow data shows it clearly. Per-host alarms do not.

Application layer

Here is the arithmetic that ought to be on a slide in every procurement meeting. Thirty thousand nodes, ten requests per minute each, is 300,000 requests per minute, or roughly 5,000 requests per second. Point that at an uncached search endpoint that costs the database 200 milliseconds per query and the connection pool is gone in seconds. Now look at any individual source: ten requests a minute, one every six seconds, from a residential address with a plausible user agent. That is slower than a real shopper browsing a category page.

Attackers pick the expensive endpoints deliberately: internal search, faceted filters, login and password reset, add-to-basket, anything with a query string that defeats the cache. Bandwidth at the edge may look unremarkable throughout.

Authoritative DNS

The surface almost nobody has budgeted for. On 21 October 2016 a Mirai-based botnet attacked the managed DNS provider Dyn; the widely reported consequence was that users could not reach services including Twitter, Reddit and Spotify, none of which were themselves under attack. Their web tiers were fine. Name resolution was not.

Two vectors dominate. Straight query floods, and the random subdomain or “water torture”attack, where the botnet requests a8f3k2.yourdomain.co.uk, then another random label, then another. Recursive resolvers cannot serve those from cache, so every query is forwarded to your authoritative servers, and your own customers’ resolvers become the delivery mechanism. Your web server sees nothing. Your site is still down.

The pattern in the field is consistent: an organisation buys a reverse proxy for the website, leaves DNS with the domain registrar on whatever plan came free with the renewal, and discovers during the incident that DNS DDoS attack protection was never part of the contract. If your DNS sits on two non-anycast nameservers at a registrar, that is the weakest link in your estate, and it is usually the cheapest one to fix.

One botnet can be pointed at all three surfaces in sequence during a single incident. Fifteen minutes of SYN flood, a pause while someone reads the effect, then an HTTP flood, then DNS when the HTTP flood stops working. Treat the incident as one campaign, not three unrelated events.

Reading the evidence: botnet flood, flash crowd or badly behaved crawler

Three things produce a traffic spike, and only one of them is an attack. The separators are behavioural, not volumetric.

  • Source diversity and depth. A flash crowd (a newsletter send, a broadcast mention, a viral post) has concentrated referrers and normal session depth: landing page, then two or three more pages. Botnet traffic has extreme source diversity and session depth of one, repeated.
  • User agent and header spread. Real populations produce a long, messy tail of browser versions. Botnets produce either an unnaturally narrow set or an unnaturally uniform distribution, and often header ordering that does not match the browser being claimed.
  • Cache hit ratio. Genuine traffic raises hits. Attack traffic aimed at query strings and search collapses the ratio while requests climb. That divergence is one of the earliest reliable signals.
  • Conversion behaviour. Sessions up, transactions flat is an attack or a scraper. Sessions up, transactions up is a good day.
  • Robots and rate. A misconfigured crawler identifies itself, comes from a narrow set of prefixes, and usually respects a 429 response. A botnet does none of that.

Look in this order: edge or content delivery network logs for endpoint and cache behaviour; NetFlow or sFlow from the border routers for packet rates and destination spread; authoritative DNS query logs for NXDOMAIN volume; and origin connection counts. Then the trap. Per-IP rate limiting is close to useless against a wide botnet, because every source is under any threshold you could set without harming real users. Detection has to run on aggregate behaviour and endpoint cost, not per-source counters.

One diagnostic worth committing to memory: if the origin’s 5xx rate is climbing while edge traffic looks normal, the attack is bypassing the proxy. Someone has your real origin address.

Which defences actually stop botnet traffic

Match the tool to the layer, because none of them covers everything.

  • Reverse proxy or CDN for HTTP and HTTPS floods. It terminates TLS, applies challenges and behavioural rules, and absorbs application-layer volume. It does nothing for traffic sent directly to your IP addresses.
  • BGP-based cloud DDoS scrubbing for network and transport layer floods and carpet bombing. Your prefixes are announced to the scrubbing network, dirty traffic is filtered, clean traffic returns over GRE tunnels or a direct connection. Note the entry requirement: for IPv4 you generally need to control a /24 you can announce, which rules the model out for most organisations sitting on provider address space.
  • Hosting-level filtering is a partial measure. It helps with obvious volumetric noise and costs nothing extra. It rarely includes application-layer inspection, and the provider’s ultimate defence is often a remotely triggered blackhole of your address, which completes the attacker’s objective for them.

Always-on versus on-demand deserves a firm position rather than a balanced shrug. On-demand diversion costs you detection time plus BGP convergence plus tunnel establishment, and a rented botnet reaches full rate in under a minute. Carpet bombing makes it worse, because the per-host thresholds that trigger diversion may never be crossed. If your risk profile includes network-layer attacks on your own prefixes, always-on is the honest choice; the trade-off between always-on and on-demand protection is mostly a question of how many minutes of downtime you can absorb, and what a time-to-mitigate SLA actually commits the provider to.

Origin IP leakage beats raw volume

More proxies are bypassed by leaked origin addresses than by attack size. The leaks are boringly consistent: an old A record still in passive DNS history; a mail server on the same address as the web application, advertised in SPF and MX records; a certificate transparency log entry (public by design under RFC 6962) exposing staging.yourdomain.co.uk; a development host, a status page, or a direct-to-origin API subdomain that was never proxied.

The fix takes an afternoon and almost nobody does it at onboarding: change the origin IP addresses after moving behind the proxy, then lock the origin firewall so ports 80 and 443 accept traffic only from the provider’s published ranges. Everything else gets dropped. If your provider does not publish those ranges, that is worth asking about before signing.

What to ask a provider, and what to do when the note arrives

Ask whose network you are actually buying. Resale chains are common, and the capacity figure in the deck, the SLA and the escalation path may each belong to a different company. Ask how many layers sit between your contract and the engineer who can change a mitigation policy.

Pin down what “managed”includes: onboarding and rule tuning, traffic baselining, named contacts, who raises the ticket, and specifically who is authorised to act at 03:00 without waking your CTO for sign-off. If nobody on their side can change policy without your approval, you have bought monitoring, not management. The detail of what a managed DDoS contract should specify in the UK is worth reading before the first renewal, not after the first incident.

Then judge their attack reports, which is the cheapest evidence available to a buyer. A useful report shows source distribution by network and geography, a vector breakdown, peak packet and request rates, and the exact mitigation applied with timestamps. A bandwidth graph with a red line on it is marketing. Ask for a redacted sample during procurement, alongside any vendor claims you intend to test against real attack behaviour.

Ransom demands

The pattern is familiar: a demonstration burst lasting a few minutes, then an email demanding cryptocurrency and naming a return date. That demonstration is evidence. Capture the flow data and the edge logs from those minutes, because they tell you the vector mix, the approximate node count and whether the operator has application-layer capability or only volumetric noise. That is a better basis for deciding what to buy than any threat in the email.

In the UK, denial of service offences are prosecuted under the Computer Misuse Act 1990, section 3 having been amended by the Police and Justice Act 2006 to cover unauthorised acts intended to impair the operation of a computer. Report to Action Fraud (Police Scotland if you are in Scotland) and follow NCSC guidance on denial of service attacks. Paying is not recommended by UK authorities, and the practical argument is stronger than the moral one: payment confirms the target pays, and the operator selling you peace has no mechanism to stop a second crew, or himself, coming back next quarter. Spend the money on capacity instead, and rehearse the first sixty minutes of an incident before you need it.

Frequently Asked Questions

How is a botnet DDoS attack different from a reflection or amplification attack?

A botnet flood is generated directly by compromised machines, so the source addresses are real and the sessions can be genuine TCP or TLS connections. Reflection abuses third-party servers by spoofing your address as the source, so the responses land on you, and amplification is the multiplier when a small request produces a large answer. Reflection needs very few attacker-controlled hosts and is usually easier to filter upstream by protocol and port.

How can I tell a botnet attack from a sudden spike in genuine traffic?

Compare behaviour, not volume. Genuine spikes carry concentrated referrers, normal session depth, a rising cache hit ratio and some conversion; botnet traffic shows enormous source diversity, single-request sessions, a collapsing cache hit ratio and flat transactions. Authoritative DNS query logs and NetFlow will usually confirm the picture within a few minutes.

Does blocking countries or IP ranges stop a botnet DDoS attack?

Rarely, and it often costs you customers. Modern device mixes include compromised cloud instances in mainstream hosting regions and residential proxy exits inside the UK, so country blocking removes legitimate buyers while leaving much of the attack in place. Filtering has to work on request behaviour and endpoint cost instead.

Why does my DDoS protection stop working even though the proxy is switched on?

Almost always because the attacker has your origin IP address, from an old DNS record, a mail server sharing the host, a certificate transparency entry or an unproxied staging subdomain. Traffic then goes straight past the edge, which is why origin 5xx errors climb while edge graphs look calm. Rotate the origin address and restrict the firewall to your provider’s published ranges.

Should I pay a ransom demand attached to a botnet DDoS attack?

UK guidance from the NCSC and Action Fraud does not recommend paying, and payment marks you as a target that pays. Preserve the logs from the demonstration burst, report the incident, and put the money towards scrubbing capacity and DNS protection instead.

“`

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. Before signing that quote, it is worth learning how to judge Tbps claims on scrubbing capacity against what the contract actually guarantees.

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.

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. For sector buyers weighing this, our look at law firm cyber attack protection beyond phishing breaks down what managed cover actually costs.

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.