Eine IP-Geolokalisierungsdatenbank von Grund auf aufbauen

 (ipapi.is)
5 Punkte von GN⁺ 2023-09-15 | 1 Kommentare | Auf WhatsApp teilen
  • Eine IP-Geolokalisierungsdatenbank verknüpft IP-Bereiche mit Land, Stadt, Postleitzahl, Zeitzone und Koordinaten; ipapi.is bietet kostenlose CSV- sowie kommerzielle CSV/MMDB-Datenbanken an
  • Die Gratisversion deckt nicht den gesamten IPv4- und IPv6-Adressraum ab und ist weniger präzise, die kommerzielle Version ist jedoch die vollständige Datenbank, die im location-Feld der API verwendet wird, und wird mindestens zweimal pro Woche aktualisiert
  • Wer so etwas selbst aufbauen will, muss geoloc und geofeed aus WHOIS, Standortableitung aus WHOIS-Adress- und Beschreibungsfeldern sowie öffentliche Projekte wie RIPE IPmap, geofeed-finder und OpenGeoFeed gemeinsam nutzen
  • Wenn Netzwerke auf mehrere Regionen verteilt sind oder IPs neu zugewiesen bzw. vermietet werden, leidet die Genauigkeit; die geoloc-Abdeckung bei RIPE NCC lag im Juli 2023 bei 2,3 %, die Abdeckung von geofeed-URLs bei 0,17 %
  • Gesammelte Daten erfordern Anreicherung und Normalisierung, etwa um aus Stadt/Land Koordinaten zu ermitteln oder aus Koordinaten die nächste Stadt zu finden; ipapi.is nutzt dafür GeoNames-Dateien für Postleitzahlen, Städte und Länder

Aufbau einer IP-Geolokalisierungsdatenbank

  • Eine IP-to-Geolocation-Datenbank speichert Geolokalisierungsinformationen für einzelne IP-Bereiche
  • Eine IP-Adresse kann mit folgenden Informationen geolokalisiert werden
    • Land, Stadt, Bundesstaat/Region, Postleitzahl
    • Zeitzone
    • Breitengrad, Längengrad
  • Die Datenbank von ipapi.is ist in eine Gratisversion und eine kommerzielle Version unterteilt
    • Die Gratisversion kann im CSV-Format heruntergeladen werden
    • Die kommerzielle Version wird im CSV- und MMDB-Format bereitgestellt
    • Die kommerzielle Version deckt den gesamten IPv4- und IPv6-Adressraum ab
    • Die Gratisversion enthält nur einen Teil des IPv4- und IPv6-Adressraums
  • Die kommerzielle Datenbank wird mindestens zweimal pro Woche aktualisiert

Unterschiede zwischen Gratis- und kommerzieller Version

  • Die kostenlose IP-Geolokalisierungsdatenbank hat weniger Einträge als die kommerzielle Version und deckt nicht den gesamten IPv4- und IPv6-Adressraum ab
  • Die Gratisversion hat eine geringere Geolokalisierungsgenauigkeit
  • Die wichtigsten Quellen der Gratisversion sind WHOIS-Daten und RFC 8805 Geofeeds
  • Die kommerzielle Datenbank ist die vollständige Datenbank, die im location-Feld der API von ipapi.is verwendet wird
  • Die kommerzielle Version ermittelt Standorte durch die Kombination mehrerer Quellen
    • WHOIS-Einträge
    • ping- und traceroute-basierte aktive Latenzmessungen
    • RFC 8805 Geofeeds
    • Reverse-DNS-Lookups

Datenbankformate und Genauigkeitsfeld

  • Die Datenbankdateien liegen im CSV- oder MMDB-Format vor
  • Wichtige Felder enthalten zusammen IP-Bereich, Standort, Koordinaten und Genauigkeit
    • ip_version: IPv4 ist 4, IPv6 ist 6
    • start_ip, end_ip: Start- und End-IP des Netzbereichs
    • continent, country_code, country, state, city, zip
    • timezone, latitude, longitude
    • accuracy
  • accuracy kennzeichnet die geschätzte Genauigkeit der Geolokalisierungsinformation auf einer Skala von 1 bis 5
    • 1: sehr hohe Genauigkeit, meist auf Stadtebene zuverlässig
    • 2: hohe Genauigkeit, in der Regel auf Stadtebene zuverlässig
    • 3: mittlere Genauigkeit, auf Stadtebene nicht zuverlässig
    • 4: geringe Genauigkeit, meist auf Länderebene korrekt
    • 5: sehr geringe Genauigkeit, voraussichtlich nur auf Länderebene korrekt

