Application Layer DDOS Protection: 7 Real Gaps

Application Layer DDOS Protection: 7 Real Gaps

A business that has signed a scrubbing contract, bought a web application firewall (WAF) licence and put a managed service retainer on the renewal calendar tends to file DDoS under “handled”, somewhere between the firewall renewal and the cyber insurance schedule. Then the search page stops answering on a Tuesday afternoon, the origin database sits at 100 per cent CPU, and the edge bandwidth graph never moves. That is the moment most buyers discover that application layer DDoS protection and network-layer capacity are two different purchases, and they only bought one of them properly.

What follows assumes you already have something in place: a reverse proxy, a WAF, a hosting-level filter, maybe all three. The question is not what a Layer 7 attack is. The question is why the thing you are paying for did not stop it.

Why Layer 7 attacks slip past protection you already pay for

An application-layer, or Layer 7, attack sends requests that look legitimate. Valid HTTP, correct headers, often real browsers or real mobile clients driven by malware. The traffic targets whatever endpoint costs the most to serve: a full-text search, a faceted product filter, a login that triggers a password hash, a PDF or invoice render, a GraphQL query that fans out across three services. Volume is beside the point. A few thousand requests per second against a search endpoint can exhaust a connection pool that would shrug off a hundred times that in cached image requests.

So a 40Gbps clean bandwidth commitment tells you nothing about whether 8,000 requests per second to /search gets stopped. Those are different units measuring different failure modes. Network-layer defences count bits; Layer 7 defences have to count requests, weight them by cost, and decide which sessions are real.

Assess three surfaces separately, not as one product

Every estate has three surfaces that fail independently, and contracts routinely cover one or two of them:

  • Network and transport: volumetric floods, reflection and amplification, SYN floods. This is where scrubbing capacity and BGP diversion matter.
  • Application layer: HTTP and HTTPS request floods, slow-read and slow-post attacks, API abuse. This is proxy, challenge and rate-limiting territory.
  • Authoritative DNS: if the name does not resolve, everything above it is decoration.

Write those three headings on a page and map each line of your current contract to one of them. The gaps usually appear within ten minutes.

Read your own telemetry first

The diagnostic signature is unglamorous and reliable. Edge bandwidth flat at normal levels, request counts up sharply on one or two URL paths, origin CPU and database connections climbing, error rates rising on those paths before anywhere else. That pattern points at an application flood, not a pipe-filling attack. If you are still deciding whether you are under attack at all rather than suffering a self-inflicted outage, the triage steps in this guide to telling a DDoS from an ordinary outage will save you arguing about it for an hour.

Gap 1: your origin IP is still reachable, so the proxy is optional

More reverse proxies are bypassed through origin IP leakage than through sheer attack volume. Not close, in practice. An attacker who knows the origin address simply skips the edge entirely and hits the web server directly, and every rule you tuned at the proxy becomes advisory.

The address leaks from predictable places: historical DNS A records captured by passive DNS services long before you onboarded; mail headers from transactional email sent by the same host; TLS certificate transparency logs, which have been mandatory for publicly trusted certificates in Chrome since 2018 and are publicly searchable, so issuing a cert for staging.yourcompany.co.uk or admin.yourcompany.co.uk publishes that hostname to anyone watching; verbose error pages that print internal hostnames; and API endpoints that were pointed direct-to-origin for latency reasons and never moved back.

The fix is dull and effective. Firewall the origin so it accepts inbound traffic only from your provider’s published IP ranges, rotate the origin address after onboarding so historical records are worthless, and then verify it: curl the origin IP directly with the Host header set, from a network outside your own, and confirm you get a refusal rather than a page. Do that before you buy anything else. There is no point evaluating challenge algorithms while the front door has no lock on it.

Gap 2: the WAF is blocking signatures, not behaviour

A WAF ruleset is built to recognise malicious payloads: SQL injection strings, path traversal, known exploit patterns. A Layer 7 flood contains none of those. Each individual request is unremarkable and would be served happily on a quiet Wednesday. Volume in aggregate is the attack, and signature matching has nothing to match.

What actually works sits one layer up in logic: per-session request budgets rather than per-IP counters; JavaScript and cryptographic proof-of-work challenges that cost the client something; and cost-weighted rate limits, which is the control most estates are missing. A request for a cached product image and a request that triggers a full-text search or a PDF render are not equivalent, and a flat limit treats them as if they were. Set it low enough to protect search and you throttle genuine shoppers browsing a catalogue. Set it high enough for browsing and the expensive path stays wide open.

Per-IP limiting also collapses against distribution. A botnet spread across tens of thousands of residential addresses, each sending a handful of requests a minute, never trips a per-IP threshold anywhere. Every source looks like a normal user on a normal broadband line, because it largely is one. The defender’s view of botnet-driven floods is worth reading if you want to understand why source-based blocking degrades as the botnet grows.

One more thing procurement should force into the timeline: the false-positive conversation. Tuning thresholds for your real traffic shape, including scrapers you want to keep and the price-comparison feed you depend on, belongs in onboarding week. Not at 04:00 during an incident, with the commercial director asking why paying customers are seeing a challenge page.

Gap 3: your API and mobile traffic bypass the human-facing defences

Browser challenges, fingerprinting and cookie-based session tracking assume a browser. Your mobile app does not have one. Neither does your partner’s integration, your payment webhook receiver, or the B2B client pulling stock levels every thirty seconds. Turn on aggressive challenges and you break them; exempt them and you have created an unprotected lane straight to the most expensive endpoints you own.

Authenticated APIs are the attractive target precisely because they skip caching and touch the database on every call. Checkout APIs, GraphQL endpoints that allow deeply nested queries, and account-history calls all cost real compute per request. Sensible controls here are different in kind: rate limits keyed to API tokens or account identity rather than IP; explicit request cost budgets where a heavy query consumes more of the allowance than a light one; schema validation and query depth limits on GraphQL; and mutual TLS or signed requests for partner traffic so you can distinguish it cleanly.

Check subdomain coverage while you are there. One forgotten host, a legacy api-v1 or a marketing microsite on the same origin, undoes the proxy configuration for everything behind it.

Gap 4: authoritative DNS sits outside the contract

Layer 7 protection and DNS protection are frequently sold as one story and scoped as two line items. Read the schedule. Authoritative DNS is the layer most often left unmanaged, usually because it came free with the registrar years ago and nobody revisited it.

