Zusammenfassung

  • RFC 9910 ist IETF Proposed Standard, January 2026 und beschreibt RIR-spezifische RDAP-Suchen.
  • Basis- und Relationssuchen erfassen IP-Netze, einzelne ASNs oder ASN-Bereiche sowie Reverse-DNS-Objekte. Die Erweiterung verwendet ausdrückliche Pfadsegmente und den Bezeichner rirSearch1.
  • Ein gespeicherter Suchlink bewahrt die ursprüngliche Abfrage. Eine Lookup-URL ist ein späterer Kurzweg zu einem Objekt; zwischen beiden Zeitpunkten kann sich die Registerlage ändern.

Die Erweiterung macht die Hierarchie von Internetnummern-Registern abfragbar. Sie begründet aber weder Eigentum noch einen rechtlichen Titel. Bei einer Basissuche wählt der Client die Objektklasse und übergibt die dazu passende Eingabe: eine IP-Adresse oder ein CIDR-Paar für Netze, eine einzelne ASN oder einen ASN-Bereich sowie einen Domainnamen für Reverse-DNS-Objekte. Die grundlegenden Pfad- und Abfrageformen folgen RFC 9082. Für die RIR-spezifische Erweiterung sind die Pfadsegmente ausdrücklich festgelegt; der registrierte Bezeichner lautet rirSearch1.

Eine Relationssuche fragt Objekte ab, die relativ zur Position einer anderen Ressource in der Hierarchie stehen. Die Richtung ist entscheidend: Eine Suche nach dem übergeordneten Objekt ist nicht dasselbe wie die Suche nach untergeordneten Objekten. RFC 9910 definiert Relationstypen und ermöglicht, sofern der jeweilige Suchpfad dies vorsieht, zusätzliche Statusfilter. Relationstyp, Richtung und Status müssen gemeinsam ausgewertet werden. Ein Treffer beweist nicht, dass die Beziehung später unverändert bleibt.

Die Antwort kann nach RFC 9083 eine Ergebnismenge sein und nicht nur ein einzelnes Objekt. Link-Objekte zeigen, wie eine Abfrage fortgesetzt oder ein Objekt aufgerufen werden kann. Liefert eine Suche genau einen Treffer, darf der Server einen Link zur ursprünglichen Suche beibehalten oder ihn durch einen Lookup-Link ersetzen. Der Suchlink bewahrt Abfrageabsicht und Kontext. Der Lookup-Link verschiebt die spätere Prüfung auf den Client und dessen neuen Abruf. Wird das Register zwischen beiden Abrufen aktualisiert, können Such- und Lookup-Antwort auseinanderlaufen.

Evidenzprotokoll zum Beobachtungszeitpunkt

  • Zeitpunkt: 2026-09-06; zusammen mit Registerautorität, Such-URI, Eingabe, Relationstyp und Statusfilter dokumentieren.
  • Antwort: Rohdaten, Ergebnisklasse, Linkrelationen und Eingangszeit speichern; einen späteren Lookup-Abruf nicht als Ersatz für die ursprüngliche Momentaufnahme verwenden.
  • Reichweite: RFC 9910 beschreibt Suchen für IP-Netze, ASNs oder ASN-Bereiche und Reverse-DNS-Objekte. Daraus folgt jedoch keine Aussage über die aktuelle Einführung bei jedem RIR.
  • Unbekannte: Datenvollständigkeit, konkrete Autorisierung und Rate Limits eines Servers sowie die Zulässigkeit eines bestimmten Verwendungszwecks in einer Rechtsordnung müssen jeweils gesondert geklärt werden.

RFC 7481 setzt die Sicherheitsgrenze: Datenschutz, Authentisierung und Autorisierung, Vertraulichkeit, Ratenbegrenzung und regulatorische Vorgaben bleiben maßgeblich. RFC 9910 hebt keine Zugriffs- oder Datenschutzregeln auf. Weder allgemeine Bereitstellung noch vollständige Datensätze oder universelle Unterstützung durch RIRs dürfen ohne aktuelle Evidenz behauptet werden.

Betreiberpfad zur Annahmeentscheidung

  1. Objektklasse, Relation und Hierarchierichtung festlegen; die Unterstützung von Pfad und rirSearch1 beim konkreten Server prüfen, statt eine flächendeckende Einführung anzunehmen.
  2. Vor der Abfrage Berechtigung, Datenschutz, Rate Limits und die einschlägige Rechtsordnung prüfen.
  3. Suchanfrage, Registerautorität, Beobachtungszeit, Rohantwort, Relationstyp, Ergebnismenge und verfügbare Links gemeinsam protokollieren.
  4. Den Treffer nur als zeitgebundene Betriebsevidenz annehmen. Bei einer folgenreichen Entscheidung erneut abfragen; einen späteren Lookup und eine frühere Beziehung niemals als dauerhaften Eigentumsnachweis behandeln.

Quellen