Zusammenfassung

  • Laut dem RootViz-Vortrag auf RIPE 93 meldeten vom 22. bis 26. Januar 2026 rund 2.000 RIPE-Atlas-Probes IPv4-Zeitüberschreitungen auf dem Weg zu L-Root.
  • Beim Vergleich zweier Zehn-Minuten-Fenster fielen 1.773 Probes nur während des Ereignisses aus. Die zuvor erreichten Anycast-Standorte antworteten anderen Netzen weiter; die Untersuchung verortete das Problem auf dem Netzpfad.

Ein roter Buchstabe ist eine gute Schlagzeile für ein Dashboard. Für einen Techniker ist er erst der Anfang der Wegbeschreibung. Der Originalvortrag von Giovane Moura auf RIPE 93 zeichnet nach, wie aus auffälligen L-Root-Messungen im Januar eine Pfaduntersuchung wurde.

Am 22. Januar stiegen die IPv4-Timeouts an, bis zum 26. Januar hielt das Muster an. Über den Zeitraum hinweg waren ungefähr 2.000 Atlas-Probes betroffen. IPv6 und die anderen Root-Identitäten zeigten im Vergleich keinen entsprechenden Ausschlag. Besonders anschaulich sind zwei Fenster am 22. Januar, 04:00–04:10 und 13:00–13:10 UTC: 1.773 Probes lieferten nur im zweiten keine Antwort mehr. Diese Zahl zählt Messpunkte, keine Menschen mit ausgefallener Namensauflösung.

RootViz macht vorhandene Daten sichtbar. Das Projekt verarbeitet Atlas-Messungen für alle 13 Root-Identitäten, berücksichtigt funktionierende Netzwerk-Stacks, verwirft Antworten mit unpassender Serverkennung und bündelt die Timeout-Probes in Halbstundenfenstern. Die Autoren verglichen am 6. Mai die Reichweite dieses Ansatzes mit DNSMON: 14.528 Atlas-Probes in 180 Ländern standen 999 DNSMON-Ankern in 109 Ländern gegenüber. Der RIPE-Atlas-Katalog führt Messung 10308 als wiederkehrende IPv4-UDP-Abfrage an L-Root. So taucht ein schadhafter Weg auch dann auf, wenn er an keinem der wenigen Anker vorbeiführt. Welche Stelle auf diesem Weg gestört ist, zeigt der größere Zähler allein nicht.

Die Forscher sahen nach, welche Anycast-Standorte die betroffenen Probes zuvor erreicht hatten. Andere Netze kamen während des Ereignisses weiterhin zu diesen Standorten durch. Traceroutes und Routingprüfungen führten zur Diagnose eines Problems unterwegs im Netz. Einen einzelnen eindeutig verantwortlichen Transitbetreiber benennt der Vortrag für den Januar nicht. ICANN betreibt L-Root; die Wege zu seinen Standorten verlaufen jedoch durch fremde Betriebsbereiche.

Im Januar kam die Diagnose erst nach Stunden manueller Arbeit zustande. Die Forscher mussten dieselben Probes vor und während des Ereignisses vergleichen, ihre früheren Anycast-Standorte prüfen und Traceroutes sowie BGP-Befunde zusammenlegen. Gerade die weiterhin erreichbaren Standorte änderten die Richtung der Suche: vom benannten Root-Betreiber zum Transportweg. Hätte die erste Meldung Zeitfenster, Adressfamilie und Standortvergleich mitgeliefert, wäre die nächste Prüffrage für die beteiligten Netze sofort sichtbar gewesen.

Originalquellen: RIPE-93-Vortrag, RIPE-Atlas-Messkatalog, ICANN zum Root-System.