Zusammenfassung

  • RFC 1279 bildete Domains in X.500 ab, hielt aber Domain und Organisation sowie Mailbox und Person als verschiedene Objekte auseinander. Deshalb war ein Alias keine geeignete Verbindung.
  • AssociatedDomain und AssociatedName hielten gerichtete Beziehungen fest. Domain-Einträge sollten schlank bleiben und auf Organisationsdaten verweisen, statt sie zu duplizieren; die Zuordnung konnte n:m sein.
  • Ein Zone-Transfer durfte DNS Records in einen DSA schreiben, nicht aber benachbarte Nicht-DNS-Attribute verändern. Quelle, Transfer, Annahme, Erhaltung, Link, Abfrage und Wirkung blieben getrennte Nachweise.

Zwei Namensräume, zwei Gegenstände

RFC 1279, X.500 and Domains, erschien im November 1991 als Experimental-Dokument. Es schlug vor, die DNS-Hierarchie in einem X.500 Directory Information Tree abzubilden, damit Directory-Werkzeuge Domains, Mailboxes, Manager und verwandte Informationen auffinden konnten.

Das Dokument erklärte diese Möglichkeit nicht zum vollzogenen Wechsel. Anfangs würden Daten wahrscheinlich weiter in Domain Databases geführt und in den DIT übertragen. Erst nach Werkzeugen, wiederholten Transfers, Link-Ergänzung, Verteilung und Leistungsvergleich erwog der Anhang, einzelne DNS-Bereiche im DIT zu führen.

Ein Plan ist kein Betriebsnachweis. Eine Übertragung ist keine neue Zuständigkeit, und eine beschriebene Endstufe ist kein Beleg ihrer Umsetzung.

Im DNS-förmigen Zweig wurde jedes Label als DomainComponent dargestellt. Der lokale Teil einer RFC-822-Mailbox konnte den Zweig fortsetzen. In einem anderen Zweig standen Organisationen, Einheiten, Personen und Rollen.

Ähnliche Namen machten die Objekte nicht identisch. Eine Domain bezeichnete eine Stelle im technischen Namensraum; eine Organisation besaß eigene Attribute. Eine Mailbox war ein Zustellziel, nicht die Person dahinter.

Darum lehnte RFC 1279 Aliasing für diese Verbindung ab. Ein Alias verspricht einen anderen Namen für dasselbe Objekt. Benötigt wurde dagegen eine Relation zwischen verschiedenen Objekten.

Die Richtung gehörte zur Aussage

AssociatedDomain führte vom Organisationseintrag zur Domain. AssociatedName führte vom Domain-Eintrag in den organisatorischen DIT.

Beide Richtungen waren eigenständige Aussagen. Ihre Autoren und Zeitpunkte konnten abweichen. Ein fehlender Rückverweis blieb sichtbar, statt von der Oberfläche als vermeintliche Symmetrie ergänzt zu werden.

Auch 1:1 war nicht garantiert. Eine Domain konnte zu mehreren Organisationen gehören; eine Organisation konnte mehrere Domains haben. Ein einziges Owner-Feld hätte diese Vielfalt gelöscht.

Der Verweis bewies weder rechtliches Eigentum noch Authentisierung oder Berechtigung. Eine verknüpfte Organisation musste nicht jeden Dienst der Domain betreiben. Die Verbindung zwischen Mailbox und Person bestätigte nicht den Absender einer Nachricht.

Eine belastbare Relation behält Prädikat, Richtung, Quelle und Gültigkeitszeit. Ohne diese Angaben wird Nähe erst zur Identität und scheinbare Identität anschließend zur Autorität.

Nicht kopieren hieß Zuständigkeit erhalten

Domain-eigene Daten durften im Domain-Eintrag liegen, darunter DNS Records. Wenn die organisatorische Seite die relevante Information bereits besaß, sollte der Domain-Eintrag jedoch relativ schlank bleiben und dorthin zeigen. Duplizierung wurde ausdrücklich vermieden.

Zwei Kontaktkopien benötigen zwei Aktualisierungen. Nach einem Personalwechsel kann die Organisationsseite stimmen, während die alte Domain-Kopie weiterhin plausibel aussieht. Keine Syntaxprüfung entscheidet, welcher Wert das Mandat für die Gegenwart hat.

