The 2015 Root DNS Flood Made Cross-Operator Telemetry an Accounta

Summary

The root-server traffic event at the end of 2015 was neither a single, open-ended crisis nor evidence that the global Domain Name System stopped working. It consisted of two abnormal intervals: approximately 06:50-09:30 UTC on 30 November and 05:10-06:10 UTC on 1 December. During each, most but not all root-server letters received well-formed queries for one domain name, with a different name used on the second day. The collective Root Server Operators' report placed the rate at roughly five million queries per second for each affected letter.
It also recorded saturation near some instances and valid-query timeouts from some vantage points, while several letters remained continuously reachable and operators knew of no end-user-visible errors attributable to the event [1].
Those facts create an accountability question about evidence, not a basis for outage rhetoric or attacker attribution. In an anycast system, BGP can direct different resolver paths to different sites, so service-wide continuity can coexist with congestion or loss at a particular instance, uplink or catchment [3][4]. K-root's account gives a valuable operator-specific view of that asymmetry, including high load, local overflow, filtering readiness and subsequent repair, but it cannot stand in for every root operator [2].
The inquiry is whether operators could recognize a shared event, preserve comparable telemetry, distinguish affected layers, deploy controls and explain both continuity and impairment within the limits of their observations.

The event boundary is strictly two intervals

The event record begins at about 06:50 UTC on 30 November 2015 and ends, for the first interval, at about 09:30 UTC. It resumes at about 05:10 UTC on 1 December and ends at about 06:10 UTC. Those are the boundaries supplied by the collective report, and they should govern every claim about the incident [1]. Describing “the 2015 attack” without that boundary risks combining two traffic episodes, local after-effects, mitigation work and later analysis into one supposedly continuous condition.

The two intervals also define which evidence is contemporaneous. The Root Server Operators’ report and K-root’s operator account are records of the observed event [1][2]. Later anycast studies can help explain why load and reachability differed by site or path [3][4]. Later RSSAC measurements and ICANN studies can provide a vocabulary for availability, latency, load and instance identity [8][9][13]. None of those later frameworks can retroactively create packet, link, resolver or user measurements that were not collected during the two intervals.

This boundary prevents an observation at one K-root site from being projected onto every K-root site, much less every root letter. It prevents a timeout seen by a probe from becoming proof of a failed recursive resolver or end-user transaction. It also keeps an earlier emergency-response exercise outside the event chronology: that exercise may show which coordination controls operators had already identified, but it does not prove that a particular control failed in November.

The bounded event leaves major unknowns intact, including the actor, intent, full path distribution, universal user experience, every operator’s internal decision timeline and the causal effect of any single coordination choice.

30 November and 1 December, in sequence

At about 06:50 UTC on 30 November, root-server instances began receiving an unusual volume of DNS queries. The queries were syntactically well formed and concentrated on a single domain name. Most, but not all, root letters observed the traffic at their anycast sites. The collective report estimated a peak on the order of five million queries per second for each affected root letter; that is a per-letter characterization, not a warranted global sum across all letters or sites [1].

As the first interval continued, links close to some root-server instances saturated. From some external vantage points, otherwise valid queries timed out. At the same time, several root letters remained continuously reachable throughout the event. These statements describe different measurement units: a nearby link, an anycast instance, a letter and a remote observation point. They are not contradictory, and none alone establishes what every recursive resolver or user experienced. The first interval subsided at about 09:30 UTC, after roughly two hours and forty minutes [1].

The second interval began at about 05:10 UTC on 1 December. It again consisted of high-rate, well-formed DNS queries, but the queried domain name differed from the one used the previous day. The collective report describes a similar broad pattern across most root letters, with source addresses appearing numerous, geographically distributed and randomized across IPv4 address space. The interval ended at about 06:10 UTC, approximately one hour after it began [1].

Operators could compare the query form, rate, address pattern, affected infrastructure and local mitigations, but the different queried name and distinct start and end times remained observable separators. K-root reported that filtering could be enabled more quickly on the second day after the first day exposed deployment friction [2]. That is evidence of K-root’s response sequence, not proof that all operators used the same filters, faced the same delay or followed the same remediation path.

