Le routage basé sur la latence d'Amazon Route 53 renvoie un serveur dans une région AWS très éloignée du client. Par exemple, lorsqu'un utilisateur situé aux États-Unis tente d'accéder à mon site web, Route 53 renvoie l'adresse IP d'un serveur situé en Europe. Comment puis-je éviter que des clients soient acheminés vers des régions AWS éloignées de leur emplacement ?

Route 53 identifie la région AWS avec la latence la moins importante selon l'emplacement de la requête DNS si les éléments suivants sont vrais :

Route 53 calcule la latence en fonction des éléments suivants :

Les serveurs de nom Route 53 prennent en charge EDNS0-Client-Subnet par défaut. Si un résolveur DNS récursif prend en charge EDNS0-Client-Subnet, le résolveur DNS envoie à Route 53 une version tronquée de l'adresse IP du client. Route 53 utilise alors cette adresse IP tronquée pour déterminer la région AWS dont la latence est la plus faible.

La région AWS ayant la latence la plus faible ne sera pas nécessairement la plus proche du résolveur DNS d'un point de vue physique. Il est possible qu'un comportement de routage inapproprié se produise si le client ne se trouve pas au même emplacement que le résolveur DNS ou si l'adresse IP du résolveur a des informations d'emplacement différentes.

Utilisez les étapes suivantes pour dépanner le comportement non souhaité de routage basé sur la latence :

1. Vérifiez la plage d'adresses IP utilisée par le résolveur DNS dans une région AWS spécifique. 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

2. Vérifiez que le résolveur DNS prend en charge Anycast à l'aide de la sortie. Si la sortie contient toujours la même adresse IP unique, le résolveur DNS ne prend pas en charge Anycast. Si l'adresse IP change lorsque vous exécutez la commande plusieurs fois, le résolveur DNS prend en charge Anycast.

Lorsqu'un résolveur DNS prend en charge Anycast, il y a plusieurs emplacements périphériques pour les résolveurs DNS et l'emplacement périphérique d'un utilisateur est choisi en fonction de la latence optimale, ce qui donner un emplacement inattendu pour l'adresse IP du résolveur.

3. Recherchez l'adresse IP du client. À partir de l'ordinateur client, visitez l'URL suivante dans un navigateur afin de voir l'adresse IP du client : https://checkip.amazonaws.com/

Ou utilisez curl :

curl https://checkip.amazonaws.com/

4. 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 @<DNS Resolver>

Sous Windows, utilisez nslookup :

nslookup -type=txt o-o.myaddr.l.google.com <DNS Resolver>

5. Vérifiez le premier enregistrement TXT renvoyé dans la section Answer de la sortie. Cette valeur est le serveur DNS le plus proche publiant Anycast. 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 également en charge EDNS0-Client-Subnet. Le résolveur fournit, puis envoie un sous-réseau client tronqué (/24 ou /32) au serveur de noms faisant autorité de Route 53.

6. Vérifiez que la valeur TTL de la réponse est de 60 secondes. Si tel n'est pas le cas, la réponse est mise en cache. Répétez votre commande dig ou nslookup jusqu'à ce que la valeur TTL de la réponse soit de 60 secondes.

7. Si vous avez accès à l'outil de vérification DNS de Route 53, simulez des requêtes à partir d'un résolveur DNS ou d'une adresse IP client spécifique. Utilisez ces requêtes pour rechercher le jeu d'enregistrements de ressources de latence renvoyé par Route 53.

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'IP de sous-réseau du client EDNS0 comme valeur dans l'outil. Choisissez More Options (Options supplémentaires), puis spécifiez le masque Subnet (Sous-réseau) également. Ne spécifiez pas l'adresse IP d'un résolveur.

Remarque : cet outil interroge directement la base de données des mesures de latence Route 53 afin de déterminer la latence précalculée entre les régions AWS et un réseau Internet. L'outil n'envoie pas réellement de requêtes DNS via Internet ou aux résolveurs DNS. L'outil de simulation ne vérifie pas si le résolveur DNS prend en charge EDNS0-Client-Subnet. Les résultats obtenus avec un simulateur ou une véritable requête DNS peuvent varier.

8. (Facultatif) Si vous n'avez pas accès à l'outil de vérification DNS de Route 53, 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 IP source :

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

Remarque : la latence entre les hôtes sur Internet peut évoluer dans le temps en raison des changements de connectivité réseau et de routage.

9. Pour les clients qui prennent en charge EDNS0-Client-Subnet, remplacez le point de sortie des requêtes DNS du client par un emplacement situé plus près du client d'un point de vue géographique. Si le résolveur prend en charge EDNS0-Client-Subnet, il est possible que les requêtes DNS du client partent d'un emplacement différent de celui du client et entraînent un comportement de routage inattendu.

Pour les clients qui ne prennent pas en charge EDNS0-Client-Subnet, remplacez le résolveur DNS utilisé par le client par un autre résolveur DNS récursif situé plus près du client d'un point de vue géographique. Si le résolveur ne prend pas en charge EDNS0-Client-Subnet, il est possible que les requêtes DNS du client utilisent un résolveur DNS dans un emplacement géographique différent de celui du client, ce qui pourrait entraîner un comportement de routage inattendu.

10. (Facultatif) Si le résolveur DNS ne prend pas en charge EDNS0-Client-Subnet, basculez vers un résolveur DNS récursif public qui prend en charge EDNS0-Client-Subnet. Comparez ensuite vos anciens résultats de réponse de routage avec latence depuis Route 53 à vos nouveaux résultats. Par exemple, deux résolveurs DNS publics qui prennent actuellement en charge EDNS0-Client-Subnet sont GoogleDNS (8.8.8.8 et 8.8.4.4) et OpenDNS (208.67.222.222 et 208.67.220.220).

Exemple de dépannage

Une société a des enregistrements de routage basé sur la latence pour deux Elastic Load Balancers situés en Virginie (us-east-1) et en Irlande (eu-west-1). Les utilisateurs qui se trouvent aux États-Unis utilisent un résolveur DNS d'entreprise situé en Europe ou se connectent au siège social européen via le VPN.

Si le résolveur DNS d'entreprise n'est pas capable d'envoyer des données EDNS0-Client-Subnet (informations d'adresses IP de clients tronquées) au serveurs de noms faisant autorité, Route 53 considère que l'adresse IP du résolveur DNS en Europe est la source de la requête. Route 53 effectue ensuite une recherche dans sa base de données de latence et détermine à tort que l'équilibreur de charge situé en Irlande présente la latence la plus faible.

Toutefois, si le résolveur DNS d'entreprise est capable d'envoyer des données EDNS0-Client-Subnet, Route 53 considère l'adresse IP du client tronquée aux États-Unis comme la source de la requête DNS. Route 53 effectue ensuite une recherche dans sa base de données de latence et détermine à raison que l'équilibreur de charge situé en Virginie présente la latence la plus faible.


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support

Date de publication : 06/09/2017

Date de mise à jour : 20/11/2018