Zusammenfassung

  • draft-ranjbar-regext-rdap-subordinate-referrals-01 schlägt Richtungsrelationen vor, über die ein vom Inhaber bestimmter RDAP-Dienst für untergeordnete Namen, Netze oder Adressen gefunden wird.
  • Die Downstream-Daten behauptet der Inhaber, nicht der Registerbetreiber. Strikte Unterordnung, Rücklink und Ein-Hop-Grenze beschränken die Aussage; zugleich sieht der Inhaber die eintreffenden Abfragen.
  • Ein Client sollte eine Hoheitsnaht bewahren: Deckungsobjekt des Registers, Bestimmungsakt und untergeordnete Antwort des Inhabers bleiben getrennte Belege.

Der übliche RDAP-Weg beginnt bei den IANA-Bootstrapdaten. Er führt zum zuständigen Dienst für eine Top-Level-Domain oder einen Nummernressourcenbereich und von dort zum spezifischsten Objekt, das dieser Betreiber hält. Das sieht nach einer geschlossenen Autoritätskette aus.

Die Kette endet jedoch absichtlich. Ein Domain-Register kann die registrierte Domain führen, ohne jeden dynamisch erzeugten Namen darunter zu speichern. Ein RIR kann eine überdeckende Zuteilung oder aggregierte Zuweisung halten, ohne jedes spezifischere Netz oder jede einzelne Adresse zu erfassen, die der Inhaber intern vergibt. Feindaten liegen im System, das sie erzeugt und ändert.

Der individuelle Entwurf will diese nächste Quelle auffindbar machen. Der Ressourceninhaber bestimmt einen eigenen oder beauftragten RDAP-Server. Die Registerantwort weist nach unten, die Inhaberantwort hält den Weg zum überdeckenden Register offen. Volatile Daten müssen nicht zentralisiert werden, dennoch kann der Client sie finden.

Der Governancefehler entsteht, wenn die Oberfläche den Übergang entfernt.

Abwärtsrichtung vererbt keine Registerstellung

Revision 01 nennt rdap-base-down für die Basis-URL des nachgelagerten Dienstes und rdap-base-up für die Rückrichtung zur Basis-URL des überdeckenden Registers. Die Namen beschreiben eine Richtung zwischen Diensten. Sie erheben den Downstream-Betreiber nicht zum Register.

Der Geltungsbereich ist streng. Ein bestimmter Server ist nur für Ressourcen eine mögliche Quelle, die vollständig unter dem verweisenden Objekt liegen. Das Ziel muss HTTPS nutzen. Ein Client darf ihm keine Hoheit über Geschwister, Eltern oder fremde Ressourcen zuschreiben. Der Rücklink bewahrt die Navigation, die Zahl der Inhaber-Verweise wird begrenzt; für die beschriebenen Fälle reicht ein Hop.

Damit bleiben zwei Aussagen. Das Register sagt: Dieser Inhaber hat für diesen Bereich diesen Dienst bestimmt. Der Inhaber sagt anschließend: Diesen untergeordneten Datensatz führe ich. Wer beides als „Registerdaten“ ausgibt, macht aus der Bestimmung eine inhaltliche Billigung.

Kompatibilität kann den Sprecherwechsel verbergen

Der Vorschlag lässt alte Clients weiterarbeiten. Ist ein Zeiger registriert, soll der Registerserver die Abfrage nach einer untergeordneten Ressource weiterhin zum bestimmten Dienst umleiten. Ein unveränderter Client erhält den spezifischsten Datensatz, ohne die neue Relation zu verstehen. Ein fähiger Client entdeckt den Link bewusst. Wer zusätzlich den Registerdatensatz will, kann die im Begleitentwurf diskutierte Unterdrückung der Umleitung verwenden.

Das ist praktisch, doch HTTP-Umleitungen sind visuell leise und werden oft automatisch verfolgt. Die Endansicht verrät nicht zwingend, dass Betreiber, Verfügbarkeit, Datenschutzwirkung und Beweisqualität gewechselt haben.

draft-ietf-regext-rdap-referrals-04 definiert eine ausdrückliche Umleitungsanfrage zu einer verknüpften RDAP-Ressource. Existiert genau ein geeigneter Link und ist der Client berechtigt, antwortet der Server mit einem HTTP-Redirect und Location. Relationsauswahl, Aushandlung, Caching und Mehrfachsprünge werden behandelt. Das spart den Abruf eines ganzen Datensatzes nur zum Extrahieren eines Links, bestimmt aber nicht die öffentliche Zuschreibung der Zielantwort.

Der Inhaber wird Herausgeber und Beobachter

