Warum wird der Traffic für meine Webinhalte an den falschen CloudFront-Edge-Standort weitergeleitet?

Lesedauer: 4 Minute
0

Ich verwende Amazon CloudFront, um meine Webinhalte zu verteilen. Der Traffic auf meine Website wird jedoch an den falschen Edge-Standort weitergeleitet. Wie kann ich das beheben?

Kurzbeschreibung

CloudFront leitet Traffic auf der Grundlage der Preisklasse der Distribution, der zugehörigen Geolocation-Datenbanken und der Unterstützung von EDNS0-Client-Subnetzen weiter. Abhängig von der Kombination dieser Faktoren werden die Besucher Ihrer Website möglicherweise an einen unerwarteten Edge-Standort weitergeleitet. Dies kann die Gesamtlatenz beim Abrufen eines Objekts von einem CloudFront-Edge-Standort erhöhen.

Um Probleme beim Routing zu einer unerwarteten Edge-Position zu beheben, überprüfen Sie Folgendes:

  • Die Preisklasse unterstützt die Edge-Lage, die Sie erwarten.
  • Der DNS-Resolver unterstützt Anycast-Routing.
  • Der DNS-Resolver unterstützt das EDNS0-Client-Subnetz.

Behebung

Die Preisklasse unterstützt die Edge-Lage, die Sie erwarten

Informieren Sie sich über die Edge-Standorte, die in der Preisklasse Ihrer CloudFront-Distribution enthalten sind. Sie können die Preisklasse Ihrer Distribution aktualisieren, wenn Sie andere Edge-Standorte einbeziehen möchten.

Der DNS-Resolver unterstützt Anycast-Routing

Wenn der DNS-Resolver Anycast-Routing unterstützt, verwendet der DNS-Resolver mehrere Edge-Standorte. Dies bedeutet, dass der Edge-Standort eines Anforderers auf einer optimalen Latenz basiert, was zu einem unerwarteten Standort für die IP-Adresse des Resolvers führen kann.

Um zu überprüfen, ob der DNS-Resolver Anycast unterstützt, führen Sie einen der folgenden Befehle mehrmals aus:

Hinweis: Ersetzen Sie in diesen Beispielbefehlen example.com unbedingt durch den DNS-Resolver-Domainnamen, den Sie verwenden.

Führen Sie unter Linux oder macOS einen Befehl dig aus, der dem folgenden ähnelt:

dig +nocl TXT o-o.myaddr.l.example.com

Führen Sie unter Windows einen nslookup-Befehl aus, der dem folgenden ähnelt:

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

Wenn die Ausgabe bei jeder Ausführung des Befehls dieselbe IP-Adresse enthält, unterstützt der DNS-Resolver Anycast nicht. Wenn die Ausgabe bei jeder Ausführung des Befehls eine andere IP-Adresse enthält, unterstützt der DNS-Resolver Anycast. Dies könnte eine unerwartete Kantenposition erklären.

Der DNS-Resolver unterstützt das EDNS0-Client-Subnetz

Um herauszufinden, wie Sie falsches Routing vermeiden können, überprüfen Sie zunächst, ob der DNS-Resolver EDNS0-Client-Subnet unterstützt, indem Sie einen der folgenden Befehle ausführen:

Hinweis: Ersetzen Sie in diesen Beispielbefehlen example.com unbedingt durch den DNS-Resolver-Domainnamen, den Sie verwenden.

Führen Sie unter Linux oder macOS einen Befehl dig aus, der dem folgenden ähnelt:

dig +nocl TXT o-o.myaddr.l.example.com

Führen Sie unter Windows einen nslookup-Befehl aus, der dem folgenden ähnelt:

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

Hinweis: Überprüfen Sie den TTL-Wert und stellen Sie sicher, dass Sie den Befehl ausführen, wenn der TTL-Wert abgelaufen ist. Andernfalls erhalten Sie möglicherweise eine zwischengespeicherte Antwort vom rekursiven Resolver.

Wenn der DNS-Resolver das EDNS0-Client-Subnetz nicht unterstützt, sieht die Ausgabe ähnlich wie folgt aus:

$ dig +nocl TXT o-o.myaddr.l.example.com  +short
"192.0.2.1"

Im vorherigen Beispiel ist 192.0.2.1 die IP-Adresse des nächstgelegenen DNS-Servers, der Anycast verwendet. Dieser DNS-Resolver unterstützt kein EDNS0-Client-Subnetz. Um falsches Routing zu vermeiden, können Sie einen der folgenden Schritte ausführen:

  • Wechseln Sie zu einem DNS-Resolver zu einem rekursiven DNS-Resolve, der sich geografisch näher an den Kunden Ihrer Website befindet.
  • Wechseln Sie zu einem DNS-Resolver, der das EDNS0-Client-Subnetz unterstützt.

Wenn der DNS-Resolver das EDNS0-Client-Subnetz unterstützt, enthält die Ausgabe ein verkürztes Client-Subnetz (/24 oder /32) zum autoritativen CloudFront-Nameserver, ähnlich dem Folgenden:

$ dig +nocl TXT o-o.myaddr.l.example.com @8.8.8.8 +short
"192.0.2.1"
"edns0-client-subnet 198.51.100.0/24"

Im vorherigen Beispiel ist 192.0.2.1 die nächstgelegene DNS-Resolver-IP-Adresse. Darüber hinaus beträgt der Client-Subnetzbereich 198.51.100.0/24, der für die Beantwortung von DNS-Abfragen verwendet wird. Um falsches Routing zu vermeiden, wenn der DNS-Resolver das EDNS0-Client-Subnetz unterstützt, stellen Sie sicher, dass eine öffentliche Geolocation-Datenbank mit dem Client-Subnetzbereich verknüpft ist, der die Anfrage an den DNS-Resolver sendet. Wenn der DNS-Resolver die gekürzte Version der Client-IP-Adressen an CloudFront-Nameserver weiterleitet, überprüft CloudFront eine Datenbank, die auf mehreren öffentlichen Geolocation-Datenbanken basiert. Die IP-Adressen müssen in der Geolocation-Datenbank korrekt zugeordnet sein, damit Anfragen korrekt weitergeleitet werden.

Wenn der DNS-Resolver das EDNS0-Client-Subnetz unterstützt, können Sie den Edge-Standort überprüfen, zu dem der Datenverkehr weitergeleitet wird, indem Sie zuerst Ihren CloudFront-CNAME auflösen, indem Sie einen DNS-Suchbefehl wie dig ausführen:

$ dig dftex7example.cloudfront.net. +short
13.224.77.109
13.224.77.62
13.224.77.65
13.224.77.75

Führen Sie dann eine umgekehrte DNS-Suche für die IP-Adressen durch, die vom vorherigen Befehl zurückgegeben wurden:

$ dig -x 13.224.77.62 +short
server-13-224-77-62.man50.r.cloudfront.net.

Im vorherigen Beispiel wird der Verkehr an den Edge-Standort Manchester weitergeleitet.

Tipp: Für einen zusätzlichen Test können Sie einen öffentlichen DNS-Resolver verwenden, der das EDNS0-Client-Subnetz unterstützt, z. B. 8.8.8.8 oder 8.8.4.4. Senden Sie Abfragen mit Edge-Standort-IP-Adressen an den öffentlichen DNS-Resolver. Überprüfen Sie anschließend die Ergebnisse der DNS-Abfragen, um festzustellen, ob CloudFront über die richtigen Informationen zu Ihrem EDNS0-Client-Subnetz verfügt.


AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren