EBERO-Übungen dauerten acht Tage; ICANN schloss SSR2 24.1 ab

Summary

Drei EBERO-Übungen 2016 und 2017 erreichten simulierte DNS-Ausfallzeiten von elf Stunden und 55 Minuten bis zu einem Tag, neun Stunden und fünf Minuten. Die längste gemessene RDDS-Unterbrechung betrug fünf Tage, 17 Stunden und 58 Minuten; die Treuhandfunktion war erst nach acht Tagen, drei Stunden und 21 Minuten wiederhergestellt.
SSR2-Empfehlung 24.1 verlangte wenigstens jährliche Tests des ganzen Ablaufs mit vorab festgelegten Daten, Zuständen, Fristen, Ausnahmewegen und veröffentlichten Ergebnissen. Der ICANN-Vorstand stufte sie im November 2022 anhand älterer Tests und jährliche Übungen ermöglichender Verträge als erfüllt ein.
Weder die Implementierungsdokumentation vom Januar 2023 noch der ICANN-Bericht für das zweite Quartal 2026 enthalten in ihrer Erläuterung zu 24.1 eine datierte spätere Messreihe. Ein neuer Bericht müsste die Zeiten aller Funktionen und die Behandlung der früher gefundenen Probleme zeigen.

Der langsame Teil beginnt nach dem ersten grünen Licht

EBERO ist ICANNs Notfallkonstruktion für generische Top-Level-Domains, deren Betreiber eine kritische Registerfunktion nicht mehr aufrechterhalten können. ICANN erklärt den Notfall und koordiniert einen vorübergehenden technischen Betreiber. Die offizielle Programmseite nennt DNS-Auflösung, gemeinsames Registrierungssystem, Registrierungsdaten-Auskunft, Datentreuhand und eine mit DNSSEC ordnungsgemäß signierte Zone. Wer nur den ersten wieder laufenden DNS-Server zählt, übersieht die Daten und die Schritte in der Root-Zone.

Die ICANN-Präsentation von 2017 zeigt, warum. Drei Übungen begannen am 26. Januar 2016, 25. April 2017 und 21. September 2017. Verwendet wurden drei generische Top-Level-Domains, deren Registerverträge ausliefen, und drei verschiedene EBERO-Dienstleister. Jeweils nur ein vom Register selbst gehaltener Name war registriert; gewöhnliche Registranten gab es nicht. Die Betreiber stimmten vor der Entfernung der Domains aus der Root-Zone zu. Der Ausfallschwellenwert wurde simuliert. Die publizierten Dauern sind Messwerte der Übungen und keine realen Ausfälle bei Endkunden.

Auf den Ersatzservern war DNS samt DNSSEC nach drei Stunden und 46 Minuten, neun Stunden und elf Minuten sowie drei Stunden und 59 Minuten wiederhergestellt. Die jeweilige Änderung der Root-Zone erfolgte nach acht Stunden und 22 Minuten, einem Tag, fünf Stunden und fünf Minuten sowie sieben Stunden und 55 Minuten. ICANN bezifferte die gesamte simulierte DNS-Unterbrechung, bereinigt um Cache-Effekte, auf zwölf Stunden und 22 Minuten, einen Tag, neun Stunden und fünf Minuten sowie elf Stunden und 55 Minuten. Zwischen „Ersatzserver bereit“ und „öffentliche Delegation geändert“ liegt ein eigenständiger Behörden- und Technikschritt.

Noch deutlicher wird der Abstand beim Datenpfad. Die Escrow-Hinterlegung stand ICANN nach einem Tag, sieben Stunden und 31 Minuten, nach zwei Tagen, 19 Stunden und 36 Minuten sowie nach einem Tag, 14 Stunden und 22 Minuten zur Verfügung. Das gemeinsame Registrierungssystem kehrte nach fast zwei, fast drei und mehr als vier Tagen zurück. Für den Registrierungsdaten-Dienst RDDS verzeichnete ICANN Gesamtunterbrechungen von zwei Tagen, fünf Stunden und fünf Minuten; drei Tagen, zwei Stunden und 14 Minuten; und fünf Tagen, 17 Stunden und 58 Minuten.

Erst mit der wiederhergestellten Treuhandfunktion endeten die Übungen: nach fünf Tagen, 21 Stunden und 53 Minuten, acht Tagen, zwei Stunden und 34 Minuten und acht Tagen, drei Stunden und 21 Minuten. „DNS wieder da“ war ein Zwischenstand, keine vollständige Übergabe.