Ask who answers queries for your zone when your primary DNS provider is itself the target, how many anycast points of presence serve UK resolvers, and whether secondary DNS with a second independent provider is included or chargeable. Then look at your TTL values. A 3,600 second TTL means up to an hour before a failover to a backup provider takes effect across resolvers; 60 to 300 seconds, set in advance and left there, gives you near-immediate redirection when you need it. Lowering TTLs during an incident does not help, because the old values are already cached.

Our buyer’s guide to authoritative DNS protection goes through anycast footprints and secondary configurations in more detail, and the record of what happens when a DNS provider itself goes down explains why single-provider dependency keeps producing the same headline.

Gap 5: nobody is contractually obliged to act during the attack

The dividing line is simple. A self-service plan gives you a dashboard, a rate-limiting engine and rules you write and troubleshoot yourself. A managed service means a named engineer on the provider’s side is empowered to change policy at 03:00 without waiting for your sign-off. If that authority is not written down, you have bought monitoring, not management.

Deployment model matters more at Layer 7 than most buyers expect. On-demand mitigation, where traffic is diverted via BGP once an attack is detected, is a defensible trade-off for volumetric floods; detection plus diversion plus route convergence is tolerable when the alternative is paying for always-on capacity you rarely use. It is a poor fit for application attacks. A 5,000 requests-per-second flood against a search endpoint can drain your database connection pool well before diversion completes and traffic starts flowing through the scrubbing path. By the time mitigation is live, you have already taken the outage. The comparison of always-on and on-demand models sets out where each one genuinely earns its cost.

In procurement, run the escalation test rather than reading the SLA summary. Ask who answers the phone at 03:00 on a Sunday, whether that person is in the UK or following the sun, what they are authorised to change unilaterally, and how a customer raises severity. Then look at the wording: time to mitigate versus time to first human response (they are not the same metric), what counts as an attack start for the purposes of the clock, and the exclusions. Many time-to-mitigate commitments apply only to network-layer events and quietly exclude application-layer mitigation altogether.

Gap 6: you are buying a resale chain, not a network

A large number of UK providers resell another vendor’s proxy or scrubbing platform under their own brand. That is not automatically a problem; the underlying platforms are often excellent, and the reseller may add genuine tuning value. The problem is the extra escalation hop. During an incident, the distance between you and the engineer who can actually push a rule change is measured in handoffs, and each one costs minutes you do not have.

Questions that tend to get honest answers: which points of presence serve UK traffic and where do they sit; what is the underlying platform; who holds the capacity contract; can your engineers speak directly to the platform’s operations team during a severity-one event, or does everything route through account management. If the answers are vague, the escalation path is probably vaguer.

Gap 7: no post-attack evidence, so nothing improves

Judge a provider on the quality of a redacted post-incident report, not on a headline Tbps figure. Anyone can print a capacity number. A report that names the endpoint under attack, the rule that fired, the time from detection to mitigation and the residual request rate still reaching your origin tells you whether there was an engineer watching.

A usable attack report contains request rates broken down by endpoint and method, source distribution by network and geography, the vector breakdown, which mitigation action was applied and when, and what got through. That evidence has value well beyond engineering. Cyber insurers ask for it, boards ask for it, and any legal route following an attack depends on contemporaneous logs rather than recollection. The UK’s National Cyber Security Centre sets out the same expectation in its denial of service guidance collection: know what normal looks like, and capture what happened.

On the business case, argue from downtime cost per hour, not the headline monthly fee. UK managed pricing is typically assembled from four components: clean bandwidth commitment, the number of protected assets or domains, request volume tiers, and the level of incident support. Those variables move independently, so two quotes with similar monthly figures can differ enormously in what they cover at Layer 7. Work out revenue and recovery cost for a four-hour outage during your busiest trading window, and the comparison becomes straightforward.

The pre-purchase checklist

  1. Curl your origin IP directly from an external network with the Host header set. Do you get a page?
  2. Ask for the endpoint-level rate-limiting configuration, weighted by request cost, that the provider proposes for your top five most expensive paths.
  3. Confirm in writing which mobile and API traffic is covered, and how, given those clients cannot solve browser challenges.
  4. Check whether authoritative DNS is inside the managed scope, and whether secondary DNS is included.
  5. Establish who changes rules at 03:00, their authority level, and the time-to-mitigate definition that applies to Layer 7 specifically.
  6. Ask what the underlying platform is and how many escalation hops sit between you and it.
  7. Request a redacted Layer 7 post-incident report as a sample deliverable before you sign.

If you are still mapping requirements before shortlisting, our overview of DDoS attack solutions and how they differ covers the architectural options in more detail. Effective application layer DDoS protection is rarely a product decision. It is a coverage decision, an authority decision and an evidence decision, and the estate that gets those three right will survive a request flood that flattens a better-funded competitor.

Frequently Asked Questions

What is the difference between application layer DDoS protection and network layer scrubbing?

Network-layer scrubbing removes volumetric and protocol attacks measured in bits and packets per second, usually by diverting traffic through a scrubbing centre. Application layer DDoS protection inspects HTTP and HTTPS requests, counts them per endpoint and per session, and decides which clients are genuine. A contract covering one does not necessarily cover the other, and the SLA clocks are often defined separately.

Can a WAF alone stop a Layer 7 DDoS attack?

Rarely. A WAF is built to recognise malicious payloads, and a request flood consists of well-formed, individually legitimate requests. Stopping it needs behavioural controls: session-level request budgets, challenges, bot scoring and cost-weighted rate limits on your most expensive endpoints. A WAF with those features enabled and tuned can do the job; a signature-only ruleset will not.

How do attackers find my origin IP and get past the proxy?

Through historical DNS records held by passive DNS services, mail headers from transactional email sent by the same host, certificate transparency logs that publish staging and admin hostnames, verbose error pages, and API endpoints pointed straight at the origin. The countermeasure is to restrict inbound traffic at the origin firewall to your provider’s published IP ranges and rotate the origin address after onboarding.

Does application layer DDoS protection cover APIs and mobile app traffic?

Only if it was scoped to. Browser challenges and JavaScript fingerprinting do nothing for clients that cannot execute JavaScript, so API and mobile paths need token-based limits, request cost budgets, schema and query depth validation, and signed or mutually authenticated requests. Ask the provider specifically how non-browser clients are handled, and check every subdomain is behind the edge.

What does managed application layer DDoS protection typically cost in the UK?

