Könnte ein Nameserver IP-Adressen basierend auf einer Strategie dynamisch auflösen?


11

Wir haben einige Nameserver für die DNS-Auflösung für unsere Website registriert, die in mehreren Rechenzentren bereitgestellt wird.

Unsere derzeitige Strategie der DNS-Auflösung besteht darin, dass der Nameserver basierend auf den verschiedenen Client-IP-Adressen unterschiedliche IP-Adressen für dieselbe Domäne zurückgibt. Wenn die Client-IP-Adresse beispielsweise aus Nordamerika stammt, gibt der Nameserver eine IP-Adresse zurück, die die IP-Adresse unseres Rechenzentrums in Nordamerika ist.

Die Client-IP-Adresse ist jedoch manchmal nicht die tatsächliche IP-Adresse der Benutzer. Dies kann eine IP-Adresse von DNS sein, die einem ISP oder einem Proxyserver gehört. Wenn andererseits eines unserer Rechenzentren ausgefallen ist, möchten wir, dass unser Nameserver die IP-Adresse ausschließt, die zum abgestürzten Rechenzentrum gehört. Wir hoffen daher, dass wir eine dynamischere Strategie für unsere DNS-Lösung erhalten können. Gibt es dafür eine Lösung?


Das klingt nach einem Fall für Anycast.
Ron Maupin

1
@RonMaupin Es darauf hingewiesen werden sollte , dass Anycast man eine hat zu tun haben Provider unabhängige Adressblockzuordnung und was noch wichtiger ist BGP laufen die Präfixe von jedem Datenzentrum zu werben. Das ist eine völlig neue Ebene der Geschäftstätigkeit und nicht etwas, mit dem viele "inhaltsorientierte" Unternehmen Erfahrung haben würden. DNS-basierte Lösung sieht viel einfacher aus.
IPX

@IPX, ich würde mir vorstellen, dass ein Unternehmen mit Rechenzentren auf der ganzen Welt, wie es in der Frage scheint, eine anbieterunabhängige Adressierung und eine eigene AS-Nummer haben wird. Damit ist Anycast kostenlos und einfach.
Ron Maupin

1
@ RonMaupin Wenn das OP-Unternehmen tatsächlich mehrere Rechenzentren auf der ganzen Welt betreibt, dann ja, aber dann würden sie hier wahrscheinlich keine relativ einfache Frage stellen. Ich wette, sie finden einfach ihre eigene oder gemietete Hardware in mehreren kommerziellen Rechenzentren und kümmern sich nicht wirklich um fortgeschrittene Netzwerkoperationen. Das haben viele mittelständische Unternehmen aus Redundanzgründen gesehen. Wenn dies der Fall ist, ist DNS die Antwort, kein Routing .
IPX

