Dokumentiert, nicht belegt: ICANNs Notfall-Rückfallsystem für Registries

Zusammenfassung

• Die hier geprüfte öffentliche Aktenlage belegt, dass ICANN ein Notfallprogramm für Registry-Backends betreibt und dass eine Benennung aus dem Jahr 2013 drei Anbieter nannte. Alle gesicherten Quellen sind Zusammenfassungen; in dieser Prüfung wurde kein Vertrag, keine Haushaltslinie und keine Benennungsurkunde gelesen.
• Fünf voneinander unabhängige Tatsachen entscheiden darüber, ob diese Zusicherung vollstreckbar ist: eine aktuelle Benennung, ein durchsetzbarer Abrufanspruch, finanzierte und gepflegte Bereitschaft, eine geübte Übergabe und ein definierter Geltungsbereich. Öffentliche Darstellungen behandeln meist die erste als Beweis für alle fünf. In dieser Aktenlage sind nur die ersten beiden belegt, und die zweite ausschließlich über einen Fachbericht, der eine Ankündigung von 2013 zitiert.

Registries scheitern auf unspektakuläre Weise: Ein Betreiber geht pleite, verliert sein technisches Personal oder antwortet einfach nicht mehr. Das Gegenmittel, das ICANN für dieses Szenario ankündigt, ist ein Ersatz-Backend – eine Partei, die vorab bereitsteht, um die kritischen Funktionen einer generischen Top-Level-Domain zu übernehmen, damit die Domain weiter auflöst, während eine längere Lösung entschieden wird. Die Frage dieses Textes ist enger als die, ob das eine gute Idee ist. Sie lautet, ob die öffentliche Aktenlage zeigt, dass der Mechanismus tatsächlich abgerufen werden kann.

Was die Akte sagt – und was nicht

Vier Dokumente bilden die gesamte Beweisgrundlage dieser Prüfung. Die Programmseite von ICANN beschreibt den Mechanismus als Kontinuitätsleistung für Betreiber neuer gTLDs im Fall eines kritischen Ausfalls oder einer Transition (ICANNs EBERO-Programmseite). Die Seite zur gTLD-Registry-Vereinbarung wird so beschrieben, dass sie die vertraglichen Anforderungen an Betreiber enthält, darunter eine Spezifikation 10 zum Registry-Transition-Verfahren, und den Notfallbetreiber als Kontinuitätssicherheitsnetz bezeichnet (Seite zur gTLD-Registry-Vereinbarung). Die Programmübersicht vom 2. April 2013 wird dahingehend zusammengefasst, dass der Dienst zum Einsatz kommen soll, wenn ein Betreiber wesentliche Registry-Funktionen nicht erbringt oder nicht aufrechterhalten kann – unter Bezug auf fünf kritische Registry-Funktionen, vorübergehend oder während einer Transition (Programmübersicht EBERO, 2. April 2013).

Das vierte Dokument ist das einzige, das jemanden nennt. Ein unabhängiger Fachbericht, hier nur als vom Anbieter gemeldeter Auszug gesichert, gibt an, das China Internet Network Information Center, das US-amerikanische Unternehmen Neustar und das britische Unternehmen Nominet seien ausgewählt worden, und schreibt dies einer ICANN-Pressemitteilung zu (InfoWorld-Bericht über die Auswahl von 2013).

Das ist alles, und es ist dünner, als es aussieht. Alle vier Quellen sind Zusammenfassungen. Die Provenienz des Auszugs ist für den Fachbericht als anbietergemeldet verzeichnet; für die drei ICANN-Seiten wurde überhaupt kein Auszug gesichert. Die obigen Beschreibungen sind also die Charakterisierung durch den Recherchedienst, nicht aus den Instrumenten gelesener Text. Die Seite zur Registry-Vereinbarung ist eine Einstiegsseite, nicht die Vereinbarung; Spezifikation 10 wird erwähnt, nicht zitiert.

Die Prüfung hinter diesem Text hat weitergehen wollen und es nicht gekonnt. Am 18. Oktober 2026 scheiterte eine Anfrage zur Einsicht auf Dokumentebene, die Vereinbarung, Programmseite und die Übersicht von 2013 umfasste, weil die Kapazität des Recherchedienstes nach begrenzter Wartezeit nicht verfügbar war (04:50:16 UTC). Eine zweite Anfrage richtete sich auf die beiden gänzlich ungestützten Schenkel – wer derzeit die Rückfallrolle innehat und ob die Bereitschaft finanziert ist – und lief erfolgreich durch, lieferte aber null Quellenkandidaten (04:51:46 UTC).