Pricing is usually assembled from clean bandwidth commitment, the number of protected domains or assets, request volume tiers and the incident support level, so published headline figures are hard to compare and change frequently; check current quotes directly. The more useful exercise is calculating your cost of downtime per hour during peak trading and testing the annual protection spend against that. Get each quote broken down by those four components so you are comparing the same coverage.



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.



DDOS or Outage? How to Tell in 10 Minutes

DDOS or Outage? How to Tell in 10 Minutes

The question every on-call engineer eventually asks, somewhere between the first alert and the first angry customer email, is whether they are looking at a DDoS or an outage. It matters more than almost anything else you decide in the first hour, because the two answers send you in opposite directions: one escalates to a scrubbing provider and an attack evidence pack, the other escalates to a supplier status page and your own change log. Guess wrong and you lose the hour. Ten minutes of disciplined triage is usually enough to avoid that, provided you know which signals actually discriminate and which ones fit a hundred unrelated faults.

Why the first ten minutes decide the rest of the incident

Paging a distributed denial-of-service (DDoS) mitigation provider for a failed deployment wastes the one team who could have rolled it back. Rolling back clean code while a botnet chews through your search endpoint wastes the window in which mitigation would have been cheapest to apply. Both mistakes are common, and both come from the same root cause: a single person looking at a single browser tab and reasoning outwards.

Cloudflare’s global outage on 18 November 2025 is the cleanest recent illustration. Large parts of the web returned errors simultaneously, social media immediately assumed a record-breaking attack, and Cloudflare’s own published incident report attributed it to an internal failure involving an oversized bot management configuration file, not to malicious traffic. From a UK office, a worldwide provider failure and a worldwide attack looked identical for the first several minutes. Plenty of teams spent that time on the wrong phone call.

Set the ground rule before the next incident, not during it. One named person owns the diagnosis and says out loud what they currently believe and why. Everyone else gathers evidence and reports it to that person. Diagnosis by group chat produces four confident theories and no decision.

The evidence that actually separates a DDoS from an outage

Vague symptom lists are useless here. “The site is slow”describes a volumetric flood, a saturated database connection pool, a mis-sized instance and a bad ORM query equally well. What separates them is the shape of the traffic and the fingerprint of the errors.

Traffic shape before the failure. In an attack, request or packet rate rises first and errors follow. In an outage or a capacity fault, traffic is flat or falling while errors climb, because the same visitors are arriving and being turned away. Pull the request-rate graph and the error-rate graph on the same time axis and look at which line moved first. That single overlay resolves more arguments than any other artefact.

Error fingerprints. Connection timeouts, SYNs with no completed handshake and half-open sessions point at the network and transport layers. Clean 502s and 504s served promptly by a healthy edge point upstream, at your origin or at something between the two. A wall of 403s or interstitial challenge pages is frequently your own mitigation: a rate limit set too tight, or a WAF rule someone shipped on a Friday afternoon.

Who is affected. Everybody at once, or one mobile network, or one geography, or one point of presence? An outage confined to a single POP or a single ASN is a provider routing problem far more often than it is an attack. Global and total, with no gradient, tends to mean something above the web stack: DNS, certificates, domain registration or routing.

Source diversity against payload sameness. This is the signature no capacity problem can imitate. Take a worked contrast. Forty thousand requests per second arriving from six thousand distinct autonomous systems, nearly all of them aimed at one expensive search endpoint with near-identical headers, is an attack; organic traffic never distributes like that. Flat request volume, clean 502s at the edge and a normal origin process count is an upstream or deploy failure wearing an attack’s clothing.

Screenshot early. Edge dashboards frequently aggregate fine-grained data after a few hours, and the per-second view you need for an evidence pack may be gone by the time you write the report.

Check three surfaces in order: DNS, network, application

Order matters, because a failure in the first surface produces symptoms in all three.

Authoritative DNS first

Authoritative DNS is the layer most often left unmanaged, inherited from whoever registered the domain, and it fails in a distinctive way: mail, APIs, SSO callbacks and third-party integrations all break at the same second as the website. If your payment webhooks and your Microsoft 365 mail flow died alongside the site, stop looking at the web tier.

Resolve your zone against several public resolvers (for example 1.1.1.1, 8.8.8.8 and 9.9.9.9), then query each of your authoritative nameservers directly by IP address and compare SOA serial numbers. Check the delegation the registrar actually publishes against the NS records in the zone; the two disagree more often than people expect after a migration. Teams that have not thought about this surface before should read a proper treatment of authoritative DNS resilience and what to demand from a provider while nothing is on fire.

Network and transport second

Is your prefix still being announced? A public looking glass or a route-collector view answers that in under a minute, and a withdrawn or leaked prefix produces total, instant, global loss that feels exactly like a terabit-class flood. If the prefix is up, run traceroutes from at least two networks outside your estate. Packets dying several hops upstream, at the same router, for everyone, is a transit problem. A saturated link and a dark link look different on an interface graph: one is pinned at line rate, the other is at zero.

Application layer third

Thread starvation is the great impersonator. A worker pool exhausted by one slow database query produces queueing, timeouts and rising latency that reads like an application-layer flood until you put request concurrency next to origin CPU. Attack: concurrency high, CPU high, request mix skewed to one or two endpoints. Capacity fault: concurrency high, CPU idle, everything waiting on a lock or a downstream call.

The cross-check that settles most disputes is the edge-versus-origin comparison. Does the origin see far more traffic than the edge forwarded? Or does it see almost nothing while the edge reports normal volumes? Either mismatch tells you more in thirty seconds than an hour of log grepping.

Outages that get misreported as attacks, and attacks mistaken for outages

DNS provider failure versus DNS flood. Both produce the same maddening pattern: some users fine, others seeing nothing, depending on whose resolver cache still holds a valid answer. The test is to query each authoritative nameserver directly from more than one network. Responses from some anycast locations and timeouts from others suggests attack traffic or a partial platform fault; uniform timeouts everywhere, from every vantage point, suggests the platform itself. There is more detail on staying reachable through a DNS provider outage or an attack on your zone for teams building that plan properly.

Origin IP leakage. If the proxy reports normal traffic while the origin is being hammered, the attacker has your real IP address. This is a more common route to a bypassed proxy than sheer volume, and the causes are mundane: historical DNS records, a mail server on the same host, an unproxied staging subdomain, a certificate transparency log entry. The fix is re-IPing the origin and restricting its firewall to the edge provider’s published ranges. Buying more scrubbing capacity does nothing, because the attack is not touching the scrubber.

