Spamhaus's 2013 DDoS Made Open DNS Recursion a Network Accountabi

Summary

Cloudflare reported an initial attack that saturated Spamhaus's connection and later reflected-DNS waves observed at larger rates, but those provider observations do not establish a universal Internet peak or global outage. [1][2]
The executable path joined a forged source address, an exposed recursive resolver, an amplified response and shared routing or mitigation links. Recursive and authoritative DNS remain distinct roles. [4][10]
RFC 5358 already recommended restricting recursion, while BCP 38 and BCP 84 assigned source-address validation to access, customer and multihomed network edges. [4][5][6]
Resolver operators, access networks, mitigation providers, upstreams, exchanges and Spamhaus each controlled different parts of the running path; responsibility requires path-specific evidence rather than institutional labels.
Website interruption did not prove that Spamhaus's distributed blocklist data stopped globally. Service-layer claims must identify the endpoint, path and observation window. [3]
Later DNS mechanisms, RIPE, MANRS, DNS-OARC and research provide useful comparison and verification tools, but they cannot be projected backward as controls available in identical form in March 2013. [7]-[9][14]-[19]
The accountability test is operational: close unintended recursion, validate source addresses, document routing and mitigation changes, preserve coordination evidence and verify repairs from outside the affected path.

The Accountability Frame

The March 2013 attack on Spamhaus was an accountability test for ordinary network controls, not merely a legend about one enormous flood. From March 18 to 27, traffic first disrupted Spamhaus’s website and later reached infrastructure used by Cloudflare’s providers and peering surface. The path joined independently operated systems: forged source addresses, exposed recursive DNS servers that accepted requests, larger replies directed toward the forged destination, and shared links carrying the aggregate load.

Cloudflare’s contemporaneous accounts bound the event; earlier standards identify which operators controlled key parts of that path [1][2][4][5][6].

Recursive and authoritative DNS are different roles. An authoritative server publishes data for zones it serves; a recursive resolver performs lookups for clients. A resolver open to arbitrary external clients can become a reflector despite having no relationship with the target [4][10]. RFC 5358 already recommended limiting recursive service, while BCP 38 and BCP 84 described source-address validation at access, customer, and multihomed network edges [4][5][6]. The first control limits reflection; the second blocks forged packets.

Responsibility follows practical control. Resolver operators controlled who could recurse and response behavior. Access and transit operators controlled edge filtering. Cloudflare controlled anycast mitigation, routing changes, and its public claims. Spamhaus controlled service design and recovery communications, not remote resolvers or spoofing networks. Exchange operators and upstreams merit conclusions only where path evidence shows what they carried or controlled.

This analysis takes no position on the legitimacy of Spamhaus’s blocklists. Its narrower finding is that neglected edge configurations can combine into a shared externality. Accountability requires evidence that each operator repaired what it could control.

The Bounded Event Record

The event boundary is the March 18–27 campaign against Spamhaus and, later, parts of Cloudflare’s provider and peering surface. Cloudflare said Spamhaus sought mitigation after an attack saturated its connection and made its website unreachable. It reported roughly 10 Gbit/s initially, then waves around 75–90 Gbit/s, largely reflected through open recursive resolvers [1]. A follow-up described escalation toward 120 Gbit/s and traffic shifting from the customer address toward providers and exchange-facing links [2].

These observations must not be collapsed into one continuously, uniformly measured event. Traffic at a protected customer interface, inside a mitigation network, and against upstream or peering links comes from different vantage points and may describe different failure domains. Website unreachability also does not prove Spamhaus’s distributed anti-spam data disappeared. Spamhaus later said its blocklist data remained available while its website, hosts, DNS partners, and supporting services were targeted [3]. The record therefore does not show that global email filtering stopped.

The mechanism was specific. Cloudflare said requests used spoofed source addresses, asked exposed recursive resolvers for ripe.net data, and caused larger replies to converge on the victim. Cloudflare reported more than 30,000 participating resolvers and estimated amplification near one hundred for the request-and-response shape it observed [1][2]. Each resolver or source network could contribute modest traffic locally while thousands of such paths accumulated into a link-saturating flood.

