Summary

  • A root-DNS sample proves that a collector observed a name, query and response within a stated scope. It does not identify the originating application, enterprise, affected population or likely harm.
  • RFC 8023 reports that short sampled datasets were an unreliable basis for second-level block lists and that several apparent causes in root traffic remained speculative.
  • ICANN’s 2026 Name Collision Observatory keeps the same boundary: query magnitude is one input, and a low score is not a safety decision.

Picture an assessment table with one impressive number. A proposed top-level string appeared thousands of times in root traffic during a collection window. The table turns red. Someone copies the observed second-level labels into a block list, assigns an owner and describes the users at risk.

Only the first sentence came from the measurement.

The rest is an inference chain. A root operator saw a DNS query at a particular instance and time. The query may have emerged from a search list, an application with a hard-coded suffix, a misconfigured resolver, a monitoring system, an abandoned device or deliberately generated traffic. Network address translation, forwarding and recursive resolution can separate the visible source from the system that originated the name. One name can appear repeatedly from a small population; a rare name can guard a critical dependency.

RFC 8023 is useful because it refuses to hide those transitions. Published in November 2016, it is an Informational Independent Submission by Matthew Thomas, Allison Mankin and Lixia Zhang. It reports on a public London workshop held in March 2014, with a wider program committee and participant group. The document is not an IETF Standards Track specification and its three authors do not become sole owners of the workshop’s findings.

The problem they reported begins where two naming contexts overlap. A system uses a suffix inside a private environment and expects the public DNS to return NXDOMAIN. That expectation may never have been standardised or even documented. If the same label is later delegated in the global root, the answer can change. Traffic that previously failed closed may be redirected, reach an unintended service or stop satisfying an internal dependency.

The root sees leakage, not intent.

That distinction matters because the most available evidence was also bounded. RFC 8023 describes Day in the Life of the Internet, or DITL, as a short coordinated collection from a varying subset of root operators. It was designed for research, not as a continuous operational view of the whole root system. A label missing from one collection might appear on another day, at another root instance or after a device wakes from a long cycle.

The workshop also recorded concern that later datasets might be affected after the list of applied-for strings became public. The wording is important: no conclusive empirical evidence of tampering was presented. A sound audit preserves both facts—the possibility of measurement effects and the absence of proof—rather than converting concern into accusation.

Why the block list looked stronger than the sample

One workshop paper compared second-level labels visible in DITL with a multi-month collection at the A and J roots. RFC 8023 reports that the work showed the ineffectiveness of building domain block lists from sampled DNS data such as DITL. The claim is narrower than “block lists never work.” It says a finite observational slice did not carry the completeness that this particular mitigation assumed.

The failure mechanism is straightforward. Suppose printer.candidate appears during the sampled days but payroll.candidate does not. Blocking the first label can create a reassuring inventory while leaving the second dependency untouched. Extending the window improves coverage, but still does not identify the software, organisation or business function behind either query. Frequency ranks investigation; it does not explain the path.

Another analysis measured root queries with the recursion-desired bit set. The traffic looked like evidence of naive DNS clients, but the responsible implementation or mechanism could not be determined. Explanations remained hypotheses, and the analysis did not identify actual or potential harm from those clients. A flag in a packet was real; the story attached to it was not yet proved.

This is the central control lesson. Keep observation, inference and corroboration in separate fields.

An observation record should preserve the queried name, type, flags, response, root instance or vantage, collection window and known source view. An inference should name its confidence and alternatives: perhaps search-list expansion, a fixed application suffix or resolver error. Corroboration then has to come from somewhere closer to the cause—a client trace, enterprise configuration, software inventory, support case or reproducible test.

Risk requires another step. Analysts must describe how a public answer could change behaviour, which asset is exposed, how often the dependency runs, and what failure or redirection would follow. A high count with no impact path can be noise. A low count attached to an emergency control system can be material.

Bottom-up evidence changes the question

RFC 8023 records a complementary proposal: begin with a model of name resolution at the client and derive measurements from the steps a real resolver library takes. That approach does not make root data obsolete. It explains what root data cannot see.

The useful investigation runs in both directions. Top-down measurement finds names, times and concentration patterns worth examining. Bottom-up work asks which application formed the name, whether a search suffix was appended, which resolver received it, when it escaped the private boundary and what answer the application expected. Where the paths meet, causality becomes testable.

Ownership also becomes less imaginary. The enterprise team may own a private suffix or search list. A software vendor may own a hard-coded name. A recursive operator may own forwarding behaviour. A registry operator may own activation controls. ICANN’s process may own a particular assessment or contractual requirement. The IETF can standardise shared mechanisms. None of these actors automatically owns every transition.

The workshop therefore called for more than a larger dataset. It highlighted data access, theory, tooling, monitoring, analysis, education and communication. Mitigation could happen at a central level and inside enterprises. That division is not bureaucratic decoration: a root-facing control cannot repair an unknown application, while an enterprise migration cannot decide the global delegation process.

The current tool repeats the warning

ICANN’s Name Collision Observatory, announced for the 2026 round, exposes historical DNS magnitude data for possible top-level strings. ICANN explicitly says the score is one of several factors in an initial assessment. Quantitative and qualitative evidence are considered, and applicants must not interpret low query volume as a finding that a string is safe to delegate.

That statement is the modern form of the RFC 8023 boundary. Magnitude is useful. It can prioritise research, reveal a change, compare time windows and show concentration. It cannot silently become identity, causality, severity or permission.

Controlled interruption illustrates the same principle. The 2014 framework used 127.0.53.53 to make a hidden collision visible to administrators. In March 2026, ICANN said the 2026 round would not add an IPv6 controlled-interruption mechanism while further standards work continues. That is a limit of the current signal, not evidence that IPv6 dependencies or collision risks do not exist.

Reserved names provide a preventive boundary. RFC 2606 set aside names such as .test, .example, .invalid and .localhost; RFC 6761 later described a process for special-use names. But a reserved label protects systems only when designers and operators actually use it. An undocumented suffix chosen merely because it is unassigned inherits future coordination risk.

Allison Mankin’s documented contribution sits precisely here. The IETF’s current PEARG surface identifies her as a chair and provides the public photograph used to ground this article’s editorial portrait. RFC 8023 establishes her co-authorship of the report. Those records support a real role in Internet protocol and privacy work; they do not make her the sole author of the evidence or the decision-maker for ICANN.

Her subject is best understood as a method: refuse to let a precise count carry claims it was never designed to prove.

A decision-grade collision record

A durable name-collision record can be compact. It needs a bounded observation; the collection scope; a stated causal hypothesis; competing explanations; corroborating evidence; the proposed impact mechanism; the responsible owner; and a mitigation with a test and rollback condition.

Heng Lu’s Running-Code Primacy gives this record its operational centre. A registry row, risk score or block list is administrative evidence. The running system—what name a client constructs, which resolver path it follows and what happens when the answer changes—remains the stronger test of behaviour.

Minimum Initial Specification supplies the coordination boundary. Shared rules should define the smallest evidence needed across parties without pretending to choose every enterprise migration or product design. Root operators can publish bounded observations. Analysts can state uncertainty. Enterprises can test their dependencies. Decision-makers can require proof appropriate to the impact.

The sample then becomes more valuable, not less. It tells the truth about what was seen and leaves room for the next test to discover why.

Sources