Tag Archives: dns ddos attack protection

DDOS Attacks on Healthcare Providers: 6 Weak Points

DDOS Attacks on Healthcare Providers: 6 Weak Points

Picture the first Tuesday clinic of the month at a district general hospital: twenty-eight outpatient slots booked through a third-party portal, a pathology feed arriving over SFTP from a regional lab, community nurses logging in through a VPN concentrator that was sized in 2019, and a website that quietly stopped being the trust’s problem the day the original web agency took over the domain. Then the portal stops answering. DDoS attacks on healthcare providers rarely succeed because the traffic volume was extraordinary; they succeed because one of those components had no owner, no mitigation and nobody awake to act on it.

This piece does not rehearse sector statistics. It names the six places UK health estates actually break during a denial-of-service event, and what to put in a contract so they do not break twice.

Why health estates fall over at volumes other sectors absorb

A bank runs its own autonomous system, its own IP space and a security operations centre with a rota. A trust runs a federation. The main website might sit with a regional NHS host, the patient portal with a clinical software vendor, e-referral with another, video consultation with a third, the integration engine on a virtual machine in a shared data centre, and the authoritative DNS wherever it was parked a decade ago. Six owners, six contracts, six different answers to the question of who is allowed to phone a mitigation provider at 02:00.

The damaging outcome in a clinical setting is not data theft. It is unavailability. A booking engine that is unreachable for ninety minutes produces paper fallback, phone triage, a clinic list worked from printouts, and a rebooking backlog that is still being cleared weeks later. Ambulance diversion is the extreme case, but the ordinary case is quietly expensive: consultant time burned on a stalled list, administrative overtime, and appointment slots that cannot be recovered because the capacity simply does not exist.

Motive shapes the target, not the size of the pipe

Hacktivist pressure campaigns pick targets for visibility, which means public-facing portals and anything with a recognisable name. The US Department of Health and Human Services’ Health Sector Cybersecurity Coordination Center (HC3) published an analyst note in January 2023 on the pro-Russian group KillNet targeting the health sector with denial-of-service attacks, and pro-Russian groups have since claimed attacks against European public sector sites. Ransom-motivated actors behave differently: they time the disruption around a known pressure point, such as a winter surge or the first working day after a bank holiday, and they test which surface hurts most. Reading the motive early tells you whether to expect a short noisy burst or a sustained campaign, which is the practical value of understanding what hacktivist attack motives predict.

Weak point 1: authoritative DNS that nobody in the trust owns

Ask an information governance lead who manages the trust’s authoritative nameservers and the answer is often a pause. The zone is frequently still with the agency that built the original site, or inside a legacy hosting account whose billing contact left in 2018. Domain Name System (DNS) is the layer most reliably left unmanaged in health estates, and it is the one with the widest blast radius.

A query flood against a single authoritative provider does not take down one website. It takes down every name in that zone at once: the patient portal, staff email routing, the identity provider used for single sign-on, and any API hostname your suppliers resolve. Web application firewalls and reverse proxies are irrelevant at that point, because nothing ever resolves far enough to reach them.

Three practical steps. Inventory every zone the organisation depends on, including the ones registered by departments and charities under your name. Check whether you have genuinely diverse authoritative nameservers (two providers, separate anycast networks, not two hostnames on one platform). Set time-to-live values you can actually work with during an incident, because a 24-hour TTL means your emergency change takes a day to propagate. The detail of provider selection is covered in this buyer’s guide to authoritative DNS protection.

Questions worth putting to your DNS host in writing: what query-per-second capacity do you provision per customer, how many points of presence carry our zone, and who answers the phone at 02:00 on Boxing Day?

Weak point 2: origin IP leakage behind the patient portal

Proxy bypass is the most common way a protected site falls over, and it is almost never a capacity problem. The attacker has simply found a route that goes around the proxy entirely.

Health estates leak origins in predictable places: an old A record for a decommissioned booking subdomain that still points at the real server, a UAT or staging environment on the same subnet, a mail host sharing the range, a certificate transparency log entry naming an internal hostname, or a PDF and imaging endpoint serving large files straight from the origin because someone excluded it from the proxy for performance. Attackers enumerate those first. Appointment booking and repeat prescription ordering are the endpoints they probe hardest, because both are expensive per request on the back end.

The fix is unglamorous. Lock the origin firewall to the proxy’s published address ranges, deny everything else, then verify it from outside your network rather than assuming the rule works. Re-verify after every migration. Application-layer protection is only as good as the path discipline underneath it, which is the recurring theme of these application layer protection gaps.

Weak point 3: clinical SaaS and integration layers outside your contract

Most clinical availability depends on networks the trust does not control. Booking engines, e-referral, remote patient monitoring, pathology result delivery, prescription services and video consultation platforms all sit on someone else’s infrastructure, often in shared tenancy where an attack aimed at a neighbour can degrade your service.

Protection so belongs in supplier contracts, not only in your own hosting arrangement. Insist on four things in writing: the named mitigation provider and the underlying network doing the scrubbing; a stated time to mitigate with the conditions under which the clock starts; a notification duty within a defined window when the supplier is under attack; and a written post-attack report with a vector breakdown.

Then do the mapping exercise. Take each clinical pathway and ask what happens if that one supplier is unreachable for two hours on a weekday morning. Some pathways degrade gracefully. Others stop. The ones that stop are the ones to argue about at contract renewal.

Weak point 4: remote clinician access and the network edge

VPN concentrators, remote desktop gateways and session brokers are low-capacity choke points sitting in front of high-value work. A state exhaustion attack fills the session table or the TLS handshake queue while using a fraction of the link’s bandwidth. Your monitoring shows the circuit at 12 per cent utilisation and the clinicians cannot log in. That combination causes more wasted triage time than any volumetric flood.

Reverse proxy protection does nothing here, because none of this is HTTP traffic you can route through a content delivery network. If your organisation holds its own IP space and autonomous system number, Border Gateway Protocol (BGP) based scrubbing covers the whole range, including SFTP result feeds, HL7 interfaces and API endpoints. If it does not, you need per-service protection from whoever owns the addresses, and you need to know that before an incident rather than during one.

Weak point 5: on-demand mitigation that misses clinical timeframes