Nothing in this sequence warrants the phrases “global DNS outage” or “worldwide end-user failure.” The record instead shows a high-rate event with localized saturation, uneven visibility and continued service at multiple letters. The operators’ statement that they knew of no end-user-visible errors attributable to the event is part of the chronology, but it remains a bounded statement about known reports and attribution, not universal measurement of every user path [1].

What the collective operator report establishes—and what it does not

The collective report establishes a shared minimum record. Two intervals occurred. Each centered on well-formed queries for one name. Most, rather than all, root-server letters observed the traffic. The reported rate approached five million queries per second for each affected letter. Some links near instances saturated, some observation points saw valid queries time out, several letters remained reachable, and the operators reported no known attributable end-user-visible errors [1].

The report is especially valuable because it preserves differences among layers. A root letter can be announced from multiple anycast sites. BGP steers a resolver toward a catchment according to routing conditions, so an intense flow may be distributed across the system yet overwhelm a particular site or uplink. Research on the event found that anycast could localize portions of the load rather than spreading identical effects everywhere [3][4]. System continuity, letter reachability, site availability, link capacity, probe reachability, recursive-resolver behavior and an end-user transaction must therefore remain separate claims.

The report does not establish equal load or equal impairment across letters. It does not inventory every affected instance, reconstruct every upstream path, measure every resolver, or prove that every user completed queries normally. “No known end-user-visible errors” is an evidence boundary: it says what operators knew and could attribute, not that universal end-user success was demonstrated. Conversely, local timeouts do not prove a global service failure. A probe can reveal a path-specific symptom without establishing its prevalence or downstream consequence.

Nor does the collective account identify the actor, motive or legal responsibility. It does not expose every operator’s internal recognition time, escalation threshold, packet-retention practice or mitigation decision. It cannot show that one coordination choice caused or prevented a particular outcome. Later service expectations and measurement frameworks can make such questions more precise, but they cannot overwrite the uncertainty in the contemporaneous record [8][9][13].

K-root is an operator-specific case, not a system-wide proxy

RIPE NCC’s K-root account supplies granularity that the collective report cannot. K-root traffic climbed to roughly twenty times its usual level. Some K-root sites remained reachable, while uplinks at multiple sites overflowed and monitoring showed severe packet loss or unreachability from affected catchments [2]. This is a concrete example of how one anycast letter can display aggregate resilience and local stress at the same time. It is not a template that can be copied onto the other root letters.

K-root also documented an operational readiness problem. Filters reduced the unwanted traffic, but deploying them took longer than desired because the required tooling was not available on every server. On 1 December, K-root operators enabled filters more quickly. RIPE NCC subsequently prioritized hardware upgrades and changed its operational setup so that response tools would be present by default [2]. These are bounded claims about one operator’s infrastructure and workflow.

The evidence does not show that every root operator lacked the same tools, used an equivalent filter, experienced comparable uplink constraints or made the same repairs.

That boundary matters to accountability. K-root’s post-event actions are evidence of controls within RIPE NCC’s reach: server tooling, filter deployment, link and hardware planning, monitoring and operational defaults. Sharing packet captures through DNS-OARC further converted local observation into material that other specialists could examine [2]. Those actions can be tested against the conditions K-root reported. They do not establish the full state of the Root Server System, and they do not assign responsibility to another operator whose paths, capacity and response record are absent.

The case also demonstrates why “reachable” needs an identified scope. A K-root site that remained reachable does not negate loss at another site. An unreachable probe does not prove that the entire K-root letter was unavailable. BGP-selected catchments mean two resolvers can approach the same letter through different instances and links [3][4]. A defensible assessment must name the site, catchment, link, vantage point and time window behind each result. K-root’s value is precisely that it narrows those objects more carefully than a system-wide label would.

Query and source-address evidence stop short of attribution

The traffic had observable features that support classification without supporting identity. The queries were well formed, targeted one domain name during each interval and used a different name on the second day. K-root observed queries requesting recursion even though root servers provide authoritative service rather than recursive resolution [1][2]. Those properties help define a traffic signature and guide mitigation. They do not reveal who generated the queries or why.

The apparent source addresses were numerous, geographically distributed and seemingly randomized across IPv4 space [1]. That pattern admits materially different explanations. Addresses may have been spoofed, meaning the packet header did not identify the sending system, or the traffic may have been generated through widely distributed sources. K-root’s observations supported spoofing or broad distribution as possibilities, not a choice between them [2]. Verisign’s account likewise emphasized that spoofed and distributed traffic frustrates attempts to infer origin and intent from source addresses alone [5].

