Zusammenfassung

  • Tata Communications berichtete von einem Kunden, der auf französische Webportale gelenkt wurde, obwohl der RIR-Eintrag korrekt war und mehrere Geo-IP-Datenbanken den erwarteten Standort auswiesen.
  • Ein von einem Portal beauftragter externer Datenanbieter hatte den Eintrag nach rund zwei Monaten Nachverfolgung noch nicht aktualisiert; dieser Schritt lag außerhalb der direkten Kontrolle des Netzbetreibers.

Der Satz „Im Register stimmt es“ klingt nach erledigter Arbeit. Für den betroffenen Nutzer ist er erst der Beginn einer Beweiskette. Das Beispiel aus dem Cooperation SIG bei APNIC 62 macht sichtbar, wie viele voneinander unabhängige Entscheidungen zwischen einem korrekten RIR-Datensatz und einem korrigierten Webdienst liegen.

Der von Tata Communications beschriebene Kunde wurde zu französischen Portalen umgeleitet. Die Prüfung der RIR-Daten ergab keinen Fehler. Mehrere branchenübliche Geo-IP-Datenbanken lieferten ebenfalls den erwarteten Standort. Eine Website, in den Folien als GEOLOCATION.com bezeichnet, ordnete die Adresse weiterhin Frankreich zu. Sie bezog ihr Ergebnis von einem externen Geo-IP-Datenanbieter. Tata verfolgte den Fall ungefähr zwei Monate lang; zum Zeitpunkt der Präsentation hatte der Anbieter die Aktualisierung laut den Folien nicht vorgenommen. Tata konnte die Abweichung belegen, aber den fremden Veröffentlichungszyklus nicht steuern.

Mehr lässt sich aus der Quelle nicht seriös behaupten. Die Folien von Tata Communications nennen weder Präfix noch Kunden oder Anbieter. Auch die Zahl betroffener Nutzer, das spätere Ergebnis und die vertragliche Verantwortung bleiben offen. Der Konferenzbericht zu APNIC 62 ordnet den Vortrag ins Programm ein, ist jedoch keine unabhängige Untersuchung. Der Fall erlaubt daher weder eine Fehlerquote noch einen Schuldvorwurf. Er belegt nur, dass die Korrektur im beobachteten Zeitraum nicht durch die gesamte Kette lief.

Die Kette hat mindestens vier getrennte Zustände. Im RIR-System steht die Registrierung der Internet-Nummernressource. Der Betreiber kann zusätzlich erklären, wo diese Ressource eingesetzt wird. Ein Geo-IP-Unternehmen bildet daraus und aus weiteren Signalen eine eigene Schätzung. Ein Portal setzt schließlich eine bestimmte Version dieses Datenbestands ein. Ein korrekter erster Zustand verbessert die Evidenz, löst aber weder die Aufnahme im dritten noch das Deployment im vierten Zustand automatisch aus.

Die einschlägigen Standards stärken vor allem die Betreibererklärung. RFC 8805 definiert ein selbst veröffentlichtes Geofeed-Format. RFC 9632 beschreibt dessen Auffindbarkeit über RPKI, RFC 9877 die Validierung. Damit lassen sich Herkunft und Unversehrtheit besser prüfen. Eine Abnahmefrist für kommerzielle Anbieter oder ein Nachweis der beim Portal laufenden Version folgt daraus nicht.

Der Internet-Draft eines IAB-Workshopberichts beschreibt die breitere Koordinationslücke: teils manuelle oder asynchrone Aktualisierungen, wochen- oder monatelang veraltete Standorte und keinen standardisierten Rückkanal vom Datenanbieter zum ISP. Der Text wurde an den RFC Editor übermittelt, bleibt aber ein Internet-Draft und ist weder IETF-Konsens noch eine Position des IAB. Er liefert Kontext für den Mechanismus, nicht für dessen Häufigkeit.

Eine knappe Lösung wäre eine datensparsame Korrekturquittung. Der Betreiber übermittelt einen authentifizierten Hinweis mit einem hinreichend eingegrenzten Ressourcenbezug. Der Anbieter vergibt eine beständige Vorgangsnummer und teilt mit, ob er annimmt, ablehnt oder weitere Evidenz benötigt. Bei Annahme nennt er die vorgesehene Datenversion. Das Portal weist aus, welche Version es tatsächlich nutzt. So würde aus zwei Monaten privaten Nachfassens ein prüfbarer Statusverlauf, ohne die Identität des Kunden offenzulegen.

Diese Quittung macht APNIC nicht zur Instanz für physische Standortwahrheit. Sie hält Registrierung, Betreiberangabe, Anbieterurteil und Portalbetrieb bewusst auseinander. Verantwortlich wird lediglich der Übergang zwischen ihnen.

Ohne getrennte Zustände kann ein Supportfall erledigt wirken, obwohl sich das Ergebnis nicht verändert hat. Ein Techniker prüft den RIR-Eintrag, legt ein Geofeed vor und reproduziert die falsche Weiterleitung. Der Anbieter bestätigt den Eingang, verschiebt die Aufnahme aber auf den nächsten Lauf. Das Portal hält anschließend noch eine alte Version im Cache. „Eingegangen“, „akzeptiert“, „veröffentlicht“ und „ausgerollt“ sind vier verschiedene Aussagen. Der Kunde braucht die konkrete Aussage, nicht den Hinweis, irgendein Team sei befasst.

Ein strukturiertes Verfahren würde zudem unnötige Offenlegung vermeiden. Ohne klare Schnittstelle versenden Betreiber Screenshots, Routen, Adressen und Kundendetails an allgemeine Postfächer, obwohl sie nicht wissen, welche Signale der Anbieter bewertet. Dieser sollte die geprüfte Behauptung, die maßgebliche Evidenz und gegebenenfalls den Grund eines Widerspruchs benennen. Das zwingt ihn nicht, einem Betreiber zu folgen; es macht seine Abwägung nachvollziehbar.

Die Spezialisierung bleibt erhalten. RIR und RPKI belegen Ressourcenhoheit und Herkunft des Geofeeds. Der Geo-IP-Anbieter gewichtet dies zusammen mit Routing, Latenz, Infrastruktur und eigenen Beobachtungen. Das Portal wählt den Aktualitätsgrad, den es bezahlen und betreiben will. Die Quittung verbindet diese Entscheidungen, ohne eine zentrale, unfehlbare Wahrheit vorzutäuschen.

Eine bloße Rückverweisung an das RIR wäre hier also kein Rechtsbehelf, sondern ein Kreislauf.

Quellen