The boring catastrophes. An expired TLS certificate and a lapsed domain registration both produce total, simultaneous, global failure that is indistinguishable from a massive attack for the first few minutes. Check the certificate chain and WHOIS expiry before you dial anyone. Control-plane and dashboard failures deserve the same scepticism: if you cannot log in to change anything, the platform may be broken even when the data plane is serving traffic fine.

Self-inflicted downtime. On-demand mitigation creates its own outage window. Time-to-mitigate is not just the vendor’s detection number; it includes human authorisation and BGP convergence, and a diversion triggered mid-incident can look to users like a second, separate failure while routes settle. Anyone weighing that trade-off should understand what the seconds in a time-to-mitigate SLA actually cover before treating the figure as a promise.

Low-and-slow attacks. Application-layer attacks that hold connections open barely register on a bandwidth graph, so they get filed as performance degradation and sit in a backlog for days. Watch concurrent connection counts and time-in-request rather than megabits per second. If connection counts are at ceiling while throughput is unremarkable, you are not looking at a capacity problem.

What to do once you have the answer

If it is an attack: find out, now, who is contractually permitted to trigger mitigation. “Managed”varies wildly. Some contracts let a named engineer on the provider’s side change policy without waking you; others require the customer to raise a ticket and confirm the attack first, which means your protection is only as fast as whoever is asleep with their phone on silent. If a human on the provider’s side cannot change policy at 03:00 without your sign-off, you have bought monitoring, not management. Know your resale chain too: if your supplier resells someone else’s scrubbing network, your escalation carries an extra hop and your evidence has to survive being retold by a first-line agent. That question belongs in a structured comparison of vendor claims at contract time, but it bites during triage.

If it is a provider outage: work out whether the failing component is the one that publishes your failover. Changing nameservers during a DNS provider outage is slow and sometimes impossible. A zone with 3600-second records means a nameserver change can take up to an hour to reach resolvers, which is precisely why TTLs are lowered days before a planned cutover and not during an incident.

If it is you: roll back cleanly, one change at a time, and resist the temptation to describe a bad deploy as “a sophisticated attack”in the status update. Customers forgive mistakes. Engineers at your customers’ companies read traceroutes, and they will notice.

Tell the board and your customers what you know, what you do not know yet, and when you will next update. Then insist on a written post-incident report. A credible attack report contains a timeline in UTC, a vector breakdown, peak figures in bits per second, packets per second and requests per second, the moment mitigation engaged, and how much traffic was dropped against how much was passed. A credible provider root cause analysis names the change, the blast radius and the preventative action. “Elevated error rates were observed”is not an RCA.

Build the runbook before you need it

The five checks, in order, each with an owner and a command or dashboard written next to it:

  1. Resolve the zone from three public resolvers and query each authoritative nameserver directly; compare SOA serials.
  2. Compare the registrar’s published delegation against the NS records in the zone, and check WHOIS expiry and the certificate chain.
  3. Confirm the prefix is announced, then traceroute from two external networks.
  4. Overlay edge request rate against origin request rate, and note any mismatch in either direction.
  5. Put application concurrency next to origin CPU and the top endpoints by request count.

Host that card somewhere outside the failure domain, along with out-of-band monitoring from an external vantage point; monitoring that shares a CDN, a DNS provider or a cloud region with production will go dark exactly when you need it. Keep phone numbers, not just email addresses, for the scrubbing provider, the host, the registrar and the DNS operator, and confirm annually that the out-of-hours numbers still reach a human. The UK’s National Cyber Security Centre publishes denial of service guidance that is a sensible baseline for preparation and reporting expectations.

Finally, work out your downtime cost per hour. That number decides whether always-on protection is worth its premium over an on-demand arrangement with a convergence delay, and it sets how much evidence and contractual commitment you are entitled to demand at purchase. Answering “DDoS or outage?”in ten minutes is mostly a matter of having decided, in advance, which five things you will look at and who will be looking at them.

Frequently Asked Questions

How can I tell if my site is down from a DDoS or an outage?

Put request rate and error rate on the same time axis. If traffic climbed before errors appeared, and the sources are spread across thousands of networks hitting a narrow set of endpoints, treat it as an attack. Flat or falling traffic with rising errors points at a provider failure, a capacity fault or your own recent change.

What are the first three checks to run when a website goes down?

Resolve your domain against several public resolvers and query your authoritative nameservers directly. Confirm your prefix is still announced and traceroute from outside your own network. Then compare what the edge says it forwarded with what the origin actually received. Certificate expiry and domain registration status are worth a ten-second look in the same pass.

Can a DNS provider outage look the same as a DDoS attack?

Yes, and the user-visible pattern is nearly identical: some visitors keep working on cached answers while others get nothing at all. Query each authoritative nameserver directly from two different networks. Uniform timeouts from every vantage point suggest a platform failure; partial responses that vary by location lean towards attack traffic or a degraded anycast footprint.

Why does my site go down when my DDoS proxy says traffic is normal?

Usually because the attacker found your origin IP address and is going around the proxy entirely. Old DNS records, mail hosts, staging subdomains and certificate transparency logs all leak it. Re-IP the origin and restrict its firewall to your edge provider’s published ranges; extra scrubbing capacity will not help with traffic that never reaches the scrubber.

Who should I contact first, my hosting provider or my DDoS provider?

Contact whoever owns the surface your triage implicates. Clean 5xx errors from a healthy edge with no traffic spike means the host or your own deploy; a verified flood means the mitigation provider. Check in advance who on the provider side is contractually permitted to trigger mitigation without your written confirmation, and whether they resell another network’s scrubbing capacity, because that adds a hop to every escalation.



DDOS Attack Penalties and Sentences in the UK Explained

DDOS Attack Penalties and Sentences in the UK Explained

A defendant who rents ten minutes of botnet capacity for the price of a takeaway, points it at a school’s exam portal and walks away thinking nothing will come of it is, on paper, exposed to one of the heaviest maximum penalties in English criminal law. In practice, most of them get a suspended sentence. That gap between the statutory ceiling and the real-world DDoS attack penalties and sentence outcomes is the part almost every guide skips, and it matters as much to the victim organisation as it does to the offender.

The short version: the law is severe, the charging rate is low, and the reason it is low is usually evidence. Not attribution. Evidence.

Which UK laws set DDoS attack penalties, and what the maximums are