It would therefore be unsound to convert a packet address into an attacker identity, a hosting-network accusation or a legal conclusion. Apparent geography is not proof of origin. High rate is not proof of motive. A recursion-request bit is not proof of the sender’s objective. Even packet captures, valuable as they are, show traffic presented to an observation point; they do not automatically reconstruct the complete path or the human decisions behind it.

The evidence can support narrower accountability tests. Root operators can show when they detected the shared signature, which instances and links were affected, what filtering rules changed the load, what packets they retained and what indicators they shared. Transit, hosting or access networks can be assessed only where path evidence connects their controllable infrastructure to the observed flow. Recursive-resolver operators remain responsible for retry and caching behavior at their own layer, but the root reports do not establish how every resolver behaved.

By stopping before attribution, the analysis becomes more—not less—demanding: each responsibility claim must be tied to an observable control, a defined network layer and evidence from the relevant path.

BGP Turns One Root Letter Into Many Catchments

The phrase “root server” can obscure the topology that actually carries DNS traffic. The Root Server System is the collective service. A root letter is one independently operated part of that system. That letter may be announced from many anycast sites, each containing infrastructure that receives traffic routed toward it. An upstream link connects a site to surrounding networks, while a recursive resolver sends queries from its own network location. None of those units is equivalent to an end-user transaction, which also depends on resolver caching, retries and the rest of the user’s path.

Anycast allows the same root-letter service to be presented from multiple locations. BGP then selects a route according to the policies and reachability visible between networks; there is no central dispatcher assigning every query to a globally optimal instance. The resolvers whose routes lead to a particular site form that site’s catchment. A routing change can alter a catchment even when the root operator changes nothing at the site itself. Conversely, two resolvers in the same country may reach different sites because their providers have different routes or interconnection arrangements.

Research examining the November 2015 event uses this catchment structure to explain why traffic could be distributed unevenly across the anycast deployment [3][4].

Distribution is not the same as pooling all capacity. Each site still has finite servers, ports and upstream links. If one catchment receives a disproportionate volume, its local link can fill while another site announcing the same root letter remains lightly loaded. BGP can also steer attack packets and ordinary resolver queries into the same catchment, forcing them to compete at the constrained link before filtering or server capacity becomes relevant. Anycast therefore creates fault separation and aggregate reachability, but it does not make each path, link or instance interchangeable.

The 2015 traffic illustrates that distinction. The Root Server Operators reported that most, but not all, root letters saw the abnormal queries at their anycast sites. They estimated traffic at roughly five million queries per second for each affected letter, but that letter-level figure does not disclose the distribution among every site or upstream link [1]. Numerous, geographically distributed and apparently randomized IPv4 source addresses further limit any reconstruction of the true sending population.

They may reflect spoofing, broad distribution or some combination; packet source fields alone do not establish origin, intent or actor [1][5].

Consequently, an accountability record must identify the denominator behind every traffic statement. “Five million queries per second at a letter” is not “five million at each site.” A saturated upstream link is not proof that every instance of the letter was unreachable. A resolver routed into one impaired catchment does not represent every resolver, and a successful query from another catchment does not prove universal success. The running BGP and link state—not the declared number of sites by itself—determines which traffic reached which capacity at a given moment [3][4].

Local Saturation Can Coexist With System Continuity

Local impairment and system continuity are not contradictory findings. They answer different questions. System continuity asks whether the Root Server System continued providing root service through its distributed operators and letters. Local saturation asks whether a particular anycast site, upstream link or resolver path could carry valid queries during a defined interval. Combining those questions into one binary “up” or “down” label discards the mechanism that made the event significant.

The Root Server Operators’ report preserved part of this distinction. It recorded saturated links near some instances and timeouts for valid queries from some vantage points, while also stating that several root letters remained continuously reachable. The report did not describe a global failure of root DNS. It also said that the operators knew of no end-user-visible errors attributable to the event [1]. Those propositions can all be true: local paths can lose packets while other sites and letters continue answering.

K-root provides a bounded example, not a template for all operators. RIPE NCC reported traffic at approximately twenty times K-root’s usual level. Some K-root sites remained reachable, while uplinks at multiple sites overflowed and monitoring showed severe loss or unreachability from affected catchments [2]. Those observations establish conditions at K-root locations and monitored paths. They do not establish that every K-root site behaved identically, and they cannot be transferred to another root letter without that operator’s evidence.

