Wie behebe ich Probleme mit IP-basiertem Routing in Route 53?

Lösung

Beispielszenario

Sie haben IP-basierte Routing-Einträge für Clients, deren CIDR 172.32.0.0/16 und 172.33.0.0/16 auf zwei Elastic Load Balancing (ELB)-Load Balancer verweisen. Ein ELB Load Balancer befindet sich in Virginia (us-east-1) und der andere in Irland (eu-west-1). Clients mit CIDR 172.32.0.0/16 lösen die Domäne für den Load Balancer in us-east-1 auf. Clients mit CIDR 172.33.0.0/16 lösen die Domain auf den Load Balancer in eu-west-1 auf. Die Clients erhalten jedoch nicht die erwartete Ausgabe.

Hinweis: IP-basiertes Routing wird nicht für private gehostete Zonen unterstützt.

Gehen Sie wie folgt vor, um Probleme mit IP-basiertem Routing zu beheben:

1.    Vergewissern Sie sich, dass Sie die IP-basierten Ressourceneinträge für Ihre gehostete Route-53-Zone für Ihren Anwendungsfall korrekt konfiguriert haben. Öffnen Sie die Route 53-Konsole und Überprüfen Sie den Standardstandort, der in Ihrer gehosteten Route 53-Zonen-Konfiguration angegeben ist.

Hinweis: 

• Wenn in der CIDR-Sammlung, die der Quell-IP-Adresse entspricht, keine CIDR-Blöcke angegeben sind, antwortet Route 53 mit dem Standardspeicherort „*“.
• Route 53 antwortet mit NODATA, wenn Folgendes zutrifft:
  Es ist kein Standardspeicherort „*“ angegeben.
  Die Abfrage stammt aus einem CIDR-Block, der mit keinem der angegebenen CIDR-Blöcke in der CIDR-Sammlung übereinstimmt.
• Route 53 ordnet DNS-Abfragen, deren CIDR länger ist als das angegebene CIDR, dem kürzeren CIDR in der CIDR-Sammlung zu. Wenn Sie beispielsweise 2001:db8::/32 als CIDR in Ihrer CIDR-Sammlung angeben und eine Abfrage von 2001:0db8:1234::/48 erhalten, dann stimmt das CIDR überein. Wenn Sie 2001:db8:1234::/48 in Ihrer CIDR-Sammlung angeben und eine Abfrage von 2001:db8::/32 erhalten, dann stimmt sie nicht überein. Route 53 antwortet mit dem Eintrag für den Speicherort „*“.

Informationen zu den Kontingenten für CIDR-Erfassung und CIDR-Blocklimits finden Sie unter Kontingente für Einträge.

2.    Prüfen Sie, ob der Client das Problem korrekt löst.

Wenn der Client die Auflösung innerhalb der Virtual Private Cloud (VPC) durchführt und den VPC DNS .2-Resolver verwendet, funktioniert IP-basiertes Routing nicht. Dies liegt daran, dass der .2-Resolver das EDNS-Client-Subnetz (ECS) nicht unterstützt.

Wenn der Client die Auflösung außerhalb der VPC durchführt, führen Sie den folgenden Befehl aus, um zu überprüfen, ob Ihr DNS-Resolver EDNS0 unterstützt:

Linux oder macOS

dig TXT o-o.myaddr.google.com -4

Windows

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

Die folgende Beispielausgabe zeigt DNS-Resolver, die EDNS0 nicht unterstützen:

$ dig TXT o-o.myaddr.google.com -4

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> TXT o-o.myaddr.google.com -4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38328
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;o-o.myaddr.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.google.com. 60 IN TXT "3.209.83.70"

Die folgende Beispielausgabe zeigt DNS-Resolver, die EDNS0 unterstützen:

$ dig TXT o-o.myaddr.google.com -4 @8.8.8.8

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> TXT o-o.myaddr.google.com -4 @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30624
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;o-o.myaddr.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.google.com. 60 IN TXT "172.253.8.137"
o-o.myaddr.google.com. 60 IN TXT "edns0-client-subnet 54.82.0.0/24"

3.    Um die DNS-Auflösung zu überprüfen, verwenden Sie den autoritativen Nameserver Ihrer gehostete Zone, um den Datensatz aufzulösen. Führen Sie den folgenden Befehl aus. Ersetzen Sie im folgenden Beispielbefehl example.com durch Ihre Domain.

dig A example.com +subnet=172.3.0.0/16 @ns-1875.awsdns-42.co.uk

Oder verwenden Sie dig oder nslookup, um zu überprüfen, ob die DNS-Auflösung wie erwartet funktioniert. Ersetzen Sie in den folgenden Beispielbefehlen example.com durch Ihre Domain.

dig example.com @8.8.8.8
nslookup example.com 8.8.8.8

4.    Wenn Sie Zustandsprüfungseinträge für IP-basierte Ressourceneinträge konfigurieren, verwenden Sie diese Einträge, um den Zustandsstatus zu überprüfen. Wenn eine Zustandsprüfung für einen Datensatz mit einem Standardspeicherort (*) fehlschlägt, gibt Route 53 den Standardstandort als Antwort auf eine DNS-Abfrage zurück.

Ähnliche Informationen

IP-basiertes Routing