Zusammenfassung

  • RFC 920 listete nicht nur Namen für die oberste Ebene auf. Sie ordnete den Kategorien Administratoren, Registrierungsstellen und Zulassungsbedingungen zu.
  • ARPA war ausdrücklich temporär. GOV, EDU, COM, MIL und ORG bildeten institutionelle Kategorien; Länderkennungen und Mehrorganisationen waren noch nicht eingerichtete Möglichkeiten.
  • Mehr als 500 Hosts waren die allgemeine Erwartung für eine Top-Level-Domain. Die Marke von mehr als 50 Hosts auf der zweiten Ebene galt dagegen als sehr weiche Leitlinie; große Organisationen konnten darunter liegen.

Die Liste verteilte Zugang und Zuständigkeit

Die frühen Namen im Domainbaum waren keine offene Auswahlliste. RFC 920, veröffentlicht im Oktober 1984 von Jon Postel und Joyce Reynolds, bezeichnete sich als offizielle politische Erklärung des Internet Activities Board und der DARPA für die Einrichtung von Domains im ARPA-Internet und in der DARPA-Forschungsgemeinschaft. Der Text beschrieb nicht nur eine Namenshierarchie. Er legte auch fest, welche Arten von Domains eingerichtet werden konnten, wer sie verwaltete und wie ein Antrag eine Genehmigung erreichen sollte.

Dem waren technische Dokumente vorausgegangen. RFC 881 beschrieb den Plan für Domainnamen; RFC 882 und RFC 883 erläuterten Konzepte und Implementierung. RFC 920 sagt, sie präzisiere die früheren Anforderungen und ergänze eine begrenzte Menge von Top-Level-Domains. Die technische Namensauflösung und die politische Frage, wer an der Spitze stehen durfte, gehörten zusammen, waren aber unterschiedliche Aufgaben.

Die erste Menge umfasste einen vorübergehenden Namen, institutionelle Kategorien und zwei noch nicht eingerichtete Arten:

Position in der ersten Liste Name oder Kategorie Stand laut RFC 920 im Jahr 1984
Temporär ARPA Die damaligen Hosts des ARPA-Internet; ausdrücklich befristet
Institutionelle Kategorien GOV, EDU, COM, ORG DARPA als Administrator, NIC als Agent
Militärische Kategorie MIL DDN-PMO als Administrator, NIC als Agent
Länder Englische ISO-alpha-2-Codes mit zwei Buchstaben Noch keine Länderdomain eingerichtet
Mehrorganisationen Noch kein konkreter Name Noch keine eingerichtet; eine internationale Gruppe außerhalb der übrigen Kategorien war denkbar

Die Liste behauptete nicht, dass jeder Zweig schon existierte. RFC 920 hält ausdrücklich fest, dass Länder- und Mehrorganisationen-Domains noch nicht eingerichtet waren. Auch die Zuständigkeiten waren nicht überall gleich: DARPA verwaltete ARPA, GOV, EDU, COM und ORG; das Network Information Center trat als Agent auf. Für MIL war DDN-PMO zuständig, ebenfalls mit dem NIC als Agent und Registrar. Eine plausible Bezeichnung allein schuf keine Top-Level-Domain; Autorisierung und Registrierung waren eigene Schritte.

Die Hostzahlen bildeten keine einheitliche harte Schranke. Eine Top-Level-Domain musste besonders genehmigt werden; im Allgemeinen war eine solche Genehmigung nur für eine Domain zu erwarten, die voraussichtlich mehr als 500 Hosts umfassen würde. Für die zweite Ebene galt die Leitlinie von mehr als 50 Hosts. RFC 920 nannte sie jedoch eine sehr weiche Anforderung und ließ zu, dass eine bedeutende Universität oder Firma nur wenige Hosts hatte. Niemand musste allein deshalb eine Domain bilden, weil die Zahl überschritten wurde.

Die Größe war nur ein Faktor: Erforderlich waren außerdem verantwortliche Verwaltung, ein zuverlässiger Namensdienst und die Registrierung bei der übergeordneten Stelle.

