Comment résoudre les problèmes de routage de géolocalisation de Route 53?

Date de la dernière mise à jour : 26/05/2021

Mes requêtes DNS renvoient une adresse IP d'un serveur Web dans une autre région AWS. Par exemple, un utilisateur aux États-Unis est routé vers une adresse IP d'un serveur Web situé en Europe. Comment résoudre les problèmes de routage de géolocalisation d’Amazon Route 53 ?

Brève description

Les problèmes de routage de géolocalisation de Route 53 peuvent être causés par :

  • emplacement par défaut manquant dans la configuration du routage de géolocalisation
  • résolveur DNS qui ne prend pas en charge l'extension edns-client-subnet d'EDNS0 (conduit à une détermination inexacte de votre emplacement)
  • résolveurs DNS géographiquement diversifiés
  • modifications DNS pour les enregistrements de ressources qui ne se sont pas propagés globalement

Solution

1.    Vérifiez que les enregistrements de ressources de votre zone hébergée Route 53 sont correctement configurés pour votre cas d'utilisation et qu'il existe un jeu d'enregistrements de ressources par défaut. Dans la console Route 53, vérifiez l'emplacement par défaut spécifié dans la configuration de la zone hébergée Route 53.

Prenez l'exemple de sortie suivant :

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

Si aucun emplacement par défaut n'est spécifié dans votre configuration de routage de géolocalisation, la réponse DNS renvoie NOERROR pour le champ rcode. Dans ce cas, il n'y a pas de résultat dans la section ANSWER. Pour corriger ce problème, ajoutez un emplacement par défaut dans votre configuration de routage de géolocalisation.

2.    Pour vérifier la plage d'adresses IP du résolveur DNS, exécutez les commandes suivantes 5 ou 6 fois pendant une période de 11 secondes. Veillez à noter le résultat à chaque fois.

Sous Linux ou macOS, utilisez dig :

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

Sous Windows, utilisez nslookup :

nslookup resolver-identity.cloudfront.net

3.     Vérifiez si le résolveur DNS prend en charge EDNS0-Client-Subnet à l'aide d'une des commandes suivantes. Veillez à noter le résultat.

Sous Linux ou macOS, utilisez dig :

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

Sous Windows, utilisez nslookup :

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

Vérifiez le premier enregistrement TXT renvoyé dans la section Answer de la sortie. La première valeur d'enregistrement TXT est l'adresse IP du résolveur DNS. S'il n'y a pas de deuxième enregistrement TXT, le résolveur DNS ne prend pas en charge EDNS0-Client-Subnet. S'il y a un deuxième enregistrement TXT, le résolveur DNS prend en charge EDNS0-Client-Subnet. Le résolveur fournit, puis envoie une adresse IP de sous-réseau client tronqué (/24 ou /32) au serveur de noms faisant autorité de Route 53.

4.    Utilisez le jeu d'enregistrements de test Route 53 de l'outil de vérification pour déterminer quels enregistrements de ressource sont renvoyés pour une demande spécifique. Pour plus d'informations, consultez la section Utilisation de l'outil de vérification pour voir comment Amazon Route 53 répond aux requêtes DNS.

Si le résolveur DNS ne prend pas en charge EDNS0-Client-Subnet, spécifiez l’adresse IP du résolveur comme valeur dans l'outil.

Si le résolveur DNS prend en charge EDNS0-Client-Subnet, spécifiez l’adresse IP de sous-réseau client EDNS0 comme valeur dans l'outil. Choisissez More Options (Options supplémentaires), puis spécifiez le masque Subnet (Sous-réseau). Ne spécifiez pas l'adresse IP d'un résolveur.

5.    (Facultatif) Si vous n'avez pas accès à l'outil de vérification, utilisez dig pour interroger les serveurs de noms faisant autorité de Route 53 pour votre zone hébergée avec EDNS0-Client-Subnet. Utilisez la sortie pour déterminer la région AWS dont la latence est la plus faible à partir de votre adresse IP source :

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

