Zusammenfassung

  • RFC 3375 beschrieb ein gemeinsames Registrierungssystem: Mehrere Registrare konnten gesponserte Objekte verwalten, doch für einen bestimmten Namensraum und eine Zone blieb genau eine Registry autoritativ.
  • Objektidentität, Sponsoring, Verknüpfung mit gemeinsam genutzten Ressourcen, Transfer, Transaktionsstatus und DNS-Veröffentlichung waren getrennte Tatsachen. Der Erfolg auf einer Ebene belegte nicht automatisch die nächste.

Für einen Domaininhaber wirkt die Registrierung wie ein Geschäft mit einem einzigen Unternehmen. Er wählt einen Registrar, übermittelt Angaben und erhält eine Bestätigung. Der Registrar muss den Auftrag jedoch an eine Registry weiterreichen, die das zentrale Repository für Delegationen führt. Erst später wird ein Teil dieses Bestands in eine DNS-Zone projiziert. Die Dienstleistung erscheint einheitlich, ihre Befugnisse sind es nicht.

RFC 3375 wurde im September 2002 als Informational veröffentlicht. Das Dokument war weder Internet Standard noch Bericht über tatsächliche Einführung. Es formulierte Anforderungen an ein allgemeines Registry-Registrar-Protokoll, das verschiedene Betriebsmodelle tragen sollte, als gemeinsame Registrierung zur Infrastruktur wurde.

Die Rollen waren bewusst getrennt. Der Registrant beantragte Namen über einen Registrar. Der Registrar bot die öffentliche Schnittstelle und griff auf die Registry zu. Die Registry verwaltete das zentrale Repository für Delegationen und war typischerweise für Erzeugung und Verteilung der Zonendateien zuständig. In einem Shared Registration System nutzten mehrere unabhängige Registrare denselben Registry-Dienst in loser Kopplung.

Wettbewerb am Kundenzugang teilte die technische Letztinstanz nicht auf. Für einen gegebenen Namensraum und eine Zone, so RFC 3375, gab es genau eine autoritative Registry; eine Registry konnte allerdings mehrere Namensräume bedienen. Ein Registrar erhielt Verwaltungsrechte an den von ihm gesponserten Objekten, aber keine Souveränität über den Namensraum.

Das Protokoll sollte Sitzungen, Abfragen, Anlage, Änderung, Verlängerung, Löschung und Transfer abdecken. Es musste Clients und Server identifizieren und authentisieren, Berechtigungen prüfen und Zustände melden. Verändernde Operationen erhielten eine innerhalb der Registry eindeutige Transaktionskennung. Sie machte einen Vorgang nachvollziehbar, bewies aber weder den Willen des Registranten noch die Erzeugung einer Zone, deren Laden auf autoritativen Servern oder die Beobachtung durch einen entfernten Resolver.

Objekte brauchten eine Identität, die ihre jeweilige Verwaltung überdauerte. Ihre Kennungen sollten weltweit eindeutig sein und während der Lebenszeit im Repository unverändert bleiben, selbst wenn die administrative Kontrolle wechselte. Ein Domaintransfer änderte daher den sponsernden Registrar, ohne die historische Identität des Objekts zu ersetzen. Gerade diese Kontinuität machte den Übergang prüfbar.

Gemeinsam genutzte Ressourcen zeigten eine weitere Grenze. Ein Nameserver-Objekt unter Verwaltung von Registrar X konnte zugleich einer von Registrar Y gesponserten Domain dienen. Y musste den vorhandenen Server mit seiner Domain verknüpfen können, ohne dadurch Änderungsrechte am Server zu bekommen. Eine Referenz bedeutete Abhängigkeit, nicht Kontrolle. Andernfalls könnte ein indirekter Nutzer alle anderen abhängigen Domains gefährden.

Der Transfer war deshalb ein autorisierter Prozess. Der Registrar, der neuer Verwalter werden wollte, leitete ihn ein. Das System sollte die Berechtigung bestätigen, den Status zeigen, mitübertragene Objekte beschreiben, einen Abbruch vor der Entscheidung zulassen und Annahme oder Ablehnung melden. Innerhalb der Domain registrierte Nameserver konnten mitwandern; diese Folge musste sichtbar sein.

RFC 3375 ließ sowohl Thick als auch Thin Registries zu. Im Thick-Modell lagen technische Delegationsdaten und soziale Angaben wie Kontakte bei der Registry. Im Thin-Modell blieb ein Teil bei den Registraren. Die allgemeinen Anforderungen sollten beiden Modellen gemeinsame Handlungen geben, nicht eine einzige Datenbankarchitektur erzwingen.

Besonders leicht verschwimmt die Grenze zum DNS. RFC 1034 und RFC 1035 beschreiben Zonen, autoritative Server, Caches und Auflösung. RFC 2136 definiert einen Weg zur dynamischen Aktualisierung einer Zone. RFC 3375 behandelt Registry-Objekte und die Erzeugung von Zonendateien. Eine Verlängerung oder Kontaktänderung kann erfolgreich sein, ohne DNS zu verändern. Eine Delegationsänderung kann angenommen sein und dennoch auf Projektion, Verteilung, Laden und Cache-Ablauf warten.

RFC 2832 hatte zuvor das Registry Registrar Protocol spezifiziert. Danach definierte RFC 3730 EPP; RFC 5730 ersetzte später die Basisspezifikation, und RFC 5731, RFC 5732 sowie RFC 5733 beschrieben Abbildungen für Domains, Hosts und Kontakte. Die Folge zeigt technische Verfeinerung. Sie beweist weder vollständige weltweite Implementierung noch eine einheitliche Betriebsdauer bis zur Sichtbarkeit.

Auch die normativen Wörter aus RFC 2119 müssen eng gelesen werden. MUST bezeichnet eine Anforderung an das entworfene Protokoll und kein Zertifikat über die Außenwelt. Die Internationalisierungspolitik aus RFC 2277 erinnert daran, dass Zeichen, menschliche Sprache, Kontaktdaten und DNS-Bezeichner verwandte, aber verschiedene Probleme waren.

Lu Hengs Gedanke einer „Minimum Initial Specification“ erklärt die institutionelle Ökonomie: Gemeinsam festgelegt wird nur, was für Zusammenarbeit nötig ist; spätere Entscheidungen bleiben beim verantwortlichen Kontext. Sein Modell der Realitätsebenen schärft die Prüfung. Auftrag des Registranten, Autorisierung des Registrars, Sponsoring, Registry-Annahme, Repository-Zustand, Zonenerzeugung, autoritativer Dienst und Resolver-Beobachtung bilden eine Kette, aber keine austauschbare Tatsache.

Das bleibende Erbe von RFC 3375 ist diese produktive Trennung. Ein Markt konnte viele Verkaufspunkte haben und dennoch einen kohärenten autoritativen Namensraum bewahren. Ein Objekt konnte den Verwalter wechseln, ohne seine Identität zu verlieren. Eine Ressource konnte von mehreren Parteien genutzt werden, ohne allen Nutzern zu gehören. Skalierung entstand aus präzisen Grenzen; belastbare Belege müssen sie ebenso präzise einhalten.

Quellen