On-demand mitigation sounds economical. Detection, then a BGP announcement, then route convergence, then traffic actually arriving at the scrubbing centre. Each step costs real minutes, and minutes map directly onto cancelled slots during a running clinic.

Read the service level agreement for what triggers the clock. A “15 second time to mitigate”usually assumes always-on traffic baselining, pre-agreed thresholds and signed-off authorisation; without those, the clock starts when a human on your side raises a ticket and gets authenticated. Ask who in your organisation is authorised to trigger mitigation out of hours, and check that person exists on an August bank holiday weekend. Many escalation matrices name a role rather than a rota.

Diversion has trade-offs worth stating openly: added latency on every clinical session, asymmetric routing that can break stateful appliances, and services (voice, some VPN tunnels, IP-allowlisted supplier feeds) that fail when source addresses change. Test those before you need them, not at 09:15 on a Monday.

Weak point 6: a ‘managed’ contract that is really a portal login

The dividing line is simple. Managed means onboarding and rule tuning against your real traffic, a tested runbook, a named escalation path and an engineer empowered to change policy during the attack without waiting for your ticket. If nobody on the provider’s side can act without your sign-off, you have bought monitoring, not management, and out of hours that means nobody acts at all.

In public sector procurement the resale chain matters. The logo on the quote is often not the network doing the scrubbing; capacity, peering and support hours frequently belong to a provider two steps down the chain. Ask who operates the scrubbing centres, where they are, and whether support is in-house or subcontracted overnight. Then judge on evidence: sample post-attack reports with real vector breakdowns, references from organisations of comparable size, and a straight answer on how false positives are handled.

Healthcare tuning has one rule generic providers get wrong. Never rate-limit a clinician into a locked-out state. Hospital networks present hundreds of users behind a handful of NAT addresses, kiosk browsers carry odd user agents, and automated feeds (results, device telemetry, interoperability polling) look exactly like scripted abuse to a default ruleset. Allowlist them deliberately, by source and by behaviour, before go-live. General principles on how denial-of-service attacks work and how they are mitigated are a useful grounding for the governance papers that accompany this sort of procurement.

Building the business case and surviving the first hour

Price the downtime before you price the protection. Take one cancelled outpatient list: the lost slots, consultant and nursing time spent on paper fallback, administrative overtime, out-of-hours recovery, and the rebooking backlog that spreads across the following weeks. Put a figure against it using your own costing data, then set that beside an annual protection contract. That comparison persuades finance directors; fear does not.

UK managed protection is usually priced on a committed bandwidth or protected-IP basis with a monthly fee, plus onboarding, and often with burst or overage charges once attack traffic exceeds a threshold. The line items buyers forget at first invoice are additional protected subnets, extra portal users, out-of-scope incident response hours and the cost of a second mitigation point for DNS. The breakdown in this guide to what UK DDoS protection actually costs is a reasonable starting point for a budget paper.

For the first hour, work in sequence. Confirm it is an attack rather than a failed deployment or an upstream fault, using the approach in this piece on telling a DDoS apart from an ordinary outage. Check three surfaces in order: DNS resolution, the proxy or edge, then the origin and the remote access concentrators. Notify affected clinical suppliers and ask them to confirm their own status. Capture evidence as you go (packet samples, flow records, timestamps, portal screenshots), because reconstruction afterwards is always worse.

Governance follows. Inform the on-call director and the information governance lead, log the incident against the NHS Data Security and Protection Toolkit processes your organisation already uses, and consider obligations under the Network and Information Systems Regulations 2018 if your organisation is designated an operator of essential services. UK GDPR Article 32 expects availability and resilience of processing systems, so a sustained outage is a security matter, not only an operational one. Denial-of-service attacks are offences under the Computer Misuse Act 1990, which is the basis for reporting to Action Fraud and, for significant incidents, to the National Cyber Security Centre.

Frequently Asked Questions

Why are healthcare providers targeted by DDoS attacks?

Visibility and urgency. Hacktivist groups choose targets whose disruption gets reported, and health services qualify; HC3 in the United States issued an analyst note in January 2023 about pro-Russian actors targeting the sector. Extortion-motivated attackers pick healthcare because the tolerance for downtime is close to zero, which increases the chance of a fast payment or a fast concession.

Can a DDoS attack on a hospital affect patient care directly?

Yes, indirectly but materially. If booking, e-referral, results delivery or remote clinician access is unreachable, staff revert to paper and telephone, lists slow down and appointments get cancelled. The clinical risk sits mostly in delayed care and the backlog, rather than in any loss of patient data.

Does a patient portal behind a reverse proxy still need network-level protection?

Usually, yes. A proxy only protects traffic that goes through it, so a reachable origin, an exposed UAT host or a mail server on the same range reopens the direct path. Non-HTTP services (VPN, SFTP feeds, HL7 interfaces) are not covered by a web proxy at all.

How much does managed DDoS protection cost for an NHS trust or private hospital group?

Pricing varies by committed clean bandwidth, number of protected IP ranges, always-on versus on-demand, and support hours, so there is no single figure worth quoting. Build the comparison from your own downtime cost per cancelled clinic list, and ask every bidder to quote onboarding, overage and out-of-scope incident hours separately.

What should we do in the first hour of a suspected DDoS attack on a clinical system?

Confirm it is an attack rather than a deployment or upstream failure, then check DNS, the edge and the origin in that order. Notify your mitigation provider and any affected clinical suppliers, start the clinical fallback process, and record evidence with timestamps for reporting to Action Fraud and the NCSC and for any later contractual or legal action.



Hacktivist DDOS Attack Motives: What They Predict

Hacktivist DDOS Attack Motives: What They Predict

Hacktivist DDoS attack motives are listed in almost every security blog going: geopolitics, protest, revenge, clout within a channel. What almost none of them do is join the motive to the attack you actually receive at 09:00 on a Tuesday. That link matters, because motive is a forecasting tool. Once you accept that the attacker’s success metric is coverage rather than your revenue loss, the shape of the incident becomes predictable, and so does the list of surfaces that will fail first.

This piece is written for the people who sign the protection contract and run the incident bridge, not for policy analysts trying to map the ideology.

What actually drives hacktivist DDoS attack motives

