Wie behebe ich Probleme mit latenzbasierten Ressourceneinträgen und Route 53?

Kurzbeschreibung

Route 53 wird anhand des Standorts der DNS-Abfrage in die Region mit der niedrigsten Latenz aufgelöst, wenn Folgendes zutrifft:

• Sie haben Endpunkte in mehreren AWS-Regionen mit demselben Ressourcendatensatz verknüpft.
• Sie verwenden eine latenzbasierte Routing-Richtlinie.

Route 53 trifft latenzbasierte Routing-Entscheidungen auf der Grundlage von:

• Die Quell-IP-Adresse des rekursiven DNS-Resolvers, der die Anfrage an den autoritativen Route 53-Namenserver sendet.
• Die verkürzte Version der Client-IP-Adresse (wenn der DNS-Resolver die Erweiterung edns00-client-subnet unterstützt).

Route 53-Nameserver unterstützen standardmäßig edns0-client-subnet. Wenn ein rekursiver DNS-Resolver edns0-client-subnet unterstützt, sendet der DNS-Resolver Route 53 eine verkürzte Version der IP-Adresse des Clients. Route 53 verwendet dann diese verkürzte IP-Adresse, um die Region mit der niedrigsten Latenz zu bestimmen.

Die Region mit der niedrigsten Latenz ist dem DNS-Resolver möglicherweise nicht physisch am nächsten. Es kann zu unerwünschtem Routingverhalten kommen, wenn sich der Client nicht am selben Standort wie der DNS-Resolver befindet. Es kann auch zu unerwünschtem Routingverhalten kommen, wenn die IP-Adresse des Resolvers unterschiedliche Standortinformationen enthält.

Beispielszenario

Ein Unternehmen verfügt über latenzbasierte Routing-Datensätze für zwei Elastic Load Balancers, von denen sich einer in Virginia (us-east-1) und der andere in Irland (eu-west-1) befindet. Benutzer in den USA verwenden einen Unternehmens-DNS-Resolver in Europa oder stellen über ein VPN eine Verbindung zur Unternehmenszentrale in Europa her.

Der Unternehmens-DNS-Resolver kann keine edns0-Client-Subnetzdaten an die autoritativen Nameserver senden. Route 53 betrachtet also die IP-Adresse des DNS-Resolvers in Europa als Quelle der Abfrage. Route 53 führt dann eine Suche in ihrer Latenzdatenbank durch und stellt fälschlicherweise fest, dass der Load Balancer in Irland die niedrigste Latenz aufweist.

Wenn der Unternehmens-DNS-Resolver edns0-Client-Subnetzdaten senden kann, betrachtet Route 53 die verkürzte Client-IP-Adresse in den USA als Quelle der Anfrage. Route 53 führt dann eine Suche in ihrer Latenzdatenbank durch und stellt korrekt fest, dass der Load Balancer in Virginia die niedrigste Latenz aufweist.

Auflösung

Gehen Sie wie folgt vor, um unerwünschtes latenzbasiertes Routing-Verhalten zu beheben:

1. Überprüfen Sie den vom DNS-Resolver verwendeten IP-Adressbereich. Führen Sie unter Linux und macOS den Befehl dig in einer Schleife aus. Führen Sie unter Windows den Befehl nslookup mehrmals aus. Achten Sie darauf, jedes Mal die Ausgabe zu notieren.

Führen Sie unter Linux oder macOS den Befehldig in einer Schleife aus.

for i in {1..10}; do dig TXT o-o.myaddr.l.google.com +short; sleep 61; done;

Führen Sie unter Windows den Befehlnslookup mehrmals aus. Achten Sie darauf, jedes Mal die Ausgabe zu notieren.

nslookup -type=txt o-o.myaddr.l.google.com

2.Vergewissern Sie sich, dass der DNS-Resolver Anycast unterstützt, indem Sie die Ausgabe des vorherigen Befehls verwenden. Wenn die Ausgabe immer dieselbe einzelne IP-Adresse enthält, unterstützt der DNS-Resolver Anycast nicht. Wenn sich die IP-Adresse ändert, wenn Sie den Befehl mehrmals ausführen, unterstützt der DNS-Resolver Anycast.

Wenn ein DNS-Resolver Anycast unterstützt, gibt es mehrere Edge-Standorte für DNS-Resolver. Der Edge-Standort eines Benutzers wird auf der Grundlage der optimalen Latenz ausgewählt, was zu einem unerwarteten Standort für die Resolver-IP-Adresse führen kann.

