Zusammenfassung

  • ICANN nimmt vom 10. August bis 21. September 2026 Kommentare zum ersten Bericht einer Technical Study Group über die Verbindung globaler DNS-gTLDs mit alternativen Namenssystemen entgegen.
  • Kern ist die „String+Controller“-Integration: Name und Inhaber müssen in allen Systemen übereinstimmen, gestützt auf ein gemeinsames Registrierungssystem oder eine logisch vereinheitlichte Wahrheitsquelle in einer verteilten Architektur.
  • Der Bericht billigt keine Integration. Jeder Registry-Betreiber braucht weiterhin eine Einzelgenehmigung über RSEP oder das Verfahren der 2026-Runde; Vertragsklauseln folgen in einer späteren Konsultation.
  • Außerhalb des technischen Mandats bleibt eine wesentliche Verteilungsfrage: Vorhandene alternative Namen könnten dazu führen, dass dieselben DNS-Namen gesperrt werden, bevor sie dort je aktiviert wurden.

Eine Schwellenprüfung, kein Startschuss

ICANNs Mitteilung vom 11. August klingt auf den ersten Blick wie der Beschluss, DNS und Blockchain-Namen zusammenzuführen. Tatsächlich ist der Auftrag eng. Seit 2022 fragen bestehende Registry-Betreiber und mögliche Bewerber der nächsten gTLD-Runde, ob sie dieselbe Zeichenfolge im globalen DNS und in einem anderen Namenssystem anbieten dürfen. Die Studiengruppe soll die gemeinsamen technischen Fragen einmal klären, statt sie in jedem Antrag kostenpflichtig neu prüfen zu lassen.

Nicht untersucht werden sämtliche Wallet-Namen, App-Kennungen, privaten Namensräume oder alternativen Roots. Gegenstand ist ein Registry Service, bei dem der gTLD-Betreiber dieselbe Zeichenfolge im DNS und in einem oder mehreren alternativen Systemen unter derselben institutionellen Kontrolle hält.

Eine allgemeine Erlaubnis gibt es nicht. Das 39-seitige Dokument vom 10. August ist als Entwurf gekennzeichnet und wird als erster Bericht konsultiert. Seine Vorfrage im Rahmen der Registry Services Evaluation Policy lautet: Kann diese begrenzte Klasse von Integration sicher und stabil betrieben werden, und welche technischen Mindestbedingungen gelten?

Die Antwort ist vorsichtig positiv. Bei wirksamen Kontrollen sieht die Gruppe für ein Modell mit gleichem Namen und gleichem Inhaber voraussichtlich kein erhebliches Sicherheits- oder Stabilitätsrisiko im Sinne der RSEP. Zugleich erklärt sie, weder diesen Mechanismus gegenüber anderen noch die Idee einer Integration an sich zu befürworten. Machbarkeit ist keine institutionelle Zustimmung.

Das Invariant ist Kontrolle, nicht Blockchain

Der Bericht spricht von „string+controller integration“. Dieselbe Zeichenfolge muss in jedem beteiligten System stets von derselben Partei kontrolliert werden. Wo sie nicht aktiv ist, muss sie exklusiv für diese Partei zurückgehalten werden. Lässt sich eine der Bedingungen nicht dauerhaft erfüllen, fällt der Namensraum aus dem untersuchten Modell heraus.

Das gilt auch unterhalb der TLD. Zuteilung, Transfer, Suspendierung oder Deaktivierung dürfen keine widersprüchlichen Inhaber erzeugen. Bei internationalisierten Namen müssen Varianten und Label Generation Rules vor der Integration abgearbeitet werden. Unterschiedliche Normalisierungen würden die Behauptung derselben Zeichenfolge unzuverlässig machen.

Zwei Betriebsmodelle stehen im Bericht. Im ersten steuert das Shared Registration System die Einschreibung, während alternative Systeme hinter den üblichen Registry-Ablauf geschaltet werden. Die bekannte Kette aus Registry, Registrar und Registrant bleibt erhalten. Dafür braucht es Erweiterungen von EPP zur Bearbeitung und von RDAP zur Anzeige des zusätzlichen Zustands.

Das zweite Modell verteilt Datenbanken und Betreiber, verlangt aber eine logisch einheitliche Wahrheitsquelle. Kein Teilsystem darf eine Änderung abschließen, die Zeichenfolge und Inhaber auseinanderfallen lässt. Wallet, dauerhafte Kennung oder kryptografischer Nachweis können die Kontrolle belegen. Bei langsamer Finalität kann ein DNS-Vorgang warten müssen, bis das andere System seinen Zustand festgeschrieben hat.

Der Antragsteller muss nicht nur freiwillige Zusammenarbeit zeigen. Er muss belegen, dass kein Beteiligter die Integration ohne Anweisung oder Zustimmung des Inhabers brechen kann. Verteilte Technik verteilt deshalb nicht automatisch die Verantwortlichkeit. Die juristische Gesamtverantwortung verbleibt beim Registry-Betreiber, auch wenn mehrere Anbieter Komponenten betreiben.

Der erste politische Konflikt steht bereits im Entwurf

