Vendor DDoS threat reports follow a familiar shape: a peak attack figure in the terabit range, a named vector, and an implicit argument for the mitigation product sitting next to the download link. The figures describe what one vendor observed on its own network, the same vendor that sells the mitigation, and they should be checked against a second measurement source before they drive a capacity decision. What survives the news cycle either way is structural: DNS runs on UDP, UDP floods amplify, and anycast edge networks now carry the absorption burden that dedicated scrubbing capacity was sized for.
What can actually be verified?
Architecture, not attack statistics. The sources available for this piece are Cloudflare’s homepage, its DNS learning-center explainer, Wikipedia’s DNS article, and a Cloudflare One Client changelog. The changelog is dated through a 2026-07-21 client release, so the vendor pages reflect a post-July-2026 state, but none of the four contains attack-volume figures of any kind: no peak throughput, no DNS-flood counts, no attribution narratives. The verifiable material in this article is architectural, and it is enough to reason from.
What the evidence does support is the frame. Cloudflare’s own homepage states that its security, connectivity, and code services run in more than 335 cities1, and that its network sits within 50ms of 95% of the world’s population1. These are Cloudflare’s own marketing figures, not audited capacity numbers. They are still the right starting point, because the absorption argument in any vendor’s DDoS pitch rests on exactly that footprint.
The second thing the evidence supports is the conflict of interest. Cloudflare sells DDoS mitigation; the homepage lists DDoS protection, WAF, bot management, and Zero Trust controls as built into the network. A threat report showing attacks that exceed on-prem scrubbing capacity is, conveniently, an argument for that product line. That does not make the numbers false. It means the reader should hold them at arm’s length until a second measurement source, a Radware or Netscout report, an ISP’s own telemetry, anything with a different commercial motive, corroborates the trend. No such source was available for this article.
Why is DNS the pressure point in a terabit flood?
DNS is the pressure point because the protocol originally used connectionless UDP as its transport, and UDP’s lack of a handshake is what makes reflection and amplification floods structurally possible.
The mechanics have not changed in four decades. A DNS query is small. The response can be many times larger, especially for DNSSEC-signed records or responses carrying multiple record types. Because UDP has no connection setup, the attacker forges the source address on the query packet, pointing it at the victim rather than at themselves. The resolver, doing exactly what the protocol asks, delivers the large answer to the forged address. The attacker spends a small packet and the victim receives a large one. Multiply across thousands of reflectors and the arithmetic gets ugly fast. The Wikipedia article on DNS records that the system originally used UDP as transport over IP, and that reliability and security concerns later spawned the use of TCP as well.
The concentration story is worth a paragraph of its own, and it does not need a threat report to land. Cloudflare’s homepage puts the company’s security, connectivity, and code services in more than 335 cities1, which tells you how blurred the line has become between “public internet infrastructure” and “vendor edge network.” When a DNS-flood wave arrives, the absorption capacity that stands between a victim and a bad day is increasingly the same anycast fabric a vendor advertises on its homepage.
For a platform team, the practical reading of “a DNS-flood wave” in any threat report is not the count of attacks. It is the reminder that authoritative nameservers are internet-facing UDP services with an amplification property, and that their exposure is an architectural choice, not an accident.
Anycast edge vs dedicated scrubbing: which model absorbs more?
Above the capacity ceiling of any single scrubbing deployment, anycast edge absorption wins, because it dilutes attack traffic across hundreds of points of presence instead of concentrating it at a handful of scrubbing centers.
The dedicated-scrubbing model was designed for a different era of attack volumes. You buy appliances or a scrubbing service, sized to some multiple of your expected peak, and divert traffic through them when an attack starts. The model fails in two places. First, the ceiling: if your scrubbing capacity is sized for hundreds of gigabits and the attack peaks in terabits, no configuration change closes that gap. Second, the diversion itself: scrubbing on demand usually means a BGP announcement change or a GRE tunnel at attack time, which is exactly when you least want to be re-architecting your routing.
The anycast model inverts the economics. The same IP address is announced from every point of presence simultaneously, so attack traffic is absorbed at the edge closest to its source rather than hauled to a central scrubber. A terabit distributed across a few hundred cities is a few gigabits per location, which ordinary edge hardware handles. This is the pitch implicit in Cloudflare’s 335+ city footprint1 and its “within 50ms of 95% of the world’s population”1 claim.
The skeptical reading: cities are not capacity. A point of presence can be a full data center or two racks in a colocation cage, and the marketing page does not say which. The 335-city figure1 tells you about fan-out, not about how many terabits the network can actually sink before queues fill. When a vendor’s threat report and a vendor’s absorption pitch arrive in the same document, the capacity numbers behind the pitch deserve the same scrutiny as the attack numbers in front of it.
The decision frame for platform teams is therefore not “anycast good, scrubbing bad.” It is a sizing question. If your honest worst-case peak fits inside dedicated scrubbing capacity with headroom, the scrubbing model gives you control and auditability. If the worst case exceeds what you can economically provision, the absorption burden migrates to an edge network you rent rather than hardware you own. That is a procurement decision with lock-in consequences, and it should be made with verified numbers.
How should you provision DNS for flood resilience?
Provision authoritative and recursive DNS as separate systems on separate infrastructure, and treat multi-provider authoritative DNS as an explicit resilience decision with real operational costs rather than an accident of org structure.
The separation rule comes first. A recursive resolver’s job is to chase answers across the internet on behalf of clients, which makes it both an amplification reflector if left open and a resource-exhaustion target if flooded with queries for randomized nonexistent subdomains. Your recursive resolvers should answer only for your own networks, behind access control, with response-rate limiting applied. Your authoritative servers answer for your zones and nothing else. Mixing the two roles on the same hosts means a flood aimed at one function degrades the other.
Response-rate limiting on the authoritative side needs care rather than blind application. RRL throttles repeated identical responses to the same source, which blunts reflection abuse of your servers. But during an actual attack with spoofed sources, aggressive RRL can drop legitimate retries from real resolvers whose queries happen to collide with the attack pattern. The setting deserves testing, not defaults.
Multi-provider DNS is where the flood-resilience question has its sharpest consequence. Historically, many organizations ended up with two DNS providers by accident: an acquisition, a migration that never finished, a registrar default nobody revisited. The argument the current threat environment makes is that second provider should be a deliberate, tested configuration. That means both providers serving the same zones with synchronized records, NS records at the registrar pointing at both, and regular verification that zone transfer or API-based sync has not silently drifted. It also means accepting real friction: feature parity is not guaranteed between providers, apex-record handling differs, DNSSEC signing must be coordinated, and a misconfiguration at either provider now takes you down. The resilience gain is genuine; a single provider’s total outage stops being your outage. The price is that DNS becomes a distributed system you operate rather than a service you forget about.
What should your DDoS capacity checklist demand?
Demand three things from any DDoS sizing exercise: measured peak ingress at your own edge, the amplification factor your exposed services can be forced to generate, and a written escalation path for the moment both are exceeded.
A workable checklist, derived from the structural facts rather than vendor statistics:
- Baseline and peak measurement. Your own traffic graphs, not a vendor’s report, set the denominator. Peak-to-average ratio determines how much headroom a scrubbing commitment actually buys.
- Exposure inventory. Every UDP service reachable from the internet is a potential reflector. Authoritative DNS is the obvious one; anything else answering UDP deserves the same scrutiny.
- Amplification audit. Measure the largest response your own DNS servers will emit relative to the smallest query that triggers it. That ratio is what an attacker gets for free if they reflect off you.
- Contract terms before the attack. Unmetered mitigation versus burst pricing, diversion time under BGP change, and the support escalation path all behave differently at 03:00 during an event. Read them now.
- Failover rehearsal. If multi-provider DNS is the plan, test it. An untested secondary provider is a placebo.
- Vendor number interrogation. For any threat report or capacity claim, ask: peak or percentile, attack duration, deduplication across points of presence, and whether the sample is the vendor’s network or something broader.
What are the limits of single-vendor telemetry?
Single-vendor telemetry tells you what one network saw, not what the internet experienced, and when the vendor sells the mitigation, the report functions as both measurement and sales instrument.
That is not an accusation of bad faith. Cloudflare’s vantage point is genuinely large, and a vendor operating in a self-reported 335+ cities1 sees more attack traffic than most organizations ever will. The limits are structural instead. The sample overrepresents the vendor’s own customers. Geopolitical attribution for UDP floods is inherently weak because the source addresses are forged by design; any “tied to geopolitical tensions” framing is a correlation claim about timing and targeting, not a measurement of who sent the packets. And no rival methodology was available to triangulate against for this article, so cross-vendor agreement on any surge figure remains an open question.
The practical verdict survives all of that. Treat single-vendor DNS as a concentration risk regardless of whose numbers you believe. The durable facts are the old ones: DNS has used UDP as its transport since the protocol’s November 1983 introduction, UDP floods amplify, and the absorption capacity that matters in a terabit event lives in anycast fan-out that almost no organization can justify building for itself. The specific figures in any vendor’s report, the peak thresholds, the flood counts, the geopolitical attribution, need to be validated against the actual document and a second measurement source before they change anyone’s provisioning. The provisioning questions they raise, anycast versus scrubbing sizing, authoritative-recursive separation, multi-provider DNS as a chosen architecture, were worth answering before the latest threat report and will still be worth answering after the next one arrives with bigger numbers.
Frequently Asked Questions
How does DNS-over-HTTPS (DoH) change the amplification risk profile?
DoH shifts DNS traffic to TCP port 443, which requires a three-way handshake before any data exchange. This handshake prevents source-address spoofing, the core mechanic of UDP reflection attacks. However, DoH does not eliminate volumetric risk; attackers can still exhaust server CPU and memory by initiating millions of TCP connections, a technique known as a slowloris or connection-flooding attack.
What is the operational cost of maintaining multi-provider DNS?
Running two providers requires synchronizing zone files via API or zone transfers, which introduces latency and drift risks. DNSSEC signing must be coordinated across both providers to avoid signature expiration or mismatched keys. Additionally, monitoring tools must be configured to query both providers independently to detect outages that affect only one path.
Why does BGP diversion introduce risk during an attack?
Diverting traffic to a scrubbing center requires changing BGP announcements, which can take minutes to propagate globally. During this window, the victim site may be unreachable or partially reachable. Furthermore, BGP hijacking attacks can occur simultaneously, where an attacker announces the victim’s IP to a malicious scrubber, bypassing the intended diversion path entirely.
How does DNSSEC impact scrubbing capacity requirements?
DNSSEC adds digital signatures to DNS records, increasing response size by 20 to 50 percent. This larger payload means a given bandwidth capacity can absorb fewer queries before reaching saturation. Teams must recalculate scrubbing headroom to account for this amplification factor, as a 1 Tbps pipe will handle significantly less DNS traffic when DNSSEC is enabled compared to unsigned zones.