The governing statute is the Computer Misuse Act 1990. Section 3 covers unauthorised acts with intent to impair, or recklessness as to impairing, the operation of a computer. That is the section a denial-of-service attack normally lands on, and it carries a maximum of ten years on indictment.

Denial of service was not always so clearly covered. A 2005 case involving a teenager who flooded his former employer’s mail server with emails ended in acquittal at first instance, and the Police and Justice Act 2006 amendments rewrote section 3 specifically to put impairment offences beyond argument. The wording now reaches temporary impairment, and recklessness is enough. You do not have to intend the outage.

Section 3A is the one that catches customers, not just operators. Making, adapting, supplying or offering to supply an article for use in a section 1, 3 or 3ZA offence is an offence; so is obtaining such an article with a view to its supply. Buying a subscription to a booter or stresser panel can engage section 3A, which carries a two-year maximum on indictment, where the article is obtained with a view to supplying it on; a customer who simply uses the panel is charged under sections 1 and 3 for the attacks themselves.

Then there is section 3ZA, inserted by the Serious Crime Act 2015. It applies where an unauthorised act causes, or creates a significant risk of, serious damage. The general maximum is fourteen years. Where the damage is to human welfare or national security, the maximum is life imprisonment. It has been used sparingly, and it is aimed at consequences a court can see: disruption to food or fuel supply, to health services, to transport, to systems of national importance.

Other offences stack. A ransom demand brings blackmail under section 21 of the Theft Act 1968, with a fourteen-year maximum. Proceeds of Crime Act 2002 confiscation proceedings follow criminal benefit, which for a booter operator means subscription revenue. Where a stresser site advertises itself as a legitimate load-testing service and takes card payments, Fraud Act 2006 charges can enter the picture too.

From statutory maximum to actual sentence: how courts decide

Here is the structural point most coverage misses. The Sentencing Council has no offence-specific guideline for Computer Misuse Act offences. Judges work from the General guideline: overarching principles, in force since 1 October 2019, which asks the court to assess culpability and harm, find a starting point by reference to the statutory maximum and comparable cases, then adjust.

Read that again from the victim’s side. Where there is no tariff table, the harm assessment is built largely from what the prosecution can put in front of the court, and the prosecution builds it from what you gave the police. A vague statement that “the website was down for a while and customers complained”produces a low harm finding. A reconstructed timeline with downtime to the minute, lost transaction volume, staff hours diverted and a named service that failed produces a different one.

Factors that push sentences towards custody are consistent across reported UK cases: repeated attacks over a sustained period, targeting of hospitals, schools, banks or emergency services, selling attacks for profit or running the panel rather than merely buying from it, and publicising the attack or the victim’s data afterwards.

Factors that regularly keep defendants out of prison are equally consistent. Youth. An early guilty plea, which under the Sentencing Council’s reduction guideline attracts credit of up to one third if entered at the first stage of proceedings. A diagnosis of autism or another neurodevelopmental condition, supported by a psychiatric report, which can affect both culpability and the court’s view of whether custody would be disproportionately damaging. No previous convictions. Real cooperation with investigators.

Put those together and the common outcome for a first-time individual offender who bought attacks rather than sold them is a suspended sentence, a community order with unpaid work, or a rehabilitation activity requirement. Custody becomes far more likely for panel operators, for repeat offenders who breach existing orders, and for anyone who attached a demand for money.

The penalties that are not a sentence at all

Ask anyone who has been through it and the sentence is rarely the worst part.

Devices get seized under PACE 1984 powers and forensically imaged. Phones, laptops, games consoles, the family router in some cases. Retention runs for as long as the material is needed for the investigation and any proceedings, which in a digital forensics backlog can mean many months. Bail conditions frequently restrict internet use or require it to be monitored.

Courts can impose a Serious Crime Prevention Order under the Serious Crime Act 2007, lasting up to five years, with terms restricting computer and network use, requiring disclosure of accounts and devices, and requiring notification of changes of address. Breach is itself an offence carrying up to five years. For anyone hoping to work in IT, an SCPO plus an unspent conviction under the Computer Misuse Act is close to disqualifying for roles that need security clearance or a clean DBS check.

The National Crime Agency’s Cyber Choices programme is the diversion route, and it is the reason a good number of teenage booter customers never see a courtroom. Regional Cyber Crime Units use it to engage young people identified in booter site user databases, often through a home visit rather than an arrest. Diversion stops being realistic once there is financial gain, once the targets include critical services, and once there has been a prior warning that was ignored.

Collateral consequences employers underestimate: vetting failures, loss of professional registration, refusal of US and other visas at the point of application, and named reporting in local press that outlives the conviction by years.

Ransom DDoS and hacktivist attacks: where sentences climb

A ransom demand changes the legal picture more than attack size does. Two hundred gigabits per second with no demand is a section 3 offence. Two gigabits per second with an unwarranted demand backed by menaces is section 3 plus blackmail plus a POCA confiscation route, and the sentencing arithmetic shifts accordingly. The history of organised cyber-extortion gangs receiving long custodial terms reflects exactly that: it is the extortion, not the packet rate, that drives the number.

There is a practical instruction buried in this for victims. The demand itself, the email, the note in a form submission, the message pasted into a support ticket, is often the single most useful piece of evidence you will ever hold. Preserve it verbatim with full headers. Do not delete it, do not forward it around and lose the original, and do not let a well-meaning support agent close the ticket.

Claimed political motive is not a defence. Hacktivist groups that announce attacks on government sites or NHS trusts sometimes seem to believe otherwise. Motive does shape how a court assesses harm, and attacks on public services push harm findings upward, because the people inconvenienced are patients and claimants rather than shareholders. Attribution of motive, though, should stay an open question in your own incident reporting; write what the traffic did, not who you think was behind it.

Paying rarely ends the campaign. Payment marks you as a payer, funds the next round, and complicates any later prosecution by introducing questions about the transaction itself and, for regulated firms, about sanctions exposure.

Why prosecutions are rare, and what that means for victims

Attribution is genuinely hard. Rented capacity from a booter or botnet-for-hire service means the source addresses belong to compromised devices and abused reflectors, not to the person who pressed the button. Add a VPN layer and cryptocurrency payment and the trail to a human being runs through several jurisdictions.