Four drivers cover most of what UK organisations see. Political or geopolitical grievance, usually tied to a conflict, a sanctions decision or a government position. Protest against a named policy, planning decision or contract award. Retaliation for something a named executive or organisation said in public. And status, which is the one defenders underrate: in a coordinating channel with a few thousand subscribers, posting a screenshot of a downed council homepage earns reputation in a way that a quiet, damaging intrusion never will.

Attention is the objective. Not extortion, not competitive harm, not data. The campaign is built so that a claim can be posted, reposted and, ideally, picked up by a journalist who does not check it. That single fact explains the duration, the target list and the vectors.

Where the lines blur

Three complications are worth stating plainly. State-aligned groups adopt hacktivist branding because deniability is cheap and the aesthetic is established. Criminal crews borrow political language to muddy attribution or to recruit. And ransom demands now appear mid-campaign, sometimes days after a political claim, from the same or an adjacent account.

If you are working out what to do about a ransom DDoS attack, the technical response does not change: you mitigate, you do not pay, and you preserve evidence. The legal and reporting picture does change, because an extortion demand brings a different set of obligations and a different conversation with your insurer and your board. Treat every motive claim as unverified attribution, including the political ones. The group claiming your outage may not have caused it, and the group that caused it may not be the one you think.

Competitive sabotage and gaming disputes behave differently. Those attackers want an effect and do not want an audience, so they are quieter, more patient and more willing to run for hours. A hacktivist campaign that runs for six hours is unusual. A gaming grudge that runs for six hours is Tuesday.

How motive shapes the attack you actually see

Attention-driven campaigns are short and rhythmic. They cluster around a fixed point in time: a parliamentary vote, a court date, a contract announcement, a sanctions package, the anniversary of something. Waves of ten to thirty minutes, repeated, are far more common than sustained pressure, because a burst is enough to generate a screenshot from a public reachability checker and a burst costs less booter credit.

The toolkit is unglamorous. Rented booter and stresser capacity, reflection and amplification floods against the network edge, and plain HTTP GET floods pointed at whatever endpoint is most expensive to serve. Site search is the perennial favourite, followed by login pages and any URL with a query string that defeats the cache. The volunteer-tool era of Operation Payback, with participants running LOIC and HOIC from their own machines, has largely given way to rented botnet and stresser capacity coordinated through chat channels, which is why a handful of organisers can now generate more traffic than a few thousand volunteers once did.

Target selection follows the same logic as everything else. Homepages, public-facing portals, authoritative nameservers, anything with an address a reader will recognise. Not the claims processing system. Not the back-office integration that would genuinely hurt if it stopped.

Plenty of claimed campaigns sit well under 10 Gbps and well under an hour. That sounds survivable, and against a properly protected estate it is. The FBI’s Internet Crime Complaint Center made the point in a public notice on 4 November 2022, observing that hacktivist DDoS activity against critical infrastructure had produced limited operational impact while generating publicity out of proportion to the damage. The gap between impact and publicity is the thing to plan around. It is also why a modest flood still takes sites down: one unprotected surface is all the campaign needs, and modest is more than enough to saturate a registrar’s nameservers or a single origin VM.

Who gets picked, and why symbolism beats value

The recurring sectors will not surprise anyone: DDoS attacks on government websites and local council portals, NHS trusts and healthcare providers, airports and airlines, law firms acting on contested matters, broadcasters and news sites. High recognisability, public-facing, and easy to describe in a one-line post.

Collateral exposure is where organisations get caught out. Your payment page, your booking engine, your DNS provider and your CDN-hosted assets carry your brand and your reputation, but not necessarily your controls. When a third-party checkout goes dark, the screenshot still has your logo on it.

Supplier exposure works the same way. Organisations get targeted for a client they act for, a contract they won or a position their parent company took, rather than anything they did themselves. The attempted attacks on the Vatican’s website are a useful illustration of the pattern: a symbolic institution picked for what it represents, an attack claimed loudly, and an outcome rather less dramatic than the claim. Once a name appears on a circulated target list, unrelated participants join in simply because the list exists. Removal from the list is not a thing you can request.

Verifying a claim of responsibility against your own evidence

Here is the part no one else covers, and it is the defence that most often decides how the incident is reported. Hacktivist campaigns are optimised for narrative. If you cannot produce request rates, regional reachability and edge logs for the claimed window, a fifteen-minute partial slowdown gets written up as a day-long outage, and you are arguing from the back foot with your regulator, your insurer and the trade press.

Check three surfaces, in order:

  1. Authoritative DNS. Query your nameservers directly from multiple regions. If resolution failed, nothing downstream matters, and the web tier logs will look misleadingly quiet.
  2. Network and transport. Interface counters, upstream flow data, any scrubbing provider’s traffic graph for the window. Look for volume and for the vector mix.
  3. Application layer. Requests per second per endpoint, cache hit ratio, origin response times, 5xx rates. A GET flood on search shows up as a single endpoint carrying a request rate it has never carried before.

Then separate real impact from a reposted screenshot. Public checker tools report from one vantage point and cache aggressively; a red tick on such a site is not evidence of an outage. Synthetic monitoring from several regions, plus your own edge logs, is. Our 10-minute triage for telling a DDoS from an ordinary outage covers the sequence in more detail, and it is worth rehearsing before you need it.

Capture the evidence in the first hours, not the following week: precise timestamps in UTC with your local offset, vector breakdown, source ASNs and country spread, packet and request rates, the mitigation actions taken and when, and screenshots of the claiming post with its own timestamp. Insurers ask for it. Regulators ask for it. Any realistic legal route depends on it.

Ask your provider for a post-attack report and check the contract says what it must contain. Per-vector and per-ASN detail, start and end times, peak and sustained rates, and which rules fired. Where a reseller sits between you and the scrubbing network, that report often arrives late and thin, because the reseller is asking someone else for it too.

The defences that hold against attention-driven attacks

Burst-shaped protest traffic and on-demand mitigation are a poor fit. Detection, human decision, BGP announcement and route convergence all stack up, and a campaign built around a twenty-minute window can finish, be claimed and be screenshotted before your traffic ever reaches a scrubbing centre. Always-on for the symbolic hostnames, on-demand for the rest, is usually the honest compromise; the trade-offs in cost and latency are set out in our comparison of always-on versus on-demand DDoS protection.