The phrase “almost broke the Internet” was contemporary publicity framing, including Cloudflare’s own headline, not a demonstrated finding of global failure [2]. No cited record establishes a particular exchange-wide outage, universal disruption, or a legally adjudicated attacker identity for this bounded account. Those claims remain outside the evidence.

What Was Measured, and Where

Every headline rate needs a named observer and measurement context. The roughly 10 Gbit/s and 75–90 Gbit/s figures were reported by Cloudflare in its customer-mitigation account [1]. The movement toward 120 Gbit/s, and the often repeated 300 Gbit/s peak, belong to Cloudflare’s later provider-side narrative [2]. The 300 Gbit/s number is therefore a provider-observed claim, not a measurement of the public Internet as a whole. None of these figures can be treated as a universal peak without synchronized, independently documented observations across relevant networks.

The same discipline applies to attribution. Resolver logs can show recursion exposure and response behavior. Spoofing tests and customer-edge records can show whether source-address validation worked. Flow data, route changes, scrubbing records, and transit coordination can locate where traffic entered and which links encountered pressure. Abuse notices and post-incident scans can show whether exposed systems were identified and repaired. Anycast can distribute load, but its outcome still depends on route selection, peering, transit capacity, and the locations at which traffic arrives.

Later guidance sharpens that evidence model. DNS Cookies, reduced ANY-response behavior, and architecture for large authoritative services provide modern comparison points [7][8][9]. RIPE and DNS-OARC material likewise supports inventories, closed recursion, response controls, role separation, and operational verification [14][16][17][19]. These sources do not prove that every later control was available or deployable in the same way during the attack.

Several limits remain unresolved: the complete source-AS distribution; exact peak measurement points; any universal peak; the extent of bystander congestion or impact outside reported paths; actor-specific or internal operator knowledge before and during the campaign; and exact causal apportionment among participating networks. Preserving those unknowns is part of the accountability test. The sound conclusion is not who deserved blame in the abstract, but which operator had a working control, what evidence demonstrates its state, and whether the repair was auditable.

The Executable Reflection Path

The executable path began with a lie in an IP header. An attacker sent a small UDP DNS query while replacing its source address with Spamhaus’s address or, in later phases, infrastructure carrying mitigated traffic. UDP establishes no connection before a reply, so the server returned its answer to the forged address. The attacker supplied the small trigger; the DNS server sent the large packet.

The intermediary was an open recursive resolver. It accepted requests from arbitrary Internet addresses, retrieved the requested data, and returned the result to the claimed client. Cloudflare reported queries for ripe.net, more than 30,000 participating resolvers, and amplification near one hundred for the query-and-answer shape it observed [1]. Those figures are Cloudflare’s observation, not a census of every resolver or packet. Repetition produced the operational effect: many small forged requests induced larger responses that converged on one destination.

That destination could be the victim, an anycast mitigation site, or a provider-facing link carrying the protected service. Pressure could therefore exhaust network capacity before reaching an application. Cloudflare describes traffic against Spamhaus and later traffic affecting its mitigation and provider path [1][2]. A reflected packet on that path proves a response arrived; it does not reveal the originating bot, the complete source-AS distribution, or a universal Internet peak.

Recursive and authoritative DNS are distinct. An authoritative server publishes answers for zones it serves. A recursive resolver accepts a client’s question, follows the DNS hierarchy when needed, caches results, and returns a resolved answer [10]. One machine can perform both functions, but the roles remain separable. This path exploited externally available recursion, not “DNS servers” as one class. Authoritative services can enable other amplification patterns, but that does not make every authoritative operator an open-resolver operator.

Recursion Is an Operator Control

RFC 5358 had described this reflector problem in 2008, five years before the Spamhaus campaign. Its central operational allocation is direct: recursive nameserver operators should provide recursion only to intended clients, while network operators should prevent packets carrying forged source addresses from escaping their networks [4]. Closing recursion does not mean disabling public authoritative DNS. It means defining who is entitled to use the recursive service and enforcing that boundary through access controls, interface policy, or a separately operated resolver.

