Zusammenfassung

  • In einem auf der RIPE 93 vorgestellten Fall stieg die Zahl der RIPE-Atlas-Sonden mit IPv4-Zeitüberschreitungen zu L-Root für mehrere Tage von gewöhnlich etwa 1.000 auf rund 3.000. Etwa 1.700 Sonden fielen im Vergleich zweier Zeitfenster neu auf, verteilt über 97 Länder.
  • Andere Sonden erreichten die Standorte weiter. Die Auswertung wies auf gestörte Netzwege; eine passende Messung des Effekts bei rekursiven Resolvern und deren Nutzern lag im Vortrag nicht vor.

Ein Servername steht über dem Diagramm, darunter klettert die rote Kurve. So entsteht in Sekunden eine fertige Anklage. Auf der RIPE 93 hieß der Name L-Root; die Kurve erreichte ungefähr 3.000 RIPE-Atlas-Sonden mit Zeitüberschreitungen über IPv4. Der anschließende Befund war für eine Schlagzeile unbequemer: Die Standorte des Root-Dienstes antworteten weiterhin. Einige Wege dorthin funktionierten nicht.

Giovane Moura stellte den Fall am 27. Oktober vor. Das von einem Team mit Bezug zu SIDN Labs und der TU Delft entwickelte RootViz verarbeitet Messungen aus RIPE Atlas, das das RIPE NCC betreibt. Bei L-Root lag die gewöhnliche Zahl der betroffenen Sonden laut Moura um 1.000. Sie erhöhte sich für Tage auf etwa 3.000. Das Team verglich kurze Abschnitte vor und während des Anstiegs und isolierte rund 1.700 Sonden, die erst im Ereignisfenster ausfielen. Sie lagen in 97 Ländern.

Ein solcher Ausschlag verdient sofortige Aufmerksamkeit. Für die Reparatur genügt er nicht. Das Team prüfte, ob die Sonden selbst noch verbunden waren. Es verglich IPv4 mit IPv6 und die Erreichbarkeit anderer Root-Buchstaben. Das IPv6-Bild zeigte den gleichen Einbruch nicht, und andere Root-Dienste blieben für die untersuchten Sonden erreichbar. Traceroutes und die zuvor erreichten Anycast-Standorte lieferten die nächste Spur. Von anderen Sonden kamen Antworten aus den Standorten. Die Störung betraf Pfade zum Dienst. Moura beschrieb die Suche nach der genauen Ursache weiterhin als teilweise mühsame Handarbeit.

Dass RootViz den Fall sah, hängt mit seiner Auswahl der Messpunkte zusammen. DNSMON, der DNS-Monitoringdienst des RIPE NCC, nutzt Atlas-Anker. Diese leistungsfähigeren und stabileren Punkte messen Root- und viele Top-Level-Domain-Server aktiv. RootViz zieht auch gewöhnliche Atlas-Sonden hinzu. Der Jahresbericht des RIPE NCC verzeichnete für 2025 etwa 14.400 verbundene Sonden und 963 verbundene Anker. Das sind historische Bestandszahlen, keine gleichzeitigen Nenner für den L-Root-Fall vom Oktober 2026. Sie machen sichtbar, wie stark die Wahl der Stichprobe den Suchraum vergrößert.

Anker liefern einen ruhigen Bezugspunkt. Gewöhnliche Sonden bringen Messungen aus viel mehr Netzen, dafür auch die Ausfälle ihrer Heimanschlüsse und Hostrechner mit. Ein roter Punkt kann ein ausgeschaltetes Gerät sein. Eine Kohorte, die vorher funktionierte und nun nur bei einem Ziel über eine Adressfamilie ausfällt, verdient eine andere Untersuchung. Für eine öffentliche Fehlermeldung braucht es deshalb die Zahl angeschlossener Sonden, den Zeitpunkt jedes Messfensters und denselben Satz von Beobachtern vor und während des Ereignisses.

Die L-Root-Analyse verwendete genau solche Gegenproben. IPv6 blieb anders als IPv4 erreichbar. Andere Root-Buchstaben zeigten nicht dasselbe Muster. Die Sonden waren online. Anycast-Standorte antworteten über andere Wege. Jeder Vergleich schränkte die Zahl plausibler Fehlerorte ein. Der Name L-Root auf der Kurve sagte, welches Ziel getestet wurde; er sagte nicht, welcher Netzbetreiber auf dem Weg ein Problem hatte.

Dann stellte Hans Petter Holen, Geschäftsführer des RIPE NCC und Betreibervertreter von K-Root, die Frage nach dem Schaden: Wie stark traf das die Resolver und Nutzer? Ein Teilnehmer erinnerte daran, dass normale Endgeräte ihre DNS-Abfragen oft an rekursive Resolver anderswo im Netz senden. Atlas-Sonden sind keine Zählgeräte für diese Abfragen. Moura räumte ein, dass seine Sicht auf Sondenpfade keine direkte Umrechnung in betroffene Nutzer erlaubt. Resolveraufzeichnungen aus denselben Netzen und demselben Zeitraum würden die Größenordnung des Nutzereffekts klären.

Ein gestörter Weg bleibt ein Betriebsproblem, auch wenn Nutzer über andere Wege Antworten erhalten. Die Verantwortlichkeiten müssen aber zur Art des Belegs passen. Ein Root-Betreiber kontrolliert seine Standorte und Ankündigungen. Transitnetze kontrollieren Abschnitte des Weges. Resolverbetreiber sehen, ob Abfragen tatsächlich fehlgeschlagen sind. Wer aus „3.000 Sonden liefen in einen Timeout“ sofort „L-Root war ausgefallen“ macht, schickt das erste Reparaturteam an den falschen Ort.

RIPE Atlas stellt die Daten bereit, RootViz macht den Ausschlag sichtbar. Die nächste Stufe entscheidet über den Wert des Alarms: dieselbe Sondenkohorte festhalten, Kontrollziele vergleichen, den Pfad eingrenzen und die Wirkung auf Resolver getrennt messen. Die rote Linie ist der Anfang einer Störungsakte. Ihre Unterschrift gehört dem Befund.

Quellen: RootViz-Sitzung der RIPE 93 und offizielles Transkript; RIPE-NCC-Dokumentation zu DNSMON, integrierten Atlas-Messungen und Jahresbericht 2025.