Summary

  • At RIPE 93, RootViz's presenter described an L-Root IPv4 episode in which roughly 3,000 RIPE Atlas probes timed out for days, against a baseline near 1,000. His team found about 1,700 probes newly affected during the spike across 97 countries.
  • The investigation found root sites still reachable from other probes. The timeout graph located a path problem; it supplied no matched measurement of resolver-user impact.

A red line climbed on the dashboard. The easy headline was that a root server had gone dark. The inconvenient detail was that the root sites were answering. What vanished, for many RIPE Atlas probes, was the path to them.

Giovane Moura brought that example to RIPE 93 on 27 October. His RootViz dashboard takes measurements that RIPE Atlas already collects and gives root-server reachability a wider screen. During the L-Root episode he described, the number of probes timing out over IPv4 rose from a usual level near 1,000 to roughly 3,000 and stayed high for days. His team compared a short window before and during the spike. About 1,700 probes that had reached L-Root before the event were timing out during it, spread across 97 countries.

Those numbers made the incident worth investigating. They did not identify the failing device. Moura's team checked whether the affected probes could still reach other roots and whether IPv6 showed the same pattern. It examined traceroutes and the anycast sites the probes had reached before the timeouts. The sites stayed up; other probes could reach them. The break sat on network paths between some probes and the service. The precise point of failure remained a harder, partly manual question.

The distinction sounds obvious once a technician has done the work. Before that, a timeout graph can send blame to whichever operator owns the name on the chart. A root-server operator runs machines and announces routes. It cannot repair every transit path a probe takes across the Internet. An Atlas probe tells the investigator where a particular journey stopped. It does not deliver a guilty party with the timestamp.

RootViz is built outside RIPE NCC, by a team associated with SIDN Labs and TU Delft. Its fuel comes from RIPE NCC's Atlas network. The official RIPE 93 session describes a deliberate change of measurement population: RootViz uses ordinary Atlas probes as well as anchors, whereas RIPE NCC's DNSMON uses the smaller, more stable anchor set. The 2025 RIPE NCC annual report counted about 14,400 connected probes and 963 connected anchors. Those are historical network totals, not denominators for the October 2026 L-Root chart; they show the scale of the choice.

Anchors offer a cleaner reference. RIPE NCC's DNSMON technical documentation describes them as its measurement points for root and many top-level-domain servers. Ordinary probes spread the view into more networks, including less tidy ones. Their home links, host machines and intermittent connectivity add noise. A wide detector therefore finds patterns the anchor screen may miss, then forces the investigator to ask whether a cluster of failures came from the probes, the paths or the destination. More dots make a better alarm. They do not make a verdict.

Moura showed why the extra dots were useful. The L-Root spike affected IPv4 while the corresponding IPv6 view held up. Other root letters lacked the same pattern. A comparison of affected probes before and during the event narrowed the inquiry. The team then looked at traceroutes and anycast catchments instead of declaring that the red line itself was the cause. That sequence turned a dramatic chart into an operational lead.

It also exposed an awkward gap between reachability and harm. During the discussion, RIPE NCC CEO Hans Petter Holen asked what the measured failures meant for resolvers and users. An audience member pointed out that many end users send DNS queries to recursive resolvers elsewhere in their networks; ordinary Atlas probes are not those resolvers. Moura agreed the sample is a best-effort view of network paths, not a direct count of affected DNS users. A matched resolver-side record from the same networks and interval would show how far this path failure reached into actual query service.

That is the useful editorial rule for measurements of critical infrastructure: publish the alarm and the investigation together. The L-Root timeouts deserve a line on a chart and a place in an incident notebook. The checks that kept the root sites out of the blame column deserve just as much space. A figure with 3,000 in it is powerful. It should not be allowed to impersonate a postmortem.

RIPE Atlas has made the raw view available. RootViz has made it easier to notice. The remaining work is the difficult bit: line up probe state, address family, traceroutes, anycast catchment and resolver behaviour for the same time window. At RIPE 93, the presenter said much of that attribution still required manual analysis. That is where an institution earns confidence in its measurements—by showing how a red signal became a specific account of what failed, who could act and what stayed alive.

Sources: RIPE 93's RootViz session and official transcript; RIPE NCC's DNSMON technical documentation, RIPE Atlas built-in measurements and 2025 annual report.