Die letzte Zeile der Tabelle zählt 44, 37 und 20 festgestellte Probleme. Addiert sind das 101 Problembeobachtungen in drei Läufen; die Folien sagen nicht, ob einzelne Befunde mehrfach auftauchten. Laut ICANN waren Probleme bereits gelöst oder noch in Bearbeitung. Eine datierte Liste, die Befund und erneuten Test verbindet, bietet diese Präsentation nicht. Gerade diese offene Nachverfolgung macht einen Folgeversuch wertvoll: Er zeigt, ob ein Fehler tatsächlich aus dem Ablauf verschwunden ist.

Ein Vertrag ist noch kein Messprotokoll

Das SSR2-Überprüfungsteam formulierte 2021 deshalb mehr als einen Wunsch nach grundsätzlicher Einsatzfähigkeit. Empfehlung 24.1 verlangte einen End-to-End-Test des gesamten EBERO-Prozesses in festgelegten Abständen, mindestens jährlich. Testdaten, Fortschrittszustände und Fristen sollten vorher feststehen. Auch Ausnahmewege sollten zusammen mit den Vertragspartnern geübt und die Ergebnisse veröffentlicht werden. Eine regelmäßige Übung misst, ob die Rettungskette nach Personal-, Vertrags- und Systemwechseln noch funktioniert.

Im November 2022 entschied der ICANN-Vorstand, 24.1 sei vollständig umgesetzt. Als Belege nannte er die bisherigen Tests und Bestimmungen der EBERO-Verträge, die jährliche Bereitschaftsübungen zulassen. Die Umsetzungssprecher hatten klargestellt, dass man nicht auf aktuell aktiven Domains mit Registranten üben müsse. Diese Grenze bewahrt Dritte vor einem erzwungenen Probelauf. Die Übungen mit auslaufenden Domains zeigen, dass sie gründliche Tests nicht verhindert. Strittig ist, was die öffentliche Erfüllungsmeldung über die Wiederholung und ihre Ergebnisse tatsächlich belegt.

Die am 6. Januar 2023 veröffentlichte Implementierungsdokumentation identifiziert ausdrücklich die drei Übungen von 2016 und 2017. Sie verweist auf die Dienstleisterverträge, nennt die Vorstandsentscheidung als finales Datum und führt für „Implementation completed“ und Meilensteine jeweils „n/a“. Eine spätere Übung mit Datum, Zeitwerten und Abschluss der Befunde ist dort nicht dokumentiert. Der Bericht für das zweite Quartal 2026 führt 24.1 weiterhin als abgeschlossen und erläutert erneut, dass die Verträge jährliche Übungen erlauben. Auch sein Abschnitt zu 24.1 veröffentlicht keine spätere Zeitreihe.

Auf der aktuellen Programmseite stehen Dienstleisterverträge und ein Übergabehandbuch. Diese Unterlagen regeln Fähigkeiten und Pflichten. Sie beantworten eine andere Frage als die Folien mit den Wiederherstellungszeiten. Ob der langsame RDDS-Pfad inzwischen schneller ist und ob die 44, 37 und 20 Befunde geschlossen wurden, lässt sich aus einem Vertragsabsatz nicht ablesen. Der Vorstand hat eine wiederkehrende Anforderung mithilfe vergangener Ergebnisse und künftiger Vertragsmöglichkeiten zu einem abgeschlossenen Verwaltungsvorgang gemacht.

Die Übung selbst ist deshalb umso wichtiger, weil ICANN bereits bewiesen hat, dass es aussagekräftige Zeiten veröffentlichen kann.

Die nächste Veröffentlichung braucht keine dramatische Inszenierung. Datum, verwendeter Dienstleister, Datensatz, Ausgangslage, Ausnahmewege und Zeitpunkte für DNS, Root, Registrierungssystem, RDDS und Escrow reichen als Anfang. Dazu gehört, welche älteren Befunde erneut geprüft wurden. Dann könnte der Leser erkennen, ob ein acht Tage langer Datenpfad verkürzt wurde oder nur in einer Akte verschwand. Ein grüner Status ohne solchen Vergleich ist ein Beschluss über die Dokumentation, keine Messung der aktuellen Notfallgeschwindigkeit.