Jurisdiction is the second brake. The Computer Misuse Act has broad extraterritorial reach where there is a significant link to the UK, so an overseas offender attacking a UK business can in principle be prosecuted here. Mutual legal assistance requests take months, sometimes longer, and prosecutors make hard choices about which cases justify that effort. Coordinated operations do happen: the takedown of Webstresser.org in April 2018, run by Dutch police and Europol with NCA involvement, removed what was then one of the largest DDoS-for-hire services and led to action against users across several countries. The NCA also confirmed in March 2023 that it had been running fake booter sites to collect data on people trying to buy attacks.

The third brake, and the one you can actually influence, is the evidential threshold. The Crown Prosecution Service applies the Full Code Test: sufficient evidence for a realistic prospect of conviction, and a prosecution in the public interest. Patchy logging kills cases at the first limb. If you cannot show the court what arrived, when, from where and what it did, there is nothing to convict on regardless of how confident everyone is about who did it.

Set expectations accordingly. Compensation orders in these cases tend to be modest and constrained by the defendant’s means, which for a nineteen-year-old with no assets means very little. Civil recovery against an identified and solvent defendant is rare. Cyber insurance and business interruption cover, properly evidenced, usually matter far more to the balance sheet than the sentence does.

Building an evidence trail your DDoS provider can actually supply

This is where procurement decisions made eighteen months ago decide whether a prosecution is possible.

A usable attack report is not the PDF your account manager sends with a nice bandwidth graph and a congratulatory note. Sales-deck-grade summaries are worthless in court. What a prosecution needs is: timestamps accurate to the second and tied to a known time source; source address distribution and autonomous system breakdown; a vector breakdown separating, for example, UDP reflection from HTTP request floods; packet and request rates at peak and over time; every mitigation action taken and when; and residual impact on origin infrastructure. Plus a named engineer who can attest to all of it in a witness statement.

So ask the awkward questions before you sign, not after the incident:

  • How long are attack logs and flow records retained, and at what granularity after the first thirty days?
  • Is raw packet capture available on request, and is there a charge or a time limit on that request?
  • Who inside the provider is authorised to produce and sign a statement for police or civil proceedings, and has anyone there done it before?
  • Does the report cover DNS query traffic and application-layer requests, or only network-layer volumetrics?
  • What happens to the evidence if you terminate the contract mid-investigation?

Most buyers never raise any of this. They negotiate hard on time-to-mitigate SLA wording and never once ask what the provider can prove afterwards.

Two architectural gaps produce incidents with almost no usable evidence at all. The first is origin IP leakage. If an attacker has your real origin address, from an old DNS record, an SPF entry, a certificate transparency log or a misconfigured mail server, the traffic bypasses the scrubbing layer entirely and the only record is whatever your own edge kept, which is typically thin and rotated within days. The second is authoritative DNS sitting outside the protection contract, which happens more often than vendors admit. Knock out name resolution and the site is unreachable without a single packet touching the protected perimeter, and your provider’s report will show a quiet day.

On the reporting side: file with Action Fraud and keep the reference number, since it is what insurers and police forces both ask for. Escalate to the National Crime Agency where the incident affects critical services or has national impact. Notify the ICO only where personal data is implicated; a pure availability incident with no data involvement usually is not reportable, though the seventy-two hour clock under UK GDPR is unforgiving if it turns out to be. Internally, record who handled what and when, keep the original files rather than screenshots of them, and cost the downtime properly while the numbers are still retrievable. If you run an online shop, fold this into your first-hour incident playbook rather than treating it as paperwork for later.

UK penalties in international context

In the United States, DDoS offences run under the Computer Fraud and Abuse Act, 18 U.S.C. §1030. Federal sentences for booter operators have included custodial terms, supervised release with computer monitoring conditions, and restitution orders tied to documented victim losses. Restitution is worth noting, because it rewards exactly the kind of detailed loss quantification that also drives harm findings in an English court.

Australia’s Criminal Code Act 1995 sets a maximum of ten years for unauthorised impairment of electronic communication. Canada charges mischief in relation to computer data under section 430 of the Criminal Code, also with a ten-year indictable maximum. Across the EU, Directive 2013/40/EU on attacks against information systems requires member states to set maximums of at least two years, rising for botnet-enabled attacks and attacks on critical infrastructure. NIS2, the 2022 network and information security directive, is sometimes cited here but it regulates operators rather than punishing attackers; it imposes security duties and administrative fines on the organisations being attacked, which is a different instrument entirely.

The common thread across all of them is that maximums are high and prosecutions are comparatively few. Which leads to the one position worth holding firmly: legal deterrence has no place in a defence business case. Rented capacity, overseas infrastructure and mutual legal assistance timelines mean the prospect of prosecution protects nobody’s revenue on the day. What protects it is scrubbing capacity, time-to-mitigate, closed origin leakage and DNS inside the contract. Understanding UK DDoS attack penalties and how a sentence is actually reached is useful for setting expectations, for briefing the board, and for knowing what evidence to keep. It is not a control.

Frequently Asked Questions

What is the maximum sentence for a DDoS attack in the UK?

Section 3 of the Computer Misuse Act 1990 carries up to ten years on indictment for unauthorised acts impairing the operation of a computer. Section 3ZA, added by the Serious Crime Act 2015, raises that to fourteen years, or life imprisonment where the attack causes or risks serious damage to human welfare or national security. Actual sentences for individual offenders are usually far below these ceilings.

Is using a booter or stresser service a criminal offence?

Yes. Making, supplying or offering to supply an article for use in a Computer Misuse Act offence, or obtaining one with a view to its supply, is an offence under section 3A, with a two-year maximum on indictment, and launching the attacks themselves engages section 3. Paying a subscription to a stresser panel leaves a payment record and an account record, which is how law enforcement has identified customers after booter site takedowns.

Do first-time offenders go to prison for a DDoS attack?

Often not. Youth, an early guilty plea attracting credit of up to one third, no previous convictions, cooperation and supported neurodevelopmental assessments frequently combine to produce a suspended sentence or a community order with unpaid work. Immediate custody becomes much more likely where the defendant sold attacks, targeted healthcare or emergency services, or attached a ransom demand.

Can I sue the attacker or claim compensation after a DDoS attack?

In principle yes, but it is rarely worth it. Compensation orders in criminal proceedings are limited by the defendant’s means, and civil claims require an identified, solvent defendant within a practical jurisdiction. For most UK businesses, insurance recovery and contractual remedies against providers matter more, and both depend on the same downtime evidence a prosecution would need.

What evidence do UK police need before they will charge someone over a DDoS attack?