So prüft man ein MMDB-Beispiel

Einsatz und Grenzen der IP-Geolokalisierung

  • IP-Geolokalisierung ist der Prozess, eine IP-Adresse auf einen durch Breiten- und Längengrad definierten geografischen Standort abzubilden
  • Online-Unternehmen und Serviceanbieter nutzen Geolokalisierungsinformationen für verschiedene Zwecke
    • zielgerichtete Werbung
    • Betrugserkennung und -verhinderung
    • Lokalisierung von Inhalten
    • DRM und Compliance
    • Netzwerksicherheit
    • Analysen und Insights
  • Dass IP-Geolokalisierung nicht immer genau ist, hat strukturelle Gründe
    • Zugewiesene IPv4- und IPv6-Netze können geografisch verteilt sein
    • Es gibt Netze, die sich über mehrere Regionen erstrecken, etwa Mobilfunk- oder Satellitennetze
    • Wenn ein Regional Internet Registry oder ein Unternehmen für IP-Vermietung IP-Netze neu zuweist oder weitervergibt, kann sich der Standort ändern
  • Die Geolokalisierung von IP-Adressen ist komplex, kann aber bei IP-Adress-APIs eine Genauigkeit liefern, die schwer zu ignorieren ist

Was für einen Aufbau von Grund auf nötig ist

  • Jede IP-Adresse im Internet gehört einer bestimmten Organisation oder wird von ihr verwaltet
  • Regional Internet Registries (RIRs) wie ARIN und APNIC speichern Eigentumsinformationen in WHOIS-Datenbanken
  • WHOIS-Einträge enthalten nicht immer Geolokalisierungsinformationen für zugewiesene Netze
  • Organisationen, denen Netzwerke gehören, können IPs an beliebigen geografischen Standorten nutzen, an Dritte weitergeben oder IP-Blöcke vermieten
  • Die Erfassung von Geolokalisierungsinformationen lässt sich grob in drei Bereiche unterteilen
    • Extraktion direkter Geolokalisierungsdaten wie geoloc und geofeed aus WHOIS-Einträgen
    • indirekte Standortableitung aus Postadresse, Beschreibung und Länderangaben in WHOIS
    • Nutzung öffentlicher Projekte wie RIPE IPmap, geofeed-finder und OpenGeoFeed

Direkte Geolokalisierungsdaten je RIR

  • RIPE NCC

    • Die Objekte inetnum und inet6num von RIPE NCC weisen IP-Netze Organisationen zu
    • Geolokalisierungsinformationen können über die beiden Attribute geoloc und geofeed bereitgestellt werden
    • geoloc enthält Breitengrad und Längengrad als Zeichenkette
    • Beispiel: 47.855374 12.132041
    • Im Juli 2023 enthielt die Datenbank von RIPE NCC 4.190.644 inetnum- und 819.381 inet6num-Objekte
    • Davon enthielten 114.389 Objekte das Attribut geoloc, was einer Gesamtabdeckung von 2,3 % entspricht
    • geofeed enthält die URL einer CSV-Datei im Format von RFC 8805
    • Eine geofeed-URL kann in einem dedizierten geofeed-Attribut oder im remarks-Attribut im Format Geofeed {URL} stehen
    • Im Juli 2023 gab es bei RIPE NCC 6.643 geofeed-URLs im remarks-Attribut und 2.035 WHOIS-Einträge mit einem geofeed-Attribut
    • Die Abdeckung von geofeed-URLs beträgt 0,17 %, diese Zahl kann aber irreführend sein, weil eine einzelne geofeed-Datei mehrere Netze enthalten kann

  • ARIN

    • ARIN stellt Geolokalisierungsinformationen bereit, indem eine geofeed-URL im Attribut Comment des NetRange-Objekts hinterlegt wird
    • Ein Antrag auf ein eigenes geofeed-Attribut wurde zwar gestellt, aber mit der Begründung abgelehnt, Comment oder Remark reichten aus
    • Anders als RIPE NCC verwendet die ARIN-Datenbank kein geoloc-Attribut

  • LACNIC

    • LACNIC ist bei der Unterstützung von Geolokalisierung aktiver als ARIN
    • LACNIC betreibt einen Geofeed Service, über den Mitglieder Geolokalisierungsinformationen für ihre IP-Adressen bereitstellen können
    • Öffentliche Daten sind unter milacnic.lacnic.net/lacnic/geofeeds verfügbar
    • Die WHOIS-Datenbank von LACNIC liefert standardmäßig Geolokalisierungsinformationen auf Stadtebene
    • Die LACNIC-Datenbank kann vom FTP-Server ftp.lacnic.net/lacnic/dbase/ heruntergeladen werden

  • AFRINIC und APNIC

    • AFRINIC gibt an, keinen Geolokalisierungsdienst anzubieten und auch keine formale oder operative Beziehung zu Geolokalisierungsanbietern zu haben
    • AFRINIC unterstützt ähnlich wie RIPE NCC die Verwendung von geofeed-URLs im remarks-Attribut
    • APNIC unterstützt Geolokalisierung nahezu auf dem gleichen Niveau wie RIPE NCC
      • geoloc-Attribut
      • geofeed-URLs im remarks-Attribut
    • APNIC zeigt sich offen für Verbesserungen bei der Geolokalisierungsunterstützung