Sind im alternativen System schon Namen vorhanden, verändert die Technik die DNS-Verfügbarkeit. Diese Zeichenfolgen müssen in den gemeinsamen Zustand aufgenommen und auf der DNS-Seite mindestens zurückgehalten werden, auch wenn sie nie in einer DNS-Zone aktiv werden. Sonst könnte eine andere Partei denselben scheinbar integrierten Namen erhalten.

Der Bericht nennt das eine technische Folge mit möglichen politischen Auswirkungen und nimmt diese Auswirkungen aus seinem Auftrag heraus. Genau dort verläuft die Grenze zwischen Eindeutigkeit und Zuteilungsmacht. Das Zurückhalten verhindert widersprüchliche Kontrolle, entzieht aber zugleich einen Namen dem DNS-Angebot. Umgekehrt kann eine DNS-Registrierung das alternative System einschränken.

Technik beantwortet nicht, welche ältere Forderung Vorrang hat, wie Betroffene benachrichtigt werden, wer eine defensive Sperre bezahlt, wie ein falscher Nachweis berichtigt wird oder wo eine kollidierende Historie angefochten werden kann. Synchronisation schafft keine Zuständigkeit für die Verteilung von Rechten.

ICANNs Bylaws setzen dafür eine Grenze. Koordination ist zulässig, soweit sie für Offenheit, Interoperabilität, Resilienz, Sicherheit oder Stabilität des DNS vernünftigerweise notwendig ist. Der Bericht betont selbst, dass ICANN nicht für jedes Namenssystem im Internet verantwortlich ist und nur dort eingreifen muss, wo das globale System berührt wird.

Lu Hengs Ansatz einer dünnen Koordinationsschicht schärft den Test. Eindeutigkeit, Kontrollnachweis, prüfbarer Zustand und Kontinuität können gemeinsame Anforderungen sein. Kommerzielle Priorität, zulässige Nutzung und wirtschaftlicher Wert werden nicht durch eine Schnittstelle zu technischen Befugnissen. Eine enge Weigerung, doppelte Kontrolle zu erzeugen, kann sachlich begründet sein. Weitergehende Folgen brauchen einen benannten Entscheider, Beteiligung der betroffenen Prinzipale, Gründe und Überprüfung.

Die Genehmigung bleibt individuell und vertraglich

Die Konsultation ist keine Sammellizenz. Jeder Betreiber muss RSEP oder den einschlägigen Weg der neuen Runde durchlaufen. RSEP prüft Sicherheit, Stabilität und Wettbewerb. Der gemeinsame Bericht soll Wiederholungskosten sparen, nicht die besondere Architektur eines Antrags der Kontrolle entziehen.

Auch der Vertrag fehlt noch. ICANN org verfolgt die Arbeit, um Änderungen an Registry Agreements zu entwerfen. Ein Entwurf des Schlussberichts soll zusammen mit den Vertragsklauseln erneut kommentiert werden. Die Charta sieht eine zweite Runde und den Abschluss im Januar 2027 vor. Nachweise, Prüfintervalle, Verstoßschwellen, Heilungsfristen, Sanktionen und Rechtsmittel sind deshalb offen.

Der Ausstieg ist ebenso wichtig. Der Bericht empfiehlt einen verpflichtenden Abschaltplan. Alternative Integration scheint zudem nicht zu den kritischen Funktionen zu gehören, die ein Emergency Back-End Registry Operator übernimmt. Scheitert eine Registry und wechselt zu EBERO, kann das DNS weiterlaufen, während der alternative Dienst endet.

Ein Produkt, das einen Namen in mehreren Systemen verspricht, kann sich damit gerade in der institutionellen Krise teilen. Der Antrag muss erklären, welcher Zustand fortgilt, wie veraltete Einträge behandelt werden, was der Inhaber behält und wie Nutzer informiert werden. Gleichheit des Namens ist eine dauernde Betriebspflicht, kein Startetikett.

Vier Entscheidungen dürfen nicht zusammenfallen

Die aktuelle Konsultation kann Kontrollnachweise, Synchronisation, verteilte Finalität, IDNs, RDAP, Transfers, Suspendierung, EBERO und Abschaltung testen. Wertvolle Beiträge benennen einen konkreten Bruchpfad statt nur eine Haltung zu Blockchain-Namen.

Die Vertragsrunde muss vier Akte trennen: Die TSG stellt technische Sicherheit fest. ICANN genehmigt oder verwirft einen einzelnen Dienst. Der Vertrag begründet Überwachungs- und Durchsetzungsbefugnisse. Eine politische Regel entscheidet über verdrängte Namen oder Anspruchsteller. Jeder Akt hat einen anderen Träger, Grund und Rechtsbehelf.

Die Stärke des ersten Berichts liegt darin, die Metapher einer „Brücke“ durch ein Betriebsinvariant, eine verantwortliche juristische Person und einen Abschaltfall zu ersetzen. Legitim bleibt er, wenn er diese Grenze wahrt. Technische Machbarkeit öffnet eine Prüfung; sie vergibt nicht die Macht über die Schwelle.

Quellen