Zusammenfassung

  • RFC 9877 definiert geofeed1, die Linkrelation geofeed und den Medientyp application/geofeed+csv, damit ein RDAP-IP-Netzobjekt auf einen Geofeed unter HTTPS verweisen kann.
  • Der Link belegt einen Auffindepfad in einer bestimmten Antwort. Er belegt weder die Aktualität jeder Zeile noch einen physischen Netzstandort oder den Aufenthaltsort einer Person.
  • Eine belastbare Nutzung bewahrt den Objektbereich, verwirft fremde Präfixe, prüft Publikationsbefugnis und Alter und trifft die sachliche Entscheidung in einer getrennten Kontrollstufe.

Ein RDAP-Client fragt eine Adresse ab. Das spezifischste Netzobjekt enthält keinen Geofeed. Erst im übergeordneten Objekt erscheint der Link. Wer daraus sofort einen Ländercode ableitet, überspringt die entscheidende Frage: Für welchen Bereich durfte dieses Elternobjekt überhaupt sprechen?

Der RFC 9877, im Oktober 2025 als IETF Standards Track veröffentlicht, schafft Ordnung in der Auffindeschicht. Ein Server kann in den normalen links eines IP-Netzobjekts die Relation geofeed, eine HTTPS-Adresse und den empfohlenen Typ application/geofeed+csv ausgeben. geofeed1 beschreibt das Erweiterungsverhalten des Servers.

Das ist ein Gewinn gegenüber proprietären oder erratenen Verweisen. Gleichzeitig erklärt der RFC Abruf und Verwendung der Geofeed-Daten ausdrücklich für nicht umfasst. Der Standard sagt, wie der Wegweiser aussieht. Er bescheinigt nicht, dass am Ziel jede Ortsangabe richtig oder für jeden Zweck zulässig ist.

Was der Konformitätshinweis verspricht

Ein Server, der geofeed1 in rdapConformance nennt, muss den Bezeichner in Such- und Abfrageantworten mit IP-Netzobjekten sowie in der Hilfeantwort führen. Besitzt er für ein bestimmtes Objekt eine Geofeed-URL und kann er sie herausgeben, muss der Link in der Antwort stehen. Regulatorische oder vergleichbare Gründe können eine Herausgabe verhindern.

Fehlt dann ein Link, ist nur eine bedingte Schlussfolgerung zulässig: Dieser Server hat für dieses Objekt unter den aktuellen Bedingungen keinen Geofeed verfügbar. Daraus folgt nicht, dass ein Elternobjekt ebenfalls leer ist, der Ressourceninhaber nirgendwo veröffentlicht oder das Präfix keine betriebliche Geografie besitzt.

Umgekehrt darf ein RDAP-Server die registrierte Linkrelation und den Medientyp auch ohne geofeed1 einsetzen. Ein sauberer Client wertet daher Konformitätserklärung und tatsächliche Links getrennt aus. Ein einzelnes Ja-Nein-Feld reicht nicht.

HTTPS schützt die Übertragung und authentisiert den Web-Endpunkt. Es weist nicht automatisch nach, dass dessen Betreiber für jeden im CSV genannten Adressraum zuständig ist. Transportsicherheit und Ressourcenautorität sind verschiedene Glieder derselben Beweiskette.

Beim Aufstieg zum Elternobjekt wächst der Kontext

Nach RFC 9082 liefert eine IP-Abfrage das spezifischste Netzobjekt, das die Anfrage abdeckt. RFC 9877 sieht vor, dass der Geofeed nur an einem weniger spezifischen Elternobjekt hängen kann; der Client kann deshalb rekursiv aufsteigen.

Mit jedem Schritt muss der Referenzbereich erhalten bleiben. Enthält eine gemeinsam genutzte Datei weitere Ressourcen, sind alle Zeilen außerhalb des Adressbereichs des verweisenden Objekts zu ignorieren. Eine korrekt geladene Datei erhält nicht automatisch Zuständigkeit für ihren gesamten Inhalt.

RFC 8805 empfiehlt, die Autorität des Herausgebers für die betroffenen Ressourcen zu prüfen. Das Bootstrap-Verfahren aus RFC 9224 hilft, den RDAP-Dienst zu finden, der autoritative Aussagen über die Zuordnung der Ressource machen kann. Es stärkt die Herkunft des Verweises, nicht die physische Wahrheit einer Ortszeile.

Ein Geofeed ist eine vom Ressourceninhaber veröffentlichte Aussage zur Präfixgeografie. Sie darf grob sein, kann einer Infrastrukturverlagerung zeitlich hinterherlaufen und passt bei Anycast, Mobilfunk oder multinationalen Netzen nicht auf einen einzelnen Punkt. Fachlich ehrlich ist „gemeldete Betriebsgeografie dieses Bereichs zu diesem Zeitpunkt“, nicht „ermittelter Nutzerstandort“.

Eine Signatur schließt die Kette nicht

RFC 9632, der RFC 9092 ablöst, beschreibt eine optionale RPKI-Authentisierung. Eine gültige Signatur kann die Datei besser an ein Zertifikat für den abgedeckten Adressraum binden. Sie bestätigt weder die semantische Richtigkeit jeder Ortsangabe noch deren Aktualität oder die Zulässigkeit einer geschäftlichen Maßnahme.

Die Betriebszustände sollten deshalb getrennt bleiben: Link entdeckt, Datei abgerufen, Transport geprüft, Referenzbereich gespeichert, Zeilen gefiltert, Herausgeberbefugnis geprüft, Signatur bewertet, Alter berechnet, Datenschutzzweck freigegeben, Entscheidung getroffen und Wirkung beobachtet. Wer daraus nur „geortet“ speichert, verliert die Rückverfolgbarkeit.

Auch die Abrufhäufigkeit setzt Grenzen. RFC 9877 verbietet häufige Echtzeitabfragen, die Server unangemessen belasten. RFC 9632 empfiehlt HTTP-Aktualitätssignale zu beachten und ohne solche Signale nicht öfter als wöchentlich abzurufen. Eine Live-API macht die dahinterliegende Quelle nicht automatisch live.

Beim Datenschutz ist die Grenze ausdrücklich: Der Herausgeber darf den Standort einer Person nicht offenlegen. Registerbetreiber sollen prüfen, ob ihr regulatorisches Umfeld die Funktion erlaubt. Die leichte Auffindbarkeit hebt Zweckbindung und Verhältnismäßigkeit nicht auf.