The separation of units matters especially at the resolver layer. A recursive resolver may have cached relevant root information, may retry after a timeout, or may reach another functioning service path. An end user therefore might complete a transaction despite loss on one root query. Alternatively, a particular resolver or application path might suffer delay that never appears in a system-wide availability statement. The frozen record does not establish the complete distribution of those outcomes, so it cannot support either universal impairment or universal normality.

“No known end-user-visible errors” must consequently remain an attributed evidence boundary. It reports what the operators knew, not omniscient observation of every resolver and user. Likewise, the existence of local timeouts cannot be inflated into a claim that the global DNS failed. Responsible reporting retains both facts and their scopes: Root Server System continuity, letter-level reachability, site and link saturation, resolver-vantage results and end-user transactions are related, but they are not substitutes for one another [1][2].

Telemetry Has Different Fields of View

Root operators and external measurement systems observe different parts of the event. An operator can inspect packets arriving at its own infrastructure, interface utilization, server load, filtering actions and the timing of changes under its control. That evidence can show that a specific upstream link filled, that queries of a particular form reached certain instances, or that a mitigation changed traffic visible inside the operator’s domain. It cannot, by itself, describe every resolver’s route or every user’s experience outside that domain.

Operator-local packet evidence also has attribution limits. In 2015, the observed queries carried numerous apparently randomized source addresses. Even a complete packet capture at an affected instance would show the addresses presented in those packets, not necessarily the systems that generated them. Spoofing and distribution complicate inferences about origin and coordination [1][2][5]. Local telemetry can be strong evidence of received traffic and resource pressure while remaining weak evidence of actor identity or motive.

RIPE Atlas and DNSMON reverse the perspective. Their probes can test DNS reachability and performance from selected external vantage points, exposing path effects that an operator’s internal counters may not reveal [14][18]. But a probe result is still a path-specific observation. A timeout may involve the probe, its resolver behavior, intervening routing, a saturated upstream link or the anycast site reached at that moment. A successful response proves that the tested transaction succeeded from that vantage point; it does not prove that every catchment, site or resolver succeeded.

This creates a structural asymmetry. Operators may possess high-resolution evidence about packets and links but incomplete visibility into user-side consequences. External measurement systems may reveal geographically or topologically dispersed symptoms but lack the internal context needed to identify the constrained interface or mitigation state. Even when both observe “K-root,” anycast means they may be discussing different sites and catchments. Correlation therefore requires timestamps, instance or site identity where available, route context, query characteristics and clearly bounded definitions of loss and reachability.

RSSAC service expectations and measurement frameworks provide useful vocabulary for availability, latency, load, instance identity and distribution [8][9][16][17]. Later guidance and ICANN studies can help compare evidence models and expose missing fields [10][11][12][13]. They cannot retroactively create packets, link counters, probe coverage or internal timelines that were not retained in 2015. The defensible method is triangulation: preserve operator-local evidence, external-vantage evidence and public event reporting as separate records; reconcile what overlaps; and mark what none of them can prove.

No single dashboard automatically becomes a universal account of the Root Server System, a letter, a site, a link, a resolver population or end users.

The Emergency Exercise Defined a Coordination Problem Before the Flood

Earlier in 2015, the Root Server Operators conducted an emergency-response exercise built around a simulated threat. Its published recommendations treated coordination as an operational control rather than an informal courtesy. They included triggers for initiating communications, backup communication channels, designation of an incident coordinator for each event, shared terminology for describing impact, monitoring thresholds and coordinated external communication [6].

Communication triggers matter because independently operated letters may first see fragments of a common event. One operator may detect an unusual query name; another may see an upstream link approach saturation; an external monitor may record timeouts from only some catchments. A trigger defines when those partial observations should enter a shared channel. A backup channel addresses the possibility that the ordinary channel is unavailable or unsuitable during an emergency. Neither measure guarantees an accurate diagnosis, but both make timely comparison less dependent on personal improvisation.

A per-event incident coordinator can maintain a common event clock, request comparable indicators and track unresolved disagreements. That role need not imply command over the independent operators. Its accountability value lies in custody of the shared picture: who reported which symptom, which measurement unit it concerned, when a threshold was crossed, and what remained uncertain. Common impact terms make that record interpretable across operators whose architectures and monitoring systems differ.

