The DDoS that takes you down is not in the headlines

When a denial-of-service attack makes the press it is because it broke a record: tens of terabits per second, a huge number and an infographic. The figures for the first half of 2026 tell a rather less spectacular story. Of all the network-layer attacks Cloudflare mitigated, 96.62% stayed under 500 Mbps and 90.60% ended in under ten minutes.

Those two percentages ought to change the conversation you have with your provider, and they almost never do. Mitigation is still bought by capacity — how many terabits the company protecting you can absorb — when for a mid-sized company the provider's capacity is rarely what fails. What fails is the clock.

Small for them, total for you

A 400 Mbps attack is background noise for a global network. For an office with a 300 Mbps symmetric line it is the end of the working day: no email, no VPN, no ERP in the data centre, no phone system. And you do not even need to fill the pipe. Many of those small attacks are not about volume but about packets per second, and there it is the firewall CPU that runs out of breath, chewing tiny packets long before the bandwidth is exhausted.

On why a firewall at your office cannot defend you against something that already filled the link before it arrived, and why the blackhole your ISP advertises is throwing your IP in the bin rather than a defence, we already wrote a whole post back in July. That remains the heart of it. What this year's figures add is the shape of the attack, and the shape changes what you should demand in the contract.

The metric is the clock, not the terabits

Nine out of ten attacks are over inside ten minutes. And it is not that the big ones last longer: the report itself mentions record-breaking assaults of 35 seconds from start to finish. At both ends of the scale, the clock runs the same. Now take that figure and put it next to the procedure you have signed: detect the anomaly, open a ticket, have somebody triage it, have a provider engineer confirm it is an attack and not a marketing campaign that went well, and only then activate the traffic diversion. If that loop takes twenty minutes, you have bought a defence that arrives after the attacker has packed up.

Hence the question that actually separates providers: is mitigation always on, or does it have to be requested? If it has to be requested, the number that matters is not how many terabits it absorbs, but how many seconds pass between the first odd packet and the first filtered packet, and who decides to start. If the answer contains the word "call", you already know how this ends.

And now they are aiming at your DNS

The other figure in the report that made us look up: DNS floods went from 25.7% to 40.0% of network-layer attacks from one quarter to the next. Four in ten. It makes complete sense from the attacker's side: it is far cheaper to knock over the service that translates your name than the one that serves your website. If nobody can resolve yourcompany.com, it makes no difference at all that your servers are fine and your link is empty.

The check takes five minutes and, of the clients we have asked for it, almost none had done it. Look at your domain's authoritative servers with dig NS yourcompany.com, then resolve each name and see which network it lands in: dig +short ns1.yourprovider.com and that IP against a looking glass. If the two or three end up on the same network, from the same provider, in the same place, you do not have two name servers: you have one written three times. With one honest exception: if that provider serves the zone over global anycast, its two names may be announced from hundreds of locations and you already have the diversity. The problem is self-hosted DNS and the DNS that comes free with the domain. It is the same trap we described in redundancy is not route diversity.

We already touched on this in August from another angle, when we wrote about who can switch off your servers after a registrar's DNS went down. We repeat the caveat we made there, because it is what prevents a false sense of safety: a secondary name server at another operator keeps resolution alive, not the service. If what sits underneath does not answer, resolving the name saves you nothing.

The five questions before you sign

This is what we ask when somebody shows us an anti-DDoS quote. None of the five is too technical; all five get answered in writing or they have not been answered.

1. Always on or on demand? And if it is on demand, how many seconds from detection to the first filtered packet, measured in a real incident and not in the brochure.
2. Who pulls the trigger? If somebody on your team has to phone in to switch it on, your defence depends on that person not being in a meeting, driving, or on holiday.
3. What happens to legitimate traffic while it lasts? A blackhole on your own IP achieves the attacker's goal in a tidier fashion. If that is the provider's answer, you are not buying mitigation: you are buying an orderly shutdown.
4. Does it cover authoritative DNS, or only the website? With four in ten network-layer attacks aimed at DNS, protection that only looks at port 443 leaves out the fastest-growing flank.
5. How long does it take you to find out? If the first news of the attack comes from a salesperson saying the ERP is slow, the problem is not the attacker: it is that you are not watching the traffic. With NetFlow in the core you see the shape of the attack before the complaint arrives.

When you do not need to buy anything

Saying this costs us work, but it is true: if everything of yours sits behind a content delivery network and you publish nothing directly from your own premises, you already have much of this covered, and paying on top is paying twice. If the only exposed things are hosted email and a static site, there is not much to defend either. The conversation changes the moment something is published from an IP of your own — a VPN, an ERP, an API, a phone system — and it changes completely if your revenue depends on that answering at eleven on a Tuesday.

What these numbers do not say

These are the figures of a single network, Cloudflare's, and they reflect what reaches its customers: companies that have already decided to protect themselves. They are not a census of the internet, nor do they measure what happens on the link of a company in Manresa with nothing in front of it. Nor does the report contain any Spain-specific figure. And the typical attack being small does not mean the big one will not touch you: it means that if you only prepare for the big one, the small one is what will hurt. We do not sell terabit scrubbing and we are not going to pretend otherwise; what we have is our own network, a public looking glass, and the habit of watching traffic before anyone calls.

What we can and cannot do

We are an operator with our own network: BGP, transit, peering and a public looking glass at lg.everywan.com anyone can query. We run blackholing in the core and analyse traffic with NetFlow. And since blackholing is exactly what the third question describes — an orderly shutdown — we say it plainly: it is the last resort, not the defence. Useful mitigation happens upstream, never on the box at your office. That, plus designing connectivity so one attack does not take everything else with it, is the part of networks and communications you notice on the bad day. When the attack is the tip of something else — somebody looking for a way in while you stare at the traffic graph — it comes in through cybersecurity, and whoever watches the counters at three in the morning is the same 24x7 support team.

If you take one idea away: stop asking how many terabits your provider can absorb and start asking how many seconds it takes. The attack that will hurt you will be over by the time somebody answers the phone.

Sources (consulted on 23 Sep 2026): the 96.62% of network-layer attacks under 500 Mbps, the 90.60% ending in under ten minutes, DNS floods going from 25.7% to 40.0% quarter over quarter, the 23.2 million network-layer attacks mitigated in the half-year (around 5,343 per hour) and the mention of record-breaking assaults lasting 35 seconds all come from Cloudflare's DDoS threat report for the first half of 2026, published on 11 August 2026. What this post does NOT claim: those figures describe what one specific network sees — Cloudflare's, and therefore its customers' traffic — not the internet as a whole, and the report gives no Spain-specific figure; the example of 400 Mbps against a 300 Mbps office is our own illustration, not a measured case; the claim that many small attacks saturate firewall CPU by packets per second before they saturate bandwidth is our own engineering judgement and not a figure from the report; and we publish no figure here for attacks mitigated on our own network, because we have no audited number to show. The five questions in the central section are our own criteria from running a network, not any vendor's recommendation.