Why 2026 Is a Record Year for DDoS
The scale of DDoS attacks has multiplied within a few years. Cloudflare reported around 47.1 million mitigated attacks for the whole of 2025 - a 121 percent increase year over year - and an average of 5,376 mitigated DDoS attacks per hour (Cloudflare 2025). At the network layer, incidents more than tripled: from 11.4 million (2024) to 34.4 million (2025), and in the fourth quarter of 2025 they already made up 78 percent of all DDoS attacks (Cloudflare 2025). The sheer frequency means even smaller websites come into statistical range - not because they are the target, but because they share the same hosting, the same upstream or the same IP range with an actual target.
The absolute peak has grown too. The record of 31.4 Tbps in late 2025 clearly exceeded the previous best of 5.6 Tbps, and attack sizes grew by over 700 percent compared with the large attacks of late 2024 (Cloudflare 2025). There is also a shift in character: large campaigns increasingly combine several attack families at once - the record attack bundled SYN floods, Mirai traffic and multiple reflection vectors into a single wave (Cloudflare 2025). Such multi-vector attacks are harder to filter - and from the outside, indistinguishable for the operator from a plain server outage. Anyone who wants to know whether their own site is currently reachable needs a measurement from the outside, not just a look at server load.
A common assumption is: we are too small to be a target. 59 percent of small business owners believe this - and around 51 percent have no protective measures against DDoS in place at all (SentinelOne 2026). At the same time, small and medium-sized enterprises are seeing a twelvefold rise in API-based DDoS attacks (SentinelOne 2026). Size offers no protection; the lack of preparation raises the risk.
How DNS Amplification Works
DNS amplification is a reflection and amplification attack. The attacker sends small DNS queries to publicly reachable open resolvers - but forges the sender address and inserts the victim's IP address instead. The resolver dutifully replies, but sends the much larger answer to the victim rather than the attacker. Because a compact query can trigger a far larger response, every abused resolver acts as an amplifier: the documented bandwidth amplification factor for DNS is 28 to 54 times the original query (CISA TA14-017A). With thousands of resolvers abused in parallel, this adds up to a data flood that saturates the victim's connection.
- Source IP spoofing - the attacker enters the victim's address as the sender so the responses flow there
- Small query, large response - a request for all records of a zone (ANY) or for large records produces a multiple of response data
- Reflection via open resolvers - each abused server adds its response volume, without the attacker needing much bandwidth
- Bandwidth saturation - the combined responses saturate the victim's connection and the website becomes unreachable
The appeal for attackers lies in the leverage: little bandwidth of their own produces large volumes of data, and the true source stays hidden behind the resolvers. That is exactly why the availability of open resolvers is the decisive factor. How strongly this vector is back in the foreground is clear from the 2025 measurements: DNS floods were the most common network-layer attack vector, accounting for nearly a third of all L3/4 DDoS attacks (Cloudflare 2025). DNS - long overshadowed by other reflection methods - has thereby become the dominant amplification vector once more.
Open Resolvers and the BCP38 Problem
Two structural weaknesses make DNS amplification possible in the first place. The first is open DNS resolvers: servers that answer recursive queries from across the whole internet rather than only from their own network, and can therefore be abused as reflectors (CISA). Many of these are not deliberately operated services but misconfigured home routers and IoT devices left reachable from the internet. As long as such open resolvers exist in large numbers, DNS amplification keeps its punch.
The second weakness is the absence of source address validation. BCP38 is the long-established recommendation (Best Current Practice 38) advising network operators to discard packets with an obviously forged sender address at the network edge (Heimdal 2026). If this filtering were implemented everywhere, spoofing would lead nowhere - because a packet carrying the victim's IP as sender would not even leave the attacker's network. Since many networks do not enforce BCP38, forging the source IP remains technically trivial. An individual site owner can neither close the open resolvers of the world nor force foreign networks to filter - what remains is the ability to notice an attack quickly and respond.
| Weakness | Who can fix it | What operators can do |
|---|---|---|
| Open DNS resolvers | Resolver operators, ISPs | Close your own resolvers, restrict recursion |
| Missing BCP38 filtering | Network operators at the edge | Little directly - pressure via host/provider |
| Large DNS responses (ANY) | DNS operators | Limit ANY responses, response rate limiting |
| Late outage detection | The site owner themselves | External multi-location monitoring with instant alert |
The last row is the only one fully within your own hands. Anyone who wants to keep an eye on resolver configuration too will find related check patterns in the article on multi-resolver DNS propagation. How closely DNS security and availability are linked is also shown in the article on DNSSEC validation as DNS hardening.
Why Short Attacks Are So Dangerous
The most important development for site owners is not the record size but the shortening. Attackers are shifting from long campaigns to short bursts (SentinelOne 2026). 89 percent of network-layer attacks end within 10 minutes, and many hyper-volumetric waves last only 35 to 45 seconds (Cloudflare 2025); a substantial share is therefore over before anyone even looks. A burst attack probes defenses, distracts from other activities, or is simply enough to damage revenue and trust - and is over before a classic alarm even fires.
A monitor that only checks every five minutes can miss a 90-second outage entirely: the check before was green, the check after is green - the outage falls through the gaps. This is exactly the time window in which modern burst attacks operate. The tighter the check interval and the more locations measure in parallel, the smaller the blind window becomes.
There is also a psychological effect: because a short outage often cannot be reproduced, it is quickly dismissed as a one-off or blamed on the complainant's device. Without an objective recording from the outside, it stays unclear whether it was a local problem of the user or a real, broadly effective outage. This very uncertainty delays the response - and during a series of short burst attacks it costs valuable time. A complete, time-stamped history from several locations ends the speculation and turns a vague suspicion into a solid fact, on the basis of which the host and protection service can be approached in a targeted way.
The economic consequences are real even for short outages. 91 percent of companies put the damage at more than 30,000 US dollars per hour of downtime caused by DDoS (SentinelOne 2026). Small and medium-sized enterprises spend around 120,000 US dollars on average to recover after an attack (Kaspersky Lab IT Security Risks Survey). These figures arise not only from long complete outages but also from repeated short disruptions that damage conversion, search engine crawling and customer trust. Anyone treating availability as a business foundation should understand the link between downtime and cost - the article on calculating monitoring ROI works it through.
Why In-House Dashboards Miss Short Outages
An internal dashboard usually measures the server's view of itself: CPU, memory, application response times. That is precisely blind during a volumetric DDoS. When the connection is saturated, traffic does not even reach the application - the server feels healthy while visitors stand in front of an unreachable site. The dashboard shows green because it simply cannot see the missing reachability from the outside. This gap between server is running and website is reachable is the core of the problem.
Internal metrics measure the server, not the path to it. A saturated connection or a DNS problem stays invisible as long as the process itself is running.
Checks every five minutes miss burst attacks under a minute entirely. Only a tight interval noticeably shrinks the blind window.
A single check point may be affected itself, or mistake a regional outage for a global one. Several locations separate a real outage from local noise.
A log nobody reads in the moment is not an alarm. Without an instant notification, the attack is over before anyone reacts.
Then there is the DNS layer itself. If an amplification attack targets a domain's authoritative name servers, the website is gone not because of a server problem but because its name can no longer be resolved. An internal dashboard on the web server does not notice this at all - the server is reachable, only nobody can find it anymore. How consequential disruptions at the resolution layer can be is examined in the article on the resilience of DNS resolvers during a TLD outage.
What XICTRAQ Monitors
Against short, externally visible outages, a continuous check from several locations combined with an immediate notification helps. XICTRAQ measures your website the way a visitor experiences it - from the outside, across several geographically separated nodes and at a tight interval.
Checks from several locations at once (Nuremberg, Helsinki, Falkenstein). Only when multiple nodes see the same outage does it count as confirmed - separating a real outage from local noise. More in multi-location monitoring.
If the site goes down, a notification goes out within seconds via email, Slack, Discord or Telegram - fast enough to still catch a short burst attack.
An adaptive baseline detects unusually slow responses of the kind that appear with the onset of overload - an early signal before the site collapses entirely.
Beyond pure reachability, DNS resolution is observed, so an attack at the name-server layer also shows up, not just a web-server outage.
Every incident is logged with duration and affected locations. This produces a solid availability history instead of fleeting log lines - a basis for SLA calculations.
If an alert stays unacknowledged, the notification escalates to the next level. Planned maintenance can be excluded so real incidents do not drown in noise.
Since many attacks last under a minute, the check interval is the decisive lever. For business-critical pages, the tightest available interval combined with several locations is advisable - this shrinks the blind window in which a short outage slips past unnoticed.
Set Up Monitoring Properly - Without Alarm Fatigue
More locations and a tighter interval increase sensitivity - and with it the risk of false alarms if the thresholds are set poorly. The key is confirmation across multiple nodes: only when independent locations report the same outage does the alarm fire. A single node with a local network problem therefore does not lead to a false alarm. How to configure alerts so they report reliably without drowning in noise is described in the article on configuring monitoring alerts properly.
It also makes sense to tie monitoring to service-level objectives. Anyone who defines an availability budget can react to its consumption rather than to every single short twitch - an approach the article on error-budget burn-rate alerts explores in depth. This produces escalation with a sense of proportion: a one-off 30-second outage is logged, but a pattern of repeated burst attacks triggers full attention.
What matters is a realistic understanding of what monitoring achieves. External uptime monitoring does not fend off a DDoS - that is the task of the network and hosting layer. What it does deliver is the fast, objective finding that a disruption exists, including duration, extent and affected locations. This information is the prerequisite for any response: informing the host, activating protective mechanisms, telling customers about the status. Without this outside view, a short outage remains a rumour; with it, it becomes a documented incident that can be acted upon.
The practical value lies in the time factor. Without external monitoring, a short DDoS outage typically only comes to light when a customer complains or an order fails to arrive - often hours later, when the incident can no longer be reconstructed. With multi-location monitoring, the same outage becomes visible in seconds, with a timestamp and location reference. This shortening from hours to seconds is the real gain - it turns an invisible data stream into a clear, documented signal.
This article draws on data from: Cloudflare DDoS Threat Report 2025 (31.4 Tbps record in 35 seconds, 47.1 million attacks, 5,376 per hour, network-layer tripling, +700% attack size, DNS floods as the most common L3/4 vector at nearly a third share, multi-vector character of large campaigns), CISA TA14-017A UDP-Based Amplification Attacks and DNS Amplification Attacks (28 to 54 amplification factor for DNS, open recursive resolvers, forged source addresses), Cloudflare DDoS Threat Report 2025 Q1 (89% of network-layer attacks end within 10 minutes, hyper-volumetric attacks often only 35 to 45 seconds), Kaspersky Lab IT Security Risks Survey (~120,000 USD average DDoS recovery cost for SMBs), SentinelOne DDoS Attack Statistics 2026 (44,000 attacks daily, 91% >30,000 USD per hour, 59%/51% small-business assumption, twelvefold API DDoS rise), Heimdal Most Common DNS Security Risks 2026 (BCP38, open resolvers, response-to-request ratio).