3.Finden Sie die Client-IP-Adresse. Öffnen Sie auf dem Client-Computer einen Internetbrowser und navigieren Sie dann zu https://checkip.amazonaws.com/.

Oder verwende curl:

curl https://checkip.amazonaws.com/

4.Überprüfen Sie mit einem der folgenden Befehle, ob der DNS-Resolver edns0-client-subnet unterstützt. Achten Sie darauf, die Ausgabe zu notieren.

Verwenden Sie unter Linux oder macOS dig:

dig +nocl TXT o-o.myaddr.l.google.com @<DNS Resolver>

Verwenden Sie unter Windows nslookup:

nslookup -type=txt o-o.myaddr.l.google.com <DNS Resolver>

5.Überprüfen Sie den ersten zurückgegebenen TXT-Datensatz imAntwort-Abschnitt der Ausgabe. Dieser Wert ist der nächstgelegene DNS-Server, der für Anycast wirbt. Wenn es keinen zweiten TXT-Eintrag gibt, unterstützt der DNS-Resolver edns0-client-subnet nicht. Wenn es einen zweiten TXT-Eintrag gibt, unterstützt der DNS-Resolver edns0-client-subnet. Der Resolver sendet ein verkürztes Client-Subnetz (/24 oder /32) an den autoritativen Route 53-Namenserver.

(Optional) Wenn Sie die Route 53-DNS-Abfrageprotokollierung in Ihrer Hostzone aktiviert haben, erstellen Sie einen Testeintrag. Führen Sie eine DNS-Suche nach dem neuen Datensatz durch. Überprüfen Sie die Abfrageprotokolle, um die Resolver-IP-Adresse und das edns0-client-Subnetz (falls vorhanden) zu bestätigen, die den Route 53-Nameservern zur Verfügung gestellt wurden.

6.Stellen Sie sicher, dass der TTL-Wert der Antwort 60 Sekunden beträgt. Wenn die TTL nicht 60 Sekunden beträgt, handelt es sich bei der Antwort um eine zwischengespeicherte Antwort. Wiederholen Sie Ihren Befehldig oder nslookup, bis der TTL-Wert der Antwort 60 Sekunden beträgt.

7.Wenn Sie auf das Route 53 DNS-Überprüfungstool zugreifen können, simulieren Sie Abfragen von einem bestimmten DNS-Resolver oder einer bestimmten Client-IP-Adresse. Verwenden Sie diese Abfragen, um herauszufinden, welchen Latenzressourcendatensatz Route 53 zurückgibt.

Wenn der DNS-Resolver edns0-client-subnet nicht unterstützt, geben Sie die Resolver-IP-Adresse als Wert im Tool an.

Wenn der DNS-Resolver edns0-client-subnet unterstützt, geben Sie die EDNS0-Client-Subnetz-IP als Ihren Wert im Tool an. Wählen Sie Zusätzliche Konfiguration und geben Sie dann die **Subnetzmaske ** an.

**Hinweis:**Das Route 53 DNS-Überprüfungstool fragt direkt die Route 53-Datenbank zur Latenzmessung ab. Die Abfrage bestimmt die vorberechnete Latenz zwischen AWS-Regionen und einem internetbasierten Netzwerk. Das Tool sendet keine DNS-Abfragen über das Internet oder an DNS-Resolver. Das Tool überprüft nicht, ob der DNS-Resolver edns0-client-subnet unterstützt. Die Ergebnisse des Tools und einer tatsächlichen DNS-Abfrage können abweichen.

8.(Optional) Wenn Sie nicht auf das Route 53 DNS-Überprüfungstool zugreifen können, verwenden Sie dig. Mit dig können Sie die autoritativen Route 53-Nameserver für Ihre Hostzone mit edns0-client-subnet abfragen. Verwenden Sie die Ausgabe, um anhand Ihrer Quell-IP-Adresse die Region mit der niedrigsten Latenz zu ermitteln.

dig lbr.example.com +subnet=<Client IP>/24 @ns-xx.awsdns-xxx.com +short

**Hinweis:**Die Latenz zwischen Hosts im Internet kann sich im Laufe der Zeit aufgrund von Änderungen der Netzwerkkonnektivität und des Routing ändern. Beispielsweise könnte eine Anfrage, die diese Woche an die Region Oregon weitergeleitet wird, nächste Woche an die Region Ohio weitergeleitet werden.

