Zusammenfassung

  • Die technische Studiengruppe von ICANN untersucht ein enges Modell: dieselbe Zeichenfolge in einer gTLD und mindestens einem alternativen Namenssystem, unter demselben Verfügungsberechtigten und koordiniert vom Registry-Betreiber.
  • Der Entwurf empfiehlt einen verpflichtenden Abschaltplan und ordnet die Integration außerhalb der fünf kritischen Funktionen ein, die ein Emergency Back-end Registry Operator aufrechterhält.
  • Die erste öffentliche Konsultation endet am 21. September 2026. Der Bericht ist weder endgültige Richtlinie noch genehmigter Dienst oder Beleg für einen realen Ausfall.

Ein Dienst kann verschwinden, während die von ihm verteilte Verfügungsgewalt bestehen bleibt.

Genau dieses Risiko macht den am 10. August veröffentlichten Erstbericht der Technical Study Group zu einer Governance-Frage. Die Gruppe beurteilt nicht alle alternativen Namenssysteme. Sie beschränkt sich auf eine Konstruktion, in der dieselbe Zeichenfolge sowohl als gTLD im globalen DNS als auch in einem anderen System vorkommt und in beiden Fällen von derselben Partei kontrolliert wird. Der Registry-Betreiber koordiniert diese Bindung. Auch bei ausgelagerten Komponenten bleibt die Richtlinienverantwortung bei ihm.

Unter geeigneten Betriebskontrollen hält die Gruppe erhebliche Sicherheits- oder Stabilitätsprobleme im Sinne des RSEP für unwahrscheinlich. Diese Aussage ist bedingt. Sie verspricht weder Risikofreiheit noch befürwortet sie alternative Namensintegration allgemein. Andere Mechanismen bleiben außerhalb des Untersuchungsrahmens.

Abschalten ist eine Folge von Zustandsänderungen

Der Bericht unterscheidet verfügbare, aufgenommene, zugeteilte, zurückgehaltene, aktive, deaktivierte, ausgesetzte und vollständig abgeschaltete Namen. Die Begriffe zeigen, warum ein einzelner Schalter nicht genügt.

Das Ende neuer Aufnahmen sagt nichts über bestehende Namen. Eine abgeschaltete Antwort lässt offen, ob die alternative Kennung weiterhin dem bisherigen Inhaber zugeteilt, für ihn gesperrt oder für andere freigegeben ist. Eine entfernte Benutzeroberfläche beweist nicht, dass Cache, verteiltes Register, Vertrag und ausgelagertes System denselben Zustand übernommen haben.

Wechselt ein DNS-Name den Inhaber, während die gleichlautende alternative Kennung beim früheren Inhaber bleibt, können beide Systeme technisch korrekt arbeiten. Trotzdem ist das Versprechen „gleicher Verfügungsberechtigter“ gebrochen. Zeichenfolge, Zustand und Kontrolle müssen gemeinsam durch Übertragung, Ablauf, Aussetzung und Beendigung geführt werden.

Der aktive Internet-Draft der IETF-Arbeitsgruppe DNSOP trennt Lebenszyklus, Kontrollprüfung, Vollständigkeit und Synchronisierung. Er warnt, dass eine veraltete Integration einer anderen Person als dem aktuellen Domaininhaber Kontrolle lassen kann. Der Entwurf ist laufende Arbeit und keine ICANN-Vorgabe. Seine Analyse erklärt dennoch, weshalb eine richtige Prüfung beim Einstieg keinen richtigen Ausstieg garantiert.

EBERO schützt einen ausdrücklich begrenzten Kern

Droht ein gTLD-Betreiber fünf kritische Funktionen nicht mehr aufrechterhalten zu können, kann ICANN einen Emergency Back-end Registry Operator aktivieren. EBERO sichert DNS-Auflösung, Shared Registration System, Registrierungsdaten-Verzeichnisdienste, Datentreuhand und eine ordnungsgemäß mit DNSSEC signierte Zone.

Alternative Namensintegration steht nicht in dieser Aufzählung. Der Erstbericht folgert, dass sie den EBERO-Betrieb wahrscheinlich nicht übersteht. Deshalb soll ihr Ende bereits Teil der Dienstprüfung sein.

Das ist kein Vorwurf gegen EBERO. Es beschreibt den Auftrag. Die Notfallfähigkeit einer DNS-Registry darf nicht zur allgemeinen Garantie für jedes angehängte Produkt werden. Ebenso wenig beweist die EBERO-Bereitschaft für fünf Funktionen, dass der Anbieter ein fremdes Namenssystem betreiben oder sauber entkoppeln kann.

Der richtige Text kann praktisch unerprobt bleiben

Der Bericht empfiehlt, in der Definition des Registry-Dienstes seine Fähigkeiten und einen Weg zu ihrer Abschaltung festzuhalten, falls die Integration nicht mehr tragfähig ist. Bis genügend Betriebserfahrung vorliegt, soll dieser Turn-down-Plan verpflichtender Bestandteil der Prüfung sein.

Ein solcher Plan kann trotzdem von einem im Ausfall unerreichbaren Lieferanten, einer abgelaufenen Berechtigung oder einer letzten Handlung des ausgeschiedenen Inhabers abhängen. Er kann neue Aufnahmen stoppen, ohne bestehende Namen zu behandeln. Oder er nimmt an, DNS und alternatives System würden stets in der vorgesehenen Reihenfolge reagieren.

Das belegt keinen künftigen Fehler. Es zeigt nur, dass Plan und Ausführung zwei verschiedene Evidenzklassen sind.

Die Registry Services Evaluation Policy liefert das Verfahren. Ein Betreiber beantragt, einen Registry-Dienst hinzuzufügen, zu ändern oder zu entfernen; ICANN prüft mögliche erhebliche Folgen für Sicherheit, Stabilität und Wettbewerb. Der Erstbericht zieht außerdem eine klare Grenze: Die technischen Mindestanforderungen dürfen nicht aus Gründen der Wirtschaftlichkeit aufgeweicht werden. Ein abgeschwächter Entwurf wäre ein anderer Dienst und bräuchte eine eigene Prüfung.

Das muss auch für Abschalttests gelten. Bleiben Zustände unvereinbar, gehört die Ausnahme in den Nachweis und der Entwurf in die Korrektur. Eine nachträgliche Verkleinerung des Begriffs „abgeschaltet“ macht aus einem Fehlschlag nur eine bequemere Definition.

Der Bericht ist noch offen

Die erste Konsultation läuft vom 10. August bis 21. September. Danach sieht die Charta eine zweite Fassung und Konsultation im Oktober sowie einen Abschlussbericht im Januar 2027 vor. Das sind Plantermine, keine erledigten Beschlüsse.

Keine geprüfte Quelle belegt einen genehmigten Dienst, den Ausfall einer benannten Registry, eine EBERO-Übernahme dieser Integration oder eine reale Trennung von Verfügungsberechtigten. Die Frage ist vorsorglich gestellt: Welcher Nachweis muss angelegt werden, bevor ein Ereignis Rekonstruktion verlangt?

Quellen