Volume is rarely the reason a symbolic target falls over. Origin IP leakage is. Stale A records on a decommissioned subdomain, a mail or staging host on the same range, an origin address sitting in certificate transparency history from a certificate issued three years ago. A 5 Gbps direct-to-origin flood beats a proxy that was never bypassed at all. Audit your own DNS zone and CT logs before an attacker does, and lock the origin to accept traffic only from your provider’s ranges.

Authoritative DNS is the layer most often left unmanaged on exactly the sites hacktivists pick. Councils, small agencies and campaign microsites routinely run registrar-bundled nameservers with no anycast spread and no mitigation, so the nameservers fall before the web tier is even touched. Closing that gap is cheap relative to everything else you will spend, and our guide to DNS DDoS attack protection and the gaps most estates leave open lists what to check.

At the application layer, three controls do most of the work against protest traffic: rate limits on search and login with a sensible response for exceeded limits, full-page caching of the homepage and other high-traffic public pages so the origin is not touched, and a static fallback page hosted somewhere completely separate from your main infrastructure.

Finally, the contract. Managed should mean pre-attack tuning against your real traffic baseline, named escalation contacts on both sides, explicit authority for the provider to change policy without waiting for your sign-off, and a defined report. If nobody on the provider’s side can act at 03:00 without waking your CTO, you have bought monitoring, not management.

Preparing before your organisation becomes a symbol

Motive is predictive, so watch the triggers. Contract awards, public statements by executives, sanctions news touching your sector, court dates, planning votes, and sector-wide campaigns announced days in advance in open channels. A contested planning vote at 09:00 is a scheduled risk event, the same as a product launch.

Picture that council: an amplification flood against the network edge, an HTTP GET flood on the site search endpoint, and authoritative DNS sitting on registrar-bundled nameservers with no protection. The web tier might hold. The nameservers will not, and the outage will be total, which is the screenshot the campaign wanted.

Your comms plan should not feed the objective. Factual status updates on a status page hosted off your main infrastructure; no engagement with the claiming channel, no quoting it, no naming it; one named person who signs off wording; and an agreed line that describes impact and restoration without confirming attribution you have not verified. Resist the temptation to say “we repelled a major attack”if it was 4 Gbps for eleven minutes. Someone will check.

On the legal side, unauthorised acts impairing the operation of a computer are an offence under section 3 of the Computer Misuse Act 1990, as amended by the Police and Justice Act 2006. Report through Action Fraud, and use the National Cyber Security Centre reporting route where the incident is significant or touches critical services. Be realistic about prosecution: attribution across borders is hard and cases are slow, and what makes any outcome possible is the evidence you preserved in the first 24 hours. Our UK playbook for legal action after a DDoS attack sets out the sequence.

Keep the pre-attack checklist short enough that people actually do it: tested failover, a cached status page off your main infrastructure, a provider contact tree with out-of-hours numbers that someone has rung this quarter, and a rehearsed ten-minute triage. Read against the grain of the loud claims, hacktivist DDoS attack motives tell you to expect something short, noisy, symbolically aimed and technically ordinary, and to spend your money on the surfaces that fail quietly while everyone is watching the homepage.

Frequently Asked Questions

What motivates hacktivist DDoS attacks compared with criminal ones?

Hacktivists want attention: coverage, screenshots and status within a coordinating channel, usually tied to a political grievance, a policy, a contract or something someone said in public. Criminal attackers want money or a commercial effect, so they are quieter, more persistent and less interested in being seen. That difference shows up in duration, target choice and whether a claim is posted at all.

Are hacktivist DDoS attacks usually large, or is the volume overstated?

Claims are frequently overstated. Many campaigns run well under 10 Gbps and under an hour, and the FBI’s IC3 notice of 4 November 2022 observed that hacktivist DDoS activity against critical infrastructure produced limited operational impact while attracting outsized publicity. Small is still enough to take down unprotected authoritative DNS or a leaked origin address.

How can we tell whether a claimed attack actually affected our site?

Check authoritative DNS resolution, then network and transport counters, then per-endpoint request rates and error codes for the claimed window. Compare against multi-region synthetic monitoring rather than a public reachability checker, which reports from one vantage point. If your own telemetry shows no deviation, the claim is unsupported and you should say so with data rather than assertion.

Should we say anything publicly when a group claims an attack on us?

Publish factual status and restoration updates on a status page hosted separately from your main infrastructure, and say nothing that engages the claiming channel or amplifies its name. Do not confirm attribution you cannot verify. One named person should sign off all wording, and the line should describe user impact and timings, not adjectives.

Is launching a hacktivist DDoS attack illegal in the UK?

Yes. Deliberately impairing the operation of a computer without authorisation is an offence under section 3 of the Computer Misuse Act 1990, as amended by the Police and Justice Act 2006, and political motivation is not a defence. Participation using a booter service counts, as does supplying or operating one.

Does always-on protection make sense if attacks only last minutes?

For the hostnames most likely to be targeted, yes, precisely because they last minutes. On-demand diversion has to detect, decide, announce and converge, which can consume most of a twenty-minute burst. Running always-on for the symbolic public hostnames and on-demand for the wider estate is normally the sensible balance of cost and coverage.

Terabit DDOS Attack: What It Means for Your Site

Terabit DDOS Attack: What It Means for Your Site

Every few months a mitigation provider publishes a traffic graph with a new peak on it, the trade press repeats the figure, and somewhere in the UK a head of infrastructure forwards the link to their team with one line attached: are we covered for this? A terabit DDoS attack makes an excellent headline and a poor planning document. For a mid-market ecommerce or SaaS platform running a few hundred Mbps of normal traffic, with occasional spikes to a couple of Gbps, the record figures change almost nothing about what should be built. The things that actually take those sites offline are smaller, quieter and mostly unrelated to volume records.

What follows is the reasoning behind that claim, and then the specific evidence to demand from any provider whose sales deck leads with a terabit number.

What a terabit DDoS attack actually is, and where the traffic lands

A distributed denial-of-service (DDoS) attack at terabit scale means aggregate inbound traffic measured in terabits per second (Tbps), typically a flood of User Datagram Protocol (UDP) packets sent from tens of thousands of compromised hosts towards a target address or prefix. Three numbers describe such an event and they are not interchangeable: peak bandwidth in Tbps, packet rate in packets per second (pps), and total bytes delivered over the life of the attack.