Das sind zwei Fehlschläge in derselben Instrumentenklasse, und dort endete die Suche. Die Lücke ist als datierte Grenze festgehalten, nicht durch Schlussfolgerung gefüllt.

Fünf Ebenen, routinemäßig zu einer zusammengezogen

Die nützliche Disziplin besteht darin, „der Notfallbetreiber existiert“ nicht länger als eine einzige Tatsache zu behandeln. Sie zerfällt in fünf, und der Beleg auf einer Ebene sagt nichts über die nächste aus.

Erstens: ein angekündigtes Programm. Belegt. ICANN veröffentlicht eine Programmseite, deren erklärter Zweck Kontinuität ist.

Zweitens: ein benannter Anbieter. Belegt, aber nur für 2013 und nur über einen Fachbericht. Auf dieser Ebene endet der größte Teil der öffentlichen Debatte.

Drittens: ein derzeit gültiger, durchsetzbarer Abrufanspruch. Nicht belegt. Nichts in der geprüften Akte zeigt, dass ein benannter Anbieter gegenwärtig unter einer Benennung steht, wie deren Laufzeit bemessen ist, welche Kündigungs- oder Abrufbedingungen daran hängen und wer sie auslösen darf. Eine abgelaufene oder neu beschaffte Benennung ist eine andere Tatsache als eine gültige, und dieser Unterschied ist genau der Unterschied zwischen einem Plan und einer Telefonnummer.

Viertens: finanzierte und gepflegte Bereitschaft. Nicht belegt. Reservekapazität ist nicht kostenlos: Jemand zahlt für vorgehaltene Infrastruktur, für die Vertrautheit der Teams mit vielen Registry-Plattformen und für regelmäßige Validierung. Ob der verabschiedete Haushalt von ICANN eine solche Linie enthält und wie die Kosten eines Abrufs zwischen ICANN, dem ausfallenden Betreiber und den Inhabern, deren Namen auf dem Spiel stehen, verteilt werden, beantwortet kein Teil des gesicherten Materials.

Fünftens: eine geübte, abrufbare Übergabe. Nicht belegt. Ein Gegenmittel, das niemand unter realistischen Bedingungen geübt hat, bleibt eine Hypothese. Die Akte enthält keinen Übungsbericht, keine Übergabefrist und keine Aussage dazu, was „vorübergehend“ in Tagen bedeutet.

Zwei von fünf belegt, und das auf der Ebene von Zusammenfassungen. Das ist der Befund, und er ist kein Skandal. Er ist eine Messung davon, wie weit die öffentliche Akte tatsächlich reicht.

Eine strukturelle Lücke, kein Gotcha

Es wäre einfach und falsch, das als Anklage zu lesen. Man betrachte, woraus ein Kontinuitätsmittel besteht.

Eine Registry-Vereinbarung bindet den Betreiber. Aber die Pflicht, auf die es am meisten ankommt – bei einer Transition mitzuwirken, Registrierungsdaten zu übergeben, die Zone weiter antworten zu lassen, während ein anderer das Steuer übernimmt –, wird genau dann dringlich, wenn der Betreiber am wenigsten in der Lage ist, sie zu erfüllen. Eine Pflicht, die erst nach dem Ausfall durchsetzbar ist, ist ein echter Rückhalt für ein späteres Verfahren. Sie ist kein Ersatz für den Ersatz.

Beides sind unterschiedliche Instrumente mit unterschiedlichen Versagensarten, und ich ziehe diese Unterscheidung analytisch, nicht als Beschreibung der ICANN-Verträge, denn diese Verträge wurden hier nicht gelesen.

Der beschaffte Ersatz ist das andere Instrument, und er lebt vollständig außerhalb der Kontrolle des ausfallenden Betreibers. Er verlangt einen Vertrag mit Laufzeit, eine Haushaltslinie, die einen Führungswechsel übersteht, und eine Routine, die belegt, dass die Maschinerie sich noch dreht. Das sind unspektakuläre Artefakte. Es sind auch die einzigen, die im Moment des Abrufs zählen, weil sie nicht von der Mitwirkung einer Partei abhängen, die bereits aufgehört hat mitzuwirken.

