Zusammenfassung

  • Der REGEXT-Entwurf zu RDAP-Erweiterungen untersagt es einem Server, Anfrageparameter ungeprüft in eine Redirect-URL zu kopieren. Er darf sie nur weitergeben, wenn er die Verarbeitungsfähigkeit des Ziels und dessen Eignung als Empfänger des Inhalts kennt.
  • Eine Erweiterung für die Suche nach dem zuständigen Server über Zuständigkeitsgrenzen hinweg darf nicht darauf bauen, dass ein Query-Parameter jeden Redirect übersteht. Bei einer direkten Suche gegen einen bekannten zuständigen Server kann ein Parameter sinnvoll sein.

Der Datensatz ist da, der Zusatzauftrag fehlt

Ein Client fragt nach einer Internetnummer und hängt einen Erweiterungsparameter für zusätzliche Angaben an. Der erste RDAP-Server verweist per HTTP-Redirect auf einen anderen zuständigen Anbieter. Dort kommt der Grunddatensatz an; die gewünschten Zusatzangaben können fehlen. Das ist ein Entwurfsfall, kein Bericht über einen nachgewiesenen Vorfall. Eine Weiterleitung bestimmt das Ziel der Anfrage. Sie berechtigt den ersten Server nicht automatisch, jedes Detail des ursprünglichen Auftrags an dieses Ziel zu senden.

RFC 9224 beschreibt die Suche nach zuständigen RDAP-Diensten mithilfe der IANA-Zuteilungsregister. Der REGEXT-Entwurf nennt die Lücke dieser Karte: Spätere Transfers von Ressourcen zwischen regionalen Registern werden durch die ursprünglichen Zuteilungen nicht erfasst. Redirects sind deshalb bei der Suche nach dem tatsächlich zuständigen RIR wichtig. Die Entscheidung über Parameter fällt mitten in einem regulären Weg zur richtigen Auskunftsstelle.

RFC 7480 verpflichtet Server, unbekannte Query-Parameter zu ignorieren. Der Erweiterungsentwurf verlangt vom Server, der den Redirect ausstellt, mehr. Er darf Parameter nicht blind in die neue URL übernehmen. Sie können Zugangsdaten oder Trackinginformationen enthalten, mit denen der Zielserver nichts zu tun hat. Weitergabe setzt voraus, dass das Ziel den Parameter verarbeiten kann und für dessen Inhalt ein geeigneter Empfänger ist. Technische Lesbarkeit ist keine Empfangsberechtigung.

Der Interessenkonflikt lässt sich hinter einer erfolgreichen HTTP-Antwort verstecken. Der erste Server kann einen Parameter aus gutem Grund zurückhalten; der Client erhält dennoch einen gültigen Grunddatensatz. Ein Dashboard mit einem grünen Häkchen verschweigt, dass die zusätzlich bestellte Ansicht fehlt. Werden dagegen alle Parameter zur Rettung der Funktion weitergereicht, können Werte eine Organisation erreichen, für die sie nie bestimmt waren. Beide Ergebnisse passen in dieselbe Kennzahl „Anfrage erfolgreich“.

Direkte Suche und Zuständigkeitssuche sind verschiedene Wege

Der Entwurf erlaubt Query-Parameter, wenn der Client den zuständigen Server bereits kennt und ihn direkt befragt. Als Beispiel nennt er die Suche. Eine Erweiterung, die auch beim Auffinden des zuständigen Servers funktionieren soll, muss strenger gebaut sein: Bei einem Redirect zwischen verschiedenen Zuständigkeiten ist die Ankunft des Parameters nicht garantiert. Was für das Verständnis der Ressource unerlässlich ist, gehört daher nicht allein an dieses abtrennbare Ende der URL.

Man könnte den Client anweisen, Redirect-Inhalte zu lesen und die Anfrage selbst neu zusammenzusetzen. Auch dafür nennt der Entwurf konkrete Kosten. Manche browserbasierten Clients können auf RDAP-Inhalte im Redirect nicht zugreifen. Andere müssten Schleifen erkennen, konkurrierende Parameter auflösen und URLs korrekt codieren. Eine erfolgreiche Vorführung an einem einzigen bekannten Endpunkt beweist noch wenig über den Weg durch mehrere Institutionen.

Der IETF-Datensatz führt Fassung 17 vom 27. Oktober 2026 als aktiven Internet-Draft der REGEXT-Arbeitsgruppe; der IESG-Status lautet „I-D Exists“. Ein RFC ist daraus bislang nicht geworden. Die Weiterleitungsregel stand bereits in einer früheren Fassung. Relevant ist die im heutigen Text sichtbare Zuordnung der Verantwortung.

Die Quellen nennen keinen konkreten Betreiber, bei dem ein Parameter tatsächlich verloren ging oder offengelegt wurde. Eine aufgezeichnete Transaktion mit ursprünglicher Anfrage, Location-URL, Zielkompetenz und Empfängerrichtlinie würde eine Bewertung dieses Betreibers ermöglichen.

Quellen