6.    Route 53 prend en charge l'extension edns-client-subnet d'EDNS0. Le récurseur ou le serveur de noms local ajoute edns-client-subnet à la requête DNS pour effectuer une recherche DNS sur le sous-réseau IP source du client. Si ces données ne sont pas transmises avec la demande, Route 53 utilise l'adresse IP source du résolveur DNS pour déterminer approximativement l'emplacement du client. Ensuite, Route 53 répond aux requêtes de géolocalisation avec l'enregistrement DNS pour l'emplacement du résolveur. Si les données EDNS ne sont pas transmises à Route 53 et que le client utilise un serveur de noms récursif géographiquement diversifié, le résultat est un emplacement sous-optimal servant l'enregistrement de ressource incorrect à la requête DNS.

Pour corriger cette configuration, modifiez le serveur DNS récursif prenant en charge edns-client-subnet. Effectuez la résolution DNS, puis partagez la sortie. Si le serveur DNS récursif ne prend pas en charge le sous-réseau client EDNS, essayez d'en utiliser un qui le fait. Par exemple, les options qui prennent en charge EDNS incluent Google DNS, OpenDNS et le serveur Amazon DNS. Pour EC2-Classic, le serveur Amazon DNS se trouve à l'adresse 172.16.0.23. Pour VPC EC2, le serveur Amazon DNS se trouve à la base de votre plage réseau VPC, en ajoutant le chiffre 2.

7.     Vérifiez l'emplacement géographique de l'adresse IP du sous-réseau client à l'aide de la base de données GeoIP de MaxMind sur le site Web de MaxMind ou de votre base de données GeoIP préférée. Vérifiez que le résolveur DNS est géographiquement proche de l'adresse IP publique du client.

8.    Vérifiez les problèmes de propagation DNS à l'aide d'un outil tel que CacheCheck sur le site OpenDNS.

9.    (Facultatif) Déterminez si les enregistrements de routage basés sur la géographie sont associés à un contrôle d'intégrité Route 53 et si « Evaluate Target Health » (Évaluer l'intégrité de la cible) est activée (pour les enregistrements d'alias). Si l'un ou les deux sont vrais, alors Route 53 renvoie le point de terminaison sain ayant la latence la plus faible.

Vérifiez l'état de votre vérification d'intégrité Route 53 dans la console Route 53. Si l'option « Evaluate Target Health » (Évaluer l’intégrité de la cible, ETH) est activée, vérifiez l'état d’intégrité du point de terminaison de l'enregistrement. Route 53 considère un point de terminaison pour un Classic Load Balancer avec ETH activé comme sain si au moins une instance backend est saine. Pour les équilibreurs de charge d'applications et de réseau, chaque groupe cible avec des cibles doit contenir au moins une cible saine pour être considéré comme sain. Un groupe cible qui n'a pas de cibles enregistrées est considéré comme malsain. Si un groupe cible ne contient que des cibles malsaines, l'équilibreur de charge est considéré comme malsain.

Par exemple, supposons que vous avez des enregistrements pour le Texas, aux États-Unis pour les États-Unis, l'Amérique du Nord et tous les emplacements (l'emplacement est par défaut). Si une requête provient du Texas et que le point de terminaison pour le Texas n'est pas sain, alors Route 53 vérifie les enregistrements pour les États-Unis, l'Amérique du Nord et tous les emplacements dans cet ordre jusqu'à ce qu'elle trouve un enregistrement avec un point de terminaison sain. Si l'enregistrement américain est sain, alors Route 53 renvoie ce point de terminaison. Sinon, Route 53 renvoie un enregistrement par défaut. Si tous les enregistrements applicables ne sont pas sains, y compris l'enregistrement pour tous les emplacements, Route 53 répond à la requête DNS en utilisant la valeur de l'enregistrement pour la plus petite région géographique.

Remarque : les modifications apportées aux enregistrements de ressources de géolocalisation alias peuvent prendre jusqu'à 60 secondes pour se propager.