Es gibt einen legitimen Grund, warum Beschaffungsbedingungen nicht immer veröffentlicht werden: Sie können Geschäftsgeheimnisse, sicherheitsrelevante Details und Preise enthalten. Aber Vertraulichkeit der Bedingungen und das vollständige Fehlen jeder Verifikation sind verschiedene Zustände, und die geprüfte Akte belegt nicht einmal, welcher gilt.

Bereichsdisziplin: Kontinuität ist keine Sicherheit

Selbst ein vollständig verifizierter Mechanismus würde nicht bedeuten, was der alltägliche Sprachgebrauch nahelegt. Das Programm wird als auslösbar beschrieben, wenn ein Betreiber fünf kritische Registry-Funktionen nicht aufrechterhalten kann, vorübergehend oder während einer Transition. Das ist ein definierter technischer Bereich: Die Domain löst weiter auf, und eine definierte Funktionsmenge läuft weiter, während eine Ausstiegslösung entschieden wird.

Es ist keine Garantie, dass für die Namen kein Risiko besteht. Es sagt nichts über die Richtigkeit der Inhaberdaten, über die Möglichkeit von Transfer oder Verlängerung während der Transition, über die kommerziellen Bedingungen, die ein Ersatz aufzwingen würde, und nichts darüber, wie lange eine vorübergehende Regelung laufen kann, bevor die zugrunde liegende Governance-Frage zum eigentlichen Problem wird. Kontinuität einer Funktion und Klarheit eines Rechts sind getrennte Zusicherungen. Jede Darstellung, die beides verschmilzt, überzeichnet, was ein technisches Sicherheitsnetz leisten kann.

Legitimität, vorsichtig formuliert

Unter der technischen Frage liegt eine institutionelle, und sie lässt sich stellen, ohne Motive zu unterstellen.

Legitimität, in dem Sinn, der für eine Zusicherungsfunktion zählt, ist eine Beziehung zwischen dem, was eine Institution behauptet, und dem, was unabhängig überprüft werden kann. Eine veröffentlichte Programmseite und eine Pressemitteilung, die Anbieter nennt, sind Formen der Zusicherung. Sie sind billig herzustellen und vermitteln Zuversicht. Unabhängige Verifikation – eine Benennung mit angegebener Laufzeit, eine Haushaltslinie, ein Übungsbericht – ist teuer herzustellen und vermittelt dasselbe mit deutlich geringerer Reichweite.

Diese Asymmetrie erzeugt eine vorhersehbare Drift: Die billige Form zirkuliert, die teure wird selten verlangt, und die Differenz dazwischen wird zum Standard unsichtbar. Inhaber, Reseller und Regierungen bepreisen dann die Beruhigung statt der Kapazität. Wenn beides auseinanderfällt, landet der Preis bei den Parteien, die am wenigsten prüfen konnten.

Das ist kein Befund von Böswilligkeit und nicht die Behauptung, die Kapazität fehle. Es ist eine Aussage darüber, was die Akte trägt: dass eine kategorische Sicherheitsbehauptung dem Beleg vorauseilen würde und die ehrliche Einordnung eine Herabstufung des Vertrauens ist, kein Urteil.

Was Klarheit schaffen würde

Sechs Artefakte würden die Lücke schließen, und jedes ist veröffentlichbar, ohne sicherheitsrelevante Details preiszugeben: eine aktuelle Benennung mit Laufzeit und Inhaber; die Abrufbedingungen und die zur Auslösung befugte Stelle; die Finanzierung, wie sie in einem verabschiedeten Betriebsplan erscheint, auf der Aggregationsebene, die der Haushalt ohnehin verwendet; ein Übungs- oder Testbericht mit Datum; eine dokumentierte Abrufhistorie mit Daten und Laufzeiten, sofern es Abrufe gab; und die ausdrückliche Nennung des definierten Funktionsbereichs.

Nichts davon verlangt die Offenlegung vertraulicher Vertragsanhänge. Jedes davon würde einem Inhaber, einem Reseller oder einer Regierung erlauben, einen abrufbaren Rückfall von einem lediglich angekündigten zu unterscheiden.

Bis dahin ist die zutreffende Aussage über ICANNs Notfall-Rückfallsystem die, die diese Akte trägt: Es existiert, es wird als Sicherheitsnetz beschrieben, drei Anbieter wurden einmal genannt, und die Bedingungen, die über seine Vollstreckbarkeit entscheiden, sind nicht gezeigt worden. Wer die Ankündigung für die Zusicherung nimmt, vertraut einem Instrument, das er nicht gesehen hat. Der Verzeichniseintrag des Programms steht unter Emergency Back-End Registry Operator Program – ICANN.