Methoden zur Standortableitung aus WHOIS

  • Der Hauptzweck von WHOIS besteht darin, Registrierungsinformationen über die Organisation bereitzustellen, der Internetnummern wie IP-Adressen oder AS-Nummern gehören
  • WHOIS enthält häufig die Postadresse und das Land des Hauptsitzes oder Verwaltungsstandorts einer Organisation
  • Manchmal entspricht die Postadresse einer Organisation dem tatsächlichen Nutzungsort der IP-Adressen, aber eben nicht immer
  • Bei großen Organisationen muss die Verwaltungsadresse nicht mit dem Standort aller ihrer IP-Adressen übereinstimmen

  • Ableitung bei RIPE NCC

    • In den Objekten inetnum und inet6num von RIPE NCC können folgende Attribute genutzt werden
      • country: liefert nur Genauigkeit auf Länderebene
      • descr: Netzwerkbeschreibung, kann Standort- oder Adressinformationen enthalten
      • netname: schwer zu parsen und wenig verlässlich
      • address: streng genommen ein Attribut des role-Objekts und enthält die Postadresse
    • Das Attribut country identifiziert den zweistelligen ISO-3166-Ländercode, legt aber nicht fest, ob dieses Land dem Hauptsitz, dem Rechenzentrum oder dem Endnutzerstandort entspricht
    • Das Attribut descr ist Freitext, kann aber für die Geolokalisierungsableitung nützlich sein, wenn Organisationen dort Standort- und Adressinformationen eintragen
    • address kann hohe Genauigkeit liefern, führt aber zu Fehlern, wenn man annimmt, dass die Postadresse eines Rollenobjekts dem tatsächlichen Nutzungsort der IP-Adresse entspricht

  • Ableitung bei ARIN

    • Bei ARIN können die folgenden WHOIS-Attribute bei kleinen Organisationen oder Organisationen mit nur einem Standort relativ zuverlässig sein
      • Address
      • City
      • StateProv
      • PostalCode
      • Country
    • Organisationen wie Universitäten, Krankenhäuser oder Behörden nutzen die IP-Adressen eines NetRange-Objekts mitunter am gleichen Ort wie ihre Verwaltungsadresse
    • Bei großen Unternehmen oder landesweit tätigen Organisationen mit vielen NetRange-Bereichen kann die Verwaltungsadresse jedoch vom tatsächlichen Nutzungsort abweichen
    • Im Beispiel Google Fiber landet man mit der WHOIS-Adresse in Mountain View, California, die meisten Geolokalisierungsanbieter verorten die betreffende IP jedoch in San Antonio, Texas

  • LACNIC, AFRINIC, APNIC

    • LACNIC liefert Geolokalisierung bereits in der WHOIS-Datenbank, daher ist keine separate Ableitung nötig
    • AFRINIC verwendet dasselbe WHOIS-Datenbankformat wie RIPE NCC, daher lassen sich dieselben Prinzipien anwenden
      • country, descr
      • address im role-Objekt
    • APNIC verwendet ebenfalls dasselbe WHOIS-Datenbankformat wie RIPE NCC, daher gelten dieselben Prinzipien

