Comment résoudre les problèmes liés aux enregistrements de ressources basés sur la latence et à Route 53 ?

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

Le routage basé sur la latence d'Amazon Route 53 renvoie un serveur dans une région AWS éloignée géographiquement 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 en Europe. Comment éviter que des clients soient acheminés vers des régions éloignées de leur emplacement ?

Brève description

Route 53 est résolu à la région dont la latence est la plus faible en fonction de l'emplacement de la requête DNS si les éléments suivants sont vrais :

Route 53 prend la décision de routage basée sur la latence en fonction des éléments suivants :

Les serveurs de noms 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 dont la latence est la plus faible ne sera pas nécessairement la plus proche du résolveur DNS du point de vue physique. Vous pouvez rencontrer un comportement de routage indésirable si le client ne se trouve pas au même emplacement que le résolveur DNS. Vous pouvez également rencontrer un comportement de routage indésirable si l'adresse IP du résolveur contient des informations d'emplacement différentes.

Exemple de scénario

Une société dispose d'enregistrements de routage basé sur la latence pour deux Elastic Load Balancers situés l'un en Virginie (us-east-1) et l'autre 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 un VPN.

Si le résolveur DNS d'entreprise ne peut pas envoyer de données EDNS0-client-Subnet aux serveurs de noms faisant autorité, Route 53 considère l'adresse IP du résolveur DNS en Europe comme 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 peut envoyer des données EDNS0-client-Subnet, Route 53 considère l'adresse IP tronquée du client aux États-Unis comme la source de la requête. 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.

Résolution

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. Sur Linux/macOS, exécutez la commande dig dans une boucle. Sous Windows, exécutez la commande nslookup plusieurs fois et veillez à bien noter la sortie à chaque fois.

Sous Linux ou macOS, utilisez dig :
for i in {1..10}; do dig TXT o-o.myaddr.l.google.com +short; sleep 61; done;

Sous Windows, utilisez nslookup :

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

2.    Confirmez 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, alors le résolveur DNS ne prend pas en charge Anycast. Si l'adresse IP change lorsque vous exécutez la commande plusieurs fois, alors le résolveur DNS prend en charge Anycast.

Lorsqu'un résolveur DNS prend en charge Anycast, il existe plusieurs emplacements périphériques pour les résolveurs DNS. Cela signifie que l'emplacement périphérique d'un utilisateur est sélectionné en fonction d'une latence optimale, ce qui peut entraîner un emplacement inattendu pour l'adresse IP du résolveur.

3.    Recherchez l'adresse IP du client. Depuis l'ordinateur client, ouvrez un navigateur Internet et accédez à 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 de l'une des commandes suivantes. Veillez à bien 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 désigne le serveur DNS le plus proche publiant Anycast. S'il n'y a pas de deuxième enregistrement TXT, alors le résolveur DNS ne prend pas en charge EDNS0-Client-Subnet. S'il y a un deuxième enregistrement TXT, alors le résolveur DNS prend également en charge EDNS0-Client-Subnet. Le résolveur envoie un sous-réseau client tronqué (/24 ou /32) au serveur de noms faisant autorité Route 53.

(Facultatif) Si vous avez activé la journalisation des requêtes DNS Route 53 sur votre zone hébergée, créez un enregistrement de test. Ensuite, effectuez une recherche DNS pour le nouvel enregistrement. Vérifiez les journaux des requêtes pour confirmer l'adresse IP du résolveur et le sous-réseau EDNS0-client-Subnet (le cas échéant) présentés aux serveurs de noms Route 53.

6.    Vérifiez que la valeur TTL de la réponse est de 60 secondes. Si ce 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 pouvez accéder à l'outil de vérification de DNS Route 53, simulez alors des requêtes à partir d'un résolveur DNS ou d'une adresse IP client spécifique. Utilisez ces requêtes pour rechercher quel jeu d'enregistrements de ressources de latence est renvoyé par Route 53.

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

Si le résolveur DNS prend en charge EDNS0-Client-Subnet, spécifiez alors l'IP de sous-réseau client EDNS0 comme votre valeur dans l'outil. Choisissez Configuration supplémentaire, puis spécifiez le masque de sous-réseau.

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

8.    (Facultatif) Si vous ne pouvez pas accéder à l'outil de vérification DNS Route 53, utilisez alors dig. Avec dig, recherchez les serveurs de noms faisant autorité Route 53 pour votre zone hébergée avec EDNS0-client-Subnet. Utilisez la sortie pour déterminer la région 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. Par exemple, une demande qui est acheminée vers la région de l'Oregon cette semaine pourra être acheminée vers la région de l'Ohio la semaine prochaine.

9.    Pour les résolveurs qui ne prennent pas en charge EDNS0-Client-Subnet, remplacez le résolveur DNS du client par un DNS récursif différent, plus proche géographiquement du client. Si le résolveur ne prend pas en charge EDNS0-Client-Subnet, les requêtes DNS du client peuvent alors utiliser un résolveur DNS dans un emplacement géographique différent de celui du client. Dans ce scénario, le résultat est un comportement de routage inattendu.

Si vous gérez le résolveur DNS, vérifiez la configuration de transmission. Confirmez que vous ne transmettez pas les requêtes DNS à un autre résolveur qui est plus éloigné de l'emplacement géographique du client.

Pour les résolveurs qui prennent en charge EDNS0-Client-Subnet, vérifiez l'emplacement géographique de l'adresse IP du sous-réseau client. Pour vérifier l'emplacement, utilisez la base de données GeoIP sur le site Web MaxMind, ou votre base de données GeoIP préférée. Si l'emplacement de l'adresse IP du sous-réseau client se trouve dans un emplacement géographique différent de celui du client, les clients peuvent alors rencontrer 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 de 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).

11.    (Facultatif) Déterminez si les enregistrements de routage basés sur la latence sont associés à une vérification d'état Route 53 et si l'option « Évaluer l'état de la cible » est activée (pour les enregistrements d'alias). Si un seul ou les deux sont vrais, Route 53 renvoie alors le point de terminaison sain dont la latence est la plus faible. Si toutes les vérifications d'état échouent, seule la stratégie de routage est prise en compte.

Vérifiez le statut de votre vérification d'état Route 53 dans la console Route 53. Si l'option « Évaluer l'état de la cible » (ETH) est activée, vérifiez le statut de la vérification d'état du point de terminaison de l'enregistrement. Route 53 considère qu'un point de terminaison pour un Classic Load Balancer avec option ETH activée est sain si au moins une instance backend est saine. Concernant les Application Load Balancers et les Network Load Balancers, 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 non sain. Si aucun des cibles d'un groupe cible n'est saines, l'équilibreur de charge est considéré comme non sain. Exception : si un Application Load Balancer a au moins un groupe cible sain et que tous les groupes cibles restants sont vides, Route 53 le considère alors comme sain.

Par exemple, disons que vous disposez de deux enregistrements de routage basés sur la latence avec des vérifications d'état Route 53 associées, l'un en Oregon et l'autre en Virginie du Nord. Lorsque la vérification d'état du point de terminaison Oregon échoue, toutes les demandes sont acheminées vers le point de terminaison Virginie du Nord, indépendamment de l'emplacement du client.