That boundary belongs to the resolver operator because that operator chooses the software, service roles, listening interfaces, client ACLs, cache policy, and response behavior. If an authoritative server also offers recursion, the operator must account for the recursive role explicitly; a combined deployment does not erase it. An exposed resolver is not excused because each reflected response is modest, nor because the operator did not select Spamhaus as the target. Its configuration supplied an executable capability to an unauthenticated external requester.

The relevant evidence is equally concrete. An operator should be able to produce a current resolver inventory, externally performed recursion tests, configuration showing authorized client ranges, role separation where used, and logs or measurements demonstrating that a repair survived restart and failover. Response-rate controls can reduce harm, and later techniques can make some exchanges harder to spoof, but they supplement rather than replace a recursion boundary [7][19]. RFC 5358’s pre-attack date matters: restricted recursion is not a control invented retrospectively to fit the incident.

Responsibility also has limits. A resolver normally sees the source address presented in the UDP packet; it does not control the distant network on which that address was forged. Conversely, an access provider that permits spoofing does not administer a remote resolver’s recursion ACL. Where one organization operates both systems, both duties attach, but they remain two controls with different evidence. Accountability follows the component an operator could configure and verify.

Spoofing at the Network Edge

BCP 38, published as RFC 2827, assigns a practical control to the network nearest the origin: filter traffic arriving from a customer or internal network when its claimed source is not legitimately reachable from that interface [5]. Although called ingress filtering from the provider’s viewpoint, its result is egress protection for the wider Internet. The customer or enterprise controls what its hosts emit; the access provider controls validation at the customer-facing boundary. That is the point at which assigned prefixes and interface relationships provide the strongest basis for rejecting a forged source.

BCP 84 extends the allocation to multihomed networks, where valid traffic may follow asymmetric routes. It does not justify abandoning source validation merely because strict reverse-path forwarding would be unsafe. It describes topology-aware choices, including interface ACLs and reverse-path methods with different acceptance properties, so operators can preserve legitimate multihomed traffic while still rejecting impossible sources [6]. A multihomed customer must accurately declare its usable source prefixes, and its providers must implement and maintain a compatible policy at each attachment.

A transit network is therefore not automatically responsible for every spoofed packet it happens to carry. Its responsibility is strongest on customer-facing edges where it knows the customer-prefix relationship and controls the filter. Farther along an arbitrary transit path, the same inference may be unavailable. Evidence should identify the actual interface and policy: permitted-prefix records, ACL or source-validation mode, asymmetric-routing exceptions, sampled drop counters, spoofing-test results, change history, and abuse-notification handling.

Continuing deployment gaps make such verification more useful than a generic claim of compliance [15].

RFC 5358 and BCP 38/84 address opposite ends of one path. Restricted recursion removes the reflector available to arbitrary requesters; source-address validation stops the forged request before it reaches any reflector [4][5][6]. Neither control transfers the other operator’s duty. The amplified response is enabled only when these independent failures align, which is why the packet path is also an accountability map.

Aggregation Turns Local Neglect into a Network Externality

An open recursive resolver can look like a small local mistake: one server answers clients it was never meant to serve, while an access network forwards packets with source addresses it never assigned. Neither act seems consequential at the rate visible locally. Reflection changes the unit of account. A forged request names the victim as its source, the resolver sends its answer to that victim, and a response larger than the request multiplies the traffic. RFC 5358 described this pattern and recommended restricting recursion before the 2013 attack [4].

The executable chain crosses administrative boundaries. An attacking host emits a small DNS query with a forged source address. The source network determines whether that impossible address may leave; an exposed recursive resolver determines whether an arbitrary external client may recurse. Authoritative servers supply data within DNS's hierarchy, but they are not interchangeable with the recursive service that obtains and returns the answer [10]. The response follows routing into transit, peering, mitigation, and victim-facing links. At every hop, software and configuration—not abstract affiliation—determine whether the chain continues.

