Twenty minutes into a 40 Gbps UDP flood, the duty engineer at the transit provider confirms the attack has been “successfully mitigated”. The graphs agree. The site is still down, the checkout is still throwing errors, and nobody on the bridge call can say why. That gap, between a provider’s definition of success and a customer’s, is what ISP-level DDoS protection conversations usually fail to close before the incident rather than during it.
ISP-level DDoS protection is the filtering your connectivity or transit provider applies to traffic before it reaches your circuit, usually at the network edge and usually priced as part of the service. It is genuinely useful. It is also narrower than most buyers assume, and the six questions below are designed to find the edges of it while you still have negotiating room.
What ISP-level DDoS protection actually does at the network edge
The mechanics are less exotic than the marketing. Routers export flow telemetry, typically NetFlow or sFlow, to a detection platform that watches for traffic patterns crossing a configured threshold: a sudden spike in packets per second toward one address, a lopsided ratio of UDP to everything else, a destination that normally takes 200 Mbps suddenly taking twenty times that. When the threshold trips, the provider either applies filtering on the router itself, diverts the traffic to a scrubbing appliance in its own core, or hands the prefix to an upstream mitigation partner’s platform.
Each of those three paths behaves differently under load, and providers rarely volunteer which one they are using for your circuit at three in the morning on a bank holiday.
Whose network is being protected
Worth being blunt about the division of labour: an ISP’s DDoS tooling exists first to keep its transit links, peering ports and shared infrastructure healthy, and second to keep your service up. Most of the time those goals point the same way. When they diverge, under a flood large enough to congest a peering point, the provider’s own network wins. That is not bad faith, it is the contract everyone signed without reading.
The same product name means different things in different countries
Groups running sites across several markets should resist the assumption that one answer travels. The depth of edge mitigation varies sharply between a tier-one carrier in Frankfurt, a national incumbent in a smaller market and a regional hosting provider with a single upstream. Flowspec may be available on one and not another; the blackhole threshold may be an order of magnitude apart; out-of-hours cover may be a staffed NOC in one country and a pager in the next. Ask per site, not per group.
Three surfaces, judged together
Any mitigation service, ISP or otherwise, should be assessed across three surfaces at once: network and transport, where volumetric floods land; the application layer, where HTTP and API abuse lands; and authoritative DNS, where the name itself can be taken off the internet. Edge filtering is strong on the first, patchy on the second and almost never touches the third. That is the single most useful frame to carry into the procurement conversation, and the reason well-defended estates still go dark.
Question 1: is mitigation always-on, or triggered on demand?
On-demand, or detect-and-divert, is the default in most bundled services. It is also where the time goes. The clock accumulates a detection window (often 30 to 60 seconds of flow sampling before a threshold is confidently crossed), then human confirmation in some providers’ workflows, then route propagation once the diversion is announced. Always-on inspection removes that stack, at the cost of a higher price and an extra hop in your traffic path that deserves its own scrutiny for latency and failure modes.
The number to extract is time-to-mitigate, and it is meaningless without knowing when the clock starts. A provider quoting “under 60 seconds”may be measuring from the moment an operator clicks confirm, not from attack onset.
Ask for, in writing:
- The detection window and the sampling rate behind it;
- The time from detection to active mitigation, with the start point defined;
- Whether any step requires a human to authorise, and what the out-of-hours staffing is;
- The last 90 days of mitigation events recorded on your own circuit, not a platform-wide sample.
That last request is the honest test. Repeated short bursts, the 30 to 90 second hits that vanish before a diverted path is live, often never appear in an event log at all. An empty log is not proof of quiet; it can be proof the detection threshold is set above the attacks you are actually receiving.
Question 2: will you blackhole my IP address, and at what threshold?
This is the buried term in almost every ISP DDoS discussion. Remote Triggered Black Hole filtering is a legitimate, standardised technique, described in RFC 5635, published by the IETF in 2009. It works by null routing the targeted address upstream so the junk traffic is discarded before it congests anything shared. The provider’s network survives. So does every other customer on that edge.
Your address does not. A null route on the attacked prefix delivers precisely the outcome the attacker was aiming for, by a different route, and providers tend to describe it in the language of protection rather than the language of outage.
Four details belong in the contract, not in a bridge call:
- The numeric trigger, expressed in Gbps and in packets per second, since small-packet floods hit the second limit long before the first;
- Who authorises it, whether your consent is required, and whether you are notified before or after;
- How long the null route stays in place and what has to happen for it to lift;
- The prefix granularity, which matters enormously.
A /32 blackhole on one marketing host is survivable. A /24 that takes your mail, your API and your VPN concentrator with it is a different incident entirely. While you are asking, find out whether BGP Flowspec rules or selective filtering by port and protocol are available on your account, or whether the only two settings are “filter”and “drop everything”.
Question 3: which attack types does the filtering actually stop?
Volumetric reflection and amplification is where edge filtering earns its place. DNS, NTP, memcached and CLDAP reflection all produce traffic with recognisable shape and enormous volume, and dropping it upstream is exactly the right response. The 2013 attack against Spamhaus, driven largely by open DNS resolvers and reported by CloudFlare at the time as reaching roughly 300 Gbps, remains the clearest demonstration of how a modest set of spoofed queries becomes a flood no single site can absorb.
Two categories slip through.
State-exhaustion attacks against firewalls, load balancers and TLS termination often look unremarkable in flow data. Packet rates stay modest; the damage is in connection tables and handshake cost, not bandwidth. Detection tuned on volume will not see it.
Application layer floods are invisible by design to a provider that is not terminating your TLS. A few thousand requests per second of well-formed HTTP GETs against a search endpoint, slow POSTs, or credential stuffing shaped to resemble real users: none of that is distinguishable from traffic at the network edge, because the edge cannot read it. Any provider claiming layer 7 coverage without a proxy, a WAF or your certificates should be asked exactly how.
Two upstream hygiene questions are worth adding, because they say something about the provider’s general standard of care: does it implement source address validation per BCP 38 (RFC 2827) on customer-facing ports, and does it participate in MANRS, the Mutually Agreed Norms for Routing Security initiative? Neither protects you directly. Both indicate whether the network is part of the amplification problem or part of its containment.
Question 4: what happens to my authoritative DNS?
Almost no ISP DDoS service protects a DNS zone hosted somewhere else, and most zones are hosted somewhere else: at a registrar, on a free nameserver pair bundled with a domain, or on two VMs inherited from a project that closed in 2019. Registrar nameservers are built for availability under normal load. Sustained query floods are a different proposition.
The failure mode is the one from the top of this article. Picture the full version: a 40 Gbps UDP flood scrubbed cleanly at the edge, a parallel HTTP flood of a few thousand requests per second quietly exhausting the application servers, and a query flood against two registrar nameservers making the domain unresolvable. One attack, three surfaces, one of them mitigated. The status page says green.
Practical checks on the DNS surface:
- How many authoritative nameservers serve the zone, and how many genuinely separate providers they represent (four nameservers on one platform is one provider);
- Whether the service is anycast, and across how many sites;
- TTL strategy, since very low TTLs remove the resolver caching that buys you time during a nameserver outage;
- Whether the zone is secondaried anywhere independent, which is the cheapest resilience available on this surface.
Authoritative DNS remains the layer most often left unmanaged in otherwise careful estates, largely because it sits with whoever registered the domain rather than with the network team. Anyone who has worked through what actually works against DNS amplification will recognise the pattern: the resolver side gets attention, the authoritative side does not.
Question 5: how much capacity sits upstream of me, and who else shares it?
Advertised Tbps figures are platform-wide totals. They tell you what a vendor can absorb globally across every scrubbing centre on a good day, which is not the same as what is standing by at the point of presence serving your circuit in Manchester, Amsterdam or Singapore.
Three questions get closer to something real: the mitigation capacity available at the specific location handling your traffic; the number of concurrent mitigations that location can run; and the documented behaviour when either limit is exceeded. The answer to the third is usually one of two things. Either the prefix gets dropped, which returns you to Question 2, or it gets handed upstream to a partner, which introduces a platform you have not assessed and a handover delay nobody has timed. Both change your risk picture, and the question is covered in more depth in this breakdown of how much scrubbing capacity you actually need.
Colocation tenants and multi-tenant hosting customers carry an extra exposure: shared fate. An attack aimed at the cabinet next door, or at another VLAN on the same aggregation switch, can congest the path you depend on. Ask how traffic is segregated during mitigation and whether per-customer policies exist or whether everything behind that uplink is treated as one blob.
Question 6: what is in the price, and what triggers extra charges?
UK managed DDoS pricing is layered rather than flat. The basic tier bundled with a circuit is cheap, sometimes free, for a straightforward reason: it protects the provider’s network, and your protection is a by-product. The tier that does what buyers imagine they already have is priced separately, usually against clean bandwidth commit, the number of protected IP addresses, or mitigation hours and events.
Charges that surface after the headline figure, and that belong on the comparison sheet:
- Out-of-hours engineering and incident support rates;
- Per-event or per-hour mitigation fees once an included allowance is used;
- Emergency onboarding when you call mid-attack, which is always the most expensive way to buy mitigation;
- Minimum term and notice periods on the upgraded tier, which are often longer than the underlying circuit.
Comparing those tiers only means something if you have a number for what an hour of downtime costs: lost transactions, SLA credits to your own customers, idle staff, and the recovery work afterwards. Build that figure first, then the difference between a bundled tier and a managed one stops being an abstract price increase. There is a workable approach to this in the board-ready DDoS business case model, and the same arithmetic settles the sequencing question.
Where the gaps usually get filled: a cloud scrubbing service or a CDN with a WAF for the application layer, plus hardened authoritative DNS across two providers. For most ecommerce and SaaS operators the DNS fix is cheaper, faster and more often the difference between degraded and unreachable, so it tends to be the better first purchase. The application layer comes next. Only then is it worth paying for more edge capacity you may never consume.
One regulatory note for operators in scope. Availability duties under the UK’s NIS Regulations 2018 and their EU equivalents, and the direction of the forthcoming Cyber Security and Resilience Bill, mean “our ISP handles DDoS”is thin as a documented control. Regulators tend to ask what was tested, what was contracted and what was measured.
Next, if you want to go further on the trade-offs behind these answers: the practical ceiling on bundled services is covered in this piece on ISP DDoS protection limits and when to top up, and the alternative path is set out in this explanation of how cloud DDoS scrubbing really works.
Frequently Asked Questions
Is ISP-level DDoS protection enough on its own?
For volumetric network and transport floods, often yes. Across the full picture, rarely. Edge filtering cannot see inside TLS, so application layer floods pass through it, and it does not protect authoritative DNS hosted elsewhere. Treat it as one of three surfaces rather than the whole defence.
What is the difference between ISP-level DDoS protection and cloud scrubbing?
ISP mitigation happens inside your connectivity provider’s network, on the path your traffic already takes, and is scoped to that provider’s footprint. Cloud scrubbing diverts traffic to a separate distributed platform, usually via BGP or DNS redirection, and is bought independently of your circuit. Cloud platforms typically offer more capacity and deeper application layer inspection; ISP mitigation is closer to your edge and usually cheaper.
Will my ISP blackhole my IP address during a DDoS attack?
Many will, if the attack threatens shared infrastructure. Remote Triggered Black Hole filtering per RFC 5635 is standard practice across the industry. Get the trigger threshold in Gbps and packets per second, the authorising party, the duration and the prefix granularity written into the contract before an incident, because a /24 null route takes everything you host with it.
Does ISP DDoS protection cover application layer and DNS attacks?
Generally not. HTTP floods, slow requests and API abuse require a proxy or WAF that terminates TLS, which an edge filter does not do. Authoritative DNS is almost always outside the scope of a circuit-level service, which is why domains can become unresolvable while the network itself is clean.
How much does upgraded ISP DDoS protection cost in the UK?
Pricing is structured rather than fixed, so there is no useful single figure. Expect a near-free basic tier at the circuit, with the managed tier priced against clean bandwidth commit, protected IP count, or mitigation hours and events, plus possible out-of-hours and emergency onboarding charges. Request current quotes with those variables itemised, and compare them against a modelled cost of downtime per hour rather than against each other.