Zusammenfassung

  • RFC 849 unterschied die aktuelle Masterdatei des NIC von den lokalen Kopien, die an den einzelnen Standorten tatsächlich in Benutzung waren.
  • Der bevorzugte Entwurf nutzte einen einmaligen Push als schnellen Weg und Versionsprüfung, Startabfrage sowie periodisches Polling als eigenständigen Reparaturweg.

Der zentrale Eintrag ist geändert. Der Empfänger ist zu diesem Zeitpunkt ausgeschaltet. Am nächsten Morgen startet er, lädt seine vorhandene Namenstabelle und liefert weiter Antworten. Technisch funktioniert alles — nur mit dem Stand von gestern.

Der Fehler liegt nicht zwingend im Master. Er liegt in einer nicht vollendeten Zustandsänderung.

Mark Crispin beschrieb diese Lücke im Mai 1983 in RFC 849, Suggestions for Improved Host Table Distribution. Das Dokument bezeichnete keine seiner Lösungen als Standard. Es war ausdrücklich eine Bitte um Stellungnahmen, aus denen später Konsens und womöglich eine Norm entstehen sollten. Sein historischer Wert besteht deshalb nicht im Nachweis einer Implementierung. Er besteht in der frühen, präzisen Trennung der Behauptungen, die sich hinter „aktualisiert“ verbergen.

Eine Quelle erzeugte noch keinen gemeinsamen Stand

RFC 608 hatte für das NIC eine gepflegte Quelldatei vorgesehen. Aus ihr sollte regelmäßig — wöchentlich oder bei Bedarf — eine aktuelle ASCII-Datei mit Rechnernamen, Adressen und Attributen erzeugt werden. <NETINFO>HOSTS.TXT war per FTP abrufbar.

Die gemeinsame Quelle beantwortete die Frage, welches Dokument das NIC veröffentlichte. Sie beantwortete nicht, wann jeder Standort dieses Dokument übernahm.

RFC 810 erweiterte 1982 das Format für das DoD Internet. Die Tabelle enthielt Netze, Gateways, Hosts, Betriebssysteme und ausgewählte Protokollangaben. Sie ließ sich anonym per FTP von SRI-NIC oder über den Host Name Server beziehen. Zugleich musste jeder Nutzer sie in das für seinen Zweck notwendige lokale Format übersetzen.

Damit gab es mindestens vier Zustände: die veröffentlichte Datei, die empfangenen Bytes, das lokal umgewandelte Datenobjekt und den vom Resolver tatsächlich gelesenen Bestand. Die erfolgreiche Übertragung bewies nicht die erfolgreiche Aktivierung.

RFC 811 bot auf TCP-Port 101 einen laufenden Abfragedienst. HNAME suchte nach einem Namen, HADDR nach einer Adresse, und ALL lieferte die gesamte Tabelle zwischen BEGIN und END. Der Dienst erleichterte den Zugriff auf die Daten des NIC. Eine günstige Aussage darüber, ob eine bereits installierte Kopie dieselbe Ausgabe war, fehlte weiterhin.

Ohne Versionsidentität blieb nur Raten oder Übertragen

Crispin begründete die lokalen Kopien mit der Verfügbarkeit. SRI-NIC sei nicht zuverlässig genug, um als alleiniger, stets erreichbarer Namensdienst zu dienen. Zwar konnte das NIC das gesamte Register ausgeben und bot anonymes FTP an. Doch jemand musste wissen, wann eine neuere Ausgabe abzuholen war; Aktualisierungen waren nach seiner Erfahrung nicht immer sorgfältig angekündigt worden.

So entstanden zwei gegenläufige Fehler. Ein Standort konnte unbemerkt bei einer alten Tabelle bleiben. Oder er konnte dieselbe Ausgabe erneut übertragen, weil eine automatische Gegenprüfung fehlte. Im ersten Fall ging Aktualität verloren, im zweiten Netz- und Rechenaufwand.

Der zweite Vorschlag von RFC 849 war daher ein Protokoll, das die aktuelle „Version“ der Hosttabelle meldete. Für Tenex und TOPS-20 bot sich die Dateigenerationsnummer an. Crispin hielt bereits eine lokale SYSTEM:HOSTS.TXT mit derselben Generation wie beim NIC und prüfte gelegentlich, ob sich die entfernte Nummer geändert hatte. Diese Prüfung sollte automatisiert werden.

Eine Generationsnummer bestätigt nicht die Richtigkeit jeder Zeile. Sie bestätigt weder Umwandlung noch Aktivierung. Sie sagt lediglich, ob zwei Dateien derselben Ausgabe angehören.

Gerade diese schmale Aussage spart Arbeit. Bei unveränderter Nummer ist kein Volltransfer nötig. Bei abweichender Nummer ist der Rückstand sichtbar, bevor ein fehlerhafter Name zum ersten Symptom wird. Erst die Beobachtung, dann die teure Bewegung der Daten.

Vollständiger Push verlangte ein zweites Register

Der erste Vorschlag setzte auf Zustellung vom NIC aus. An jedem teilnehmenden Standort sollte ein Serverprozess auf einem registrierten Port Aktualisierungen bestimmter „trusted“ Stellen, insbesondere SRI-NIC, annehmen. War der Zielrechner in Betrieb, ließ sich beinahe sofort aktualisieren.