Aggregation occurs because each participant contributes capacity without seeing the campaign. One resolver emitting a few megabits per second may remain below its alarm threshold. One broadband or hosting network may carry sparse spoofed requests across many customers. Yet tens of thousands of resolvers can answer in parallel. Cloudflare reported more than 30,000 participating resolvers in the Spamhaus campaign and estimated amplification near one hundred for the observed query-and-response pattern [1]. Those are attributed observations, not universal constants, but they show locally modest emissions converging on a remote bottleneck.

This is a network externality: the party leaving recursion open or permitting spoofing receives convenience or avoids remediation cost, while a remote service, mitigation provider, carrier, or exchange-facing link absorbs congestion. The harm can migrate. Cloudflare's accounts moved from traffic aimed at Spamhaus to later waves directed at provider and peering surfaces, where the constrained resource was no longer only the customer's connection [1][2]. Anycast can spread load across sites, while peering and transit capacity determines where concentration becomes failure.

A provider-side peak describes its measurement point, not the condition of the entire Internet [2].

The thousands-to-one effect defeats accountability based only on intent or individual volume. No neglected resolver must be indispensable, and no source network must originate a large flow. The question is whether each operator controlled an executable condition whose repetition enabled the flood. Closing one resolver barely changes an attack; maintaining closed recursion across an estate changes the reflector population. Dropping one forged packet is immaterial; validating source addresses at every customer edge removes a prerequisite at scale. BCP 38 and BCP 84 locate that duty at access, customer, and multihomed boundaries [5][6].

Evidence Must Follow Practical Control

Evidence should follow those control points. A resolver operator should retain an inventory of recursive instances, intended client prefixes, ACL or equivalent policy exports, external exposure scans, change tickets, and sampled query-and-response telemetry. Records should show when public recursion was detected, who owned remediation, and whether an outside vantage point confirmed closure. Rate-limit settings and logs demonstrate bounded behavior but do not replace access control.

Later mechanisms such as DNS Cookies and minimized ANY responses are useful comparisons, not proof that identical controls were available or deployed in March 2013 [7][8]. Tests must keep recursive and authoritative roles separate.

An access provider should retain per-interface source-prefix policy, deployment coverage, exception registers, failed-validation counters, and controlled spoofing-test results. A multihomed customer or transit operator needs evidence that filtering reflects feasible return paths rather than a brittle single-uplink assumption, the problem addressed by BCP 84 [6]. Abuse notices should identify customer, interface, AS, time window, disposition, and retest. “BCP 38 enabled” is weak unless the operator shows which edges were tested and which remain exempt.

Source-address validation's continuing operational difficulty reinforces the need for measured coverage rather than policy declarations [15].

Transit, peering, and exchange operators control another layer. They should preserve sampled flows, interface utilization, route announcements and withdrawals, communities, traffic-engineering changes, congestion alarms, and coordination timestamps. Those records identify where reflected traffic entered, which link became constrained, and what routing action changed the outcome. They cannot alone prove that a resolver operator knew of an exposure or assign attack volume to an exchange without path evidence.

RIPE and DNS-OARC material connects observable amplification load with countermeasures and measurement rather than treating shared infrastructure as one undifferentiated victim [16][17].

A mitigation provider should retain attack fingerprints, sampling methodology, measurement locations, deduplication rules, anycast site loads, scrubbing decisions, route changes, and upstream requests. Public rate claims need timestamps, observation points, and distinctions among received, dropped, and customer-delivered traffic. The reported 300 Gbit/s figure belongs to Cloudflare's provider-side narrative and should not become a globally measured outage [2]. After-action evidence should show whether mitigation preserved a website at some locations or protected the provider path more broadly.

Later guidance for large authoritative services can inform resilience reviews without rewriting 2013 capabilities [9].

Spamhaus controlled its service architecture, dependencies, recovery choices, and public status communication. It should retain dependency maps, DNS and hosting changes, website availability measurements, and separate checks for distributed blocklist delivery. Website interruption does not establish that global email filtering failed. Spamhaus did not control remote resolvers or networks admitting forged packets, just as upstreams did not control Spamhaus's application design.