The CPS applies the Full Code Test, so there must be a realistic prospect of conviction on the available evidence. In practice that means second-level timestamps, source and vector data, mitigation records, proof of impact on your systems, and a witness who can attest to all of it. Any ransom demand should be preserved verbatim with full headers, since it is frequently the strongest single item in the file.



Legal Action After a DDOS Attack: A UK Playbook

Legal Action After a DDOS Attack: A UK Playbook

When a flood of junk traffic takes a UK company offline for six hours on a trading day, the questions arrive in a familiar order: what is happening, when does it stop, who did this, and can we do anything about it afterwards. Legal action after a DDoS attack is usually the last of those to be asked and the first to be quietly dropped. Not because the attack was lawful. It plainly was not. The problem is that by the time anyone asks the question properly, the flow records that would have supported a claim have already rotated out of a buffer, and the only surviving artefact is a screenshot of a dashboard with no timezone on it.

This piece is written from the target’s side of the incident. It covers what UK law actually offers a victim, what to preserve in the first day, who to notify, how ransom demands change the calculation, and why the contract you signed with your mitigation provider usually determines your legal position far more than the Computer Misuse Act does.

What UK law says about a distributed denial-of-service (DDoS) attack on your business

Three provisions matter. Section 3 of the Computer Misuse Act 1990 covers unauthorised acts with intent to impair the operation of a computer, which is the standard charge for knocking a service offline; it carries up to 10 years’ imprisonment on indictment. Section 3A covers making, supplying or obtaining articles for use in such offences, and it is the provision that catches booter and stresser services and the people who buy them, with a maximum of two years. Section 3ZA, inserted by the Serious Crime Act 2015, covers unauthorised acts causing or creating a significant risk of serious damage, and carries up to 14 years, rising to life where the damage touches human welfare or national security.

So the sentencing range is real. What it is not is a remedy. A conviction, when one happens, arrives months or years later, usually against a teenager who bought 30 minutes of attack traffic for the price of a takeaway, and it returns nothing to your balance sheet. UK courts can make compensation orders, but they are limited by what the defendant can actually pay, and booter customers are rarely solvent.

Criminal offence, civil wrong, contract breach: pick your fight

These are three separate tracks and they behave differently. A criminal prosecution is brought by the state, needs a suspect, and is not yours to control. A civil claim is yours to bring, but you must identify a defendant, serve them and enforce against assets. A contract claim is against a party you already know, usually your hosting, content delivery or scrubbing provider, and it is governed entirely by the words in the agreement you signed. Most organisations that talk about “taking legal action”are describing track one and end up, if anything happens at all, on track three.

Attribution, not illegality, is the obstacle

Nobody disputes that flooding a UK business is unlawful. The difficulty is naming who did it to the civil standard. Reflection and amplification attacks arrive from thousands of innocent third-party servers whose owners have no idea they are participating. Source addresses are routinely spoofed. Attack capacity is rented from a marketplace that takes cryptocurrency and hides behind its own proxy layer. As we have noted before, websites have long struggled to find meaningful legal recourse for denial of service attacks, and the reason is almost always evidential rather than doctrinal.

The first 24 hours: the evidence that keeps your options open

Everything below needs preserving before the next log rotation, not after the post-mortem meeting.

  • NetFlow, sFlow or IPFIX records from your edge routers, exported and copied off the collector;
  • Edge and origin web server access logs, plus firewall, load balancer and WAF counters for the attack window and for a comparable quiet period;
  • Monitoring and synthetic check alerts, status page updates, and the timestamps on each;
  • A full packet capture sample if one was taken, even a few seconds of it;
  • Internal records of who was notified, at what time, on which channel, and what decisions they took.

Log everything in UTC from NTP-synchronised systems. Mismatched clocks are the first thing an opponent challenges, and a two-minute drift between your load balancer and your provider’s scrubbing centre is enough to muddy a time-to-mitigate argument permanently.

Ask for the written attack report, not a screenshot

The single most useful document you will ever hold after an incident is your provider’s post-incident attack report: named vectors, peak bit rate and peak packet rate, source distribution by geography and autonomous system, and precise start and stop timestamps. If your traffic passes through a third-party proxy or scrubbing centre, that provider holds the only complete record of the flood. Your own logs show the hole, not the thing that made it.

Yet a great many contracts never promise that report. Make it a named deliverable with a delivery deadline before you sign, not a favour you request in week three while the account manager is on leave. The same applies to raw evidence requests: ask during procurement whose scrubbing capacity you are actually buying, because plenty of UK offerings are resold capacity on another operator’s network. Where that is the case, your SLA counterparty may have to go and ask an upstream party that has no contract with you at all. That chain is worth mapping alongside the rest of your vendor claim checks.

Ransom notes are exhibits

Keep the original email with full headers. Keep the chat transcript, the wallet address, the sample attack timing and any subsequent messages. Do not forward the note around the business and delete the original, which is what happens roughly every time, because a forwarded copy strips the headers that make it worth anything.

Who to report a DDoS attack to in the UK, and in what order

Start with Action Fraud, the reporting centre for fraud and cybercrime in England, Wales and Northern Ireland; in Scotland, report to Police Scotland on 101. What you get back is a crime reference number, and its value is administrative rather than investigative: insurers ask for it, regulators expect it, and customers asking awkward questions are reassured by it. Feeding into the National Crime Agency’s picture matters too, even when nobody investigates your individual case, because the pattern data is what supports booter takedowns.

The NCSC’s denial of service guidance is the sensible reference point for building a defensible response plan, and pointing to it in a board paper is more persuasive than an internal opinion.

Then work through the duties that carry deadlines:

  • NIS Regulations 2018: operators of essential services and relevant digital service providers have incident notification duties to their competent authority, and availability incidents count;
  • FCA operational resilience expectations: financial firms are expected to report operational incidents and to be able to show whether an important business service breached its impact tolerance;
  • UK GDPR: Article 32 treats availability as part of security, so loss of access to personal data can be a personal data breach, and Article 33 gives you 72 hours from becoming aware to assess and, where there is a risk to individuals, notify the ICO. Document the assessment even when you conclude no notification is needed;
  • Contractual notice clauses: customer and partner agreements often require notification within a small number of days, and those clauses bite long before any regulator does.

Ransom DDoS attack: what to do before anyone discusses paying

The reflex payment is the worst available option. It buys no guarantee the traffic stops, it marks you as a payer, and extortion groups have a documented habit of returning to previously compliant targets with a larger number. Before any of that, there are UK legal problems sitting behind the transaction.

