Die meisten IP-Geolokalisierungen gehen vernünftigerweise davon aus, dass eine bestimmte Adresse einem ungefähr festen physischen Standort oder einem stabilen, identifizierbaren Netzwerk entspricht. Anycast-Adressierung bricht diese Annahme auf eine bestimmte und interessante Weise, und es lohnt sich, das zu verstehen, falls Sie jemals Traffic geolokalisieren, der von einem Content Delivery Network oder einem großen verteilten Dienst stammt statt von einer gewöhnlichen Endnutzerverbindung.
Bei Anycast wird dieselbe IP-Adresse gleichzeitig von mehreren physischen Standorten aus angekündigt, und das Internet-Routing stellt jede Anfrage an denjenigen ankündigenden Standort zu, der aus Sicht des Anfragenden in diesem Moment am nächsten oder am günstigsten liegt. Genau so erreichen viele Content Delivery Networks niedrige Latenzen im globalen Maßstab: Dieselbe Adresse antwortet für Nutzer überall lokal, statt jede Anfrage zu einem zentralen Server zurückzuleiten. Die praktische Folge für die Geolokalisierung ist, dass dieselbe IP-Adresse tatsächlich verschiedenen physischen Serverstandorten entsprechen kann, je nachdem, wer von wo aus fragt. Das ist eine grundlegend andere Situation als bei einer gewöhnlichen IP, die an einen festen Standort gebunden ist.
Eine Geolokalisierungsabfrage für eine Anycast-Adresse versteht man daher am besten als Beschreibung des Betreibers dieses Anycast-Netzwerks und manchmal eines repräsentativen oder häufig genutzten Punkts innerhalb seiner verteilten Präsenz, nicht als einen einzelnen festen physischen Standort, wie es bei einer Abfrage für eine typische private oder geschäftliche IP der Fall wäre. Den zurückgegebenen Standort als „genau den Ort, von dem der Traffic physisch ausgeliefert wird“ zu behandeln, ist für manche Zwecke eine vernünftige Näherung und kann für andere deutlich falsch sein, je nachdem, wie sich das Anycast-Routing dieses Netzwerks bei einer bestimmten Anfrage genau verhält.
Das ist vor allem für alle wichtig, die die Herkunft von Traffic geolokalisieren wollen, der durch ein CDN oder einen ähnlichen großen verteilten Dienst läuft oder von dort stammt. Wenn Sie den Besucher einer Website anhand seiner IP identifizieren möchten, seine Anfrage aber einen Edge-Server eines CDN passiert hat, bevor sie Ihre Logging- oder Anwendungsschicht erreichte, und Sie die IP des CDN-Edge statt der des ursprünglichen Besuchers geolokalisieren, dann geolokalisieren Sie die Infrastruktur des CDN und nicht die Person, um die es Ihnen eigentlich geht. Die echte IP des Besuchers korrekt in Ihre Logs zu bekommen, typischerweise über einen auf CDN-Ebene richtig eingerichteten Forwarded-For-Header, ist hier weit wichtiger als jede Verfeinerung des Geolokalisierungsdienstes selbst, denn keine Geolokalisierungsabfrage kann einen Standort wiederherstellen, den die Anfrageschicht gar nicht erst erfasst hat.
Die Felder asn und organization sind das deutlichste Signal dafür, dass Sie es mit CDN- oder Anycast-Infrastruktur und nicht mit einer gewöhnlichen Endnutzerverbindung zu tun haben. Es lohnt sich, sie gezielt zu prüfen, wann immer die Geolokalisierungsergebnisse für einen bekannten Dienst oder eine Plattform unerwartet auf eine kleine Zahl von Standorten gebündelt erscheinen, unabhängig davon, wo sich die tatsächlichen Nutzer befinden. Unsere IPv4- und IPv6-Abfragen liefern diese Felder genau, um eine solche Diagnose zu unterstützen.