Zusammenfassung

  • RFC 830 ließ den verteilten Domänendienst die Adresse des Ziel-DNS/AIP finden und übergab Transport- und Anwendungsfähigkeit danach an eine getrennte AIP-Aushandlung.
  • Zwischen-DNS brauchten nur Zuordnungen unmittelbarer Unterdomänen; interne Datenformate und Caches blieben lokal, während Befehle an den Interoperabilitätsgrenzen standardisiert wurden.
  • RFC 882 und RFC 883 legten Typen, Klassen, Zonen, Autorität, Verweise, Cache und Aktualisierung in eine gemeinsame verteilte Datenbank. Der standardisierte Datensatz blieb vom laufenden Dienst verschieden.

Gleiches Gespräch, unterschiedliche Werkstatt

SINS, das System for Internet Name Service aus RFC 830, bestand aus mehreren Prozesspaaren. Eine Anwendung sprach mit ihrem Application Interface Process. Das AIP sprach mit dem lokalen DNS. DNSs lösten die Domänenhierarchie auf. Danach sprachen Quell- und Ziel-AIP über die verlangte Fähigkeit.

Für diese Grenzen definierte das Dokument eine gemeinsame Befehlsstruktur. Elemente trugen Name, Dienst, Adresse oder Kommentar. Der Befehlstyp unterschied Anfrage, positive Antwort, negative Antwort und inkompatiblen Dienst. Ein Empfänger wusste also, wie er die Nachricht lesen musste, ohne die interne Software seines Gegenübers zu kennen.

Die Datenbanken durften dagegen verschieden sein. Endpunkt-DNSs hielten Zuordnungen für die obersten Domänen. Ein Zwischen-DNS hielt die Adressen der DNSs seiner direkten Unterdomänen. Da diese Inhalte disjunkt waren, konnten Änderungen lokal bleiben. Für ihre interne Darstellung verlangte RFC 830 kein Standardformat.

Interoperabilität bedeutete damit nicht, dass alle dieselbe Datenbanksoftware betreiben. Sie bedeutete, dass alle an der gemeinsamen Kante dieselben überprüfbaren Aussagen austauschen konnten.

Die Domäne war eine Zuständigkeit, kein fertiger Dienst

RFC 819 hatte die Hierarchie als Verteilung von Namenszuständigkeit aufgebaut. Eine Domäne verantwortete Namen und Übersetzung innerhalb ihres Bereichs, ohne zwingend einer Netzwerktopologie zu entsprechen. Jeder Elternbereich vergab eindeutige Namen für seine Kinder; der Pfad bis zur Wurzel machte den vollständigen Namen absolut interpretierbar.

Unterschiedliche interne Namenswelten konnten als Domänen angeschlossen werden. Die gemeinsame Hierarchie ersetzte sie nicht. Sie schuf eine äußere Referenz und ließ die interne Komplexität beim jeweiligen Betreiber.

RFC 830 ordnete jeder Domäne logisch einen DNS zu. Mehrere Server konnten ihn redundant verwirklichen. Eine Endpunktdomäne erhielt zusätzlich ein AIP, gewöhnlich am selben Ort.

Der Domänendienst löste einen Namen bis zur Adresse dieses DNS/AIP auf. Das Ergebnis benannte den Verhandlungspunkt der zuständigen Domäne. Es war noch nicht zwingend die Adresse der verlangten Anwendung.

Der rechte Rand bestimmte die erste Anfrage

Ein vollständig qualifizierter Name bestand aus einem lokalen Namen und Domänen von spezifisch nach allgemein. Bei der Domänenauflösung begann das Quell-DNS rechts mit der obersten Domäne.

Es kannte deren DNS-Adresse und führte die Abfrage als Polling-Hub. Der oberste Server löste die nächste unmittelbare Unterdomäne. Jeder weitere Server kannte wiederum seine direkten Kinder. Er durfte die nächste Adresse zurückgeben oder einmal weiterleiten, aber nicht selbst zum Hub für den ganzen Rest werden.

Diese Regel hielt die Ablaufverantwortung bei der Quelle. Ein Zwischenserver musste weder den gesamten Namen verfolgen noch globalen Zustand aufbauen. Seine Autorität und sein Wissen endeten am unmittelbaren Delegationsrand.

Eine erfolgreiche Auflösung konnte mehrere Adressen des Ziel-DNS/AIP zurückgeben. Das bot der Quelle Auswahl bei Multihoming. Es belegte nicht, dass alle Wege gleich, erreichbar oder für den späteren Anwendungsverkehr geeignet waren.

Die Anwendung stellte die zweite Frage

Das lokale AIP erhielt vom Quellprozess Zielname und gewünschten Dienst. Nach der Domänenauflösung fragte es das Ziel-AIP, welcher Transport, welches Anwendungsprotokoll und welcher Diensttyp verfügbar und kompatibel waren.

Das Beispiel verlangte entfernte Dateiübertragung über NIFTP. Am Ziel war NIFTP nicht vorhanden, wohl aber FTP. Unterstützte auch die Quelle FTP, konnte die Aushandlung diese Alternative anbieten. Das Ziel der Handlung blieb gleich; das konkrete Protokoll wurde lokal gewählt.

Eine positive Antwort enthielt Dienst und Adresse. Im TCP-Beispiel umfasste die Adresse IP-Adresse, Protokollnummer und Port. Eine Inkompatibilitätsantwort konnte einen anderen Dienst derselben Art mit seinen Adressen liefern. Fehlte jede entsprechende Fähigkeit, blieb der Dienst leer.

