Zuerst klären: Möchten Sie Registrierung, Routing, Standort oder Risiko abfragen?
IP-Abfragewerkzeuge sind vielfältig, aber der Kernunterschied liegt darin, dass sie unterschiedliche Fragen beantworten. Möchten Sie wissen, unter welcher Organisation ein Adressbereich registriert ist, welche Kontakt-E-Mail hinterlegt ist oder wo sich der Missbrauchsmeldeweg befindet, sollten Sie RDAP-Registrierungsdaten einsehen. Möchten Sie wissen, welche Autonomen Systeme derzeit ein bestimmtes Präfix im Netz ankündigen, sollten Sie einen Blick auf BGP-Routingtabellen-Snapshots werfen. Möchten Sie wissen, ob ein bestimmtes Präfix über eine gültige Route-Origin-Autorisierung verfügt, sollten Sie den RPKI-Validierungsstatus prüfen. Und wenn Sie das Missbrauchs- oder Proxy-Risiko einer IP einschätzen möchten, können Sie einen IP-Reputationsbericht heranziehen, im Chinesischen auch als „IP-Reinheitsbericht“ bezeichnet. Diese Fragen zu vermischen oder von einem Werkzeug gleichzeitig eine präzise physische Position, Echtzeit-Pfade und kommerzielle Risikobewertungen zu erwarten, führt oft zu Fehlurteilen.
Das Länderfeld auf der Seite kann aus der Ressourcenregistrierung oder aus GeoIP-Datenbanken stammen; zuerst muss die Quelle geklärt werden. Wenn ein Benutzer eine Abweichung zwischen Land, Seitensprache oder Netzwerkmarke sieht und daraus auf die Verwendung von VPN oder Anycast schließt, ist die Evidenz nicht ausreichend. Sie können zunächst die IP-Abfrage verwenden, um alle Felder zu erfassen, und dann RDAP, BGP und Standortschätzungen separat abgleichen; wenn Sie sich für die Reputation interessieren, sehen Sie sich den IP-Reputation prüfen: Risikowerte und Sperrlisten verstehen an, im Chinesischen auch als „IP-Reinheitsbericht“ bezeichnet. Diese Werkzeuge beantworten nicht dieselbe Frage.
Betriebspersonal sollte bei der Bearbeitung von Störungen oder Sicherheitsvorfällen die Schlussfolgerungen jedes Werkzeugs auf seinen Evidenzbereich beschränken. Beispielsweise kann eine BGP-Routing-Abfrage nur die beobachteten Routenankündigungen und AS_PATH-Attribute anzeigen, nicht direkt belegen, welche physischen Verbindungen die Datenpakete Ende-zu-Ende durchlaufen. Behandeln Sie die Abfrageausgabe als Hinweis für die Fehlersuche und kombinieren Sie sie mit anderen Evidenzen wie Traceroute, Flussdaten oder Schnittstellenzählern, um eine zuverlässige Beurteilung zu bilden. Ein Abfrageergebnis nicht dazu zu verwenden, alle anderen Informationen zu verwerfen, ist die grundlegende Disziplin beim Interpretieren von IP-Daten.
Welche Registrierungsfragen kann RDAP beantworten?
RDAP (Registration Data Access Protocol) liefert Registrierungsdaten über strukturierte Antworten und wird sowohl für Internetnummernressourcen als auch für Domänenregistrierungen verwendet; dieser Artikel konzentriert sich auf IP-Netzwerke und Autonome-System-Ressourcen. Die Antwort kann Adressbereiche, Objekt-Handles, Kontaktrollen und Ereignisse enthalten, aber der Umfang der Veröffentlichung und Vollständigkeit der Felder hängt von der Registrierungsrichtlinie und dem spezifischen Datensatz ab. Man kann nicht voraussetzen, dass jede Abfrage einen Endbenutzer, eine vollständige Historie oder eine nutzbare Missbrauchs-E-Mail liefert.
Es ist zu beachten, dass die Kontaktadresse in RDAP eine öffentliche Registrierungsadresse ist, normalerweise die Büroadresse oder Rechtsadresse der registrierenden Organisation, und nicht mit dem Standort des IP-Geräts oder dem aktuellen Benutzerstandort gleichgesetzt werden kann. Beispielsweise kann die RDAP-Adresse eines multinationalen Unternehmens in der Hauptstadt registriert sein, während die Server, die diese IP tatsächlich nutzen, in Rechenzentren anderer Länder stehen. Die RDAP-Adresse auf einer Karte direkt als „IP-Lokalisierung“ zu verwenden, überschätzt die Genauigkeit. Die Protokollspezifikationen RFC 9082 und RFC 9083 legen die Abfrage- und Antwortstruktur von RDAP fest, verlangen aber nicht, dass Registrierungsdaten einen physischen Standort enthalten.
Wenn Sie die Registrierungsverantwortung für ein Präfix bestätigen müssen, ist es zuverlässiger, direkt das RDAP-Abfrage-Werkzeug zu verwenden und den Rohdatensatz einzusehen, als sich auf sekundäre Zusammenfassungen zu verlassen. Das Abfrageergebnis zeigt Netzwerkname, Ländercode, Registrierungsstelle, Status (wie allocated, assigned), Ereignishistorie und Missbrauchskontakt-E-Mail. Diese Felder können Betreibern helfen zu beurteilen, ob ein Adressbereich lange nicht aktualisierte Registrierungsinformationen aufweist oder zu einer besonderen Zuteilung gehört, aber daraus kann nicht abgeleitet werden, ob dieser Bereich Angriffe startet, schädliche Dienste hostet oder zu einem bestimmten Endbenutzer gehört. RDAP-Evidenz deckt nur den Registrierungslebenszyklus ab, kein Echtzeitverhalten.
Warum ist ASN nicht gleichbedeutend mit der Dienstanbietermarke?
ASN (Autonomous System Number) kennzeichnet eine Routing-Policy-Domäne unter der Kontrolle eines oder mehrerer Netzbetreiber. Präfixe unter derselben ASN können für verschiedene Dienste genutzt werden, darunter Rechenzentrums-Hosting, Cloud-Dienste, CDN, Inhaltsnetzwerke sowie transparente Proxy-Dienste für unterschiedliche Einzelhandelsmarken oder Mandanten. Daher kann allein anhand der ASN nicht auf die Verbrauchermarke oder den genauen Standort einer IP geschlossen werden. Die ASN eines großen Cloud-Anbieters kann gleichzeitig IP-Adressen von Dutzenden Unternehmen hosten, und der Name der registrierenden Organisation hat möglicherweise keine direkte Beziehung zu diesen Unternehmen.
Ein Autonomes System kann mehrere Regionen und Geschäftsbereiche abdecken, und der Organisationsname kann von Einzelhandelsmarken, Kunden oder Cloud-Mandanten abweichen. Multinationale Betreiber können Präfixe in mehreren Ländern ankündigen, und dasselbe Unternehmen kann mehrere ASNs verwalten. Anycast ist eine mögliche Art der Dienstbereitstellung, deren Betriebsgrenzen in RFC 4786 beschrieben sind, aber aus dem Registrierungsland der ASN oder dem Firmennamen kann nicht direkt auf den geografischen Standort einer bestimmten IP, die Mandantenidentität oder eine Anycast-Bereitstellung geschlossen werden.
In der Sicherheitsanalyse kann eine kleine ASN auch nicht einfach mit hohem Risiko gleichgesetzt werden. Ein Autonomes System mit wenigen Präfixen und kurzer Historie kann ein legitimer neuer Inhaltsanbieter, ein Forschungsnetz oder ein regionaler ISP sein. Die Risikobewertung sollte auf Routing-Verhalten, historischer Ankündigungsstabilität, RPKI-Validierungsstatus und tatsächlichen Missbrauchsbeschwerden basieren, nicht nur auf der Größe der ASN oder dem Alter der Registrierungsdaten. Ein Blick auf die BGP-Routen und die Historie einer ASN kann helfen, deren Ankündigungsgewohnheiten zu verstehen, bleibt aber nur eine von mehreren Evidenzen zur Beurteilung.
BGP-Präfix, Origin-ASN und AS_PATH
BGP-Abfragen zeigen Control-Plane-Informationen, die an einem bestimmten Beobachtungspunkt empfangen wurden, einschließlich Präfix, Origin-ASN, AS_PATH und Zeit. Bei der Abfrage einer einzelnen IP kann das Werkzeug das längste Präfix auswählen, das diese IP abdeckt. Die längste Präfixübereinstimmung ist eine wichtige Regel für die Weiterleitungstabelle: Wenn in der Weiterleitungstabelle ein spezifischerer Treffer vorhanden ist, wird das Paket gemäß diesem Eintrag weitergeleitet; sie unterscheidet sich von der Auswahl des besten Pfads unter mehreren Kandidatenrouten für dasselbe Präfix in BGP. Beide können keine vollständige Liste der physischen Verbindungen direkt liefern.
Das AS_PATH-Attribut listet die Sequenz der autonomen Systeme auf, die eine Route durchlaufen hat, ist jedoch nicht gleichbedeutend mit dem tatsächlichen Weiterleitungspfad von Datenpaketen in der Datenebene. Routing-Richtlinien, lokale Präferenz, MED-Werte, BGP-Konföderationen und MPLS-Tunnel können dazu führen, dass der tatsächliche Paketpfad vom AS_PATH der Kontrollebene abweicht. Ein Paket kann beispielsweise über einen entfernten Peer laufen, der nicht im AS_PATH erscheint. Daher kann die Verwendung von BGP-Routen abfragen zur Bestimmung des aktuellen Ankündigers eines Präfixes zwar helfen, die Kontrolle über die Route einzuschätzen, erlaubt aber keine präzise Ableitung des End-to-End-Verkehrspfads.
Wenn Sie die Ankündigungshistorie eines Präfixes einsehen möchten, etwa ob zuvor ein anderer Ursprungs-ASN verwendet wurde oder ob spezifischere Ankündigungen auftraten, können Sie auf BGP-Verlauf zurückgreifen. Historische Snapshots zeigen den Ankündigungszustand eines Präfixes zu einem bestimmten Zeitpunkt sowie Änderungen im AS_PATH; fehlende historische Daten können jedoch auch auf unvollständige Beobachtungspunkte oder nicht erfasste Routen zurückzuführen sein. Jede einzelne Sicht eines Route Collectors stellt nur einen Teil des globalen Routing-Zustands des Internets dar und kann nicht als vollständige Wahrheit gelten. Erst die Kombination von Daten mehrerer Beobachtungspunkte ermöglicht eine verlässlichere Einschätzung der Routing-Stabilität.
RPKI: Valid, Invalid und NotFound
RPKI (Resource Public Key Infrastructure) autorisiert durch die Ausstellung von ROAs (Route Origin Authorization) einen bestimmten ASN zur Ankündigung eines Präfixes und kann optional eine maximale Präfixlänge (maxLength) festlegen. Bei der Durchführung der Ursprungsvalidierung vergleichen Router oder Validierungswerkzeuge das Präfix und den Ursprungs-ASN der BGP-Route mit der Menge der VRPs (Validated ROA Payloads), die aus gültigen ROAs generiert wurden. Das Validierungsergebnis hat drei Zustände: Valid, Invalid und NotFound.
Der Zustand Valid bedeutet, dass mindestens ein VRP existiert, dessen autorisiertes Präfix das angekündigte Präfix abdeckt, der Ursprungs-ASN übereinstimmt und die Präfixlänge im erlaubten Bereich liegt (üblicherweise unter Berücksichtigung von maxLength). Der Zustand Invalid bedeutet, dass ein oder mehrere VRPs dieses Präfix abdecken, aber der Ursprungs-ASN nicht übereinstimmt oder die Präfixlänge außerhalb des autorisierten Bereichs liegt. Gemäß RFC 6811 ist Invalid nicht automatisch gleichbedeutend mit einer Routenentführung oder böswilligem Verhalten, da Konfigurationsfehler, veraltete ROA-Updates oder betriebliche Fehler des Betreibers zu Invalid führen können.
Der Zustand NotFound bedeutet, dass kein VRP dieses Präfix abdeckt, in der Regel weil der Ressourceninhaber keinen ROA erstellt hat oder der Validator die neuesten ROA-Daten noch nicht abgerufen hat. NotFound sollte nicht als Angriffssignal verstanden werden; es zeigt lediglich, dass die Ursprungsautorisierung nicht über RPKI festgestellt werden kann. Mit RPKI-Validierung können Sie den Validierungsstatus eines bestimmten IP-Präfixes, die zugehörigen ROA-Details und den Validierungszeitpunkt einsehen. Betriebspersonal sollte bei jeder Validierung den Zeitstempel protokollieren, da sich RPKI-Daten dynamisch ändern und sich der Status eines Präfixes durch die Veröffentlichung oder den Widerruf von ROAs ändern kann.
Warum ist Valid kein Sicherheitszertifikat?
Die RPKI-Ursprungsvalidierung prüft, ob Ursprungs-ASN und Präfixlänge einer Route durch die aktuell validierten ROA-Nutzdaten autorisiert sind. Ein Valid-Ergebnis authentifiziert weder den restlichen AS_PATH noch belegt es die Sicherheit von Paketen oder die Vertrauenswürdigkeit von Endgeräten. Es bewertet auch kein Nutzerverhalten und keine Inhalte. Ein bösartiges Netzwerk kann einen gültigen ROA für sein eigenes Präfix besitzen, für seine Route ein Valid-Ergebnis erhalten und trotzdem schädliche Aktivitäten in seiner Infrastruktur ausführen. Ein Valid-Ergebnis für die Route, die eine IP-Adresse abdeckt, garantiert daher weder, dass diese Adresse nicht missbraucht wird, noch dass der Dienst vertrauenswürdig ist.
Ebenso kann der Zustand Invalid nicht direkt als Routenentführung eingestuft werden. Häufige technische Szenarien sind: Der Betreiber hat beim Migrieren eines Präfixes den ROA nicht rechtzeitig aktualisiert oder maxLength falsch gesetzt, sodass eine spezifischere Ankündigung nicht erlaubt ist. Dies sind Konfigurationsprobleme der Routenregistrierung, die durch Korrektur des ROA wieder in den Zustand Valid überführt werden können. Andererseits können echte Entführer nicht abgedeckte Präfixe (also NotFound) zur Ankündigung nutzen, was umso mehr zeigt, dass der Status allein keine Sicherheitsaussage darstellt.
Bei der Meldung an den Betreiber sollten Sie Beobachtungszeit, konkretes Präfix, Ursprungs-ASN, autorisierten ASN des abdeckenden VRP sowie maxLength und die Quelle des Validators oder der Datenquelle festhalten. Eine mögliche Formulierung lautet: „Zum angegebenen Zeitpunkt wurde 203.0.113.0/24, Ursprung AS64496, als Invalid validiert; es existiert ein abdeckender VRP, aber kein Datensatz, der sowohl Ursprung als auch Längenanforderung erfüllt.“ Hierbei handelt es sich um Dokumentationsbeispiel-Ressourcen, nicht um eine tatsächliche Routenwarnung. Der Empfänger muss die vollständige Menge der Übereinstimmungen prüfen und darf nicht nur einen nicht übereinstimmenden VRP betrachten und eine andere gültige Autorisierung ignorieren.
Warum unterscheiden sich Registrierungsland und Standortland?
Eine Abweichung zwischen Registrierungsland und Standortland bedeutet nicht automatisch einen Lokalisierungsfehler oder das Vorliegen von Anycast. IP-Adressen werden von regionalen Internetregistrierungsstellen an multinationale Organisationen vergeben; die Organisation kann die Registrierung im Land ihres Hauptsitzes wählen, während die tatsächliche Nutzung in weltweiten Niederlassungen oder Rechenzentren erfolgt. Beispielsweise registriert ein europäisches Unternehmen einen gesamten IP-Block in den Niederlanden, mietet aber Server in Singapur; bei der Abfrage zeigt das Registrierungsland Niederlande, während Netzwerklatenz und Routing-Beobachtungen auf Singapur hindeuten. Dies ist der Normalfall und keine Anomalie.
Wenn ein Upstream-ISP große Ressourcenblöcke erhält, kann er diese an verschiedene Kunden oder Regionen verteilen, während sich Registrierungsdaten, kommerzielle Geolokalisierungsdatenbanken und Website-Caches jeweils unterschiedlich aktualisieren. Ressourcentransfers, Zuweisungsänderungen oder Datenrevisionen können zu zeitlichen Verzögerungen führen; es darf nicht angenommen werden, dass sie nach einer festen Anzahl von Wochen oder Monaten synchronisiert sind. Dokumentieren Sie den konkreten Abfragezeitpunkt und die Quelle und unterscheiden Sie zwischen aktuellem Registrierungsobjekt, historischem Snapshot und Standortschätzung, um nicht ein Feld mit einer anderen Bedeutung zu überdecken.
Zu den Faktoren der Netzwerkarchitektur zählen CDNs, Cloud-Anbieter und internationale Standleitungen, die dasselbe Präfix in mehreren Ländern bereitstellen. In solchen Fällen kann kein einzelnes „Registrierungsland“ den tatsächlichen Verkehrseingang repräsentieren. Um zu beurteilen, ob eine IP in einem bestimmten Land Dienste bereitstellt, sollten Sie den AS-Pfad der BGP-Route, aktive Ping-/Traceroute-Messungen und öffentliche Regionsinformationen des Cloud-Anbieters kombinieren. Allein aus der Abweichung des Ländercodes auf Anycast zu schließen, ist nicht ausreichend belegt.
Was ist der Unterschied zwischen Anycast und Broadcast?
Anycast ermöglicht es mehreren Dienstinstanzen, dieselbe Adresse zu verwenden, wobei das Routing eine Anfrage an eine der erreichbaren Instanzen weiterleitet; bei üblichen Internetimplementierungen wird das Präfix, das diese Adresse trägt, an mehreren Standorten angekündigt. Die ausgewählte Instanz hängt von den Routing-Richtlinien ab und garantiert weder die geografisch nächste noch die geringste Latenz oder die geringste Last. Broadcast hingegen sendet ein Paket an mehrere Empfänger innerhalb einer Broadcast-Domäne; beide Konzepte unterscheiden sich grundlegend. Für technische Details zu Anycast siehe RFC 4786.
Um Anycast zu beurteilen, kann man die ausdrückliche Dokumentation des Betreibers für diese Dienst-Adresse sowie Messungen an mehreren Standorten und zu gleichen Zeitabschnitten sowie Instanzkennungen heranziehen. Dieselbe ASN kann an mehreren Anycast-Standorten auftreten, daher müssen die End-ASNs nicht unterschiedlich sein; unterschiedliche ASNs oder unterschiedliche Traceroute-Pfade beweisen auch nicht automatisch Anycast, da Routing-Änderungen, Tunnel und Messgrenzen die Ergebnisse beeinflussen können. Es sollte dargelegt werden, bis zu welchem Schritt die Evidenz trägt; man darf eine Adresse nicht allein anhand einiger Ländercodes charakterisieren.
Ein häufiger Irrtum ist, Unterschiede im Länderfeld als Anycast-Beweis zu deuten, etwa wenn dieselbe IP in verschiedenen kommerziellen Datenbanken als USA und Deutschland angezeigt wird. Dies zeigt lediglich, dass die Geodatenquellen uneinheitlich sind; es kann sich um Registrierungs-, Routing- oder Datenbankaktualisierungsprobleme handeln und ist keinesfalls ein hinreichender Beleg für Anycast. Jede betriebliche Beurteilung muss klar zwischen Möglichkeit und Beweis unterscheiden und vermeiden, ungeprüfte Annahmen als Schlussfolgerungen darzustellen.
Beispielfall: Wer sind jeweils Registrant, Betreiber und Mieter?
Im Folgenden ein illustratives Szenario, das nicht auf realen Messungen beruht. Angenommen, die Dokumentations-Beispieladresse 192.0.2.10 wird abgefragt: RDAP zeigt als Registrierungsland die USA, als Registrierungsorganisation Example Corp, während die Ursprungs-ASN der BGP-Routenankündigung zu einem europäischen Cloud-Anbieter gehört. Dieser Unterschied kann darauf zurückgehen, dass Example Corp den Adressblock an den Cloud-Anbieter vermietet hat, der Edge-Knoten in Frankfurt und Tokio bereitstellt, aber die Registrierungsdaten nicht aktualisiert hat. Allein aufgrund dieser Informationen lässt sich weder der aktuelle physische Standort der IP noch eine Anycast-Nutzung bestätigen.
In Fortführung dieser Annahme: Zwei Messpunkte in der Nähe von Frankfurt und Tokio erreichen jeweils ihre lokale Dienstinstanz und erhalten unterschiedliche, überprüfbare Instanzkennungen, während die angeforderte Zieladresse jeweils die Dokumentations-Beispieladresse 192.0.2.10 ist. Zusammen mit einer ausdrücklichen Anycast-Beschreibung des Betreibers für diese Adresse lässt sich die Beurteilung einer Mehrstandort-Bereitstellung stützen. Hier wird nur ein logisches Beispiel beschrieben; es wird nicht behauptet, dass von jedem beliebigen Punkt der Erde eine Latenz unter 10 Millisekunden erreichbar wäre. RPKI Valid verifiziert weiterhin nur die Ursprungsautorisierung des Präfixes und belegt nicht den Standort der Instanz.
Unbekannte Punkte in diesem Fall sind unter anderem: die konkrete Identität des Mieters, ob der Dienstport für alle Regionen offen ist, der Mechanismus der Zustandssynchronisierung zwischen Instanzen und ob es Paketfilter im zwischengeschalteten Netz gibt. Betriebspersonal sollte diese Unbekannten wahrheitsgemäß dokumentieren, statt fehlende Evidenz mit dem Etikett „Anycast“ zu überdecken. Eine Klassifizierung bedeutet nicht Bösartigkeit, ein Fehltreffer nicht einen Angriff; die klare Darstellung der Grenzen ist die Grundlage fachlicher Beurteilung.
Warum stimmen historische Aufzeichnungen und aktuelle Ergebnisse nicht überein?
RDAP-Ereignisse werden üblicherweise durch Felder wie eventAction und eventDate beschrieben, zum Beispiel registration oder last changed; manche Oberflächen zeigen sie zusammengefasst als „updated“ an. Diese Daten beschreiben Ereignisse am Registrierungsobjekt, nicht den Zeitpunkt eines physischen Serverumzugs. Eine Änderung von E-Mail, Status oder Verwaltungsdaten kann das Aktualisierungsdatum verändern, während sich der Dienststandort ändern kann, ohne dass es in den betreffenden Feldern erscheint. Die ursprünglichen Ereignisnamen müssen erhalten bleiben; nicht alle Daten dürfen einheitlich als Adressumzug gedeutet werden.
Präfixaufteilung und Ressourcentransfer sind häufige Ursachen. Wird ein großer /16-Block in mehrere /24-Blöcke zerlegt, können einzelne kleinere Blöcke anderen Organisationen zugeteilt werden, während das Länderfeld der übergeordneten Registrierung den ursprünglichen Wert behält. Fragt man dann RDAP für ein bestimmtes /24 ab, kann der historische Wert des übergeordneten Landes zurückgegeben werden, während die BGP-Route zeigt, dass dieser kleine Block bereits von einer ASN eines anderen Landes angekündigt wird. Auch unterschiedliche Beobachtungspunkte führen zu Inkonsistenzen: Kommerzielle IP-Datenbanken basieren auf unterschiedlichen Datenquellen und Erfassungszeitpunkten, und die Abweichungen zwischen Schnappschüssen können mehrere Monate betragen.
Das folgende hypothetische Beispiel zeigt, wie sich die Belege dokumentieren lassen. Der korrekte Umgang besteht darin, alle ursprünglichen Aufzeichnungen zu bewahren und den Abfragezeitpunkt zu vermerken. Beispiel: Im Januar 2024 zeigt RDAP als Land Großbritannien, im Juni 2024 verläuft der BGP-Pfad über Deutschland, im September 2024 endet der Traceroute eines Beobachtungspunkts in den Niederlanden. Man kann nicht einfach sagen: „Die IP ist in die Niederlande umgezogen“, sondern sollte sagen: „Zu verschiedenen Zeiten und an verschiedenen Beobachtungspunkten bestehen Unterschiede, die auf Routing-Anpassungen oder Datenbankverzögerungen zurückgehen können.“ So bleibt die Evidenz erhalten und Überinterpretation wird vermieden.
Wie kombiniert man Evidenz und bewahrt Unbekanntes auf?
Eine vollständige Beurteilung einer IP-Abfrage sollte in vier Evidenzkategorien unterteilt werden. Der Registrierungshintergrund stammt aus RDAP und WHOIS, einschließlich Registrierungsorganisation, Land, Registrierungsdatum, Kontakt-E-Mail und Status, enthält aber keine physische Lokalisierung oder Endnutzeridentität. Der Routing-Status stammt aus BGP und RPKI, einschließlich angekündigter ASN, AS-Pfad, RPKI gültig oder ungültig, Sichtbarkeit; er spiegelt nur die Erreichbarkeit der Steuerungsebene wider und garantiert nicht den vollständigen Pfad der Datenebene. Die Standortschätzung stammt aus kommerziellen IP-Datenbanken, Latenz und Traceroute und ist eine probabilistische Beurteilung.
Direktes Verhalten muss unabhängig aufgezeichnet werden, etwa ob aktiv gescannt wurde, ob schädliche Domänenauflösungen vorliegen oder ob auf bestimmte Ports geantwortet wird. Eine IP mit Registrierungsinformationen eines privaten ISP repräsentiert selbst dann keinen echten Privathaushalt, wenn die Geoposition zu einer Stadt passt, denn es können Proxy- oder Hosting-Dienste vorliegen. Hinweise zur Unterscheidung von Residential-IPs und nativen IPs finden Sie unter Residential-, ISP- und Rechenzentrums-IPs im Vergleich. Bei unzureichender Abdeckung der Beobachtungspunkte kann dieselbe IP in manchen Regionen als nicht erreichbar erscheinen; das belegt keine globale Nichterreichbarkeit, siehe Reputation eines /24-Subnetzes: Abdeckung und Risikowerte.
Angenommen, das Registrierungsland ist Kanada, die ASN wird von einem kanadischen ISP verwaltet, RPKI ist Valid, die kommerzielle Datenbank schätzt Toronto, und einige kanadische Messpunkte zeigen niedrige Latenz. Dann lässt sich sagen, dass diese Ergebnisse mit einem Dienststandort in Kanada vereinbar sind; man darf daraus aber keinen Beweis für den physischen Standort ableiten und auch nicht aus RPKI auf einen normalen Betrieb schließen. Die Registrierung ist eine Angabe, das Routing eine Beobachtung, der Standort eine Schätzung, und auch die Verhaltensaufzeichnung hat Quelle und Messgrenzen; alle Schlussfolgerungen müssen Zeitpunkt, Bedingungen und weiterhin nicht bestätigbare Teile angeben.
Häufige Fragen und Materialien zur Überprüfung
Häufige Frage 1: Bedeutet ein ASN-Wechsel einen Anbieterwechsel? Nicht unbedingt. Eine ASN repräsentiert eine Routing-Policy-Domäne; große Anbieter können mehrere ASNs besitzen, und Unternehmen können zu einem Cloud-Anbieter migrieren, aber den ursprünglichen IP-Block beibehalten. Zu prüfen ist, ob das IP-Präfix in derselben BGP-Route von verschiedenen ASNs angekündigt wird oder ob sich der AS-Pfad ändert, und dies mit den Registrierungsinformationen zu kombinieren, um zu beurteilen, ob tatsächlich der Netzbetreiber gewechselt wurde.
Die RPKI-Ursprungsvalidierung verhindert nicht alle Routing-Angriffe und authentifiziert auch nicht den vollständigen AS_PATH. Eine präzise Formulierung lautet: „Die Route ist bezogen auf die aktuelle VRP-Menge Valid, Invalid oder NotFound.“ Invalid sollte nicht vereinfacht als „ROA ungültig“ bezeichnet werden; das sind nicht dieselben Konzepte. RDAP ist ebenfalls kein Werkzeug zur Lokalisierung einzelner Endnutzer: Auch wenn ein öffentliches Objekt Personen- oder Kontaktinformationen enthält, bleibt es eine Ressourcenregistrierung; daraus lässt sich weder die Person, die aktuell eine Anfrage sendet, noch eine genaue Wohnadresse identifizieren.
Ein Rahmen zur Überprüfung von Tickets sollte vom Einreicher verlangen: Abfragezeitpunkt (UTC), konkrete IP oder konkretes Präfix, RDAP-/WHOIS-Schnappschuss, BGP-Routingtabelle oder Traceroute-Beobachtungsquelle, aktueller Status (z. B. Verbindungsfehler oder Routenleck) sowie das konkrete Anliegen. Das Betriebspersonal prüft daraufhin zuerst die Registrierungsfelder, dann RPKI und AS-Pfad und zieht zuletzt Lokalisierung und aktive Messungen heran. Mit diesem Rahmen lassen sich Fehlurteile wie „Länderfeld passt nicht, also wurde gehackt“ reduzieren.