Viele Kopien erzeugen zudem falsche Bestätigung. Derselbe veraltete Kontakt in zehn Domains bleibt eine einzige alte Behauptung, nicht zehn unabhängige Quellen.

Ein Pointer bewahrt die Aufgabenverteilung. Die Organisation pflegt ihre beschreibenden Attribute; die Domain pflegt die Beziehung. Eine Ansicht darf beide kombinieren, ohne ihre Herkunft umzuschreiben.

Fehler lassen sich begrenzt korrigieren. Ein falscher Link wird geändert, ohne die Organisation neu anzulegen. Ein neuer Kontakt wird an seiner Quelle eingetragen, ohne sämtliche Domains zu durchsuchen.

Ein TTL-Feld war noch keine DNS-Zeit

RFC 1279 wählte eine Textdarstellung für DNS Resource Records im DIT. Namen mussten vollständig sein, jeder Record musste eine TTL tragen. Ein gemeinsames DNSRecord-Attribut blieb für neue Typen offen.

Die Information sollte DNS-äquivalent sein, damit sie in beide Richtungen transportiert werden konnte. Zugleich emulierte das OSI Directory weder DNS Caching noch TTL Handling. Master Entries sollten durch Zone Transfer oder einen gleichwertigen Vorgang gepflegt werden.

RFC 1035 gab der TTL eine Laufzeit im Cache. Autoritative Zone-Daten, Cache-Daten, Refresh und Expiry haben unterschiedliche Rollen. Das Kopieren einer Zahl nach X.500 setzt nicht dieselbe Uhr in Gang.

Für Aktualität braucht man Source Zone, Serial, Transferabschluss, empfangene Menge, Annahmezeit des DSA, spätere Refreshes und die konkrete Abfrage. Eine verbliebene TTL-Zeichenfolge kann ihre operative Grundlage überleben.

Das Transferwerkzeug besaß nur seine Record-Familie

Der Anhang beschrieb ein Werkzeug zwischen DNS Server und DSA. Beim Schreiben in den DSA sollten alle Attribute, die keine DNS Records waren, unverändert bleiben.

Damit war die Befugnis eng begrenzt. Der Transport durfte DNS-Daten aktualisieren, nicht Manager, Telefonnummern, Organisationsbeschreibung oder Beziehungspointer im selben Eintrag.

Eine DSA-Verbindung beweist keinen fertigen Transfer. Dessen Abschluss beweist nicht die Annahme jedes Records. Ein erfolgreicher DNS-Write beweist die Unverändertheit der Nachbarfelder nur mit Vorher-Nachher-Beobachtung. Eine spätere Abfrage beweist keine Nutzerhandlung.

Ein belastbares Protokoll trennt Zone-Zustand, Request, empfangene Menge, akzeptierten Write, geschützte Attribute, Links, Query Response und Folgehandlung. „Synchronisiert“ allein beantwortet keine dieser Fragen.

Experiment blieb Experiment

RFC 1279 listete User Tool, Library, Zone-Transfer-, Link-Patching- und DNS-Manager-Werkzeug, Mailbox Download sowie einen emulierten DNS Server. Die Abfolge sollte Nutzen und Leistung prüfen. Sie berichtete nicht, dass alle Komponenten liefen, Links vollständig waren oder DNS ersetzt wurde.

RFC 1309 erläuterte später allgemein, wie X.500 Entries Objekte beschreiben und Organisationen lokale Daten in verteilten DSAs führen können. Dieser Kontext ergänzt das Objektmodell, liefert aber kein fehlendes Deployment-Ergebnis.

Auch Sicherheit blieb begrenzt: RFC 1279 behandelte sie nicht direkt und nannte nur die Möglichkeit sichererer Verwaltung. Ein möglicher Vorteil ist kein beobachteter Authentisierungsnachweis.

Quellen und Grenzen

RFC 1279 belegt Domain-Abbildung, Alias-Ablehnung, Links, Nicht-Duplizierung, Transfergrenze und Experiment. RFC 1274 bestätigt die zugehörigen Attribute und Domain-Klassen. RFC 1035 liefert nur DNS-TTL- und Zone-Kontext. RFC 1309 liefert nur das allgemeine X.500-Modell verteilter lokaler Datenpflege.

Keine Quelle beweist benanntes Deployment, Eigentum, authentisierte Identität, abgeschlossenen Transfer, aktuelle Daten, erfolgreiche Abfrage, Sicherheitswirkung oder Nutzerhandlung.