An auditable record therefore maps every claim to a controlled layer, timestamped observation, corrective action, and independent retest, while leaving the complete source-AS distribution, universal peak, and unobserved bystander effects explicitly unknown.

Anycast, Transit and Peering Changed the Failure Domain

When Cloudflare began mitigating the attack, protection moved beyond one server. The initial flood had saturated Spamhaus’s connection and made its website unreachable. Cloudflare described traffic near 10 Gbit/s, followed by waves around 75 to 90 Gbit/s, with open recursive resolvers reflecting DNS answers toward the protected address [1]. Anycast changed where the traffic could arrive and be absorbed.

Anycast announces the same service address from multiple locations. Routing draws portions of an attack toward different sites, allowing filtering capacity to be distributed instead of concentrated behind one access link. Its effective capacity still depended on selected routes, headroom at each site, and the transit and peering links over which packets arrived. A distributed edge can expose an interconnection narrower than its aggregate mitigation capacity.

Cloudflare reported that the campaign later shifted beyond the original Spamhaus destination, reaching roughly 120 Gbit/s and targeting providers and links on the route to its network [2]. Its account also associated the incident with a peak of about 300 Gbit/s [2]. Those figures describe observations made within a mitigation provider’s visibility. They are not a universal meter of all Internet traffic, and they do not establish that every network on every path experienced the same load.

“Exchange-facing” therefore needs careful interpretation. Attack traffic may reach a mitigation site across a private peer, an exchange port, a transit circuit, or some combination selected by BGP. Saturation on one such path can affect the networks using it without proving that an Internet exchange as a whole failed. The frozen record supports an escalation toward provider and peering surfaces [2]; it does not support inventing an exchange-wide outage. Nor does a large flow observed near an exchange identify which member, port, route, or physical link was the binding constraint. Exact attribution requires path-specific evidence.

Routing was part of the mitigation system, not merely a map drawn after the event. Service announcements determined which edge accepted packets, while route changes and coordination with upstreams could move or suppress load. Peering could shorten paths and spread ingress; transit could provide reach and additional capacity. Either could also become a choke point. A credible after-action account would therefore preserve announcement changes, site-level traffic, interface counters, peer and transit coordination records, and timestamps showing when the failure domain moved. Aggregate peak rates alone cannot reconstruct that sequence.

The measurement limits are equally important. Cloudflare said it saw more than 30,000 participating resolvers and described a query-and-response pattern with amplification near one hundred [1]. That establishes scale within its observation, not a complete inventory of source autonomous systems or operator knowledge. The complete source-AS distribution, the amount of bystander congestion, and the causal share attributable to each path remain unknown. Contemporary language that the attack “almost broke the Internet” should be treated as publicity framing attached to a provider narrative, not as a demonstrated global-outage finding [2].

Accountability should follow the controls each participant could exercise and document. Cloudflare controlled its anycast design, filtering, route changes, upstream coordination, and accuracy in reporting what it measured. Transit and peering partners controlled their own interfaces, customer policies, congestion response, and coordination records. Exchange operators controlled shared switching and operational response, but should not be assigned attack volume or an outage without evidence tied to their infrastructure. Capacity matters; so do routing decisions and records that show where capacity was actually available.

Website Availability Was Not DNSBL Availability

The first visible service failure was specific: traffic saturated Spamhaus’s connection and its website became unreachable [1]. Later phases affected Cloudflare’s provider-facing environment and supporting paths [2]. Spamhaus also described attacks against hosts, DNS partners, and supporting services, while saying that its distributed anti-spam data remained available [3]. These facts belong in the same incident history, but they do not describe one indivisible service.

A public website serves pages, contact information, explanations, and operational communications. A DNS-based blocklist distributes data through a different set of query endpoints, replicas, routes, caches, and user dependencies. Losing the web front door can obstruct support and public status information without removing every path through which mail systems obtain blocklist answers. Conversely, continued blocklist-data availability does not make the website and supporting-network disruption trivial. It means the impact must be described per service.

