Zusammenfassung

  • RFC 1101 schlug vor, Netznamen, Netznummern und verschachtelte Subnetze mit PTRs an Host-null-Namen in IN-ADDR.ARPA zu verbinden; ein A-Record konnte die Maske für die nächste Suchstufe tragen.
  • Das Dokument trennte lokal gewählte Namen von den vom NIC zugeteilten Nummern. Eine DNS-Antwort beschrieb eine Beziehung in ihrem Geltungsbereich; sie teilte keine Nummer zu, verfolgte Umbenennungen nicht automatisch und bewies weder aktuelle Kontrolle noch ein Dienstergebnis.

Die eine Lücke aus HOSTS.TXT

P. Mockapetris beginnt RFC 1101 mit einer eng umrissenen Lücke. DNS war erweiterbar und hatte viele Aufgaben von HOSTS.TXT übernommen, aber die Umrechnung zwischen Netzname und Netznummer fehlte noch. Das Memorandum vom April 1989 liefert dafür eine konkrete Methode und daneben experimentelle Ideen für allgemeinere Verzeichnisse von Kennungen und Zahlen. Der Unterschied im Status ist wichtig: Die Netznamensmethode war ein Proposed Standard, die weitreichenderen „Yellow Pages“ waren ein Experiment. Es ging nicht darum, jeder Zahl eine einzige universelle menschliche Bedeutung zu geben, sondern darum, dass ein Administrator in einem klar verantworteten Bereich eine gewählte Bezeichnung neben einer Zahl veröffentlichen kann.

Ein Diagnosewerkzeug konnte dadurch eine opake Ziffernfolge durch einen lesbaren Namen ergänzen. Daraus wurde weder eine Zuteilungsurkunde noch ein Beweis dafür, wer das Netz betreibt, welchen Weg ein Paket nimmt oder ob ein Dienst antwortet. Die Zuordnung war gerade deshalb nützlich, weil sie diese Fragen nicht vortäuschte.

Der Name blieb bei seiner lokalen Pflege

Hinter der Namenssyntax stand eine Verwaltungsfrage. Der ältere flache Namensraum begünstigte eine zentrale Regulierung von Namen parallel zu Nummern. RFC 1101 berichtet jedoch, die Mehrheitsmeinung bevorzuge lokale Kontrolle über Netznamen. Daher nahm das Dokument die erweiterte Hostnamensyntax an und erlaubte einem Administrator, Netznamen in den von ihm kontrollierten Domains anzulegen. Der Preis war offen benannt: Netznamen würden ebenso kompliziert wie Hostnamen. Der Gewinn bestand darin, dass Kontext und Pflege der Bezeichnung bei der Stelle blieben, die sie kennt. ARPANET.ARPA. ist im RFC ein historisches Beispiel einer Namenswahl, keine ewige Definition einer Ressource und keine Übertragung der zugehörigen Nummer.

Für die Gegenrichtung brauchte es einen anderen Einstieg. Aus einer IP-Adresse allein ließ sich nicht erraten, welche lokale Domain befragt werden sollte. Das RFC nutzte deshalb den bereits nach Adressen delegierten Baum IN-ADDR.ARPA. Die vorhandene Verteilung der Verantwortung konnte so auch die inverse Beschreibung tragen, ohne eine zweite globale Hierarchie zu schaffen.

Host Null war eine Karteikarte, kein Rechner

Die vorgeschlagene Form lautete <umgekehrte-Host-null-Nummer>.IN-ADDR.ARPA. PTR <Netzname>. Beim Netznamen stand der Gegen-PTR. War das Netz weiter unterteilt, lag an derselben Host-null-Stelle ein A-Record, dessen Daten die Subnetzmaske waren. 0.0.0.10.IN-ADDR.ARPA. und 0.0.2.128.IN-ADDR.ARPA. sind die historischen Strukturbeispiele des Dokuments.

Das Null-Host-Feld wird damit nicht zu einem erreichbaren Rechner. Es ist eine erkennbare Karteikarte im DNS-Baum, an die beschreibende Information geheftet und deren Vorhandensein geprüft werden kann. Der PTR verbindet einen nummernorientierten Einstieg mit einem lokal gepflegten Namen. Er konfiguriert keinen Router, verleiht kein Recht und macht aus dem Namen nicht die rechtliche oder betriebliche Identität der Nummer.