Die Mehrorganisation-Ausnahme machte sichtbar, warum eine geschlossene Kategorieliste nicht ausreichte. Eine große, internationale Gruppe aus mehreren Organisationen, die sich kaum in eine einzelne Kategorie einordnen ließ, konnte für die Spitze infrage kommen. RFC 920 beschrieb dafür hypothetisch ein Konsortium namens CSNET mit Universitäten und Industrielaboren sowie einer verantwortlichen Verwaltung. Entscheidend ist hier nicht die Zugangs- oder Kostengeschichte von CSNET, sondern die Funktion des Beispiels: Es erklärte, weshalb das Regelwerk Platz für eine Gemeinschaft ließ, die institutionelle Kategorien überschnitt.

Der Text sagt zugleich, dass es damals noch keine solche Top-Level-Domain gab. Das Beispiel belegt deshalb nicht, dass CSNET diesen Status erhielt.

Die Registrierungskette setzte sich unterhalb der Spitze fort. Eine Domain auf der zweiten Ebene registrierte sich beim Administrator der Top-Level-Domain; die nächsttieferen Ebenen wandten sich an die unmittelbar übergeordnete Stelle oder deren verantwortliche Person. Die höhere Instanz musste prüfen, ob die einschlägigen Anforderungen erfüllt waren, bevor sie eine Genehmigung erteilte. Ein Administrator konnte Aufgaben an eine Subdomain weitergeben, blieb aber für den größeren Baum verantwortlich. Die Hierarchie verteilte somit auch Pflichten und Fehlerbehebung.

Diese Pflichten hatten einen operativen Inhalt. Für jede Domain musste eine Person benannt sein, die Fragen koordinierte, technisch kompetent war und innerhalb der Domain Änderungen durchsetzen konnte. Wenn ein Host die Interaktion mit Systemen außerhalb der Domain störte, sollte diese Person Meldungen entgegennehmen und Abhilfe veranlassen. Auch der Namensdienst musste robust sein. Zwei unabhängige Server auf getrennten Maschinen mit separater Stromversorgung waren eine Möglichkeit, gemeinsame Ausfälle zu vermeiden, aber nicht die einzige. Domains konnten zusammenarbeiten oder einen Drittanbieter nutzen.

Entscheidend war die Fähigkeit, Daten und Dienst aktuell zu halten, nicht eine vorgeschriebene Serverarchitektur.

Bei ARPA war die zeitliche Grenze am deutlichsten. RFC 920 erklärte, der Name sei aus der Entwicklungsgeschichte entstanden und solle schließlich verschwinden. Hosts in dieser Domain sollten ihren Wechsel in eine andere Domain vorbereiten. DDN-Hosts, die den neuen Namensdienst nicht nutzen wollten, konnten zunächst die vom NIC gepflegte Datei HOSTS.TXT weiterverwenden; zugleich erwartete der Text, dass auch ihre Namen später geändert würden. Das sind Pläne und Hinweise aus dem Jahr 1984, kein Beleg, dass alle Hosts migrierten oder ARPA an einem bestimmten Tag endete.

Die RFC 1032 von 1987, ein Leitfaden für Domainadministratoren, zeigt eine spätere Phase. Sie beschreibt die Registrierungs- und Root-Zonen-Aufgaben des NIC und hält fest, dass CSNET- und UUCP-Verwaltungen Anträge ihrer Organisationen vorsortierten und Informationen an das NIC weitergaben. Ihre Liste umfasst bereits NET und Länderdomains. Dieser spätere Stand darf nicht in die erste Liste von 1984 zurückprojiziert werden und beweist nicht, dass alle damaligen Erwartungen unverändert umgesetzt wurden.

Die erste RFC-920-Liste war eine Zulassungspolitik, nicht bloß ein Verzeichnis vertrauter Namen. Sie ordnete Kategorien zu, benannte Administratoren, ließ eine Ausnahme für schwer einzuordnende Gruppen offen und bestimmte, wer einen neuen Zweig genehmigen konnte. Die Liste war kurz; die Entscheidung über den Zugang zur obersten Ebene war bereits institutionell.

Quellen

Diese benachbarten Dokumente wurden zur Abgrenzung des Themas geprüft; ihr späterer Stand wird nicht auf 1984 zurückprojiziert.