The exercise recommendations do not prove that a communication or coordination failure caused any part of the November event. Nor do they establish that a different coordinator, threshold or message would have changed packet loss at a particular site. The frozen sources do not provide every operator’s internal timeline or the causal effect of any individual coordination choice. Treating the exercise as proof of failure would confuse a pre-event control recommendation with evidence about a later incident.

The exercise instead supplies questions for evaluating the real response. When did operators recognize that they were observing a shared event? Which indicators were compared? Did a local link alarm activate a cross-operator trigger? How were differing catchment effects described? When one operator deployed a mitigation, what information was shared with the others? How did external statements reconcile continued system service with impairment at particular links or vantage points? Answers require event-specific records; the exercise identifies the evidence that a mature coordination process should be able to produce [6].

Impact Definitions and Public Communication Are Accountability Controls

Cross-operator impact definitions determine whether evidence can be combined without distortion. If one operator uses “affected” to mean receiving the abnormal query stream, another uses it to mean link saturation, and an external monitor uses it to mean probe timeout, a consolidated count of “affected servers” is meaningless. Each term needs a measurement unit, threshold, interval and denominator.

That discipline permits apparently conflicting statements to coexist accurately. A root letter may be affected at some anycast sites but reachable through others. A site may have running server processes while its upstream link drops traffic. A resolver vantage point may time out while another resolver reaches the same letter through a different catchment. An end-user transaction may succeed because cached data or retries avoided the impaired path. None of these observations should be promoted to a broader layer without evidence.

Public communication is therefore more than reputation management. A carefully scoped statement tells resolver operators, network operators, researchers and users what has been observed and what has not. During an evolving event, it should distinguish confirmed local facts from cross-operator assessments, state the observation window, identify whether “availability” concerns a letter or the system, and preserve uncertainty about unmeasured users. Updates and corrections should remain linked to the event record rather than silently replacing earlier claims.

The exercise’s recommendation for coordinated external communication recognizes this shared control surface [6].

Responsibility should follow practical control. Root operators control capacity, routing choices within their domain, monitoring, mitigation readiness, evidence retention and participation in coordination. Transit, hosting or access networks may control capacity, filtering and abuse response on an implicated path, but responsibility cannot be assigned without path evidence. Recursive resolver operators control their own caching and retry behavior. RSSAC and ICANN can define expectations, terminology and measurement frameworks, while the independent operators remain responsible for operating their systems [7][8][9].

None of those allocations identifies the actor behind the 2015 traffic.

A credible multi-operator account should thus preserve a layered event matrix: Root Server System status; per-letter observations; identified anycast sites; saturated upstream links; external resolver or probe results; and, separately, evidenced end-user transactions. Each entry should carry its source, time window, confidence and known blind spots. Common definitions make the rows comparable, and coordinated public communication makes their limits visible.

Together, those practices turn telemetry from a collection of private observations into an accountability control without pretending that incomplete measurement has become universal knowledge.

Filtering Readiness at K-root—and the Boundary of the Repair Evidence

The filtering lesson begins with a distinction between a shared event and a locally evidenced response. The Root Server Operators’ report placed the two abnormal intervals at roughly 06:50–09:30 UTC on 30 November 2015 and 05:10–06:10 UTC on 1 December. It reported about five million queries per second at each affected root letter, traffic at most but not all letters, saturation near some instances, timeouts from some observation points, and continuous reachability at several letters. It also said the operators knew of no end-user-visible errors attributable to the event.

Those statements can coexist because a system, a letter, an instance, a link, a probe and a user transaction are different units of evidence [1].

K-root’s account then narrows the lens. Its traffic rose to roughly twenty times normal. Some K-root sites stayed reachable, while uplinks at multiple sites overflowed and monitoring showed severe loss or unreachability from affected catchments. Filters reduced the unwanted traffic, but deployment during the first interval took longer than desired because the needed tooling was not available on every K-root server. During the second interval, K-root operators enabled filters more quickly.

RIPE NCC subsequently prioritized hardware upgrades, changed its operational setup so response tools would be present by default, and shared packet captures through DNS-OARC [2].

