Zusammenfassung

  • Vom 2. August, 00:06 UTC, bis zum 4. August, 12:30 UTC, verzögerten sich Reverse-DNS-Updates bei RIPE NCC: 60 Stunden und 24 Minuten. Eine in der RIPE Database gespeicherte Änderung konnte dadurch später im veröffentlichten DNS ankommen. Nach der Reparatur verarbeitete RIPE NCC alle offenen Updates.
  • Auf der RIPE 93 erklärte Ed Shryane die Ursache: Beim Dekodieren maskierter Zeichen kam in einem RPSL-Objekt ein Zeilenumbruch hinzu. Das machte den angenommenen Eintrag ungültig. Die Korrektur ließ die Zeichen unverändert; danach prüfte das Team die letzten 1.000 Objekte und das Ende des Datenstroms.

Analyse

Reverse DNS beantwortet die Frage: Welcher Name gehört zu dieser IP-Adresse? Während des Vorfalls kamen Änderungen an solchen Zuordnungen verspätet im veröffentlichten DNS an. Eine Änderung konnte bereits in der RIPE Database stehen, während die DNS-Seite noch auf die Aktualisierung wartete.

Für den Transport nutzt RIPE NCC Near Real Time Mirroring (NRTM). Der Dienst gibt neue Datenbankänderungen an Spiegel weiter. Wenn ein Eintrag im Datenstrom nicht mehr korrekt lesbar ist, können nachgelagerte Systeme die Änderungen nicht wie vorgesehen übernehmen.

In einer Nachricht an die Database Working Group vom 6. August nannte RIPE NCC den Zeitraum genau: 00:06 UTC am 2. August bis 12:30 UTC am 4. August 2026. Das sind 60 Stunden und 24 Minuten. Der offizielle Statusbericht stufte den Vorfall als schwerwiegend ein. Nach der Reparatur arbeitete RIPE NCC die ausstehenden Updates ab; der Status meldete Reverse DNS wieder als betriebsbereit.

Der Datenbankingenieur Ed Shryane beschrieb den Auslöser in der Database-Sitzung der RIPE 93. Ein Verarbeitungsschritt sollte maskierte Zeichen wieder lesbar machen. Dabei fügte er eine zusätzliche Zeile in ein RPSL-Objekt ein. RPSL legt fest, wie solche Registry-Einträge aufgebaut sind; der neue Zeilenumbruch zerstörte diese Struktur, obwohl RIPE NCC den Eintrag angenommen hatte.

Das Team änderte den Verarbeitungsschritt so, dass die maskierten Zeichen stehen blieben. Dann prüfte es rückwirkend die letzten 1.000 Objekte: Konnte der Parser jedes lesen? Endete die Antwort mit dem erwarteten Abschlussmarker? Die erste Prüfung testet den Inhalt, die zweite bestätigt, dass der Spiegel den gesamten Datenstrom erhalten hat.

Ein einzelner Textschritt am Anfang verzögerte so die DNS-Aktualisierung am Ende. Die öffentlichen Quellen nennen Dauer und Wiederherstellung, aber keine Zahl betroffener Spiegel oder Domains; diese Zahl würde die Reichweite außerhalb von RIPE NCC verändern.

Quellen

Transkript der RIPE-93-Database-Sitzung; RIPE-93-Sitzungsseite; RIPE-NCC-Statusbericht; Mitteilung von RIPE NCC an die Database Working Group; RFC 2622.