GeoDNS vs anycast: zwei Möglichkeiten, um Benutzer auf den nächsten Server zu senden
Zwei Technologien versprechen dasselbe: jeden Besucher auf einen Server in der Nähe zu schicken, aber sie entscheiden in verschiedenen Momenten, und eine von ihnen ist in den letzten Jahren ruhig weniger genau geworden.
Wenn Sie jemals eine Website geladen haben und sich aus einem Rechenzentrum auf dem falschen Kontinent ohne erkennbaren Grund bedient haben, haben Sie den Unterschied zwischen diesen beiden gefunden, und GeoDNS war mit ziemlicher Sicherheit beteiligt.
Beide Technologien existieren, um das gleiche Problem zu lösen: jeden Besucher auf einen nahe gelegenen Server zu bekommen. wenn zu entscheiden, und dieser zeitliche Unterschied erzeugt alles andere — die Genauigkeit, die Failover-Geschwindigkeit, die Kontrolle, die man bekommt und die Art und Weise, wie jeder scheitert.
GeoDNS entscheidet über die Nachbeobachtungszeit
GeoDNS trifft seine Wahl beim DNS-Lookup. Ein Resolver fragt "wo ist example.com?", der autoritative Nameserver schaut, woher die Frage zu kommen scheint, und gibt die Adresse eines Servers in der Nähe zurück. Fragen Sie aus Stockholm, nehmen Sie die nordische Kante. Fragen Sie von Sydney, holen Sie den Australischen.
Die Worte, die das schwere Heben dort sind scheint aus zu kommen. Der Nameserver sieht den Besucher nicht. Er sieht den rekursiven Resolver, der in ihrem Namen fragt, was vielleicht nicht in ihrer Nähe ist.
Anycast entscheidet zur Verbindungszeit
Anycast ahnt überhaupt nicht. Die gleiche IP-Adresse wird von jedem Ort aus bekannt gegeben, und wenn der Besucher tatsächlich eine Verbindung öffnet, liefert das Internet-Routing seine Pakete an den Ort, an den der Netzwerkpfad am nächsten ist. Es gibt keine geographische Datenbank, die falsch sein sollte, weil nichts nachgesehen wird — die Antwort ist eine Folge der Reise der Pakete.
Das Problem der Lösung und warum es schlimmer wurde
Das ist der Knackpunkt, und er ist konsequenter als vor fünf Jahren.
GeoDNS sieht die Quelladresse des Resolvers, nicht den Besucher. Wenn jemand in Kopenhagen den Resolver seines ISP benutzt, ist dieser Resolver wahrscheinlich auch in Dänemark und die Vermutung ist gut. Wenn sie einen öffentlichen Resolver verwenden, kann die Abfrage aus einem völlig anderen Land austreten, und GeoDNS gibt zuversichtlich einen Server in der Nähe zurück das.
Es gibt einen Mechanismus, um genau das zu beheben: EDNS-Client-Subnetz, eine Erweiterung, bei der der Resolver eine gekürzte Version des eigenen Netzwerks des Clients in die Abfrage einschließt, so dass der maßgebliche Server eine Entscheidung auf der Grundlage des tatsächlichen Besuchers treffen kann. Wenn es vorhanden ist, ist GeoDNS Genauigkeit gut.
Die Schwierigkeit besteht darin, dass ECS fakultativ ist und zunehmend zurückgehalten wird. Es ist ein Datenschutz-Austausch - es erzählt dem autoritativen Nameserver etwas darüber, wer fragt - und mehrere Resolver, insbesondere Datenschutz-fokussierte diejenigen und einige DNS-over-HTTPS-Implementierungen, absichtlich nicht senden Es ist. Aus der Sicht des maßgeblichen Servers ist der Standort des Clients einfach nicht verfügbar und fällt auf die Adresse des Resolvers zurück.
Das praktische Ergebnis ist das Verhalten, das Menschen als Routing "roulette" beschreiben: der gleiche Besucher auf der gleichen Verbindung immer eine andere, manchmal entfernte, Rand je nachdem, welche Resolver ihren Browser oder Betrieb Das System benutzt diesen Tag. Nichts ist falsch konfiguriert. Die Informationen, die benötigt werden, um die richtige Wahl zu treffen, sind nie angekommen.
Seite an Seite
| GeoDNS | Anycast | |
|---|---|---|
| Entscheidungsziffer | DNS-Suche | Paketführung |
| Basierend auf | Ort des Lösers oder ECS, wenn es gesendet wird | Tatsächlicher Netzwerkpfad |
| Genauigkeit mit öffentlichem oder verschlüsseltem DNS | Erniedrigt, manchmal schlecht | Unbetroffen |
| Failover-Geschwindigkeit | Durch TTL und Resolver-Verhalten kappen | Sekunden, über Streckenabfahrt |
| Deterministische Kontrolle | Volle — Sie schreiben die Regeln | Routing entscheidet |
| Anforderungen an die Einrichtung | Ein DNS-Anbieter, der ihn unterstützt | Eigener IP-Raum, ASN, BGP-Sitzungen |
| Compliance-Routing (Region X in Region X beibehalten) | Geradeaus | Schwer zu garantieren |
| Lastausgleich nach Kapazität | Leicht — Gewicht der Antworten | Kein direkter Mechanismus |
Also, was sollten Sie verwenden?
Für den allgemeinen Web-Datenverkehr für ein globales Publikum ist Anycast die robustere Wahl, und die Lücke hat sich vergrößert, da verschlüsseltes DNS sich ausgebreitet hat. Es kann nicht darüber getäuscht werden, wo ein Besucher ist, weil es nie fragt.
GeoDNS bleibt das bessere Tool, wenn Sie Entscheidungen benötigen, die Routing nicht ausdrücken kann. Wenn europäische Besucher aus Compliance-Gründen von der europäischen Infrastruktur bedient werden müssen, lässt GeoDNS Sie das in der Regel sagen; Anycast lässt Sie hoffen. Wenn ein Standort mehr Kapazität als ein anderer hat, kann GeoDNS den Verkehr darauf zusteuern. Und GeoDNS steht jedem mit einem geeigneten DNS-Anbieter zur Verfügung, während Anycast eine Infrastruktur benötigt, die die meisten Organisationen nie besitzen werden.
In der Praxis nutzen große Netzwerke beides und nicht als Kompromiss: Anycast für den schnellen Weg, wo die Lokalität das einzige Ziel ist, GeoDNS geschichtet oben, wo eine spezifische Antwort aus einem bestimmten Grund erforderlich ist.
Häufig gestellte Fragen
Was ist der Unterschied zwischen GeoDNS und Anycast?
GeoDNS wählt während des DNS-Lookups einen Server aus und gibt je nachdem, woher die Abfrage kommt, eine andere IP-Adresse zurück. Anycast kündigt eine IP-Adresse von vielen Standorten an und lässt das Internet-Routing jede Verbindung zum nächsten liefern. GeoDNS entscheidet früh vom abgeleiteten Ort; anycast entscheidet zum Zeitpunkt der Verbindung über den tatsächlichen Netzwerkpfad.
Warum schickt mich GeoDNS auf den falschen Server?
Weil es sieht, dass Ihr DNS-Resolver den Standort anstatt Ihren. Wenn Sie einen öffentlichen oder verschlüsselten DNS-Dienst verwenden, dessen Abfrage aus einem anderen Land austritt, wird GeoDNS einen Server in der Nähe dieses Landes zurückgeben. Die EDNS Client Subnet Erweiterung existiert, um einen Teil Ihrer eigenen Netzwerkadresse zu übergeben, aber es ist optional und viele Datenschutz-orientierte Resolver bewusst weglassen, so dass der maßgebliche Server mit nicht besser Informationen.
Was ist EDNS Client Subnet?
EDNS Client Subnet, oder ECS, ist eine DNS-Erweiterung, die einen rekursiven Resolver einen verkürzten Teil der IP-Adresse des Clients in seine Abfrage enthalten lässt, so dass ein autoritativer Nameserver einen Server in der Nähe der tatsächlichen Besucher eher als in der Nähe des Resolvers. Es verbessert die GeoDNS-Genauigkeit erheblich, aber es zeigt Informationen über den Client und wird daher von mehreren Privacy-focused und DNS-over-HTTPS-Resolvern weggelassen.
Ist Anycast besser als GeoDNS?
Für den allgemeinen Web-Traffic, in der Regel ja - es ist davon unberührt, welche resolver ein Besucher verwendet und schlägt über innerhalb von Sekunden anstatt warten, bis DNS-Caches ablaufen. GeoDNS bleibt besser, wenn Sie deterministische Kontrolle benötigen, wie beispielsweise den Verkehr von einer Region auf eine bestimmte Infrastruktur für die Einhaltung zu halten oder den Verkehr in Richtung Standorte mit mehr Kapazität zu gewichten. Große Netze nutzen beides häufig zusammen.
Können Sie GeoDNS und Anycast zusammen verwenden?
Ja, und es ist ein gemeinsames Design. Anycast behandelt den Standardfall und gibt jedem Besucher einen nahegelegenen Rand mit einem schnellen Failover, während GeoDNS für die Fälle, die eine spezifische Antwort erfordern, zusätzlich geschichtet ist — regionale Compliance-Anforderungen, Kapazitätsgewichtung oder Lenkung bestimmter Zielgruppen auf eine bestimmte Infrastruktur. Die beiden arbeiten in verschiedenen Phasen und kollidieren nicht.
Wenn Sie eine Sache aus dem Vergleich: GeoDNS ist eine Inferenz und Anycast ist eine Messung. Die Schlussfolgerungen können falsch sein, und in den letzten Jahren, als mehr Verkehr in verschlüsselte und öffentliche DNS verschoben, sie haben sich öfter geirrt.
Sehen Sie, wie NordicCDN dies für Ihre Website tut:
Mads hat seit seinem 16. Lebensjahr in der IT gearbeitet — hauptsächlich als Hosting. Er beteiligte sich früh an einer SaaS-Firma und half, sie bis zur Übernahme durch Visma weiterzuentwickeln, hat Data-Center-Netzwerke aufgebaut und betrieben und diente als CTO eines dänischen Rechenzentrums. Er hat NordicCDN gestartet, um eine schnelle, sichere Infrastruktur einfach zu bedienen.