This is strong repair evidence for K-root: it identifies an observed constraint, the control that was slow to deploy, the faster repeat response, and changes intended to reduce both capacity and readiness gaps. It is not evidence that another root operator used the same tools, had the same deployment delay, saturated the same way or made the same repairs. Research on the event explains why such variation is plausible. Anycast distributes a letter across BGP-selected catchments, so traffic and impairment can concentrate at particular sites and links even while the larger service remains reachable [3] [4].

The mechanism supports operator-specific inquiry; it does not erase operator boundaries.

A complete repair record would therefore pair the public narrative with dated asset inventories, filter availability by instance, change approvals, deployment and rollback times, link-capacity changes, exercises proving that the tooling works, and a named owner for unresolved gaps. Those items are an audit standard, not claims about unpublished 2015 records. K-root’s public account establishes a bounded operational repair. Cross-operator readiness would require equivalent evidence from each operator, expressed in compatible terms, rather than an inference from one transparent case.

Responsibility Allocation by Practical Control

Responsibility should follow the controls an actor could actually exercise at the relevant layer. A root operator controls the design and operation of its own letter: site and uplink capacity, routing policy, monitoring, mitigation procedures, response-tool availability, packet and change-log retention, escalation, and disclosure. Expectations for resilient root service can help define what competent operation should address [7] [8], but the accountability question remains factual: what did the operator observe, what could it change, when did it act, and what evidence did it preserve?

That allocation is not a claim that a root operator controls every packet path. A transit, hosting or access network may control capacity, filtering or abuse response on a path implicated in the event, but responsibility at that layer requires path-specific evidence. BGP catchments can shift, source addresses may be spoofed, and a saturated interconnection seen from one probe does not identify every network that carried the traffic. The path claim must therefore include timestamps, routing state, interface or flow evidence, and the scope of the operator’s practical ability to intervene.

Without that chain, naming a path provider would turn a technical possibility into unsupported attribution.

Recursive resolver operators occupy another layer. They control their own caching, retry logic, upstream selection, telemetry and user-facing failure records. Their observations may establish that valid queries timed out on particular paths, but they do not by themselves establish the state of a root letter as a whole. Conversely, a root operator’s aggregate availability statement cannot prove that every resolver or user path succeeded. External observation through DNSMON or RIPE Atlas can bridge part of this asymmetry, yet it still samples selected probes and paths rather than universal experience [14] [18].

ICANN and RSSAC can define expectations, measurement fields and reporting frameworks; they do not directly operate the independent root letters. RSSAC001 expectations, RSSAC002 measurements, operator responses and published measurement data can make later scrutiny more consistent [8] [9] [16] [17]. Coordination is consequently a shared control with separable duties: each operator must produce accurate local evidence, while the group must establish triggers, shared terminology, an incident coordinator, backup communications and a reconciled public account.

The early-2015 exercise shows that these were already recognized coordination surfaces, but it does not prove that any one of them failed during the November event or caused a particular outcome [6].

An Auditable Evidence Checklist for a Future Multi-Operator Root Event

A future event record should permit an independent reviewer to move from system-level claims down to local observations without collapsing the layers. It should also let operators compare evidence without forcing them to expose security-sensitive details. The minimum record should contain the following:

A common event clock. Record UTC start and end estimates, detection time, escalation time, mitigation changes and recovery for every operator. State clock sources and uncertainty. Give shared traffic intervals stable identifiers so that two operators do not unknowingly describe different windows.
A topology and identity snapshot. For each participating letter, identify active anycast instances, announced prefixes, relevant catchments, upstream links and material routing changes. DNS delegation or registry records identify roles and resources, but running routes and service observations show what was actually reachable.
Layered load and impairment data. Report query rates, packet and bit rates, interface utilization, drops and latency separately for the letter, site and link. Preserve baselines and sampling intervals. Never convert “some instances saturated” into “the Root Server System failed,” or aggregate continuity into proof that every local path worked.
Packet and query evidence. Preserve bounded packet captures, query-name and type distributions, protocol flags, apparent source-address characteristics, and collection methods. Apply access controls and retention limits. Well-formed queries, a request for recursion, or randomized addresses can describe traffic; none establishes an actor or motive [1] [2] [5].
Independent vantage-point evidence. Publish probe identifiers or reproducible aggregates, resolver location and network context, test method, timeout criteria and missing-data treatment. DNSMON, RIPE Atlas and operator-local monitoring should be aligned by time, then reported as complementary views rather than treated as interchangeable [14] [15] [18].
Mitigation and change records. For each filter, route change or capacity intervention, record the owner, authorization, scope, deployment time, validation, side effects and rollback condition. Show the difference between a mitigation being available in principle and being deployable at every intended instance.
Coordination evidence. Record when a common incident was recognized, which trigger fired, who coordinated, what indicators were exchanged, how conflicting impact descriptions were resolved, and when public communication was approved. Preserve a protected decision log even when operational details cannot be released [6].
A bounded impact statement. Report Root Server System, letter, instance, link, probe, resolver and known user effects separately. Define the population and method behind phrases such as “reachable,” “degraded” and “no known end-user errors.” List blind spots rather than converting an absence of reports into a universal negative.
Repair closure. Map every finding to an owner, due date, validation test and durable evidence. Re-test capacity assumptions, tool distribution, communications and measurement coverage. Close an action only when an observable control works, not when a policy document merely says it should.