Peak Tbps sells press releases. Packet rate is what kills stateful devices, because a firewall or load balancer has a pps ceiling long before it has a bits-per-second ceiling. Total bytes delivered is the honest measure of how much traffic a network really absorbed, and it is usually the number missing from the headline. Cloudflare’s disclosure of a 7.3 Tbps flood in mid-2025 put it at roughly 37.4 terabytes delivered in about 45 seconds. Short, brutal, over before most on-call rotas have finished reading the first alert.

Reading the record numbers properly

Publicly reported peaks have climbed quickly. Cloudflare reported 7.3 Tbps in mid-2025, then 11.5 Tbps later in the year, and by late 2025 its own quarterly DDoS threat reports had pushed the disclosed peak past 20 Tbps, with the trend line heading towards 30 Tbps. Several of the largest lasted under a minute. Duration matters more than most buyers assume, and it is the detail that reframes the whole on-demand mitigation question later in this piece.

The other detail worth holding onto: these measurements are taken at a global anycast edge spread across hundreds of points of presence. Anycast means the same IP address is announced from many locations at once, so a botnet firing at one address is automatically split across dozens of scrubbing points by internet routing. No single facility receives the full volume, and no single customer origin ever sees it. Treating a 30 Tbps figure as “the flood that would arrive at my rack”is a category error, not a conservative assumption.

Where the volume is absorbed

Terabit-scale traffic is eaten by upstream transit and peering capacity, by anycast distribution across scrubbing locations, and by filtering hardware sitting in those locations. None of that sits in your cabinet. Your firewall, your load balancer and your origin uplink are downstream of every decision that determines whether a large flood is survivable, which is why capacity is the one part of the problem you genuinely cannot fix yourself.

The sources behind the biggest floods are consistent: large botnets of Internet of Things (IoT) devices, compromised consumer routers and customer premises equipment, plus reflection and amplification through exposed UDP services. The economics are well documented in the booter and stresser market, where rented capacity is sold by the minute; the practical defender response to botnets available for hire has little to do with matching their peak output.

Why volume records rarely explain why a UK site went down

Run the arithmetic on your own estate and the record numbers lose their grip. A 10 Gbps origin uplink is saturated by roughly 0.03 percent of a 30 Tbps event. A 1 Gbps uplink goes under at about 0.003 percent. Anything above a few Gbps pointed at a single origin is already a complete outage, so the difference between a 7 Tbps record and a 30 Tbps record is academic from where you sit. Your real ceiling is three to five orders of magnitude below the league table.

So what does take these sites down?

Origin IP leakage, the most common bypass

More proxy bypass is caused by leaked origin addresses than by raw volume. The usual culprits are boring and repeatable: outbound mail headers that stamp the sending host’s real address on every transactional email; historical DNS records sitting in passive DNS databases years after a migration; certificate transparency logs listing staging, dev and admin subdomains that resolve straight to the origin; monitoring probes and payment callbacks configured against the origin IP because the proxy interfered with a health check once in 2021.

A terabit capability is irrelevant when 2 Gbps arrives at an address that was never supposed to be public. The fix is unglamorous: firewall the origin so it accepts traffic only from your provider’s published ranges or a private cross-connect, rotate the origin IP after onboarding, and send mail through a separate relay.

Application-layer floods that never register in Tbps

Layer 7 attacks are measured in requests per second, and the good ones are surgical. Consider 120,000 requests per second against an uncached product search endpoint on a mid-sized ecommerce stack. Database connections exhaust, queue depth climbs, the site returns 502s, and the whole thing registers well under 1 Gbps. Invisible in any terabit ranking. Cart, login, coupon validation and faceted search are the endpoints attackers reach for, because each request costs the target far more than it costs the botnet. The first sixty minutes of an ecommerce DDoS incident almost always involve this kind of traffic rather than a wall of UDP.

Authoritative DNS, the layer nobody owns

Authoritative Domain Name System (DNS) service is the surface most often left with whatever the registrar or hosting control panel supplied at setup. It is also the single point where a modest query flood removes every service at once, including the well-protected ones, because a client that cannot resolve your name never reaches your carefully scrubbed web tier. Three questions settle it: who operates your authoritative DNS, across how many independent anycast networks, and is that service inside the same mitigation contract as your web traffic? If the answer to the third is no, sound DNS DDoS attack protection is the cheapest resilience upgrade available to most UK buyers, and the specific gaps to close at the DNS layer are worth reviewing before renewal.

Deployment models that can absorb terabit-scale volume, and what each costs you

Four models dominate the UK market, and each buys capacity in a different currency.

  • Reverse proxy on anycast. Very large aggregate capacity, fast HTTP and HTTPS mitigation, straightforward onboarding by DNS change. Protects only what resolves through it, and collapses as a control the moment the origin is directly reachable.
  • Border Gateway Protocol (BGP) scrubbing and diversion. Protects whole prefixes and non-HTTP services such as SMTP, game protocols and APIs on odd ports. Needs a /24 or larger that you control, plus a return path by Generic Routing Encapsulation (GRE) tunnel or cross-connect, and route propagation adds minutes you must plan around.
  • Hosting-level and data centre filtering. Convenient, frequently bundled, sometimes genuinely capable. Capacity is shared across every tenant and the ceiling is whatever the facility’s upstream transit contract allows, which is rarely disclosed in the order form.
  • On-premise appliances. Useful for application-layer inspection and internal east-west protection. Useless against volumetric floods, because the flood arrives on a pipe the appliance cannot widen.

Always-on versus on-demand against a 40-second flood

Here is where the record-breaking figures earn their place in the analysis. A flood lasting 35 to 45 seconds exposes the on-demand model’s central weakness. Detection has to fire, a human has to authorise diversion, a BGP announcement has to go out, and routes have to propagate across the internet. That sequence can consume more time than the attack lasts, producing the graph nobody wants in the post-incident pack: mitigation starting just as the traffic stops.

The recommendation is blunt. Always-on for public web surfaces, and on-demand reserved for cases where diversion genuinely costs you in latency or money, such as a latency-sensitive trading path or a rarely attacked internal prefix. The trade-offs between always-on and on-demand protection are real, but sub-minute bursts have tilted the balance decisively for anything customer-facing.

