Sie sind in Shanghai, aber die IP-Abfrage zeigt eine andere Stadt; zwei Websites fragen dieselbe Adresse ab, eine liefert die USA, die andere Kanada. Bei solchen Ergebnissen denkt man intuitiv: „Eine der Datenbanken ist falsch.“ Doch bevor man Datenbanken vergleicht, sollte man prüfen: Vergleichen Sie dieselbe Adresse, dieselbe Art von Standort oder mehrere ähnlich klingende Felder mit unterschiedlicher Bedeutung?
IP-Geolokalisierung ist eine Schätzung des Standorts einer Netzwerkadresse, keine Geräteortung. Verschiedene Plattformen können unterschiedliche Datenquellen, Aktualisierungszeiten und Standortgranularität verwenden; bei abweichenden Standorten sollten Sie zuerst Adresse und Felder prüfen, bevor Sie über eine Korrektur entscheiden.
Diese Reihenfolge ist wichtig. Andernfalls könnten Sie den Standort des Netzwerkausgangs mit Ihrem eigenen verwechseln oder den Sitz der Registrierungsstelle als Argument gegen eine stadtbezogene Ortung anführen und schließlich für den falschen Ort einen Änderungsantrag einreichen.
Der Begriff „Zugehörigkeit“ kann vier verschiedene Informationen umfassen
Viele Abfrageseiten geben nur „Land“, „Region“ oder „Zugehörigkeit“ an, ohne die Bedeutung der Daten direkt zu erläutern. Tatsächlich können die folgenden Informationen einander nicht ersetzen.
Informationen, die Sie sehen | Das Objekt, das sie beschreiben | Worauf beim Vergleich zu achten ist |
|---|---|---|
IP-Geolokalisierung | Der von der Datenbank geschätzte Standort basiert auf der Nutzungsposition oder dem Netzwerkausgangspunkt | Gibt es einen Ortungsbereich, ein Konfidenzniveau und einen Aktualisierungszeitpunkt? |
Ressourcenregistrierungsinformationen | Registrierungsdatensätze der IP-Adressressourcen und der zugehörigen Organisationen | Registrierungsinformationen sind kein Nachweis für den Standort des Endgeräts |
Browser- oder Geräteortung | Der nach Erteilung der entsprechenden Berechtigungen ermittelte Gerätestandort | Kann Gerätefähigkeiten wie GPS nutzen und nicht nur die IP-Adresse abfragen |
Lokale Inhalte der Website | Vom Dienst nach eigener Logik ausgewählte regionale Inhalte | Kann außerdem durch Kontoeinstellungen, Sprache oder bisherige Präferenzen beeinflusst werden |
ARINs Einführung in Whois/RDAP erläutert den Abfragezweck der Registrierungsinformationen. Sie gehören zu einer anderen Datenschicht als die Schätzung geografischer Datenbanken, „wo diese Adresse derzeit genutzt wird“.
Die Geolocation-API-Dokumentation von MDN erklärt, dass eine Website nach Einholung der Nutzergenehmigung den Standort über die verfügbaren Ortungsfähigkeiten des Geräts ermitteln kann. Dass eine Kartenanwendung weiß, in welcher Straße Sie sich befinden, bedeutet daher nicht, dass eine andere IP-Abfrage-Website dieselbe Genauigkeit liefern sollte.
Warum kann dieselbe Adresse zu unterschiedlichen Ortungsergebnissen führen?
Wenn sich die Nutzung einer Adresse ändert, wird die Datenbank nicht unbedingt gleichzeitig aktualisiert
Adressressourcen können neu zugewiesen, weitervermietet oder für neue Netzwerkausgänge genutzt werden. Ortungsdienste benötigen jeweils eigene Prozesse, um Änderungen zu erkennen, zu verifizieren und Updates zu veröffentlichen; Websites, die Offline-Datenbanken verwenden, müssen neue Versionen zudem tatsächlich in ihren Systemen bereitstellen.
Daher sind „der Datenanbieter hat korrigiert“ und „alle Websites, die diese Daten nutzen, haben aktualisiert“ zwei verschiedene Dinge. Dass alte Ergebnisse weiterhin angezeigt werden, kann sowohl beim Datenanbieter als auch in der lokalen Datenbank oder im Cache des Nutzers liegen.
Es gibt keine feste Aktualisierungszeit, die für alle Plattformen gilt. Man kann nicht behaupten, eine Einreichung sei wirkungslos, nur weil sich nach einem Tag noch nichts geändert hat; ebenso wenig kann man versprechen, dass nach einer Korrektur alle anderen Plattformen gleichzeitig synchronisieren.
Der Netzwerkausgang muss nicht unbedingt in der Nähe des Nutzers liegen
Umgebungen wie Mobilfunknetze, Unternehmensnetzwerke und VPNs trennen den Standort des Geräts vom Standort des öffentlichen Ausgangs. Geografische Datenbanken können die Position des Ausgangs manchmal gut bestimmen, sind aber nicht in der Lage, die Person zu lokalisieren, die diesen Ausgang nutzt.
MaxMinds Hinweise zur Standortgenauigkeit behandeln speziell Szenarien wie Mobilfunk- und Datenschutznetzwerke und stellen klar, dass IP-Geodaten nicht ausreichen, um ein bestimmtes Haus, eine Person oder eine Straßenadresse zu identifizieren.
Wenn sich eine Person in Stadt A befindet, der Ausgang aber in Stadt B geortet wird, liegt also nicht unbedingt eine Leitungsstörung vor. Zunächst sollte geklärt werden, ob der Standort des Geräts oder die Netzwerkposition abgefragt werden soll, die externe Dienste sehen.
Die beiden Plattformen bieten unterschiedliche Genauigkeit
Wenn eine Plattform das Land und eine andere die Stadt angibt, bedeutet das nicht, dass letztere genauer ist. Ein feineres Feld kann lediglich einen repräsentativen Punkt innerhalb eines Bereichs darstellen; dass die Seite keinen Ortungsradius anzeigt, heißt nicht, dass es keinen gibt.
Selbst wenn eine Kartenmarkierung auf ein bestimmtes Gebäude zu fallen scheint, kann daraus nicht geschlossen werden, dass sich Server oder Nutzer in diesem Gebäude befinden. Mehr Nachkommastellen bei Längen- und Breitengrad erhöhen nur die Anzeigegenauigkeit, nicht automatisch die Datengenauigkeit.
Wenn die Datenquelle einen Ortungsbereich liefert, sollten Punkt und Bereich zusammen betrachtet werden. Andernfalls sollte ein Städtename nicht als vor Ort verifizierter Standort verstanden werden.
Gleicher Netzwerkname bedeutet nicht, dass Zweck und Standort jeder Adresse gleich sind
Eine Betreiberorganisation kann an mehreren Standorten tätig sein. Unter derselben ASN können auch Adressbereiche aus verschiedenen Regionen und mit unterschiedlichen Verwendungszwecken zusammengefasst sein.
Organisationsname und ASN helfen, den Netzwerkhintergrund zu prüfen, aber sie allein erlauben nicht, alle Adressen eines Netzwerks einer Stadt zuzuordnen. Enthält der Reverse-DNS-Eintrag die Abkürzung einer Stadt, ist das nur ein Hinweis; Hostnamen können alte Benennungen beibehalten und ersetzen keine anderen Belege.
Vor der Fehlersuche zunächst „dieselbe IP“ genau bestätigen
Der häufigste Vergleichsfehler liegt oft nicht in der Datenbank, sondern beim abgefragten Objekt.
Kopieren Sie zuerst die vollständige öffentliche Adresse und merken Sie sich nicht nur Land und Anbieter. Prüfen Sie insbesondere, ob auf den beiden Seiten IPv4 bzw. IPv6 angezeigt werden: Das sind nicht dieselben Adressen und sollten nicht direkt als Maß dafür dienen, ob zwei Datenbanken übereinstimmen.
Notieren Sie zugleich die Abfragezeit und stellen Sie sicher, dass sich die Netzwerkeinstellungen zwischenzeitlich nicht geändert haben. Automatische Proxy-Auswahl, Wiederverbindungen im Mobilfunknetz oder unterschiedliche Proxy-Regeln für Browser und andere Anwendungen können den beobachteten Ausgang verändern.
Sie können zunächst über IP-Abfrage das aktuelle Ergebnis erfassen und dann dieselbe Adresse als eindeutiges Abfrageobjekt vergleichen. Wenn Sie einen Domainnamen eingeben, beachten Sie, dass dieser mehrere Adressen auflösen kann; der Vergleich verschiedener von der Domain zurückgegebener Server ist nicht dasselbe wie der Vergleich derselben IP.
Wie lassen sich Standortunterschiede zu einem bearbeitbaren Problem zusammenfassen?
Screenshots zu sammeln und zu sagen „ihr seid ungenau“, ist meist weniger hilfreich als die folgenden Informationen.
Die vollständige abgefragte IP sowie den Typ IPv4 oder IPv6.
Abfragezeit und Zeitzone, um Ergebnisse aus unterschiedlichen Zeiten nicht als gleichzeitige Beobachtungen zu behandeln.
Die Feldbezeichnung jedes Ergebnisses: Registrierungsland, Ortungsland, Stadt oder eine andere Ortsangabe.
Datenquelle, Version oder Aktualisierungszeit; falls nicht verfügbar, ehrlich als „nicht angegeben“ kennzeichnen.
Wo Ihrer Meinung nach ein Fehler liegt und welche Materialien diese Einschätzung stützen.
Beispielsweise ist „die beiden Plattformen zeigen für dieselbe IPv4 unterschiedliche Ortungsländer“ konkreter als „die Zuordnung auf den beiden Websites ist unterschiedlich“; „unser neu zugewiesener Adressbereich zeigt noch die frühere Stadt“ kommt einem Problem näher, das Netzbetreiber und Datenpfleger gemeinsam prüfen können.
Materialien haben unterschiedliches Gewicht. Lieferregionen in Dienstleistungsverträgen, Angaben des Netzbetreibers und überprüfbare Informationen zur Ressourcennutzung sagen in der Regel mehr aus als die in Server-Betriebssystemen eingestellte Zeitzone. Zeitzonen lassen sich ändern und beweisen keinen physischen Standort.
An wen sollte man Korrekturen richten, statt sie bei allen Websites erneut einzureichen?
Sie sind Nutzer eines normalen Breitband- oder Mobilfunkanschlusses
Fragen Sie zuerst beim Anbieter, ob es zentrale Ausgänge, regionenübergreifende Gateways oder kürzliche Anpassungen der Adresszuweisung gibt. Wenn der Netzausgang ohnehin in einer anderen Region liegt, kann eine Änderung der Geodatenbank den tatsächlichen Pfad nicht zu einem lokalen Ausgang machen.
Wenn nur bei einer bestimmten Anwendung die Inhaltsregion nicht den Erwartungen entspricht, während die Ergebnisse mehrerer IP-Datenbanken übereinstimmen, sollten Sie auch die Standortberechtigungen und die Regions-Einstellungen des Kontos dieser Anwendung prüfen. In diesem Fall liegt das Problem nicht unbedingt bei der IP-Datenbank.
Sie haben einen Proxy, einen VPS oder eine feste öffentliche Adresse gemietet
Bitten Sie den Anbieter, die tatsächliche Bereitstellungsweise und Region zu erläutern, und prüfen Sie, ob die Adresse gerade migriert oder neu zugewiesen wurde. Verwenden Sie nicht allein die Regionsangabe auf der Verkaufsseite als endgültigen Standortnachweis.
Wenn die Korrektur ein gesamtes Präfix betrifft, ist es in der Regel sinnvoller, dass der Netzbetreiber, der die Ressource kontrolliert, dies einheitlich behandelt. Geofeed kann Netzbetreibern helfen, geografische Informationen zu Präfixen zu veröffentlichen, aber RFC 8805 behält ausdrücklich den Nutzern Raum zur Prüfung von Autorität und Genauigkeit vor; die Veröffentlichung einer Datei ist keine verbindliche Aktualisierungsanweisung für alle Datenbanken.
Sie wissen bereits genau, welche Datenquelle fehlerhaft ist
Nutzen Sie den offiziellen Kanal dieser Datenquelle. Beispielsweise bietet MaxMind in seiner Dokumentation einen Eingang zur Korrektur von Geodaten an. Reichen Sie überprüfbare Fakten ein, statt zu verlangen, dass die Adresse auf die von Ihnen gewünschte Region geändert wird.
Eine Korrektur dient dazu, die Daten der tatsächlichen Nutzung anzunähern, nicht dazu, eine falsche Zugehörigkeit zu einem Land oder einer Stadt zu erzeugen. Bei der Einreichung müssen Sie auch keine genaue Wohnadresse, Kontopasswörter oder Screenshots des Administrationsbereichs offenlegen; geben Sie nur die notwendigen Informationen an vertrauenswürdige Stellen weiter.
Nach der Korrektur: Wie bestätigen Sie, dass das Problem wirklich gelöst ist?
Bewahren Sie die Aufzeichnungen vor der Einreichung auf, und prüfen Sie nach der Bestätigung der Bearbeitung durch den Betreuer dieselbe Adresse und dasselbe Feld erneut. Prüfen Sie auch, ob die ursprünglich betroffene Website das neue Ergebnis übernommen hat; beides kann unterschiedlich synchronisiert sein.
Wenn sich die IP-Daten geändert haben, aber ein Dienst weiterhin die alte Region anzeigt, sollten Sie das Problem an den Nutzer des Dienstes weiterleiten: Verwendet er eine andere Datenquelle, hat er einen Cache, oder gibt es regionale Einstellungen auf Kontoebene? Bereits korrekte Daten weiter zu ändern, hilft oft nicht.
Ob der Dienst nutzbar ist, muss durch Erreichbarkeit von Diensten prüfen und normale tatsächliche Zugriffe separat überprüft werden. Eine korrekte Standortbestimmung bedeutet nicht, dass der Dienst geöffnet ist; und die Erreichbarkeit eines Dienstes kann umgekehrt nicht beweisen, dass die Stadtlokalisierung korrekt ist.
IP-Geoinformationen eignen sich, um den Netzwerkhintergrund zu verstehen, offensichtliche Abweichungen zu erkennen und Korrekturen anzustoßen. Betrachten Sie sie als eine Einschätzung mit Quellen- und Genauigkeitsgrenzen und nicht als einen bis auf die Straße genauen Adressnachweis – so nähern Sie sich ihrem tatsächlichen Zweck.
Übernationale Netze mit unterschiedlichen Ländern: Registrierungsland, Anycast und Ausgangsstandort
Betrachten wir zunächst ein hypothetisches Szenario: Ein multinationaler Dienstanbieter registriert Adressressourcen in Kanada, der tatsächliche Dienst wird in den USA bereitgestellt, und kommerzielle Standortdatenbanken und Registrierungsabfragen zeigen daher unterschiedliche Länder an. Hier muss man nicht Anycast annehmen und kann auch nicht allein aufgrund von Länderunterschieden auf Anycast schließen. Zuerst sollte unterschieden werden, ob das ausgelesene Land das Registrierungsland, eine kommerzielle Standortschätzung oder ein bei einer bestimmten Anfrage tatsächlich beobachteter Dienstknoten ist; diese beschreiben unterschiedliche Sachverhalte und lassen sich nicht allein durch „zwei Länder stimmen nicht überein“ als falsch bestimmen.
Das Registrierungsland stammt aus den Ressourcenregistrierungsdaten in der RDAP- oder Whois-Datenbank und beschreibt die administrative Zuordnung des Adressblocks, nicht den Standort des Endgeräts. Beispielsweise kann ein Adressbereich, der in Kanada registriert ist, aber dauerhaft von einem US-Rechenzentrum genutzt wird, in Geodatenbanken eine US-Stadt erhalten, während das Registrierungsland weiterhin Kanada anzeigt. Beides sind unterschiedliche Felder und sollten nicht direkt verglichen werden. Wenn Sie mehrere Abfrageergebnisse ansehen, sollten Sie zuerst prüfen, ob die Seite „Land“ (country), „Registrierungsland“ (registered country) oder „Standort“ (location) angibt.
Anycast ist eine weitere Möglichkeit, die unabhängige Belege erfordert. Dieselbe Dienstadresse kann von mehreren Standorten aus bereitgestellt werden; die Routing-Strategie bestimmt, bei welcher Instanz die aktuelle Anfrage ankommt, garantiert aber nicht, dass der physisch nächstgelegene Knoten gewählt wird. Erst wenn Belege wie Betreiberangaben, Messungen von mehreren Standorten oder Instanzidentifikation vorliegen, ist es angebracht, über den Einfluss von Anycast auf die Lokalisierung zu sprechen. Dass zwei kommerzielle Datenbanken unterschiedliche Länder anzeigen, beweist weder Anycast, noch schließt es veraltete Datenbanken, Zuweisungsänderungen oder gewöhnliche multinationale Bereitstellungen aus.
Prüfen Sie bei der Verifikation zuerst Organisation, Geltungsbereich und Ereignisse in RDAP und nutzen Sie dann BGP-Beobachtungen als Routing-Hintergrund. Ein einzelnes ASN kann mehrere Länder abdecken, und mehrere Ursprungs-ASNs für dasselbe Präfix haben verschiedene Erklärungen; keines davon kann allein den Standort der Dienststadt bestimmen. Wenn Betreiberangaben zur Region, ein gepflegtes Geofeed oder Messungen von mehreren Punkten verfügbar sind, sollten Sie jeweils Zeitpunkt und Umfang angeben und das Urteil schrittweise eingrenzen, statt das Registrierungsland direkt zur Widerlegung der kommerziellen Lokalisierung zu verwenden.
Bei der Fehlersuche sollten Sie zuerst die vollständige IPv4/IPv6-Adresse, den Abfragezeitpunkt und die Feldbezeichnungen jeder Plattform aufzeichnen. Wenn eine Adresse zu Anycast oder einem multinationalen Cloud-Netz gehört, reichen Sie nicht vorschnell eine Korrektur ein, sondern prüfen Sie die Routenankündigungen des Präfixes und die öffentliche Dokumentation des Netzbetreibers. Jedes Urteil „hier ist definitiv etwas falsch“ muss aus Registrierungsinformationen, BGP-Beobachtungen und tatsächlichen Ausgangsbelegen gebildet werden. Weitere Informationen zum Verhältnis von RDAP, ASN, BGP und Standortbelegen finden Sie im RDAP, ASN, BGP und RPKI: IP-Daten richtig einordnen.
Korrekturantrag: Evidenzebenen, Zeitaufzeichnungen und Verbreitungsgrenzen
Korrekturmaterialien müssen zum konkreten Feld passen. Bereitstellungsangaben des Betreibers für diesen Adressbereich, ein gepflegtes Geofeed und die Region der Dienstbereitstellung können Hinweise auf den Nutzungsstandort liefern; Latenz, Traceroute und Reverse-DNS bieten ergänzende Beobachtungen. BGP-Kontrollplattendaten geben nicht direkt den physischen Serverstandort an und können nicht als Beleg für den genauen Standort des Rechenzentrums aufgeführt werden. Alle Materialien sollten auf Echtheit, Aktualisierungsdatum, Anwendungsbereich und ob sie sich auf die aktuelle Adresse beziehen geprüft werden, statt eine universell gültige Autoritätsrangfolge festzulegen.
Schwächere, aber berücksichtigungsfähige Materialien sind: Nutzerberichte, die Zeitzoneneinstellung des Serverbetriebssystems, die Sprache von Website-Inhalten usw. Die Zeitzone des Betriebssystems kann beliebig geändert werden und beweist nicht den physischen Gerätestandort; die Sprache der Website oder die Regionseinstellungen des Kontos spiegeln eher Inhaltspräferenzen wider als die IP-Zugehörigkeit. Laden Sie bei der Korrektureinreichung keine genaue Wohnadresse, Kontopasswörter oder Screenshots des Administrationsbereichs hoch; stellen Sie öffentliche oder betreiberseitige Unterlagen bereit, die dem Datenpfleger die Beurteilung des Nutzungsstandorts der Adresse ermöglichen.
Halten Sie zu jeder Abfrage den Zeitstempel und die Zeitzone fest. Ein hypothetisches Beispiel: Eine Adresse wird im März 2024 einer neuen Region zugewiesen, doch im Mai ist die Geodatenbank noch immer nicht aktualisiert. Ein Screenshot aus Januar kann für einen Korrekturantrag deshalb bereits veraltet sein. Ergebnisse derselben Adresse von verschiedenen Tagen helfen dabei, eine plötzliche Aktualisierung einer Quelle von Änderungen zu unterscheiden, die sich nach und nach über mehrere Quellen verbreiten. Fügen Sie eine Zeitleiste der alten und neuen Einträge bei und nennen Sie jeweils die Datenquelle. Das erleichtert die Prüfung der Belege, garantiert aber weder die Annahme der Korrektur noch eine bestimmte Bearbeitungszeit.
Datenanbieter und Website-Betreiber befinden sich in unterschiedlichen Aktualisierungsstufen. Datenquellen wie MaxMind oder IP2Location können ihre Datenbanken zuerst aktualisieren, aber Websites, die diese Daten nutzen, müssen sie erst herunterladen, bereitstellen und möglicherweise cachen. Dass eine Datenquelle ein neues Ergebnis zeigt, während eine Website noch das alte anzeigt, bedeutet daher nicht zwangsläufig, dass die Datenquelle nichts geändert hat. In solchen Fällen ist jeweils zu prüfen: Wurde die Datenquelle korrigiert? Welche Version verwendet die Website? Hat die Website eigene Cache- oder Fallback-Logiken eingerichtet?
Kein Korrekturkanal sollte zusagen, dass andere Plattformen nach einer Änderung innerhalb einer festen Frist synchronisiert werden. Die Veröffentlichung eines Geofeeds oder eine offizielle Korrektur ist lediglich der Anfang der Datenaktualisierungskette. Manche Offline-Datenbanken veröffentlichen Updates nur alle paar Monate, und manche Websites nutzen eigene oder Drittanbieterdaten statt eines direkten Abonnements der Datenquelle. Sie können nicht erwarten, dass eine einzige Einreichung alle Abfrageergebnisse gleichzeitig ändert. Nach erfolgreicher Einreichung sollten Sie dieselbe Adresse und dasselbe Feld nach Veröffentlichung einer neuen Version erneut abfragen und dies an mindestens zwei unabhängigen Zeitpunkten bestätigen. Sollte eine Plattform tatsächlich langfristig nicht aktualisieren, ist gezielt nach deren Art der Datennutzung zu fragen, statt bereits korrekte Daten wiederholt einzureichen.
Schließlich besteht das Ziel der Korrektur darin, die Daten der tatsächlichen Netznutzung anzunähern, und nicht darin, die Adresse auf ein gewünschtes Land oder eine gewünschte Stadt zu ändern. Wenn die Belege nicht ausreichen, um einen Standortfehler nachzuweisen, oder wenn die Datenquelle bereits angegeben hat, dass die Adresse zu Anycast oder einem dynamischen Ausgang gehört, werden weitere Einreichungen wahrscheinlich wirkungslos bleiben. Sie können über Datenquellen und Methodik besser nachvollziehen, wie Geodatenbanken aktualisiert und verifiziert werden.
