Zusammenfassung

  • RFC 897 behandelte die hierarchische Schreibweise eines Hostnamens und den Wechsel von HOSTS.TXT zu verteilten Servern als getrennte Zustandsänderungen.
  • RFC 921 übernahm den alten Zeitplan in die Revision und kennzeichnete pünktliche, verspätete und noch offene Meilensteine.
  • Maschinen, Daten, Bibliotheken und einzelne Anwendungen konnten zu unterschiedlichen Zeiten umgestellt sein; für die DDN/MILNET-Gemeinschaft galt zudem ein eigener Pfad.

Schon die zentrale Tabelle war eine Lieferkette. RFC 810 spezifizierte eine beim NIC gepflegte, maschinell übersetzbare Hosttabelle. Ein Empfänger musste sie dennoch abrufen, in ein lokales Format umwandeln und aktivieren. RFC 811 beschrieb einen Hostnames Server für Einzelabfragen und die vollständige Tabelle. Richtigkeit an der Quelle war kein Nachweis für den tatsächlich gelesenen lokalen Stand.

RFC 881 benannte die Einführungsfalle. Sobald einige Gruppen Domainnamen verwendeten, tauchten diese in Nachrichten bei allen anderen auf. Wartete man auf die Bereitschaft jedes Programms, begann die Migration nicht. Daher sollte eine Domain-Tabelle zunächst parallel existieren, später die normale Tabelle ersetzen und schließlich ein Resolver an die Stelle des bisherigen Bibliotheksaufrufs treten. Der Aufrufer musste die Quelle der Adresse nicht kennen.

RFC 882 und RFC 883 beschrieben das verteilte Gegenmodell mit typisierten Daten, Zonen, Servern, Verweisen, Resolvern und Caches. Eine fertige Spezifikation sagte aber nichts darüber aus, ob ein bestimmter FTP-Client oder Mailer sie benutzte.

Der Punkt im Namen kam vor dem neuen Lookup

RFC 897 unterschied im Februar 1984 zwei Änderungen. Einerseits wurden flache, global eindeutige Strings durch hierarchische Namen ersetzt. Andererseits sollte die Namensauflösung von lokalen Kopien einer zentralen Gesamttabelle auf dynamische Abfragen bei verteilten Servern wechseln.

Der Plan hatte vier Schritte: .ARPA an den bisherigen Namen hängen, wenige Domains einführen, von Tabellen auf Server wechseln und anschließend viele Domains zulassen. Ein Name wie USC-ISIF.ARPA konnte deshalb noch aus HOSTS.TXT stammen. Die Syntax war keine Telemetrie des Backends.

Ein alter Name durfte vorübergehend als Nickname weiterleben. Das half dem Host, der dieses Alias akzeptierte. Es reparierte weder ein fremdes Adressbuch noch alte From-, To- oder Cc-Felder oder eine extern gepflegte Mailingliste. Sobald ein Name kopiert worden war, lag ein Teil des Migrationszustands außerhalb der Zuständigkeit des umbenannten Systems.

Die verteilte Datenbank sollte außerdem von einer Adresse weiterhin zum primären Namen führen. Diese Eigenschaft erforderte abgestimmte Verwaltung. Sie war weder Authentifizierung noch ein Beweis gegenwärtiger Erreichbarkeit.

Gemeinsame Namensform, getrennte Pflicht

RFC 897 setzte den 14. März 1984 für primäre Domainnamen, den 2. Mai für das Ende alter Namen, den 6. Juni für allgemeine mehrstufige Domains, den 18. Juli für Organisationsnamen, den 5. September für die Entbehrlichkeit der vollständigen ARPA-Forschungstabelle und den 3. Oktober für einen DDN-Plan an.

Die ARPA-Forschungsgemeinschaft sollte vollständig wechseln. Die operative DDN-Gemeinschaft änderte ihre Namen im selben Zeitfenster, musste aber nicht gleichzeitig auf Server umstellen. Ihr Programmbüro sollte später entscheiden; das NIC hielt ihre zentrale Tabelle weiter vor.

Damit konnten zwei Hosts dieselbe moderne Namensform zeigen, obwohl ihre Antworten aus unterschiedlichen Datenregimen kamen. Ein gemeinsames Etikett war kein gemeinsamer Betriebszustand.

Die Revision löschte die Abweichungen nicht

RFC 920 veröffentlichte die Anforderungen für neue Domains und die überarbeitete Top-Level-Struktur erst im Oktober. RFC 897 hatte diesen Baustein für Februar vorgesehen. Die Zulassungsregeln entstanden während der laufenden Umstellung.

RFC 921 fügte dem alten Zeitplan Kommentare hinzu. Die erste Domain-Hosttabelle und die Namensänderung im März waren pünktlich. ARPA-Server liefen, aber erst im September statt im April. Top-Level-Domain-Tabelle, neue Domains, mehrstufige Namen, Organisationsnamen, Abschaltung der Hosttabelle und DDN-Plan waren noch offen.

Für die nächste Runde unterschied RFC 921 drei Phasen. Machinery bedeutete Server und Resolver. Database bedeutete installierte Daten. User programs bedeutete, dass Mailer, Telnet, FTP und andere Programme die neuen Verfahren aufriefen. Im Oktober 1984 waren Maschinen weit fortgeschritten und ARPA-Daten vorhanden; bei den Anwendungen war wenig geschehen.

Der revidierte Plan reichte bis Oktober 1985. Auch diese Termine garantierten keine spätere Erfüllung. Die belastbare Information lag in der offenen Rückschau: erledigt, verspätet oder noch nicht erledigt.

Der Mischbetrieb wurde anwendungsbezogen

RFC 1031 beschrieb 1987 für MILNET drei gleichzeitig bestehende Stufen: nur Tabelle, Tabelle und DNS gemischt, nur DNS. Telnet und FTP konnten vor MAIL wechseln oder umgekehrt. Selbst ein einzelner Host hatte nicht zwingend einen einheitlichen Migrationsstatus.

Die RFC bezeichnete die meisten Hosts damals als tabellengebunden. Alte Architekturen oder unveränderbare Software könnten nie umgestellt werden. Nach dem Ende der gemeinsamen Tabelle brauchten sie eine bilaterale Quelle, ein gemeinschaftliches Repository oder lokale Pflege. Aus einem öffentlichen Fallback wurde eine eigene Abhängigkeit mit eigener Aktualisierungsfrage.

RFC 1034 hielt später die Skalierungsprobleme von HOSTS.TXT fest und beschrieb Resolver-Schnittstellen, die den alten Funktionsaufruf nachbildeten. Diese Kompatibilität erleichterte die Umstellung, verbarg aber die Herkunft der Antwort vor einer oberflächlichen Beobachtung.

RFC 1401 dokumentierte einen Briefwechsel von 1992, in dem das IAB die MILNET-Umstellung als unvollständig bezeichnete und uneinheitliche Tabellen- und DNS-Daten mit Erreichbarkeitsfehlern verband. Das ist eine politische Intervention, keine neutrale Bestandsmessung. Sie belegt dennoch die lange Wirkung des getrennten Pfads.

Quellen und Grenzen

Verwendet werden RFC 810, 811, 881, 882, 883, 897, 920, 921, 1031, 1034 und 1401. Sie belegen Spezifikationen, Zeitpläne, eine Selbstprüfung und spätere dokumentierte Aussagen. Sie belegen keinen weltweiten Stichtag, keine vollständige Standort-Compliance, keine authentifizierte Identität, keine heutige Erreichbarkeit und kein aktuelles Produktverhalten.