Wie behebe ich Probleme beim Route 53-Geolocation-Routing?

Lesedauer: 6 Minute
0

Meine DNS-Abfragen geben eine IP-Adresse eines Webservers in einer anderen AWS-Region zurück. Beispielsweise wird ein Benutzer in den USA an eine IP-Adresse eines Webservers in Europa weitergeleitet.

Behebung

Probleme beim Geolocation-Routing von Route 53 werden durch die folgenden Probleme verursacht:

  • In der Einrichtung Ihres Geolocation-Routings fehlt ein Standardstandort.
  • Der DNS-Resolver unterstützt die edns0-client-subnet-Erweiterung von EDNS0 nicht. Dies führt zu einer ungenauen Bestimmung Ihres Standorts.
  • Die DNS-Resolver sind geografisch breit aufgestellt.
  • Es gibt DNS-Änderungen für Ressourceneinträge, die nicht global verbreitet sind.

Gehen Sie wie folgt vor, um diese Probleme zu beheben:

1.    Stellen Sie sicher, dass die Ressourceneinträge für Ihre gehostete Route 53-Zone für Ihren Anwendungsfall richtig konfiguriert sind. Vergewissern Sie sich außerdem, ob ein Standard-Ressourcendatensatz vorhanden ist. Überprüfen Sie in der Route 53-Konsole den Standardstandort, der in Ihrer gehosteten Route 53-Zonen-Konfiguration angegeben ist.

**Beispiel:**Betrachten Sie die folgende Beispielausgabe:

>> dig images.example.com

; <<>> DiG
9.8.2rc1-RedHat-9.8.2-0.37.rc1.45.amzn1 <<>> images.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 51385
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0

;; QUESTION SECTION
;images.example.com.    IN            A

;; AUTHORITY SECTION:
images.example.com.    60          IN           SOA        ns-1875.awsdns-42.co.uk.awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 65 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Tue Feb  7 22:02:30 2017
;; MSG SIZE  rcvd: 124

Im vorherigen Beispiel wurde in der Geolocation-Routing-Konfiguration kein Standardstandort angegeben. Bei einer nicht übereinstimmenden Geolocation gibt die DNS-Antwort also NOERROR für das Feld rcode zurück, und es gibt kein Ergebnis im Abschnitt ANSWER. Um dieses Problem zu beheben, fügen Sie Ihrer Geolocation-Routing-Konfiguration einen Standardstandort hinzu.

2.    Um den IP-Adressbereich des DNS-Resolvers zu überprüfen, führen Sie die folgenden Befehle aus und notieren Sie sich dann die Ausgabe.

Verwenden Sie unter Linux oder macOS den Befehl dig:

for i in {1..10}; do dig +short resolver-identity.cloudfront.net; sleep 11; done;

Verwenden Sie unter Windows den Befehl nslookup:

for /l %i in (1,1,10) do (nslookup resolver-identity.cloudfront.net && timeout /t 11 /nobreak)

3.    Überprüfen Sie mit einem der folgenden Befehle, ob der DNS-Resolver edns0-client-subnet unterstützt, und notieren Sie das Ergebnis.

Verwenden Sie unter Linux oder macOS den Befehl dig:

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

Verwenden Sie unter Windows den Befehl nslookup:

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

Überprüfen Sie den ersten TXT-Datensatz, der im Abschnitt Antwort der Ausgabe zurückgegeben wurde. Der erste TXT-Datensatzwert ist die IP-Adresse des DNS-Resolvers. 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 stellt dem autoritativen Route 53-Namenserver eine verkürzte Client-Subnetz-IP-Adresse (/24 oder /32) bereit. Weitere Informationen finden Sie unter Wie kann ich feststellen, ob mein öffentlicher DNS-Resolver die EDNS-Client-Subnetzerweiterung (ECS) unterstützt?

4.    Verwenden Sie den Route 53-Testdatensatz aus dem Prüftool, um die Ressourceneinträge zu ermitteln, die für eine bestimmte Anforderung zurückgegeben werden. Weitere Informationen finden Sie unter Verwenden des Prüftools, um zu sehen, wie Amazon Route 53 auf DNS-Abfragen reagiert.

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

Wenn der DNS-Resolver edns0-client-subnet unterstützt, geben Sie die EDNS0-Client-Subnetz-IP-Adresse als Ihren Wert im Tool an. Wählen Sie Weitere Optionen und geben Sie dann die Subnetz-Maske an. Geben Sie keine Resolver-IP-Adresse an.