Auch der A-Record ist hier eng zu lesen. Er trägt in diesem Entwurf eine Maske, wenn eine weitere Subnetzebene folgt. Im damaligen A/B/C-Verfahren wird die IP maskiert, die Oktettreihenfolge umgedreht und der PTR befragt. Liefert die Antwort die A-Maske, wird sie auf die ursprüngliche IP angewandt und die Suche wiederholt; ohne A endet die Verschachtelung. Das ist eine historische Ausleseregel, kein Nachweis aktueller Topologie, Route oder Erreichbarkeit.

Drei Richtungen sind keine einheitliche Herrschaft

RFC 1101 erlaubte auch, dass ein Organisationsname per PTR auf einen oder mehrere Host-null-Netzeinträge verweist. Damit gab es Netzname zu Nummerneintrag, Nummerneintrag zu gewähltem Namen und Organisationsname zu mehreren Netzeinträgen. Jede Richtung ist brauchbar, weil sie eine andere begrenzte Frage beantwortet. Eine unter einer Domain veröffentlichte Organisationsbeziehung ist ein Fakt über diese Veröffentlichung. Ein Netzname ist ein Fakt über eine Namenswahl. Eine Antwort ist ein Fakt über Anfrage, Algorithmus und Zeitpunkt.

Nichts davon beweist allein oder ohne neue Belege in Summe gegenwärtiges Eigentum, eine Gesellschaftsbeziehung, physische Obhut, Befugnis, eine BGP-Route, Paketempfang oder Anwendungserfolg. Das Memo erkennt zudem die echte Spannung an: Zentrale Tabellen konnten konsistenter, verteilte Daten aktueller und wartbarer sein. Ein Eintragsformat beseitigt nicht die Arbeit, Fakten richtig zu halten; es zeigt Herkunft, Zuständigkeit und Grenze der Aussage.

Die Zuteilung schrieb keinen späteren Namen vor

Im YP-Abschnitt formuliert RFC 1101 die Grenze am deutlichsten. Es skizziert DNS-Bäume für Paare wie Port-Mnemonik und Portnummer, autonomes System und Nummer oder zugeteilter Netzname und IP-Adresse. Der Schlüssel musste Ausgangs- und Zieltyp benennen; eine Zahl ohne Kontext hat noch nicht die Bedeutung einer Zuordnung.

Der NIC hätte YP-Domains für seine eigenen Zuteilungsentscheidungen führen können. Doch das RFC sagt ausdrücklich, sie würden zugeteilte Namen und Nummern abbilden, nicht Namen, die Organisationen später selbst wählen. Eine Umbenennung durch neue Eigentümer würde nicht automatisch nachgezogen. Zuteilungsgeschichte und lokale Benennung waren absichtlich verschiedene Fakten.

Eine zentrale Liste kann ein starker Beleg für ihre zentrale Entscheidung sein. Eine lokale Zone kann ein starker Beleg für ihr veröffentlichtes Label sein. Beides ist kein Kurzschluss zu einem gegenwärtigen Betreiber, einem verfügbaren Dienst, einer Routenpolitik oder einem Transaktionsergebnis. Ein Register beschreibt Realität innerhalb seiner Grenze; es erzeugt nicht die weiteren Tatsachen, die Lesende gerne hineinlesen möchten.

Das RFC in seiner historischen Größe lesen

RFC 1101 belegt einen Vorschlag von 1989. Sein classful Verfahren, seine YP-Domains und Beispiele beschreiben nicht automatisch heutige DNS-Bereitstellungen. Seine Disziplin bleibt sinnvoll: Eine Zuordnung braucht Herkunft, Richtung und Umfang; sie darf nicht mit Entscheidungen belastet werden, die der Eintrag nicht enthält. Veröffentlichter Name, zugeteilte Nummer, beobachtete Route und nachgewiesenes Ergebnis sind unterschiedliche Aussagen.

Quellen und Beweisgrenze

Diese Analyse stützt sich auf RFC 1101, RFC 1034 und RFC 1035. Sie belegen den Vorschlag von 1989, seine Recordformen und die Unterscheidung zwischen zugeteiltem und lokalem Namen, nicht aber aktuelle DNS-Daten, Kontrolle, Identität, Eigentum, Route, Erreichbarkeit, Befugnis oder Dienstleistung.