9.**Für Resolver, die edns0-client-subnet nicht unterstützen:**Ändern Sie den DNS-Resolver des Clients durch einen anderen rekursiven DNS-Resolver, der sich geografisch näher am Client befindet. Wenn der Resolver edns0-client-subnet nicht unterstützt, verwenden die Client-DNS-Abfragen möglicherweise einen DNS-Resolver an einem anderen geografischen Standort als der Client. Das Ergebnis in diesem Szenario ist ein unerwartetes Routing-Verhalten.

Wenn Sie den DNS-Resolver verwalten, überprüfen Sie die Weiterleitungskonfiguration. Stellen Sie sicher, dass Sie keine DNS-Abfragen an einen anderen Resolver weiterleiten, der weiter vom geografischen Standort des Clients entfernt ist.

**Für Resolver, die edns0-client-subnet unterstützen:**Überprüfen Sie den geografischen Standort der IP-Adresse des Client-Subnetzes. Um den Standort zu überprüfen, verwenden Sie die GeoIP-Datenbank auf der MaxMind-Website oder Ihre bevorzugte GeoIP-Datenbank. Wenn sich der Standort der IP-Adresse des Clientsubnetzes an einem anderen geografischen Standort als der des Clients befindet, kann es zu unerwartetem Routingverhalten kommen.

10.(Optional) Wenn der DNS-Resolver edns0-client-subnet nicht unterstützt, wechseln Sie zu einem öffentlichen rekursiven DNS-Resolver, der edns0-client-subnet unterstützt. Vergleichen Sie dann Ihre alten Latenz-Routing-Antwortergebnisse von Route 53 mit Ihren neuen Ergebnissen. Zwei öffentliche DNS-Resolver, die derzeit das edns0-client-subnet unterstützen, sind beispielsweise GoogleDNS (8.8.8.8 und 8.8.4.4) und OpenDNS (208.67.222.222 und 208.67.220.220).

11.(Optional) Stellen Sie fest, ob die latenzbasierten Routing-Datensätze mit einer Route 53-Zustandsprüfung verknüpft sind. Stellen Sie außerdem fest, ob Evaluate Target Health (ETH) aktiviert ist (für Aliasdatensätze). Wenn einer oder beide wahr sind, gibt Route 53 den fehlerfreien Endpunkt mit der niedrigsten Latenz zurück. Wenn alle Zustandsprüfungen fehlschlagen, wird nur die Routing-Richtlinie berücksichtigt.

Überprüfen Sie den Status Ihres Route 53-Gesundheitschecks in der Route 53-Konsole. Wenn ETH eingeschaltet ist, überprüfen Sie den Gesundheitsstatus des Aufzeichnungsendpunkts. Route 53 betrachtet einen Endpunkt für einen Classic Load Balancer mit aktivierter ETH als fehlerfrei, wenn mindestens eine Backend-Instanz fehlerfrei ist. Für Application Load Balancers und Network Load Balancers muss jede Zielgruppe mit Zielen mindestens ein intaktes Ziel enthalten, um als fehlerfrei zu gelten. Eine Zielgruppe ohne registrierte Ziele wird als ungesund angesehen. Wenn eine Zielgruppe nur fehlerhafte Ziele enthält, wird der Load Balancer als fehlerhaft angesehen.

**Ausnahme:**Wenn ein Application Load Balancer mindestens eine gesunde Zielgruppe hat und alle verbleibenden Zielgruppen leer sind, betrachtet Route 53 ihn als gesund.

Beispiel

Sie haben zwei latenzbasierte Routing-Datensätze mit zugehörigen Route 53-Zustandsprüfungen, einen in Oregon und den anderen in North Virginia. Wenn die Zustandsprüfung des Endpunkts Oregon fehlschlägt, werden alle Anfragen unabhängig vom Standort des Clients an den Endpunkt North Virginia weitergeleitet.

Weitere Informationen

DNS-Antworten von Route 53 überprüfen

Wie kann ich feststellen, ob mein öffentlicher DNS-Resolver die EDNS-Client-Subnetzerweiterung unterstützt?

Wie kann ich fehlerhafte Route 53-Gesundheitschecks beheben?

Warum ist mein Aliaseintrag, der auf einen Application Load Balancer verweist, als fehlerhaft markiert, wenn ich „Evaluate Target Health“ verwende?