How to read a provider’s terabit capacity claim without a lab

Capacity claims come in three flavours and only one of them affects your uptime.

  1. Aggregate network capacity. The sum of everything, everywhere. Marketing number.
  2. Per-point-of-presence capacity. More honest, still not yours.
  3. Capacity in the region serving your users. For a UK customer base, that means London and, ideally, a second European site for failover. This is the only figure that decides whether your Tuesday morning stays quiet.

Then trace the resale chain. A meaningful share of UK managed DDoS protection is resold, sometimes twice, and the capacity in the deck may belong to a network the seller has no operational control over. Ask directly: whose autonomous system number announces my prefix during mitigation, whose scrubbing centres filter it, and which company employs the engineers who join the bridge at 03:00? A reseller can be a perfectly good buy if the answers are clear and the escalation path is named. It is the vagueness that should worry you.

Evidence to request instead of a slide

  • A redacted attack report from the last quarter showing vector breakdown, peak figures, detection timestamp and mitigation timestamp;
  • The service level agreement (SLA) definition of time to mitigate, with confirmation that the clock starts at detection rather than at ticket acknowledgement, a distinction covered in more depth in this examination of what SLA mitigation seconds actually mean;
  • A named escalation matrix with roles and out-of-hours numbers, not a shared inbox;
  • Change-freeze behaviour during peak trading, including who can push a rule change on Black Friday and who signs it off.

What “managed”has to mean in writing

Managed is the most elastic word in this market. Insist on written detail for onboarding and initial rule tuning, always-on traffic baselining, who is authorised to issue a mitigation order without customer sign-off, how a false positive gets rolled back mid-flash-sale, and what a post-incident report contains and when it arrives. If nobody on the provider’s side can change policy at 03:00 without waking your CTO, you have bought monitoring, not management. The buyer’s guide to managed DDoS protection in the UK goes further on how these contracts are typically priced and scoped.

Sizing your own exposure and building the business case

Work out your real ceiling in this order: origin port speed, upstream transit commit (the committed rate, not the burst), load balancer packet-per-second throughput, then authoritative DNS query capacity. Most teams discover the binding constraint is not the number they assumed. A 10 Gbps port fronted by an appliance that tips over at a few hundred thousand packets per second has a pps ceiling, not a bandwidth ceiling.

UK pricing tends to be built from committed clean bandwidth, per-prefix or per-domain charges, overage on attack traffic, and a cap on mitigation events per year. Read the overage clause carefully, because a single large event billed on attack traffic can dwarf the annual subscription.

Build the case from downtime cost, not from last quarter’s record. Do the division on your own trading figures: a shop turning over roughly £40,000 a day is losing, on that arithmetic alone, in the region of £1,700 of gross revenue per hour offline, before chargebacks, support volume and paid advertising spend burned on landing pages nobody can reach. That figure justifies the spend. A 30 Tbps headline does not.

One scenario to rehearse before it arrives: the ransom demand, usually a short demonstration burst followed by a deadline and a wallet address. Escalate to your provider and report it to Action Fraud, the UK’s national fraud and cybercrime reporting centre. Never pay. Payment marks the target as willing and invites the next demand, a pattern seen repeatedly in extortion cases involving DDoS blackmail prosecutions.

A short exposure review to run this month

  1. Leak hunt: check certificate transparency logs, passive DNS history and outbound mail headers for your origin address, then lock the origin to provider ranges only;
  2. DNS resilience check: confirm who runs authoritative DNS, how many anycast networks carry it, and whether it sits inside your mitigation contract;
  3. Failover test: divert and return during a maintenance window, and time it properly against the SLA;
  4. Escalation contact: one named person at the provider, one deputy, tested out of hours, documented where the on-call engineer can find it at 03:00.

The UK’s National Cyber Security Centre publishes practical guidance on denial of service preparation that pairs well with that checklist, particularly on understanding your own service dependencies before an incident rather than during one.

Frequently Asked Questions

How big is the largest terabit DDoS attack recorded so far?

Publicly reported peaks moved from 7.3 Tbps, disclosed by Cloudflare in mid-2025, through 11.5 Tbps, to figures above 20 Tbps in Cloudflare’s own reporting by late 2025. All of these are vendor-reported measurements taken at a global anycast edge, and the record moves often, so treat any figure as accurate at the time of writing rather than permanent.

Would a terabit DDoS attack take down a site that already has protection?

If the site is behind a large anycast network and the origin is not directly reachable, a terabit flood is absorbed across hundreds of locations and no single facility sees the full volume. The realistic failure modes are different: a leaked origin IP, an application-layer flood aimed at expensive endpoints, or an unprotected authoritative DNS zone. Fix those three before worrying about the peak figure.

How much bandwidth does it take to knock a typical business website offline?

Far less than the headlines suggest. A 1 Gbps origin uplink saturates at roughly 0.003 percent of a 30 Tbps event, and a 10 Gbps uplink at roughly 0.03 percent, so anything above a few Gbps arriving at a single unprotected origin is already a full outage. Stateful devices often fail earlier still, on packet rate rather than bandwidth.

Can on-demand DDoS protection stop a 40-second terabit flood?

Usually not in time. Detection, human authorisation, BGP announcement and route propagation can together take longer than a 35 to 45 second burst, so mitigation engages as the traffic ends. Always-on filtering is the sensible default for public web surfaces, with on-demand kept for prefixes where diversion carries a genuine latency or cost penalty.

What evidence should I ask for when a provider claims terabit-scale scrubbing capacity?

Ask for capacity in the region serving your users rather than the global aggregate, a redacted attack report from the last quarter with detection and mitigation timestamps, and an SLA that starts the time-to-mitigate clock at detection. Then trace the resale chain to the party that owns the scrubbing points and employs the on-call engineers. If a claimed terabit DDoS attack capability cannot be attached to a named network, named facilities and a named escalation path, treat the number as somebody else’s. If that SLA is ever tested in anger, see our UK playbook for legal action after a DDoS attack for evidence and claims steps.

DNS Provider Outage Attack: How to Stay Reachable

DNS Provider Outage Attack: How to Stay Reachable

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

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

What a DNS provider outage attack actually breaks

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

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

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

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

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

Why some users stay online and others see nothing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Decisions to make before the outage, not during it

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

