Zusammenfassung

  • RFC 1591 erklärte, die IANA werde das Internet DNS Names Review Board (IDNB) für ungelöste Streitigkeiten über die Verwaltung einer Top-Level-Domain einsetzen; seine Entscheidungen sollten verbindlich sein.
  • ccNSO-Dokumente von 2017 und 2024 halten fest, dass das IDNB nie gegründet wurde. Eine andere, nicht bindende ccTLD-Review-Policy wurde 2025 beschlossen; der ICANN86-Bericht führte sie im Mai 2026 noch unter „Implementation planning“.

Ein Satz in RFC 1591 klingt nach einem letzten Wort. Wenn sich Parteien, die eine Top-Level-Domain verwalten wollten, nicht einigen konnten, sollte das Internet DNS Names Review Board als Prüfungsgremium tätig werden. Seine Entscheidungen sollten bindend sein. Jon Postel nahm diese Regel in sein Memorandum über DNS-Struktur und Delegation vom März 1994 auf.

Das Gremium ist bemerkenswert, weil RFC 1591 nicht nur technische Anforderungen an einen Registry-Betreiber formulierte. Der Text skizzierte auch, wie Streit über die zuständige Verwaltung beigelegt werden sollte, und sah dafür ein Organ mit Entscheidungsbefugnis vor. Spätere ccNSO-Unterlagen sagen jedoch, dass weder die IANA noch eine andere Stelle das IDNB eingerichtet hat. Der Text beschrieb eine geplante Institution; ihre tatsächliche Gründung ist damit nicht belegt.

RFC 1591 ordnete den eigenen Status ausdrücklich ein: Das Dokument war „Informational“ und sollte keinen Internet-Standard festlegen. Die IANA war für die übergeordnete DNS-Koordination zuständig, während das zentrale Internet Registry — damals das InterNIC — einen Großteil der täglichen Verwaltung übernahm. Für jede Domain sollte es einen benannten Manager geben. Bei ccTLDs musste zumindest der administrative Kontakt im betreffenden Land ansässig sein; hinzu kamen erreichbare Nameserver und die Fähigkeit, den Betrieb zuverlässig zu führen.

Das Memorandum beschrieb den Manager als Treuhänder der delegierten Domain, der sowohl der nationalen Gemeinschaft als auch der globalen Internetgemeinschaft dienen sollte. Fragen nach Eigentumsrechten an Domains seien unpassend; entscheidend seien Verantwortung und Dienst an der Gemeinschaft. Zudem mussten Antragsteller gleich behandelt werden: Ein Manager durfte etwa Kunden eines mit ihm verbundenen Netzanbieters nicht bevorzugen. Subdomains sollten eigene Nameserver betreiben können, sofern ihre Angaben korrekt waren.

Bei der Auswahl sollte es Mitsprache geben. „Significantly interested parties“ sollten dem vorgesehenen Manager zustimmen. Die IANA sollte Einigkeit zwischen konkurrierenden Parteien anstreben und eine bestehende Delegation grundsätzlich nur mit Zustimmung aller ändern — außer bei erheblichem Fehlverhalten des Managers. Interessierte Parteien sollten „some voice“ bei der Auswahl haben. Wenn keine Einigung gelang oder ein Bewerber nicht das ganze Land vertreten konnte, durften IANA und zentrales Registry nur einen Teil der Domain delegieren. Für ungelöste Konflikte benannte RFC 1591 das IDNB als Review Panel mit bindenden Entscheidungen.

Diese Abfolge trennt Beteiligung und Entscheidung. Gehört zu werden bedeutete nicht automatisch, dass ein Streit entschieden war. Der Domain-Manager hatte operative Pflichten; der IANA kam die im Memorandum beschriebene Koordinierung zu. Für den Fall, dass eine Einigung scheiterte, sollte das IDNB die Entscheidungsstufe bilden. Ob dieses Gremium tatsächlich existierte, ist deshalb keine Nebensache: Davon hängt ab, ob das schriftliche Verfahren einen praktisch erreichbaren Endpunkt hatte.

Im Juni 1996 griff ein weiterer Internet-Draft Postels die IDNB-Idee für einen anderen Streit auf. Er schlug ein Verwaltungsmodell für internationale Top-Level-Domains wie COM, ORG und NET vor und erweiterte die Aufgaben des Gremiums um technische Einwände gegen das vorgeschlagene Verfahren. Außerdem verteilte der Entwurf Zuständigkeiten auf IANA, IETF, ISOC und eine Ad-hoc-Gruppe. Der Datatracker klassifiziert ihn jedoch als individuellen Internet-Draft, der von der IETF nicht gebilligt wurde und im Standardisierungsprozess keinen formellen Status hatte. Er lief im Dezember 1996 aus.

Das belegt eine erneute Verwendung der Idee in einem Vorschlag, nicht die Gründung des Organs oder die Annahme des Vorschlags als Policy.

Spätere Unterlagen benannten das Fehlen ausdrücklich. Eine im März 2017 verabschiedete Charta einer ccNSO-Arbeitsgruppe erklärte, das IDNB sei weder von der IANA noch von einer anderen Stelle eingerichtet worden. Damals gebe es für Entscheidungen über Delegation, Transfer und Widerruf von ccTLDs keinen Review- oder Beschwerdemechanismus. Der ccNSO-Abschlussbericht vom September 2024 wiederholte die Feststellung und sagte, diese Entscheidungen unterlägen zu diesem Zeitpunkt keiner unabhängigen Überprüfung. Das dokumentiert eine institutionelle Lücke, beweist aber nicht, dass jeder Streit unbeantwortet blieb, und erklärt keine einzelnen Fälle.

Der spätere Abschluss besteht nicht darin, dass das IDNB verspätet doch noch entstand. Am 8. Juni 2025 verabschiedete das ICANN-Board eine separate ccTLD-Review-Policy, die der ccNSO entwickelt hatte. Die Ankündigung beschrieb einen unabhängigen Prüfweg für bestimmte Entscheidungen des IANA Function Operator, stellte aber klar, dass das Prüfergebnis nicht bindend sein würde. Im ICANN86 Policy Outlook Report vom 14. Mai 2026 stand der Status weiterhin auf „Implementation planning“. Anwendungsbereich, institutioneller Rahmen und Wirkung unterscheiden sich von dem 1994 vorgesehenen IDNB.

Die neue Policy darf nicht als dessen nachträgliche Gründung dargestellt werden.

Die historische Unterscheidung ist einfach und folgenreich. RFC 1591 erkannte das Interesse betroffener Parteien an der Wahl des Managers an, stellte Dienst und Gleichbehandlung über Eigentumsansprüche und sah bei gescheiterter Einigung eine bindende Review-Instanz vor. Doch ein Ausschussname in einem Dokument ist noch keine arbeitsfähige Institution. Spätere Arbeiten mussten von diesem Fehlen ausgehen und einen anderen Policy-Prozess durchlaufen. Beteiligung kann Wissen, Einwände und Belege liefern. Ein Review-Verfahren braucht zusätzlich ein Organ, einen klaren Umfang, Regeln und festgelegte Folgen.

In der DNS-Geschichte kamen diese Elemente nicht gleichzeitig zusammen.

Quellen