@IPX, was ich aus der Frage ersehen kann, ist, dass das Unternehmen Rechenzentren auf der ganzen Welt hat. Wenn ein Rechenzentrum abstürzt, sollte der geleitete Datenverkehr an ein anderes Rechenzentrum geleitet werden (" wenn eines unserer Rechenzentren ausgefallen ist." . "). Ich habe die Frage einfach wie gestellt beantwortet, anstatt zu versuchen, über Hosting von Drittanbietern zu raten, und wir tun dies auch, haben aber immer noch unsere eigene anbieterunabhängige Adressierung und AS-Nummer, die verwendet wird, um mit ISPs zu vergleichen. Dies ermöglicht die Aushandlung von Verträgen und den Wechsel von ISPs ohne Netzwerkunterbrechung bei der erneuten Adressierung.
Ron Maupin

Antworten:


16

Es hört sich so an, als ob Sie Anycast wollen. So etwas verwenden Websites wie Google. Sie haben eine einzige Adresse (durch DNS aufgelöst) für alle Ihre Websites und lassen das Internet-Routing-Protokoll (BGP) die Benutzer zur nächstgelegenen Site (nach dem Routing-Protokoll) leiten. Wenn eine Site ausfällt, wird die nächstgelegene Site automatisch von BGP in die Internet-Routing-Tabelle aufgenommen.

Das klassische Beispiel ist 8.8.8.8für DNS. Es wird an verschiedenen Orten auf der ganzen Welt aufgelöst. Wenn ein Ort ausfällt, wird es an den nächstgelegenen Ort weitergeleitet.

Die Antwort lautet nicht DNS, sondern Routing.


2
Anycast ist normalerweise für TCP-basierte Protokolle nicht nützlich, da Pakete, die zur selben Verbindung gehören, an verschiedene Server gesendet werden können.
Paŭlo Ebermann

2
@ PaŭloEbermann, das ist kein Problem, wenn Sie es mit BGP-Routing tun, da sich die Routen normalerweise nicht ändern, wenn angekündigt (nur geringfügige Änderungen)
Ferrybig

2
@ PaŭloEbermann Sie können Anycasts über DSR-basierte Load Balancer ausführen, solange sich alle Load Balancer auf die Auswahl der Backends einigen.
Kasperd

3
@ PaŭloEbermann, das ist ein Missverständnis. Der gesamte Datenverkehr von einem Host wird an einen Server gesendet. Wenn dieser Server nicht ausfällt, wird der Datenverkehr an einen anderen Server geleitet. Ja, das würde die TCP-Verbindung unterbrechen, aber das wäre immer dann der Fall, wenn der Server, mit dem Sie verbunden sind, ausfällt. Anycast ist kein Round-Robin-Typ. Das Routing ist deterministisch, daher ist Anycast deterministisch.
Ron Maupin

2
@ RonMaupin Anycast-Routing ist nicht so stabil, wie Sie implizieren. Und Google verwendet Anycast nicht so, wie Sie es sagen. Wenn Sie wissen möchten, wie Google dies tatsächlich tut, lesen Sie Seite 227 in der von Google veröffentlichten Site Reliability Workbook. Kurz gesagt, die Lastausgleichsschicht hinter dem Anycast-Routing kompensiert die unvermeidlichen Änderungen im Routing, die andernfalls die TCP-Verbindungen unterbrechen würden.
Kasperd

9

Was Sie brauchen, ist genau das , was der Amazon Route53 DNS-Dienst bietet:

Sie müssen Ihre Website nicht auf AWS hosten, um Route53 verwenden zu können. Sie funktioniert problemlos mit Diensten, die in privaten Rechenzentren bereitgestellt werden.

Sofern Sie kein Facebook- oder Google-Anbieter sind, sollte die Preisgestaltung ebenfalls kein Problem sein, beginnend mit 0,40 USD pro Million Anfragen (siehe Preisdetails ).

Ich hoffe, das hilft :)


Haben Sie jemals Produkte von Drittanbietern verwendet?
Küken

@chicks nein habe ich nicht. Ich benutze immer das beste Werkzeug für den Job und Route53 passt in den meisten Fällen. Wenn Sie jedoch etwas wie "geo dns service" googeln, erhalten Sie einige Optionen. Ich habe mir schnell einige angesehen, aber sie scheinen ziemlich teuer zu sein (etwa 50 US-Dollar pro Monat - weit mehr, als Sie wahrscheinlich mit AWS Route53 ausgeben würden).
MLu

2
Ich würde meine Perspektive etwas erweitern, bevor ich das erste Werkzeug aufrufe, das ich in den meisten Fällen als das beste Werkzeug gefunden habe. Route53 könnte für jeden das Beste sein, aber wie würden Sie wissen, wenn Sie nichts anderes ausprobiert haben?
Küken

-1

Ich hatte diese Idee und hatte begonnen, sie zu codieren, war aber nie fertig, da der Bedarf zuerst verflogen war.

Der DNS-Server verfügt über die Hostnamen und MAC-Adressen aller Computer in seinem LAN und über eine Möglichkeit, diese zu erreichen. Wenn es eine Anforderung für einen Computer empfängt, den es kennt, sendet es einen umgekehrten ARP für die IP-Adresse unter Angabe der MAC-Adresse und verwendet die Antwort, um die DNS-Antwort zu erstellen.

Dies hat nichts mit dem zu tun, was Sie versuchen, aber es veranschaulicht den Punkt. Ein DNS-Server kann theoretisch so codiert werden, dass er jedes neuartige Schema ausführt, mit dem Sie Namen in IP-Adressen auflösen möchten.