Three more decisions belong on the same page:

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

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

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

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

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

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

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

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

Frequently Asked Questions

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

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

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

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

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

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

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

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

Can I run DNSSEC across two DNS providers?

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

Botnet for Hire DDOS: What Defenders Should Do

A four minute outage on a Tuesday morning, an email quoting a cryptocurrency address, and a screenshot of a control panel with a countdown timer on it: for most mid-sized UK firms, that is what a botnet for hire DDoS attack looks like from the inside. It looks nothing like the terabit-per-second records that fill vendor datasheets. The attack is short, it is bought by the minute, and it is aimed at whichever part of the estate nobody bought protection for. Booters and stressers, the subscription websites that sell distributed denial-of-service (DDoS) capacity to anyone with a payment method, have turned what used to be a specialist capability into a consumer product with a pricing page.

What follows maps what the hire market realistically delivers against the three surfaces that need defending, and what a UK protection contract has to say in writing before it is worth signing.

What the DDoS-for-hire market actually sells today

The product is a subscription, not a hit. Buyers pay monthly for a tier that caps attack duration (often measured in minutes rather than hours), limits how many attacks can run concurrently, and unlocks particular attack methods on the higher plans. The National Crime Agency has repeatedly described these services as cheap and requiring almost no technical skill, which is why the volume of nuisance attacks against small and mid-sized targets stays stubbornly high. Cost is not the constraint. Duration is.

The firepower behind the panel has also changed. Classic Windows PC botnets have largely given way to compromised Internet of Things devices (routers, cameras, digital video recorders), hijacked cloud instances bought with stolen cards, open reflectors on the public internet, and rented residential proxy pools that route requests through real consumer broadband lines. That last category matters more than the raw node count, and the mitigation section below explains why.

The “stress testing”framing on these sites is a fig leaf. A legitimate load-testing service verifies domain ownership, requires written authorisation from the asset owner, and agrees a test window. Booters do none of that. You type in a hostname or IP address and press start.

Enforcement has changed the market without ending it. Operation PowerOFF, the international campaign run with Europol, the FBI and the NCA, has seized booter domains in successive waves since 2018, and in March 2023 the NCA disclosed that it had been running its own fake DDoS-for-hire sites to collect data on the people signing up. Takedowns compress supply for a while; new panels appear under new branding. What has genuinely shifted is buyer risk, because the paper trail now sometimes leads back through law enforcement infrastructure.

Four attack profiles a rented botnet actually delivers

Short volumetric bursts

Because the subscription pays for duration, the typical hired attack is a burst sized to fit the slot: a few minutes of packets-per-second aimed at your uplink, sometimes repeated on a loop through the working day. Against this profile, peak scrubbing capacity on a datasheet is close to irrelevant. If detection plus diversion takes fifteen minutes and the attack lasts five, the traffic has stopped before mitigation engaged, and you still took the outage, still fielded the customer complaints, and still have nothing useful in the incident report. Time-to-mitigate, with a defined clock start, is the number that decides the outcome.

Reflection and amplification

Reflection borrows other people’s bandwidth. The attacker spoofs your address and queries open services on the internet, which then send far larger replies to you. CISA’s alert TA14-017 on UDP-based amplification attacks lists indicative bandwidth amplification factors including roughly 556 times for Network Time Protocol (NTP) and up to 51,000 times for memcached, alongside Domain Name System (DNS) and Connection-less Lightweight Directory Access Protocol (CLDAP) vectors. The 1.35 Tbps memcached flood against GitHub in February 2018, documented publicly by Akamai, came from a modest number of reflectors. The practical consequence for a mid-sized firm is unpleasant: the botnet does not need to be large to saturate a 1 Gbps or 10 Gbps uplink.

HTTP floods through residential proxies

Layer 7 attacks skip the pipe and go for the expensive parts of the application: internal site search, cart and checkout, login, password reset, and any API endpoint that hits the database on every call. Delivered through residential proxy pools, the requests arrive from real UK consumer IP addresses with clean reputation scores. Blocklists and ASN filtering do very little here. A modest rate of well-shaped requests against a search endpoint can take down an origin that would shrug off a far larger volume of static page requests.

Authoritative DNS floods

The fourth profile is the one that keeps working, because it is the one nobody bought protection for. Instead of attacking the website, the attacker floods the authoritative nameservers that answer queries for your domain. Resolve nothing, reach nothing: web, mail, VPN, API, all of it.

Which surfaces a hired botnet finds first

Network and transport. Ask your transit provider what it will absorb before your uplink saturates, and what it does when the flood exceeds that. Some will null-route your prefix to protect their own network, which achieves the attacker’s goal for them at no extra charge.

Application layer. A proxy tuned for volumetric traffic and a proxy tuned for bot behaviour are different products, sometimes from the same vendor at different price points. Absorbing 200 Gbps of UDP says nothing about whether the platform can separate a residential-proxy request flood from genuine Black Friday demand.

Authoritative DNS. This is the most common gap in UK estates: the web front end sits behind a paid proxy while authoritative DNS stays on the registrar’s free tier, unmonitored and unmentioned in the mitigation contract. A rented botnet pointed at those nameservers takes the whole estate offline without ever touching the protected site. Proper DNS DDoS attack protection means anycast authoritative service with query-rate controls, spread across more than one provider if the domain earns revenue, and it needs to be a named line item in the contract rather than an assumption.

Origin IP leakage. Proxy bypass is far more often a leak than a breakthrough. Historical DNS records in passive DNS databases, certificate transparency logs listing every subdomain you have ever issued a certificate for, outbound mail headers advertising the origin, and forgotten staging, webmail or cPanel hostnames all publish the address the proxy is meant to hide. Rotating the origin IP after onboarding and locking the origin firewall to the proxy’s published ranges costs an afternoon. Buying more capacity to compensate costs a great deal more and does not fix the hole.

Matching mitigation to the threat

Reverse proxy. Fastest to deploy, strongest at layer 7, and the right answer for HTTP floods. Worthless if the origin address is public and the origin firewall accepts traffic from anywhere.

BGP scrubbing. Diverts whole IP ranges, covers non-HTTP services such as SMTP, game protocols, VPN concentrators and RDP gateways, and is the only sensible model if you run your own address space. The trade-offs are route convergence time, the return path (GRE tunnel or dedicated link) and the fact that on-demand diversion has to be triggered before it does anything.

