Comment résoudre les problèmes liés au routage basé sur IP dans Route 53 ?

Lecture de 4 minute(s)
0

Je constate des résultats inattendus lorsque je teste la résolution DNS sur ma politique de routage basée sur IP Amazon Route 53.

Résolution

Exemple de scénario

Vous disposez d'enregistrements de routage basés sur IP pour des clients dont les adresses CIDR 172.32.0.0/16 et 172.33.0.0/16 pointent vers deux équilibreurs de charge Elastic Load Balancing (ELB). L'un des équilibreurs de charge ELB est situé en Virginie (us-east-1) et l'autre en Irlande (eu-west-1). Les clients dont le CIDR est 172.32.0.0/16 résolvent le domaine vers l'équilibreur de charge dans us-east-1. Les clients dont le CIDR est 172.33.0.0/16 résolvent le domaine vers l'équilibreur de charge dans eu-west-1. Toutefois, les clients ne reçoivent pas le résultat attendu.

Remarque : Le routage basé sur IP n'est pas pris en charge pour les zones hébergées privées.

Pour résoudre les problèmes de routage basé sur IP, procédez comme suit :

1.    Vérifiez que vous avez correctement configuré les enregistrements de ressources IP pour votre zone hébergée Route 53 pour votre cas d'utilisation. À partir de la console Route 53, vérifiez l'emplacement par défaut spécifié dans la configuration de votre zone hébergée Route 53.

Remarque : 

  • Si aucun bloc d'adresse CIDR n'est spécifié dans la collection d'adresses CIDR correspondant à l'adresse IP source, Route 53 répond avec l'emplacement « * » par défaut.
  • Route 53 répond avec NODATA si les conditions suivantes sont vraies :
    Aucun emplacement « * » par défaut n'est spécifié.
    La requête provient d'un bloc d'adresse CIDR qui ne correspond à aucun bloc d'adresse CIDR spécifié dans la collection d'adresses CIDR.
  • Route 53 fait correspondre les requêtes DNS dont l'adresse CIDR est plus longue que votre adresse CIDR spécifiée à l'adresse CIDR la plus courte spécifiée dans la collection d'adresses CIDR. Par exemple, si vous spécifiez 2001:db8::/32 comme adresse CIDR dans votre collection d'adresses CIDR et que vous recevez une requête de 2001:0db8:1234::/48, le CIDR correspond. Si vous spécifiez 2001:db8:1234::/48 dans votre collection CIDR et que vous recevez une requête de 2001:db8::/32, cela signifie qu'elle ne correspond pas. Route 53 répond avec l'enregistrement de la position « * ».

Pour la collecte CIDR et les quotas de limite de blocs CIDR, voir Quotas sur les enregistrements.

2.    Vérifiez si le client se résout correctement.

Si le client effectue la résolution dans le cloud privé virtuel (VPC) et utilise le résolveur VPC DNS .2, le routage basé sur IP ne fonctionne pas. Cela est dû au fait que le résolveur .2 ne prend pas en charge le sous-réseau client EDNS (ECS).

Si le client effectue une résolution en dehors du VPC, exécutez la commande suivante pour vérifier que votre résolveur DNS prend en charge le protocole EDNS0 :

Linux ou macOS

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

Windows

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

L'exemple de sortie suivant montre les résolveurs DNS qui ne prennent pas en charge EDNS0 :

$ 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"

L'exemple de sortie suivant montre les résolveurs DNS qui prennent en charge le format EDNS0 :

$ 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.    Pour vérifier la résolution DNS, utilisez le serveur de noms officiel de votre zone hébergée pour résoudre l'enregistrement. Exécutez la commande suivante. Dans l'exemple de commande suivant, remplacez example.com par votre domaine.

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

Vous pouvez également utiliser dig ou nslookup pour vérifier que la résolution DNS fonctionne comme prévu. Dans les exemples de commandes suivants, remplacez example.com par votre domaine.

dig example.com @8.8.8.8
nslookup example.com 8.8.8.8

4.    Si vous configurez des enregistrements de vérification de l'état pour des enregistrements de ressources IP, utilisez ces enregistrements pour vérifier l'état de santé. Si un contrôle de santé échoue pour un enregistrement avec un emplacement par défaut (*), Route 53 renvoie l'emplacement par défaut sous forme de réponse à une requête DNS.

Informations connexes

Routage basé sur IP

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an