Bei einem ausgeschalteten Ziel kehrte sich der Vorteil um. Sollte reiner Push vollständig sein, musste das NIC sich nicht erreichbare Hosts merken und später erneut versuchen. Neben der Namenstabelle entstand ein bewegliches Zustellregister: Empfänger, Versuche, Ausfälle und offene Wiederholungen. Mit jedem Teilnehmer wuchs die zentrale Verantwortung für lokale Abwesenheit.

RFC 849 schlug außerdem eine Prüfsumme vor, um festzustellen, ob das aktualisierte Register vollständig und unversehrt angekommen war. Mehr darf daraus nicht gemacht werden. Das Memo spezifizierte keine kryptografische Absenderauthentisierung, keinen Schutz gegen böswilligen Austausch und keine semantische Prüfung der Einträge. Transportintegrität, Herkunft, inhaltliche Richtigkeit und lokale Nutzung blieben getrennte Aussagen.

E-Mail verschob die Datei, nicht den aktiven Zustand

Ein dritter Weg hätte die aktualisierte Tabelle an eine Empfängerliste geschickt und die örtlichen Verfahren den Standorten überlassen. Für das NIC war das einfach. RFC 849 hielt E-Mail jedoch für ungeeignet, eine wachsende Datei massenhaft an viele Empfänger zu liefern.

Auch nach der Annahme einer Nachricht blieb Arbeit übrig: Warteschlange, Postfach, Extraktion, Konvertierung und Umschaltung. Ein Mailserver konnte „zugestellt“ melden, während der Namensdienst weiterhin die alte Datenbasis las.

Der vierte Vorschlag teilte den glücklichen und den gestörten Pfad

Crispins bevorzugte Lösung kombinierte Push und Versionsabfrage. Das NIC würde die neue Ausgabe einmal an registrierte Hosts senden und keine unbegrenzte Wiederholungsverpflichtung führen. Jeder Standort sollte beim Systemstart das NIC nach einer möglichen Aktualisierung fragen und sie bei Bedarf holen. Zusätzlich konnte eine regelmäßige Prüfung, etwa täglich, als Reserve dienen.

Der Push war der schnelle Pfad für erreichbare Rechner. Die Startabfrage reparierte den Fall, in dem ein Rechner während der Zustellung ausgeschaltet gewesen war. Das periodische Polling erfasste Systeme, die weder den Push bekommen hatten noch neu gestartet worden waren. Die Versionsnummer sorgte dafür, dass Reparatur nicht mit blindem Volltransfer gleichgesetzt wurde.

Die Aufgabenteilung war entscheidend. Das NIC musste nicht dauerhaft die Verfügbarkeitsgeschichte jedes Empfängers führen. Der Standort, der seinen installierten Zustand am besten beobachten konnte, erhielt einen eigenen Weg zur Wiederherstellung.

Sofortige Konvergenz war damit nicht garantiert. Das NIC konnte beim Start nicht erreichbar sein, die Übertragung abbrechen, die Prüfsumme abweichen, die Konvertierung scheitern oder der alte Bestand aktiv bleiben. Der Entwurf machte diese Fälle jedoch unterscheidbar. Jeder hatte eine beobachtbare Grenze und eine nächste Handlung; keiner verschwand hinter dem Status „Master aktualisiert“.

Verteilung beseitigte die Zeit nicht

RFC 881 stellte im November 1983 noch fest, dass nahezu alle Hosts irgendeine Tabelle auf Grundlage der Masterdatei HOSTS.TXT des NIC verwendeten. Der Plan für Domainnamen sah eine Übergangszeit mit parallelen Verfahren vor.

RFC 882 erklärte anschließend, Größe und insbesondere Änderungsfrequenz der globalen Tabelle näherten sich der Grenze des Beherrschbaren. Eine verteilte Datenbank wurde benötigt. RFC 883 verteilte den Namensraum auf Server, trennte autoritative Zonendaten von Cache-Daten und beschrieb periodische Aktualisierung. Eine Änderung am Master aktualisiere Kopien nicht augenblicklich, sondern sickere allmählich durch das verteilte System.

Das macht RFC 849 nicht zu einer implementierten Vorstufe des DNS. Seine Vorschläge waren keine Standards, und das Domainsystem entwarf Delegation, Abfrage und Wartung in größerem Maßstab. Gemeinsam ist ihnen nur die nüchterne Einsicht: Wo Kopien existieren, existieren Version, Alter, Aktualisierungsregel und ein Verhalten für fehlgeschlagene Erneuerung.

Maßgeblich ist der letzte vollendete Übergang

Ein autoritatives Register kann die heute anerkannte Zuordnung von Name und Adresse beschreiben. Mit dieser Beschreibung aktualisiert es keinen ausgeschalteten Rechner. Eine Benachrichtigung führt keine Konvertierung aus. Eine Prüfsumme aktiviert keine Datenbank. Eine Generationsnummer ändert nicht den vom Resolver geöffneten Bestand.

RFC 849 liefert deshalb eine Beweisfolge: Masterausgabe, Zustellversuch, empfangene Bytes, akzeptierte Integrität, vollendete Umwandlung, beobachteter Aktivstand und unabhängige Wiederherstellung. Jede Stufe trägt eine andere Behauptung.

Am Übergang von der zentralen Hosttabelle zum verteilten Namensdienst wurde damit eine dauerhafte Grenze sichtbar. Veröffentlichung ist ein Ereignis an der Quelle. Aktualität ist ein geprüfter Zustand beim Verbraucher. Die Masterdatei konnte schon in der Gegenwart sein, während das Netz noch aus der Vergangenheit las.

Quellen