5.    (Optional) Wenn Sie keinen Zugriff auf das Überprüfungstool haben, verwenden Sie dig, um die autoritativen Route 53-Nameserver für Ihre gehostete Zone mit EDNS0-Client-Subnet abzufragen. Verwenden Sie die Ausgabe, um die Antwort auf den autoritativen Geolocation-Datensatz für Ihre Quell-IP-Adresse zu ermitteln:

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

6.    Route 53-Nameserver unterstützen die edns0-client-subnet-Erweiterung von EDNS0. Der Resolver oder lokale DNS-Server hängt das edns0-client-subnet an die DNS-Abfrage an, um eine DNS-Suche basierend auf dem Quell-IP-Subnetz des Clients durchzuführen. Wenn diese Daten nicht mit der Anfrage übergeben werden, verwendet Route 53 die Quell-IP-Adresse des DNS-Resolvers, um den ungefähren Standort des Clients zu ermitteln. Anschließend antwortet Route 53 auf Geolocation-Abfragen mit dem DNS-Eintrag für den Standort des Resolvers. Die EDNS0-Daten müssen an Route 53 übergeben werden und der Client muss einen geografisch näher gelegenen rekursiven Nameserver verwenden. Wenn nicht, ist das Ergebnis ein suboptimaler Standort, der den falschen Ressourceneintrag für die DNS-Abfrage bereitstellt.

Um diese Konfiguration zu korrigieren, ändern Sie den rekursiven DNS-Server, der edns0-client-subnet unterstützt. Führen Sie die DNS-Auflösung durch und teilen Sie dann die Ausgabe. Wenn der rekursive DNS-Server edns0-client-subnet nicht unterstützt, versuchen Sie es mit einem, das es unterstützt. Zu den Optionen, die edns0-client-subnet unterstützen, gehören Google DNS- und OpenDNS-Resolver.

7.    Überprüfen Sie die geografische Position der IP-Adresse des Client-Subnetzes mithilfe der GeoIP-Datenbank von MaxMind auf der MaxMind-Website oder Ihrer bevorzugten GeoIP-Datenbank. Stellen Sie sicher, dass sich der DNS-Resolver geografisch in der Nähe der öffentlichen IP-Adresse des Clients befindet. Wenn die Antwort oder das Land auf der MaxMind-Website nicht mit der Antwort von Route 53 übereinstimmt, sind die Produktionsgeodaten von Route 53 möglicherweise veraltet. Wenn das Routing veraltet ist, wenden Sie sich an den AWS-Support.

8.    Suchen Sie mit einem Tool wie CacheCheck auf der OpenDNS-Site nach Problemen mit der DNS-Propagierung.

9.    (Optional) Stellen Sie fest, ob die geographischen Routing-Datensätze einer Route 53-Zustandsprüfung zugeordnet sind. Stellen Sie außerdem fest, ob Evaluate Target Health (ETH) aktiviert ist (für Aliasdatensätze). Wenn beides zutrifft, gibt Route 53 den fehlerfreien Endpunkt zurück, der am besten zum Quellstandort passt.

Überprüfen Sie den Status Ihrer Route 53-Zustandsprüfung 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-Instance 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.

**Beispiel:**Sie haben Datensätze für Texas in den USA, für die USA, Nordamerika und alle Standorte (Standort ist Standard). Und Sie haben Abfragen, die aus Texas stammen und einen fehlerhaften Endpunkt haben. Route 53 durchsucht die USA, Nordamerika und dann alle Standorte in dieser Reihenfolge, bis ein Datensatz mit einem fehlerfreien Endpunkt gefunden wird. Wenn der US-Datensatz fehlerfrei ist, gibt Route 53 diesen Endpunkt zurück. Andernfalls gibt Route 53 einen Standarddatensatz zurück. Wenn alle zutreffenden Datensätze fehlerhaft sind, beantwortet Route 53 die DNS-Anfrage mit dem Wert des Datensatzes für die kleinste geografische Region.

**Hinweis:**Es kann bis zu 60 Sekunden dauern, bis Änderungen an geolokalisierten Ressourcendatensätzen mit Alias übernommen werden.

Verwandte Informationen

Wie kann ich fehlerhafte Route 53-Zustandsprüfungen beheben?

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

DNS-Antworten von Amazon Route 53 überprüfen

AWS OFFICIAL
AWS OFFICIALAktualisiert vor einem Jahr