This distinction also limits claims about downstream email filtering. The available evidence does not show that global filtering stopped. Spamhaus’s statement supports the narrower proposition that its distributed data service continued operating during attacks on other parts of its infrastructure [3]. It does not prove that every user, resolver, region, or network path had uninterrupted access. Local failures and path-specific degradation cannot be inferred away, just as they cannot be inferred from the website outage.

Useful availability evidence would separate HTTP reachability, authoritative DNS health, DNSBL query success, update freshness, latency, and error rates. It would sample several networks and locations, record which endpoint and route were tested, and preserve time windows rather than replacing them with a single “online” label. Public incident communication should identify whether a statement concerns the website, a supporting provider, a nameserver, a blocklist query service, or data publication.

Spamhaus controlled that service architecture and the precision of its recovery messages. Cloudflare controlled mitigation for the traffic and routes it accepted. Neither controlled the remote open resolvers or networks that admitted spoofed-source packets. Keeping those control boundaries visible prevents a website interruption from being inflated into worldwide DNSBL failure, while still recognizing that attacks on supporting networks can threaten operational continuity even when the distributed data plane continues to answer.

Standards Before and After 2013

The 2013 campaign did not expose a control problem that standards bodies had yet to identify. RFC 5358, published in 2008, describes DNS amplification using forged victim addresses and publicly accessible recursive servers. It recommends restricting recursion to intended clients and notes that limiting response-generating services addresses reflection at one point, while source-address validation addresses spoofing at another [4]. That distinction is the right contemporaneous benchmark for Spamhaus: a resolver operator and the network carrying the forged request controlled different links in the same executable chain.

RFC 2827, BCP 38, had since 2000 called for ingress filtering at customer-facing edges so traffic with source addresses outside the legitimate customer prefix would not propagate [5]. RFC 3704 extended the operational model for multihomed networks, discussing strict and feasible-path reverse-path checks and other filtering methods where asymmetric routing complicates simple rules [6]. Together, these texts show that by March 2013 two relevant duties were documented: do not offer unrestricted recursion, and do not export obviously forged traffic.

They do not prove which participant had deployed what, knew what, or originated a particular packet. Accountability still requires path-specific evidence.

Later material should sharpen today's verification, not be projected backward as though it were the 2013 baseline. DNS Cookies can add spoofing resistance where both endpoints support them [7]; minimizing ANY answers can reduce one historically useful amplification shape [8]; and later authoritative-service architecture guidance addresses resilience and operational design at scale [9]. None substitutes for closing unintended recursion or filtering forged sources.

RIPE operational guidance, MANRS material, DNS-OARC presentations, and measurement research similarly provide comparisons, test methods, and evidence about persistent exposure [14][15][16][17][18][19]. They can show what mature assurance now looks like. They cannot establish that every later technique was available, uniformly deployable, or actually deployed during the March 18–27 event. The historical finding should remain narrower: the principal control categories were already public, while their implementation and verification were fragmented.

A Verification Program for Operators

A credible program starts with claims that can be reproduced. Each operator should maintain a dated inventory that maps every recursive listener to owner, interface, address family, permitted client ranges, software version, configuration source, and change ticket. External probes from unauthorized networks should receive no recursive service; internal tests should show intended clients still resolve. Test both UDP and TCP, IPv4 and IPv6, and common alternate or overlooked interfaces. Preserve signed configuration snapshots, probe locations, timestamps, packet captures, and exception approvals.

A dashboard assertion that “recursion is closed” is not evidence without the tested population and negative results.

Then verify spoofing controls at the edge where policy can be enforced. For each customer, access segment, cloud tenant class, and peering or transit role, document the expected source prefixes and the mechanism used—ACL, unicast reverse-path validation, feasible-path logic, or an equivalent control. Conduct authorized tests with deliberately invalid sources, recording whether packets leave the controlled boundary. Repeat after routing changes because multihoming and asymmetric paths can turn a once-correct strict check into either a bypass or collateral filtering [5][6].