Hosting-level or transit filtering. Read the small print. Plenty of firms sold as a DDoS protected hosting provider include basic layer 3 and 4 filtering at the edge with everything meaningful, layer 7 rules, tuning, per-incident reporting, priced as an upsell. Ask for the mitigation capacity figure at the point of presence serving UK traffic, not the global aggregate.

On the always-on versus on-demand question, short bursts settle it. Detection plus diversion on an on-demand service frequently outlasts the attack, which is the whole argument for keeping traffic on-path permanently for revenue-generating assets. The trade-offs, latency, cost and change control, are set out in more detail in this comparison of always-on and on-demand protection models, and the SLA wording that decides when the clock starts is picked apart in this guide to what time-to-mitigate seconds really mean.

Extortion, hacktivism and the note that arrives with the traffic

The ransom DDoS pattern has been stable for years: a short demonstration burst against a production asset, an email naming a deadline and a cryptocurrency wallet, and a threat of something far larger if the deadline passes. Sometimes the demonstration is impressive. Often it is a few minutes of reflection traffic bought from a booter panel, which tells you the sender’s budget runs to a subscription rather than a serious campaign.

Read the demonstration attack as evidence. Vector, duration, sustained bit rate and packet rate from your provider’s incident report are a better guide to real capability than anything in the note itself. A three minute NTP reflection burst and a promise of 2 Tbps do not belong to the same actor.

Paying is the wrong move for reasons that have nothing to do with principle. Payment confirms a working email address, a solvent victim and a decision-maker who folds, which is exactly the profile that gets resold. Preserve the note with full headers, report to Action Fraud (serious incidents get escalated to the NCA), and tell your mitigation provider immediately so they can raise thresholds before the deadline. On communications, publish a status page acknowledging degraded service and nothing about which vendor is mitigating, which thresholds tripped or what the traffic is doing. The first hour of decisions is covered in more depth in this playbook for an ecommerce site under attack.

The UK legal position for buyers, sellers and victims

Two provisions of the Computer Misuse Act 1990 do the work. Section 3 covers unauthorised acts intended to impair the operation of a computer, which is what a DDoS attack is. Section 3A covers making, supplying or obtaining articles for use in such offences, and it is the provision that reaches booter operators and, in some cases, their customers.

Buying an attack is an offence even if the buyer never touches the target. Payments leave records, panels keep logs, and seized infrastructure has produced customer lists more than once. Prosecutions of the people behind botnets do happen, as in the case of the Florida man charged over a botnet attack on Akamai, though attribution more often stalls at spoofed source addresses, bulletproof hosting and jurisdictions that do not answer requests.

Victims should log the mitigation provider’s attack report with vector breakdown and timestamps, netflow or sampled traffic from the edge, application logs showing failed transactions, and a defensible estimate of lost revenue. Do that before assuming anyone will be arrested, because the evidence file has value for insurance and for the contract review regardless.

Buying protection that holds up: what to ask before you sign

Most UK contracts in this space are resale to some degree, which is not automatically a problem. Not knowing is the problem. Three questions separate a real service from a reseller dashboard:

  • Whose scrubbing network sits behind the invoice, and what is the contracted capacity at the point of presence serving UK traffic?
  • During an attack, does escalation reach an engineer at the underlying network operator, or does it stop at a first-line desk that raises a ticket?
  • Is a named human empowered to change policy at 03:00 without your sign-off? If not, you have bought monitoring, not management.

“Managed”should mean onboarding and initial rule tuning, traffic baselining before the first incident, alerting to named contacts, out-of-hours cover with a defined response target, a written escalation matrix and a per-incident attack report afterwards. Ask for a time-to-mitigate SLA with the clock start defined in the contract, and rehearse the failover at least once with the provider on the call. Typical structures and price bands are broken down in this guide to managed DDoS protection in the UK.

Build the business case on the real threat model, not a hypothetical record breaker. Work it through with your own figures: a retailer turning over £40,000 an hour at peak would, on a straight pro-rata basis, lose in the region of £2,700 for every four minute burst that lands in the wrong window. Four of those a year, plus the support cost and the customers who bounce to a competitor, is the number to put next to the annual protection fee. Short repeated outages are what the hire market delivers, and they are what the budget line has to be justified against.

Frequently Asked Questions

What does a botnet for hire DDoS attack actually cost the attacker?

Booter and stresser plans are sold as low-cost monthly subscriptions with tiered attack duration limits and concurrent attack slots, rather than per-attack pricing. The NCA has consistently described these services as cheap and requiring little technical skill. The practical point for defenders is that the cost of launching a nuisance attack is trivially low compared with the cost of absorbing one.

Is buying a DDoS-for-hire or booter service illegal in the UK?

Yes. Section 3 of the Computer Misuse Act 1990 covers unauthorised acts intended to impair the operation of a computer, and section 3A covers obtaining or supplying articles for use in such offences. Paying someone else to run the attack does not put a buyer outside the Act, and the NCA’s March 2023 disclosure that it ran fake booter sites shows enforcement is aimed at customers as well as operators.

Can a rented botnet get past Cloudflare or another reverse proxy?

Usually by going around it rather than through it. Origin IP addresses leak through historical DNS records, certificate transparency logs, outbound mail headers and forgotten staging or webmail subdomains, and traffic sent straight to the origin never meets the proxy. Rotate the origin address after onboarding and restrict the origin firewall to the proxy’s published IP ranges.

Should we pay a ransom DDoS demand?

No. Payment identifies you as a target that pays and tends to invite repeat demands, sometimes from different actors. Preserve the note with full headers, report it to Action Fraud, notify your mitigation provider so they can tighten thresholds before the stated deadline, and treat the demonstration burst as evidence of what the sender can actually do.

How do we tell a hired-botnet attack from a traffic spike or a bad crawler?

Genuine demand and legitimate crawlers follow the shape of your site: varied paths, referrers, session progression and a plausible geographic mix. A hired layer 7 flood concentrates on a small number of expensive endpoints, shows near-identical request timing and header patterns, and produces no conversions or downstream page views. Baselining traffic before an incident is what makes that comparison possible on the day.



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.

“`

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. 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.