Der Sicherheitsabschnitt ist eindeutig: Die Daten des bestimmten Servers werden vom Inhaber behauptet, nicht vom Registerbetreiber. Diese Herkunft entscheidet, wer korrigiert, wer Kontinuität schuldet, wer für Abweichungen einsteht und welche Quelle in einem Streit zitiert werden kann.

Mit der Abfrage erreicht auch das Nutzerinteresse die Infrastruktur des Inhabers. Der Entwurf vergleicht diese Sichtbarkeit mit der eines DNS-Betreibers für seine Zonen. Clients mit Vertraulichkeitsbedarf können den Verweis ablehnen. Diese Wahl ist nur real, wenn Software sie vor der Umleitung zeigt und den überdeckenden Registerdatensatz erreichbar lässt.

Auch Verfügbarkeit teilt sich. Fällt der Inhaberdienst aus, verschwinden die zusätzlichen Unterdaten; die eigenen Registerantworten bleiben bestehen. „RDAP nicht verfügbar“ verwischt den Unterschied zwischen Registerausfall, defekter Bestimmung und Downstream-Ausfall.

Die Bestimmung ist das ungeregelte Machtgelenk

Wie der Inhaber seinen Server dem Register mitteilt, liegt außerhalb des Entwurfs. Ein Portal oder eine spätere EPP-Erweiterung sind Beispiele. Für ein fokussiertes RDAP-Dokument ist das verständlich; verwaltungspolitisch liegt dort jedoch die Befugnis, Abfragen umzulenken.

Wer darf den Zeiger setzen, ändern oder widerrufen? Darf ein Dienstleister, der den Server betreibt, auch das Ziel ändern? Wann wird eine Änderung wirksam? Löscht der Transfer der Domain oder Nummernressource die alte Bestimmung automatisch? Welcher Nachweis bleibt nach Fehlkonfiguration oder Kontenübernahme?

Register sollen prüfen, ob das Ziel für die Ressourcen des Inhabers konformes RDAP liefert. Konformität ist keine Inhaberschaft. Ein Server kann korrektes JSON über ein Objekt ausgeben, das er nicht kontrolliert. Nötig sind authentisierte Einrichtung, Bereichsnachweis, Zielprüfung, Aktivierung, Erneuerung, Änderung, Widerruf und Transferbereinigung.

Die Hoheitsnaht beim Abruf sichern

Ich schlage für jeden verfolgten Verweis einen Hoheitsnaht-Nachweis vor. Er gehört nicht zum Entwurf. Er verhindert, dass Auffindbarkeit zur stillen Bestätigung wird.

Die erste Schicht hält Bootstrapweg, Deckungsobjekt, Registerdienst, Relation, Ziel, bestimmende Person und Kanal, Aktivierung, Bereich und letzte Konformitätsprüfung fest. Nicht verfügbare Angaben bleiben unbekannt.

Die zweite Schicht beschreibt den Übergang: Abfragepfad, gewöhnliche Umleitung oder ausdrückliche Relation, HTTP-Status, Unterdrückungswahl, Ziel-URL, TLS-Ergebnis, Abrufzeit und Hopzahl. Sie hält auch fest, ob die Sichtbarkeit für den Inhaber vorab erklärt wurde.

Die dritte Schicht speichert die Inhaberaussage getrennt: antwortender Dienst, untergeordnetes Objekt, Zeitpunkt, Konformitätsmerkmale, Cachefrist und Rücklink. Eine Oberfläche kann das Detail als „vom Inhaber behauptet“ neben dem Registerobjekt zeigen.

Bei Downstream-Ausfall bleibt das Deckungsobjekt erhalten und die fehlerhafte Schicht wird benannt. Nach Widerruf oder Inhaberwechsel laufen gecachte Aussagen aus. Eine Antwort außerhalb der strikten Unterordnung wird verworfen, nicht durch den Link legitimiert.

Die Relationen sind allgemein benannt, damit sie auch delegiertes oder hybrides RPKI und die Modernisierung von RWhois oder SWIP unterstützen können. Das spart Vokabular, doch „nachgelagert“ bezeichnet Topologie, nicht Rechtsmandat, Qualität oder Servicegarantie.

Revision 01 ist ein individueller Internet-Draft vom 21. Juli 2026. Datatracker nennt keine formale IETF-Stellung, keinen Stream und keinen vorgesehenen RFC-Status, während der Kopf Standards Track sagt. Der Autor bevorzugt die Aufnahme in den REGEXT-Entwurf zu Verweisen. Der Implementierungsabschnitt berichtet einen Inhaberdienst und bezeichnet den Registerverweis als fehlenden Hop. Das ist kein Beweis breiter Einführung.

Untergeordnete Daten brauchen einen auffindbaren Weg. Sie brauchen keine geliehene Registerhoheit. Gute Clients verlängern die Suche und zeigen exakt, wo der Sprecher wechselt.

Quellen