Payments to a sanctioned person or entity breach financial sanctions, which carry strict civil liability and can attract monetary penalties from the Office of Financial Sanctions Implementation. Any payment also needs assessing against the money laundering offences in the Proceeds of Crime Act 2002. Screening the recipient is not optional diligence; it is the thing that determines whether the payment is lawful. Note also that in July 2022 the NCSC and the Information Commissioner wrote jointly to the Law Society making clear that paying does not reduce the risk to individuals, is not required by data protection law, and will not be treated by the ICO as a mitigating factor. Separately, the Home Office consulted in early 2025 on restricting ransom payments by public sector and critical national infrastructure bodies; check the current legal position before relying on anything written here.

Practical sequence: notify your insurer and broker before acting, because most cyber policies condition cover on prior consent and on using panel responders. Then follow a decision chain you wrote in advance, naming a director who owns the call, the lawyer who signs it off and the law enforcement contact who is told. Writing that chain during an attack, at 02:00, with the phones ringing, is how organisations make decisions they later cannot defend.

Suing the attacker versus claiming against your provider

Civil claims against attackers work in a narrow band of cases: identifiable commercial booter operations with reachable assets, domains or payment processors. Ubisoft’s 2021 action against a stresser operation is the usual illustration, reported as producing an award of just over $153,000 alongside site takedowns. The useful lesson is not the sum. It is that the defendant was a business with a website and a payment flow, not an anonymous customer. Against individual botnet users overseas, the cost of identification, service and enforcement will exceed anything you recover.

Claims against your hosting, CDN or scrubbing provider look more promising and usually deliver less than expected. SLA credits are typically a percentage of one month’s fee, claimable only inside a notice window of around 30 days, and sit beneath a liability cap tied to annual charges, with consequential loss excluded outright. Downtime, lost sales and reputational harm are exactly what those exclusions remove. Credits and damages are different animals; treating a credit as compensation is a category error that has cost boards a lot of wasted legal spend.

Which leaves insurance doing most of the real work. Business interruption and cyber policies commonly apply a waiting period measured in hours, so a four-hour outage may recover nothing while an eleven-hour one recovers a great deal. Loss adjusters want a defensible figure: hourly revenue derived from comparable trading periods, staff time at loaded cost, recovery and third-party response fees, and contractual penalties triggered by the outage.

Why the contract you signed decides how strong your position is

Four clauses do most of the damage, and they are all checkable before you buy.

What “managed”actually includes. Managed should mean onboarding and rule tuning records, a named escalation path, an engineer empowered to change policy during an attack without waiting for your sign-off, and a committed written attack report. Absent those, you have bought monitoring, not management.

When the clock starts. On-demand cover almost always measures time-to-mitigate from your notification, which turns your own out-of-band notification trail into evidence: timestamped emails from a mailbox that is not on the affected domain, call logs, ticket IDs. Teams forget this while firefighting. If you are weighing always-on against on-demand cover, understand that the difference is partly evidential, and read the small print on what those SLA seconds measure.

Three surfaces, not one. Network and transport, application layer, and authoritative DNS. The third is frequently outside the DDoS contract entirely, which means an outage at that layer can fall into nobody’s SLA while still being the reason customers saw an error page. Establish who covers authoritative DNS, under what commitment, and what report you receive if it fails.

Origin IP leakage. This is the claim-killer. A stale A record on an old subdomain, a mail host sharing the origin address, a staging environment nobody decommissioned: any of these lets the flood reach your origin directly, outside the protected path. When that happens the provider will say so in writing, correctly, and the SLA never applied. Origin leakage, rather than raw attack volume, is the most common reason a proxy gets bypassed and the most common reason a claim against the vendor collapses. Audit your DNS zone for it while things are calm.

Frequently Asked Questions

Is a DDoS attack a criminal offence in the UK?

Yes. Section 3 of the Computer Misuse Act 1990 covers unauthorised acts intended to impair the operation of a computer, with a maximum of 10 years on indictment. Buying or supplying a booter or stresser service falls under section 3A, and section 3ZA covers attacks causing serious damage, carrying up to 14 years or life in the most severe cases.

Can you sue someone for a DDoS attack?

You can, provided you can identify and serve a defendant with assets worth pursuing. Civil action has succeeded against commercial booter operators, as in Ubisoft’s 2021 case reported at just over $153,000 plus takedowns. Against anonymous or overseas individuals, the cost of attribution and enforcement generally outweighs anything recoverable.

Who should you report a DDoS attack to in the UK?

Report to Action Fraud for a crime reference number, or to Police Scotland on 101 if you are in Scotland. Then work through sector duties: NIS Regulations notification if you are an operator of essential services or a relevant digital service provider, FCA reporting for financial firms, and an Article 33 assessment for the ICO where personal data availability was affected.

Does a DDoS attack have to be reported to the ICO?

Not automatically, but it can be reportable. UK GDPR Article 32 treats availability as part of security, so if people lost access to personal data and there is a risk to their rights and freedoms, Article 33 requires notification within 72 hours of becoming aware. Record the assessment and its reasoning even where you decide notification is not required.

Should you pay a ransom DDoS demand?

Paying is the weakest option and carries its own legal exposure, including financial sanctions liability and the money laundering offences in the Proceeds of Crime Act 2002. It guarantees nothing and marks you as a payer. Notify your insurer and law enforcement first, and make the decision through a chain you agreed in writing before the attack rather than during it.



Authoritative DNS DDOS Protection: A Buyer's Guide

Authoritative DNS DDOS Protection: A Buyer’s Guide

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

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

Why authoritative DNS fails differently from your website

What actually stops when the nameservers stop

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

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

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

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

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

The DNS version of origin IP leakage

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

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

The attack patterns authoritative DNS protection has to survive

Direct query floods over UDP and TCP

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

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

Random subdomain floods break the usual blocking reflex

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

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

Your zone as somebody else’s weapon

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

Delegation failures that look like an attack

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

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

Deployment models compared: where each one fits

Managed anycast DNS as a hosted service

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

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

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

Dual-provider authoritative DNS with a hidden primary

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

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

Matching the model to the estate

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

What ‘managed’ actually buys on the DNS surface

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

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

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

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

Evidence to demand before you sign

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

Costs, business case and a safe cutover

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

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

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

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

Frequently Asked Questions

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

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

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

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

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

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

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

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

How does DNSSEC affect DDoS protection and failover between providers?

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



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.