Exceptions need an owner, technical rationale, compensating control, expiry date, and retest.

Telemetry must connect these two control planes. Resolver logs or sampled flow records should identify unsolicited query rates, requested names and types, response sizes, truncation, and rate-limit actions without retaining unnecessary user data. Border telemetry should show spoofing drops by interface and customer policy, while route and capacity records show where reflected traffic entered. Operators should retain enough detail to answer: Was the resolver accessible? Could the request source have been forged? What response did it generate? Which link carried it? Which control changed?

A per-AS abuse notice should include UTC intervals, destination and apparent source, protocol, representative packet evidence, measurement method, and a contactable case identifier—not merely a list of IP addresses.

Controls should be exercised, not presumed. Run scheduled external recursion scans over the operator's authorized estate; source-validation tests from representative egress points; safe response-size and rate-limit tests; and failover drills for DNS, anycast, transit, and communications. Compare observed behavior before and after each repair. Later mechanisms may be included as defense in depth: test DNS Cookie negotiation, reduced ANY behavior, authoritative/recursive role separation, and large-service failover according to their actual deployment conditions [7][8][9].

Use later RIPE, MANRS, and DNS-OARC material to refine today's coverage, especially when exposure persists across organizational boundaries [14][15][17][19].

Incident records should preserve the sequence of detection, mitigation, route change, upstream contact, capacity pressure, and recovery. Anycast providers should show which sites announced the service, how traffic shifted, where congestion appeared, and which routes or policies changed. Transit providers should produce customer-edge filtering and coordination evidence, but should not be assigned attack volume merely because they were on a plausible path. Exchange operators should report port and fabric observations only within their measurement scope. Resolver operators should demonstrate closure and retest.

Access networks should demonstrate that forged-source packets no longer exit. Service owners should distinguish website availability, DNS and supporting-host availability, and separately distributed data services; one green status must not stand in for all of them.

Finally, governance should turn artifacts into repeatable accountability. Assign each failed test to the operator with practical control, set a remediation deadline based on exposure, and require independent retesting before closure. Track coverage denominators—not just counts of fixed resolvers or blocked packets—and publish carefully scoped metrics: estate tested, methods, observation window, residual exceptions, and blind spots. Quarterly sampling should be supplemented by tests after acquisitions, network redesigns, resolver upgrades, new transit, or major route-policy changes.

Research and contemporary measurements can inform sampling and expected failure modes [18][19], but an operator passes only by producing current, path-specific evidence from its own running system.

Limits of the Public Record

The public record is narrower than the legend around the March 18–27, 2013 campaign. Cloudflare’s contemporaneous accounts describe an initial attack that made Spamhaus’s website unreachable, traffic near 10 Gbit/s, later waves around 75–90 Gbit/s, and escalation toward 120 Gbit/s as pressure moved from the customer address toward provider and peering-facing infrastructure.[1][2] The widely repeated 300 Gbit/s figure belongs to Cloudflare’s provider-side observation. It is not a universal measurement of traffic crossing the public Internet.

Likewise, “almost broke the Internet” was publicity framing, not a demonstrated finding of global failure.[2]

The mechanism is better established than the total scale. Attackers sent DNS requests carrying forged victim addresses to publicly reachable recursive resolvers. Those resolvers returned responses much larger than the requests toward the forged addresses, converting small outbound packets into an aggregate inbound flood. Cloudflare reported queries involving ripe.net data, more than 30,000 participating resolvers, and amplification near one hundred for the request-and-response shape it observed.[1][2] These are attributed observations, not a complete census.

Recursive service must also remain distinct from authoritative DNS: the operational defect was unrestricted recursion combined with spoofable traffic, not the mere existence of DNS servers.[4][10]

The affected services require similar precision. Spamhaus’s website and supporting provider paths were targets, but its distributed blocklist data was distinct and reportedly remained available.[3] Traffic aimed at mitigation providers, upstreams, or exchange-facing links could impose costs on parties that had no dispute with Spamhaus. Yet the frozen record does not justify assigning a particular outage to a particular exchange, nor does it measure all congestion experienced by unrelated networks.[2][16][18]