Öffentliche Geolokalisierungsprojekte

  • RIPE IPmap

    • RIPE IPmap war eine API für Geolokalisierungsdaten zentraler Internetinfrastruktur
    • Es scheint nicht mehr gepflegt zu werden; seit 2019 scheint es keine neuen Beiträge mehr gegeben zu haben
    • RIPE IPmap leitete die Geolokalisierung von IP-Adressen mit mehreren Engines ab
    • Die Engines latency und single-radius nutzten Messwerte von RIPE Atlas, um einen Latenzradius für IP-Adressen bereitzustellen
    • Minimale RTT-Messwerte liefern wegen der Lichtgeschwindigkeit in Glasfaser eine Obergrenze für die maximal mögliche Entfernung
    • Die Engine reverse-dns extrahierte Geolokalisierung auf Stadtebene aus Hostnamen von PTR-Einträgen
    • Die RIPE-IPmap-Datenbank kann unter https://ftp.ripe.net/ripe/ipmap/ heruntergeladen werden
    • Genauigkeit und Abdeckung des Projekts haben laut der Website des früheren Maintainers deutlich nachgelassen

  • geofeed-finder

    • geofeed-finder ist ein Open-Source-Tool, das geofeed-Dateien in WHOIS-Daten erkennt und abruft
    • Das Tool übernimmt außerdem die Verifizierung von Prefix-Eigentum, Cache-Verwaltung und ISO-Code-Prüfung
    • Gemäß RFC 9092 lassen sich geofeeds aus WHOIS-Daten extrahieren
    • Da die Abdeckung von geofeed-Informationen im gesamten Netz sehr gering ist, bleibt die praktische Nutzbarkeit begrenzt

  • LACNIC Geofeeds Service und OpenGeoFeed

    • Der LACNIC Geofeeds Service liefert Geolokalisierungsinformationen für einen erheblichen Teil der LACNIC-Mitglieder
    • Die Daten können unter milacnic.lacnic.net/lacnic/geofeeds öffentlich heruntergeladen werden
    • Das ist ein wichtiges Projekt, weil es zeigt, dass sich Geolokalisierungsinformationen auf RIR-Ebene sammeln lassen
    • OpenGeoFeed ist ein Open-Source-Projekt, das eigene öffentliche geofeeds nach RFC 9092 sammelt
    • OpenGeoFeed stellt eine einzelne Datei mit bekannten öffentlichen geofeed-Dateien bereit: opengeofeed.org/feed/public.csv
    • OpenGeoFeed ist vielversprechend, allerdings scheint die geofeed-Abdeckung nicht aktuell zu sein und die Datenquellen dürften nur selten aktualisiert werden