Die eigentliche Frage scheint zu sein, wie man die IP-Adresse des Kunden erhält, um zu entscheiden, wohin er gesendet werden soll. Dies ist ein kleines XY-Problem. Was Sie wirklich wollen, ist, dass der ISP des Kunden eine Geolokalisierung durchführt, und Sie können dies erreichen, indem Sie dies direkt von der IP-Adresse aus tun, die die Anforderung stellt, vorausgesetzt, es handelt sich nicht um 8.8.4.4 oder einen anderen DNS-Umleitungsdienst. Meiner Meinung nach besteht die beste Lösung für die DNS-Umleitungen darin, das Problem zu ignorieren und eine selbstbezogene Geolokalisierung durchzuführen (dh vom DNS-Server zu versuchen, die anrufende IP-Adresse zu finden) und entsprechend umzuleiten. Informationen zum Geolokalisieren finden Sie hier: /programming/2574542/location-detecting-techniques-for-ip-addresses

Du willst hier wirklich keinen Anycast, sondern etwas Vernünftigeres. Anycast hat die ärgerliche Eigenschaft, dass es Pakete in der Mitte Ihres TCP-Streams umleiten kann, was zu Massenverwirrung führt.

Ron Maupin behauptet, dass Anycast für TCP routenzuverlässig ist. Hier ist die Traceroute, die etwas anderes zeigt:

 3  cr1-rhe-a-be153.bb.as11404.net (174.127.183.14)  20.657 ms  20.763 ms  19.660 ms
 4  cr1-che-b-be-2.as11404.net (192.175.29.161)  22.550 ms  23.562 ms  23.538 ms
 5  * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108)  24.409 ms  38.083 ms
 6  72.14.222.146 (72.14.222.146)  40.038 ms  39.106 ms  39.125 ms
 7  108.170.242.225 (108.170.242.225)  37.930 ms 108.170.243.1 (108.170.243.1)  35.434 ms 108.170.242.225 (108.170.242.225)  33.694 ms
 8  209.85.240.249 (209.85.240.249)  33.476 ms 108.170.232.65 (108.170.232.65)  31.683 ms 108.170.234.155 (108.170.234.155)  30.754 ms
 9  google-public-dns-b.google.com (8.8.4.4)  30.491 ms  28.644 ms  25.718 ms

Wenn Sie versuchen, die Upstream-IP-Adressen auf die offensichtliche Weise zu geolokalisieren, erhalten Sie beide in Wichita. Dies ist nicht richtig, wodurch eine einfache Demonstration der Physik ausreichen wird.

Der Bereich bis 8.8.4.4 wird bei 30 ms gemessen, von denen die ersten 18 ms die lokale Strafe sind (Hop 3 ist der lokale Router meines ISP). Meine Entfernung nach Wichita beträgt 1297 Meilen. Die minimale Umlaufzeit beträgt daher (1297 * 2 Meilen / 225.000 Kilometer pro Sekunde (Lichtgeschwindigkeit in Glas)) 18,55 ms. Daher sollte ich keine Antwort schneller als 28 ms erhalten, aber ich habe eine Antwort in 25 ms zurückbekommen.

Die Pakete kommen auf zwei verschiedenen BGP-Routen bei Google an. BGP hat nicht den nächsten ausgewählt.



Kommentare sind nicht für eine ausführliche Diskussion gedacht. Dieses Gespräch wurde in den Chat verschoben .
Ward - Monica wieder einsetzen

Ich habe alle Kommentare in den Chat verschoben, aber da es so viele gab und einige automatisch verschoben wurden, bin ich mir nicht sicher, ob der spätere Chat sie alle enthält. In jedem Fall sollte eine weitere Diskussion über die Gültigkeit dieser Antwort und die Funktionsweise von Routern usw. nicht in Kommentaren enthalten sein. Bewahren Sie sie in einem der Chatrooms auf. Alle weiteren Kommentare hier werden gelöscht.
Ward - Monica wieder einsetzen

-2

Was Sie brauchen, kann mit einer Kombination aus DNS Anycast und RFC-7871 erreicht werden.


1
Weitere Details würden Ihre Antwort verbessern
Dave M
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.