Das war keine globale Optimierung. Das Ziel beschrieb sein Angebot, die Quelle entschied. Eine nachfolgende Verbindung musste die gewählte Koordinate erst prüfen. Die Aushandlung reservierte keine Kapazität und gewährte keine Berechtigung.

Live-Information war nicht automatisch stärkere Autorität

Eine aktuelle AIP-Antwort konnte näher an der laufenden Anwendung liegen als ein statischer Eintrag. Trotzdem beantwortete sie nur eine Fähigkeitsfrage. Sie identifizierte nicht den Menschen, genehmigte nicht jede Nutzung und bestätigte nicht den Erfolg der Transaktion.

Die Beweiskette blieb geteilt: Namensdelegation, Domänenauflösung, Erreichen des Endpunkt-AIP, kompatible Fähigkeit, Transportverbindung, Autorisierung und Anwendungsergebnis. Jede Stufe besaß einen anderen Verantwortlichen und eine andere Zeit.

Ein später Fehler machte den Domänennamen nicht rückwirkend falsch. Eine korrekte Adresse bewies nicht, dass das Programm lauschte. Ein offener Dienst bewies nicht, dass die konkrete Anforderung zulässig war. Diese Begrenzung verhindert, dass ein frühes Register spätere Entscheidungsgewalt übernimmt.

Der Cache blieb eine Implementierungsentscheidung

RFC 830 erkannte die Ineffizienz einer vollständigen Auflösung für jede Transaktion. Frühere Ergebnisse sollten wiederverwendet werden. Caching wurde aber nicht als Standardfunktion von SINS festgelegt, sondern dem Implementierer überlassen.

Das hielt den Anfangsvertrag schmal. Gleichzeitig fehlte eine gemeinsame Aussage über Lebensdauer, Verwerfung und Herkunft eines gespeicherten Ergebnisses. Zwei kompatible Implementierungen konnten unterschiedliche Frische zeigen.

Die Transportwahl war ebenfalls pragmatisch. Das Protokoll blieb grundsätzlich transportunabhängig, empfahl für typische kurze Vorgänge jedoch meist UDP, weil TCP Verbindungsaufbau und -pflege kostete. Die Anfrage wurde in die Antwort aufgenommen, um Zuordnung und Zuverlässigkeit zu unterstützen.

Die Komplexität verschwand nicht. Sie lag in den Endpunkt-AIPs, die gemeinsame Dienstbezeichnungen verstehen und für die Live-Aushandlung erreichbar sein mussten. Die schmale Datenbank führte zu einer dickeren Laufzeitgrenze.

Die Migration entschied sich für standardisierte Ressourcen

RFC 881 plante den Übergang von HOSTS.TXT in Stufen. Domänenförmige Namen sollten zunächst parallel erscheinen. Später ersetzte ein Resolver die bisherige Tabellenfunktion, ohne jede Anwendung umzubauen. Langfristig würde die zentrale Datei nur noch die Einstiegspunkte zu obersten Domänen enthalten.

RFC 882 und RFC 883 gaben diesem Resolver ein anderes gemeinsames Objekt. Ein Domänenname bezeichnete eine Menge von Ressourcen. Die Anfrage nannte einen Ressourcentyp; eine Klasse konnte verschiedene Protokollfamilien oder Formate unterscheiden.

Nameserver hielten autoritative Zonen und Verweise. Resolver verfolgten Fragen und speicherten Ergebnisse. Autoritative Daten stammten aus Zonen und Masterquellen. Cache-Daten stammten aus früheren Abfragen und wurden nach Zeitregeln verworfen. Herkunft und Frische wurden Teil des gemeinsamen Modells.

Auch Ressourcenformate, Abfragen, Zonenpflege und Aktualisierung erhielten Standardregeln. Die Anwendung rief den lokalen Resolver dagegen über eine Prozedur oder Betriebssystemfunktion auf; dafür brauchte es kein universelles Netzprotokoll.

Die Datenbank gewann, nicht die Allwissenheit

RFC 1034 nennt RFC 830 als eine von mehreren frühen Hierarchieideen. Die verteilte Datenbank und die generalisierten Ressourcen von RFC 882 und RFC 883 bezeichnet es dagegen als den Entwurf, der durch Implementierungserfahrung zum späteren DNS wurde.

Die gemeinsame Semantik verlagerte sich. Bei SINS war die persistente Datenbasis dünn, die Live-Aushandlung detailliert. Beim DNS wurden typisierte Ressourcen, Autorität, Cache und Aktualisierung detailliert, während Anwendungen ihre Fähigkeiten außerhalb der allgemeinen Namensauflösung aushandelten.

Das Datenbankmodell ließ sich kopieren, prüfen und für viele unbekannte Anwendungen erweitern. Es verlangte keinen universellen Anwendungsberater in jeder Domäne. Seine Antwort blieb jedoch deklarativ. Autoritativ bedeutet, dass die zuständige Zone den Datensatz veröffentlichte. Im Cache bedeutet, dass ein Resolver ihn innerhalb seiner Zeitgrenze behielt. Beides beweist weder laufende Fähigkeit noch Berechtigung oder Abschluss.

RFC 830 ist deshalb kein verlorener DNS-Standard, der einfach hätte gewinnen sollen. Es dokumentiert eine andere Platzierung der gemeinsamen Grenze. Wer heutige Systeme beurteilt, muss weiterhin sagen, ob ein Befund aus dem Register, dem Cache, der Live-Aushandlung oder der tatsächlichen Ausführung stammt.

Quellen