The following remain unknown: the complete source-AS distribution; any universal peak; the full bystander impact; what individual resolver, access, transit, exchange, mitigation, or victim operators knew before or during the event; definitive attribution of every action; and exact causal apportionment among actors. A later arrest notice is relevant context, but it does not close every technical or legal attribution question.[3] These gaps are boundaries on judgment, not invitations to fill the record with inference.

The Accountability Test

The reality-layer accountability test is central: this incident is intelligible only as running infrastructure. Remove exposed recursion, forged-source reachability, response amplification, anycast execution, peering and transit paths, or service continuity, and the accountability thesis disappears. Legitimacy here does not come from institutional standing, community rhetoric, or moral agreement with Spamhaus’s blocklists. It comes from whether operators controlled real failure surfaces, maintained accurate operational records, and repaired what their systems actually allowed.

The first test is capability. Resolver operators can restrict recursive service to intended clients, separate recursive and authoritative roles, inventory exposure, and bound abusive response behavior. RFC 5358 described the reflector risk and recommended limiting recursion years before the campaign.[4] Access networks can prevent packets with implausible source addresses from leaving. BCP 38 and BCP 84 made that filtering responsibility concrete for ordinary and multihomed environments.[5][6] Neither control alone ends every attack: closed recursion does not stop spoofing elsewhere, and source validation does not repair an exposed resolver.

Accountability follows the control each operator could actually exercise.

The second test is evidence. A credible resolver operator should be able to produce dated exposure scans, access-control configuration, query and rate-limit records, abuse-ticket handling, and post-remediation validation. An access or transit operator should be able to show source-address-validation policy, customer-edge tests, exceptions, notification records, and verification after a failure. Continued difficulty deploying source validation makes such proof more important, not less.[15] Evidence turns a general promise of “best practice” into an auditable claim about running code.

Cloudflare controlled its anycast distribution, scrubbing choices, route changes, capacity decisions, coordination with peers and transit providers, and the precision of its public measurements.[1][2] Anycast could spread load, but it could also move the failure boundary to links or sites whose headroom differed. Peers, exchanges, and upstreams controlled coordination and congestion responses; they should not, however, be assigned attack volume or fault without path-specific evidence.

Spamhaus controlled service architecture, recovery communication, and the distinction between its website and distributed data, but it did not control remote resolvers or networks permitting spoofed traffic.

The third test is externality. One resolver may emit little traffic, and one access network may pass only a thin stream of forged requests. Thousands of individually neglected controls can nevertheless combine into a link-saturating flood. Local configuration therefore creates costs outside the operator’s own network. Per-AS abuse notices, open-resolver inventories, spoofing tests, rate-limit telemetry, transit coordination logs, route-change records, and after-action verification provide a practical chain from observed behavior to repair.[16][17][19]

Later standards sharpen that evidence model without rewriting 2013. DNS Cookies can help resist spoofing in supported exchanges; minimal ANY responses reduce one attractive response shape; and later authoritative-service guidance addresses resilient large-scale architecture.[7][8][9] These are comparison points, not proof that every later control existed in identical, deployable form during the campaign. The fair question is not whether a 2013 operator anticipated every future RFC. It is whether available controls were used, limitations were documented, and corrective work was verified.

Conclusion

The Spamhaus campaign matters because it exposed a distributed accountability failure rather than a single dramatic pipe. The victim, reflectors, spoofing networks, mitigation platform, and interconnection fabric held different controls and generated different evidence. No slogan can substitute for mapping those controls to observed packets and operational records.

That approach neither endorses nor condemns Spamhaus’s policy role. It asks a narrower question: who could change the executable path, what could they prove, and did the repair preserve service continuity without exporting avoidable harm? Where the record cannot answer, the conclusion must remain unknown. Where an operator had practical control, accountability requires auditable action rather than institutional rhetoric or retrospective certainty.

Spamhaus's 2013 DDoS Made Open DNS Recursion a Network Accountability Test