Later requirements and measurement work can provide a prospective vocabulary for this record. RFC 7720, RSSAC001 and RSSAC002 address service expectations and measurements [7] [8] [9]; later RSSAC publications and the CDAR study can refine questions about identity, metrics and system analysis [10] [11] [12] [13]. They must not be used to retroactively claim that a field was measured in 2015. Likewise, a later K-root expansion study may demonstrate how external probes can evaluate operational change, but it cannot fill missing observations from the earlier event [14].

The auditable product is a time-aligned bundle of local records, sampled external observations and clearly scoped public conclusions—not a single global graph.

Bounded Unknowns and Legal or Attribution Limits

The public record does not establish the actor, intent, complete path distribution, universal end-user experience, every operator’s internal response timeline, or the causal effect of any single coordination choice. Apparent source addresses were numerous, geographically distributed and reportedly randomized across IPv4 space; they may reflect spoofing, broad distribution or some combination. That evidence constrains what can be said about packets, not who directed them or why [1] [2] [5]. A high query rate and repeated target pattern remain operational facts, not identity evidence.

The statement that operators knew of no end-user-visible errors is also bounded. It is not a claim that every recursive resolver, access network and user transaction succeeded. At the same time, observed loss at a K-root catchment or a selected probe does not establish a global DNS outage. A defensible account holds both propositions: local links and paths experienced severe impairment, while system-level service continued and no attributable user-visible error was known to the reporting operators [1] [2] [3].

Operational accountability is not automatically civil, regulatory or criminal liability. A legal conclusion would require a governing jurisdiction, applicable duties, admissible evidence, causation, harm and procedural rights not supplied by network telemetry alone. Similarly, the emergency exercise supplies a benchmark for coordination controls, not proof of negligence or causal failure [6]. The 2016 root-server event report can be used as a comparator for reporting patterns [19], and later historical analysis or the operators’ news archive can aid context [13] [20]; neither may be used to rewrite the bounded 2015 chronology.

Conclusion: The Cross-Operator Accountability Test

The 2015 flood matters because aggregate continuity and local failure were simultaneously observable. Anycast and BGP distributed traffic among catchments, but they did not give every instance or uplink identical capacity. The operators’ system-level report, K-root’s site-level account and external vantage observations answered different questions. Accountability begins by keeping those answers attached to their proper measurement units, then aligning them on a common clock.

A root operator passes the practical test when it can show what happened at its own letter and instances, which controls were available, when mitigations changed running behavior, what evidence was shared, and whether repairs were validated. The operator group passes the collective test when it can reconcile local reports into a public statement that preserves disagreement, sampling limits and unknowns. Path and resolver operators are accountable only for the layers they control and for claims supported by path or resolver evidence.

Framework bodies are accountable for usable expectations and measurement conventions, not for operating infrastructure they do not run.

This is not the generic claim that a distributed architecture can absorb a flood. The sharper lesson is that distribution creates an evidence obligation: a service may remain available in aggregate while particular catchments, links and observers lose service. Declared topology and delegation records cannot settle that question; running routes, counters, packet evidence, probes, action logs and tested repairs must do so.

The final accountability test is therefore simple to state and demanding to satisfy: can every material claim be traced to a layer, a time window, an observation method, a responsible control owner and an explicit uncertainty? If not, continuity may still be real, but it has not yet been made auditable.