Datenanreicherung und Normalisierung

  • Rohdaten zur Geolokalisierung aus verschiedenen Quellen können unvollständig oder inkonsistent sein
  • Es kann sowohl Einträge mit Land- und Stadtangaben ohne Koordinaten als auch Einträge mit Koordinaten ohne Land- und Stadtangaben geben
  • Wenn ein Rohdatensatz nur das Land enthält, ist eine Genauigkeit über Länderebene hinaus kaum erreichbar
  • Die gesammelten Daten müssen in ein gemeinsames Format angereichert und transformiert werden
  • Die Datenanreicherung erfolgt mithilfe von Open-Source-Geodatenbanken
  • Bei der Anreicherung gibt es zwei Fälle
    • Breitengrad und Längengrad anhand eines Stadt-Land-Paars finden
    • Aus Breitengrad und Längengrad die nächstgelegene Stadt und das Land bestimmen
  • ipapi.is verwendet für die Anreicherung von Geolokalisierungsinformationen die folgenden Datenbanken

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-15
Kommentare auf Hacker News

  • Ich habe seine Beiträge schon gern gelesen, bevor ich zu IPinfo kam, und IPinfo bietet IP-Geolocation-Datendienste an.
    Wir verwenden eine gegenüber der hier beschriebenen Methode erweiterte Methodik und nutzen auch einige öffentliche Datensätze, aber unsere zentralen Standortdaten stammen aus pingbasierten Messungen.
    Wir senden von mehreren Servern weltweit Pings an IP-Adressen und bestimmen den Standort per Multilateration. Ein Ping von einem einzelnen Server liefert nur eindimensionale Information – irgendwo innerhalb eines bestimmten Radius –, aber wenn man das von mehreren Servern aus wiederholt, wird der Standort immer genauer.
    Mit genügend Messungen lässt sich eine Genauigkeit erreichen, die nahe an die Postleitzahlenebene herankommt; derzeit haben wir weltweit mehr als 600 Messserver und bauen das Netzwerk weiter aus.
    Öffentliche Daten sind veraltet oder werden nicht häufig aktualisiert, sind im Allgemeinen nicht präzise genug, um nützlich zu sein, und liefern oft nur Standorte für große IP-Bereiche oder Organisationen.
    Außerdem gibt es bei öffentlichen Datensätzen keinen Verifizierungsprozess. Mit der Zunahme von IPv4-Handel und VPN-Diensten haben wir auch Fälle gesehen, in denen falsche Informationen eingeschleust wurden; daher nehmen wir Hinweise zur Korrektur von IP-Standorten dankbar an, verifizieren sie aber immer.
    Aus Erfahrung mit dem Betrieb eines Messnetzwerks ist es sehr viel einfacher und günstiger, in New York einen Server zu kaufen als in irgendeinem Land in Zentralafrika. Der Standort einer IP-Adresse hat großen Einfluss darauf, welchen Wert diese IP bieten kann.
    Wir stellen auch eine kostenlose IP-to-Country-ASN-Datenbank bereit, die man für Projekte nutzen kann: https://ipinfo.io/developers/ip-to-country-asn-database

    • Ich frage mich, von welchen Beiträgen du ein Fan bist. Von den Artikeln auf https://incolumitas.com/ oder von denen auf https://ipapi.is/?
      Die Idee der Latenz-Triangulation gefällt mir. Ich habe Latenzinformationen für verschiedene Zwecke wie VPN- und Proxy-Erkennung verwendet, hätte aber nicht gedacht, dass man damit einen so genauen Standort erhalten kann.
      Mit 600 Servern dürfte Latenz-Triangulation eine ziemlich gute Näherung liefern; das ist beeindruckend.
      Ein paar Dinge würde ich allerdings gern wissen: Wie geht ihr damit um, dass manche ISPs ICMP-Traffic mit niedriger Priorität behandeln oder drosseln? Wenn man alle IPv4-Adressen geolokalisieren will, müsste man ständig Milliarden von Adressen anpingen – messt ihr also nur eine zufällige IP pro zugewiesenem inetnum/NetRange? Und da die meisten IP-Adressen nicht auf ICMP antworten: Findet ihr den Router vor dem Ziel und bestimmt dessen Standort?
    • Anycast-Adressen lassen sich über ICMP-Antwortzeiten nur schwer einem „Standort“ zuordnen, und bei manchen ist zusätzlich ein logischer Standort verknüpft. Ein Beispiel findet sich unter https://blog.cloudflare.com/icloud-private-relay/
    • Als Fan und Kunde von IPinfo nutzen wir die API, um in Login-Benachrichtigungen Formulierungen wie „Sie haben sich gerade aus Berlin, Deutschland, angemeldet. Wenn Sie das nicht waren, klicken Sie hier“ einzubauen.
      Wir verwenden sie außerdem für Länderdaten in Kunden-Audit-Logs sowie zur Spam-Abwehr und Betrugserkennung.
    • Ich frage mich, ob ihr schon darüber nachgedacht habt, die Datenbank im Parquet-Format zum Download anzubieten.
      Dann könnte man die Datei nach S3, Google Cloud usw. kopieren und direkt mit verschiedenen Tools abfragen. Mit CSV geht das zwar auch, aber nicht besonders reibungslos.
    • Ich hatte mich gefragt, wie man den Standort einer IP-Adresse herausfindet, wenn es keine vorhandenen Informationsquellen gibt; diese Erklärung ist genau das, was ich wissen wollte, und deshalb sehr interessant.

  • Wenn man es nicht selbst implementieren möchte, kann man es mit einem einfachen Cloudflare Worker kostenlos von Cloudflare erledigen lassen. Jede Cloudflare-Anfrage enthält grobe Informationen zum IP-Standort.
    Man kann auch eine Anfrage an diese URL schicken, die über einen Cloudflare Worker läuft. Weltweit sollte die Latenz niedrig sein: https://www.edenmaps.net/iplocation
    Für kleine Apps ist das in Ordnung; ich bitte nur darum, nicht 10 Millionen Anfragen pro Tag dorthin zu schicken.

    • Besser ist es, eine IP-Datenbank herunterzuladen und zu verwenden, statt einem Dritten mitzuteilen, welche IP-Adressen möglicherweise auf den Dienst zugegriffen haben.
    • Bei mir zeigt es einen Ort 100 km vor der Küste Somalias an, tatsächlich bin ich aber in Brüssel, Belgien. Danke für den Datenschutz :D
    • Weiß jemand, wie genau die Cloudflare-Geolocation bei Worker-Anfragen ist?
    • Großartig. Falls möglich, würde ich mich freuen, wenn du den Code als Open Source veröffentlichen könntest.
    • Ich bin in München, aber Cloudflare zeigt auf einen zufälligen Wald 730 km nördlich.

  • Ich lebe in einem Land, dessen Landessprache nicht meine Muttersprache ist, und ich hasse Websites wirklich, die die Sprache anhand des IP-Standorts erraten und sie erzwingen.
    Obwohl der Browser den Sprach-Header sehr eindeutig sendet, ignorieren sie ihn und legen die Sprache auf Basis einer faulen Annahme fest.

    • Ich arbeite bei einem IP-Geolocation-Dienst, aber ich hasse das ebenfalls.
      In der Branche nennt man das „Personalisierung der Web-Erfahrung“, aber es ist eine nervige Art davon. Ich habe niemandem je empfohlen, das so zu machen.
      Wenn man eine Website per IP-Geolocation personalisiert, ist das Beste wohl so etwas wie Steuern, Versandkosten oder das Land des Nutzers in einem Länder-Dropdown ganz nach oben zu setzen.
      Darüber hinaus fällt mir kaum etwas ein. Übersetzungen funktionieren meist nicht gut und stören nur. Selbst wenn eine Website gute Absichten hat, ist es keine gute Idee, mit Google Translate eine lokale Sprachversion zu erstellen.
    • Ich lebe in den USA, und auf allen meinen Geräten zeigt die IP-Geolocation auf falsche Regionen.
      Es gibt nur wenige Technologien, die das alltägliche Interneterlebnis so sehr ruinieren wie diese Datenbanken.
      Ich wünschte, sie würden einfach verschwinden.
      Websites könnten beim ersten Laden einfach nach der Postleitzahl fragen, statt jedes Mal falsch zu raten und den Korrekturablauf hinter mehreren Links und Seitenladevorgängen zu verstecken.
      Außerdem gibt es keine Möglichkeit, die Datenbank zu korrigieren und eine „richtige“ oder „bessere“ Antwort zu erzeugen, weil ich fast nie möchte, dass eine Website meinen aktuellen Standort verwendet.
      Meistens prüfe ich den Lagerbestand eines Geschäfts an einem Ort, zu dem ich später fahren werde. Dieses ganze Feld versucht im Grunde, ein schlecht definiertes Problem zu lösen.
    • Dieselbe Frustration war so groß, dass ich sogar einen Artikel dazu geschrieben habe: https://www.fer.xyz/2021/04/i18n

  • Hängt vom Einsatzzweck und der benötigten Genauigkeit ab
    Die beste Methode, einen Geolocation-Dienst aufzubauen, ist, eine Milliarde Geräte zu haben, die gleichzeitig ihren Standort und ihre IP melden. Praktisch sind Apple und Google in dieser Position
    Da sie laufend Aktualisierungen zu IPs und Standorten erhalten, haben sie die besten Geolocation-Datenbanken der Welt
    Der Kern ist, eine App zu bauen, bei der Menschen freiwillig ihren Standort bereitstellen, und dafür zu sorgen, dass viele Menschen diese App nutzen. Deshalb verlangen heutzutage alle Apps Standortberechtigungen
    Foursquare war im Prinzip auf dem richtigen Weg, war aber zu früh dran

    • Schon vor 10 Jahren verhinderten Apples interne Datenschutzrichtlinien, dass Apple präzise Breiten- und Längengrade sammelte
      Um zu bestimmen, welcher Endpunkt für eine bestimmte IP oder ein Subnetz optimal ist, musste man HTTP-Session-Telemetrie verwenden, und daraus entstand eine eigene GeoIP-ähnliche Datenbank auf Basis realer Bedingungen
      Trotzdem musste sie aus Datenschutzgründen so kurzlebig wie möglich gehalten werden. Die Reverse-Geocoding-Ergebnisse von Apple Maps durften außerhalb des Kontexts von Echtzeit-Nutzeranfragen, etwa der Suche nach Restaurants in der Nähe, weder verwendet noch protokolliert werden

  • In gewisser Weise damit verwandt: Google Maps kann IP-Standorte daraus lernen, welche Orte man auf der Karte erkundet
    Wenn man einen bestimmten Ort oft genug ansieht, verwendet Google Maps diesen Ort beim Öffnen als Standardposition, selbst wenn man alle Cookies löscht
    Das ist mir bei der Nutzung von Google Maps aufgefallen, und wenn man bedenkt, dass mehrere Personen dieselbe IP-Adresse teilen können, ist der Datenschutzaspekt etwas beunruhigend

    • Das Gegenteil scheint wahrscheinlicher. Google hat eine sehr gute IP-Geolocation-Datenbank und nutzt sie offenbar für den angezeigten Standort, wenn keine anderen Informationen vorliegen
    • Deshalb werde ich wohl manchmal als an dem Fluss angezeigt, auf dem ich häufig rudere, und manchmal als dort, wo mein Sommerhaus steht
    • Das wird auch für Google Workspace und Datenresidenz sowie zur Bestimmung der Zuständigkeitsbereiche von Strafverfolgungsbehörden genutzt

  • Interessant, aber ich glaube nicht, dass die tatsächliche Geolocation so berechnet wird
    ARIN/RIPE-Daten sind über die Länderebene hinaus nicht genau genug und daher nicht nützlich
    Kommerzielle Geolocation korreliert Client-IPs mit bekannten physischen Standorten. Zum Beispiel mit WiFi-AP-Informationen oder Paketzustellungen an Nutzer. Zumindest habe ich das seit Jahrzehnten so gehört

    • Ich arbeite im Bereich Adtech, und dort wird Geolocation so gehandhabt
      Es gibt auch Geräte-Geolocation, aber wenn der Nutzer dem Teilen von GPS-Daten nicht zustimmt, wird fürs Targeting nur die IP-Adresse verwendet. Ein verbreiteter Anbieter ist MaxMind, der eine Datenbank ausliefert, die man lokal hostet und abfragt

  • Die Kommentare sind ziemlich zynisch, aber ich persönlich fand das wirklich interessant
    Es erinnert mich daran, wie ich in meinem ersten Job PostGIS und standortbasierte Suche zu einer Datenbank hinzugefügt habe. Damals basierte das auf Adressen und Postleitzahlen

    • Auch mit MySQL lässt sich das relativ einfach machen. Ein Trick ist, statt eines Kreises ein Quadrat zu verwenden; damit kann man viele mathematische Berechnungen vermeiden

  • Vor ziemlich langer Zeit habe ich http://www.hostip.info gebaut. Das war ein Dienst, der die Standorte von IP-Adressen gemeinschaftlich sammelte, nach dem Motto: „Ist diese Schätzung falsch? Bitte korrigieren“
    Als ich zuletzt nachgesehen habe, vermutlich vor etwa 10 Jahren, waren die Länder fast perfekt, die Regionen lückenhaft, und die Städte waren besser als ein Münzwurf. Alle Daten sind kostenlos
    Ich weiß nicht, ob es noch auf der Website ist, aber es gab auch einen rotierenden 3D-Würfel, der bekannte Adressen oder aktuelle Abfragen anzeigen sollte. x, y und z waren die ersten drei Oktette der Adresse, und nach Gruppen wie Land oder Kontinent wurden unterschiedliche Farben verwendet
    Das Ganze ist so alt, dass es als Java-Applet geschrieben war. Wenn ich es heute neu bauen würde, würde ich wohl WebGL verwenden
    Ich habe es vor langer Zeit verkauft, aber unter der Bedingung, dass die Daten immer kostenlos bleiben müssen. Zuerst hielt ich das Angebot per E-Mail für Betrug und glaubte nicht daran, aber über escrow.com lief alles gut, und ich denke, beide Seiten waren am Ende zufrieden. Das ist jetzt fast 20 Jahre her

  • Sieht aus wie eine moderne Version des zuvor erwähnten ping-basierten GeoIP: https://github.com/Ne00n/yammdb

    • Da es lediglich auf eine bereits kompilierte mmdb-Datei verweist, gibt es daran nichts, was man als „moderne“ Implementierung bezeichnen könnte, solange die Implementierung nicht offenliegt

  • Ich bin an Vorschlägen interessiert, wie man Data-Center-IPs zumindest sehr grob geografisch lokalisieren kann
    Ich analysiere traceroute-Daten und kenne Start- und Endpunkt, aber interessant sind die Zwischenstrecken
    Zum Beispiel lässt sich aus Flughafen-Codes in Node-Hostnames ein Teil der Informationen ableiten
    Unter der Annahme, dass ein bestimmter Node-Zustand nicht schlecht ist, dürfte sich die Position auch über die durchschnittliche RTT-Zeit abschätzen lassen
    Problematische Beispiel-IPs sind 193.142.125.129, 129.250.6.113 und 129.250.3.250. Sie tauchen in britischen traceroutes auf und ich gehe davon aus, dass sie in London sind, aber die Geolocation-Ergebnisse sind über die ganze Welt verstreut

    • Diese IPs gehören Google und NTT, und beide betreiben große internationale Netze, sodass sie IPs bei Bedarf weltweit umplatzieren können. Deshalb ist abfragebasierte Geolocation, wie bereits gesehen, unzuverlässig
      Die traceroutes zu diesen IPs lassen es so aussehen, als würde das Netzwerk nach London gehen
      Die Google-IP antwortet nicht auf Ping, die NTT/Verio-Seite aber schon. Wenn man von London-basiertem Hosting aus pingt, ist die Wahrscheinlichkeit hoch, Antwortzeiten im einstelligen Millisekundenbereich zu bekommen; damit ließe sich eine obere Grenze für die Entfernung von London bestimmen
      Wenn man außerdem von anderem Hosting innerhalb Großbritanniens und von der anderen Seite des Ärmelkanals pingt, kann man prüfen, ob der niedrigste Ping von London-Hosting kommt. Allerdings kann die Konnektivität lediglich über London laufen, während der tatsächliche Standort anderswo ist; vollständig wissen lässt es sich also nicht
      Man sollte es auch von anderen Messpunkten aus prüfen, um auszuschließen, dass es Anycast ist. Wenn man 8.8.8.8 aus den meisten Netzen weltweit anpingt, landet man an einem nahegelegenen Ort; bei diesen IPs geht die traceroute aber selbst aus der Region Seattle nach London, daher sind sie zumindest derzeit wahrscheinlich kein Anycast
      Wenn man kein Hosting weltweit hat, kann man nach öffentlichen Looking Glasses gut angebundener Netze suchen, über die man solche Pings gelegentlich ausführen kann
    • TULIP sah vielversprechend aus
      Dort heißt es: „Ziel von TULIP ist es, den Standort eines Zielhosts zu bestimmen, der durch IP-Namen oder -Adresse identifiziert wird, indem Ping-RTT-Verzögerungsmessungen von Referenz-Landmark-Hosts mit gut bekannten Standorten zum Ziel verwendet werden“
      https://tulip.slac.stanford.edu/
      Der veröffentlichte Endpoint scheint aber tot zu sein
    • In https://ensa.fi/papers/geolocation_imc17.pdf finden sich einige Ideen
      RTTs von RIPE-Atlas-Probes mit bekannten Standorten zu diesen IPs zu erhalten, kommt der genannten Idee nahe und ist vermutlich ohnehin die beste Methode
    • Wenn man eine populäre App oder einen Webservice betreibt, würde man eine eigene AS-Nummer haben, unter diesem AS einige IP-Blöcke kaufen und diese Adressen von mehreren eigenen oder gemieteten Data-Centern weltweit aus announcen
      Solche BGP-Announcements gehen von verschiedenen Standorten zu unterschiedlichen Upstream-ISPs
      Wenn der Upstream eines Announcements von einem bestimmten Standort ein regionaler ISP ist, kann man bis zu einem gewissen Grad vermuten, dass sich das Data-Center in dieser Region befindet. Handelt es sich aber um einen Tier-1-ISP mit direkter weltweiter Konnektivität, ist selbst diese Schätzung schwierig
      BGP-Beziehungen lassen sich in Looking-Glass-Tools wie bgp.tools ansehen: https://bgp.tools/prefix/193.142.125.0/24#connectivity
      Wenn man von mehreren Probes mit bekannten Standorten weltweit traceroute ausführen kann, lässt sich anhand fester IPs der Interfaces von Zwischenroutern triangulieren
      Nutzt man jedoch ein CDN wie Cloudflare, annonciert den eigenen IP-Block von über 200 PoPs aus und lässt den Traffic über deren privates Netz zu Data-Centern weltweit laufen, bricht auch diese Methode zusammen