Summary

  • A RIPE 93 presentation says roughly 2,000 RIPE Atlas probes suffered IPv4 timeouts to ICANN-operated L-Root from 22 to 26 January 2026; a paired ten-minute comparison found 1,773 probes timing out only in the event window.
  • The researchers found the affected probes' former anycast sites still answering other networks. Their diagnosis put the trouble on network paths, while the initial RootViz alert only showed lost reachability.

The dashboard saw smoke. The server got its name on the alarm. The fire was somewhere along the road.

That is the incident reconstructed in Giovane Moura's RIPE 93 RootViz presentation. Between 22 and 26 January, IPv4 measurements from roughly 2,000 RIPE Atlas probes began timing out on the way to L-Root. IPv6 measurements and checks of other root identities stayed steady in the team's comparison. In two ten-minute windows on 22 January, 1,773 probes that worked before the event timed out later. Those are measurement vantage points, not a count of people who lost DNS.

RootViz makes old data harder to ignore. It takes RIPE Atlas measurements of all 13 root identities, filters probes with working network stacks and responses with mismatched server identifiers, then counts timeout probes in 30-minute bins. The researchers' 6 May comparison gives its wider field of view some scale: 14,528 Atlas probes against 999 DNSMON anchors, spread across 180 rather than 109 countries. RIPE Atlas's own measurement catalogue identifies measurement 10308 as its recurring IPv4 UDP query to L-Root. More eyes expose a problem sooner; they do not decide who caused it.

The follow-up did. The team checked which anycast sites the affected probes had previously reached. Other networks could still reach those sites during the event. Traceroutes and routing checks led the presenters to a network-path problem. They did not name one proven transit culprit for the January episode. ICANN says it operates L-Root, so it is the obvious addressee when L-Root's line turns red. Yet a root operator cannot repair every path between a probe and its anycast sites.

Here is the governance question underneath the graph: who owns the incident record while the diagnosis crosses company boundaries? RootViz found the spike; the presentation says identifying the probes, sites, BGP state and data-plane failure took hours of manual investigation. A useful public receipt would state the address family, affected vantage points, comparison identities, site reachability and path evidence before attaching fault to an operator. Otherwise the loudest alarm becomes an accidental verdict.

Original records: RIPE 93 presentation; RIPE Atlas built-in measurements; ICANN root-server overview.