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

Brève description

Route 53 se dirige vers la région présentant la latence la plus faible en fonction de l'emplacement de la requête DNS si les conditions suivantes sont remplies :

• Vous avez associé des points de terminaison dans plusieurs régions AWS au même enregistrement de ressources.
• Vous utilisez une politique de routage basée sur la latence.

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

• Adresse IP source du résolveur DNS récursif qui envoie la requête au serveur de noms faisant autorité Route 53.
• Version tronquée de l'adresse IP du client (si le résolveur DNS prend en charge l'extension edns00-client-subnet).

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, il envoie à Route 53 une version tronquée de l'adresse IP du client. Route 53 utilise ensuite cette adresse IP tronquée pour déterminer la région de latence la plus faible.

La région présentant la latence la plus faible n'est peut-être pas physiquement la plus proche du résolveur DNS. Vous risquez de constater un comportement de routage indésirable si le client ne se trouve pas au même endroit que le résolveur DNS. Vous pouvez également constater un comportement de routage indésirable si l'adresse IP du résolveur contient des informations de localisation différentes.

Exemple de scénario

Une entreprise possède des enregistrements de routage basés sur la latence pour deux équilibreurs de charge élastiques, l'un situé en Virginie (us-east-1) et l'autre en Irlande (eu-west-1). Aux États-Unis, les utilisateurs utilisent un résolveur DNS d'entreprise situé en Europe ou se connectent au siège social en Europe via un VPN.

Le résolveur DNS d'entreprise ne peut pas envoyer de données de sous-réseau client edns0-aux serveurs de noms faisant autorité. Route 53 considère donc 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 en Irlande présente la latence la plus faible.

Si le résolveur DNS de l'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 correctement que l'équilibreur de charge de Virginie présente la latence la plus faible.

Résolution

Pour résoudre les problèmes de routage indésirables liés à la latence, procédez comme suit :

1.    Vérifiez la plage d'adresses IP utilisée par le résolveur DNS. Sous Linux et macOS, exécutez la commande dig en boucle. Sous Windows, exécutez la commande nslookup plusieurs fois. N’oubliez pas de noter la sortie à chaque fois.

Sous Linux ou macOS, exécutez la commande dig en boucle.

for i in {1..10}; do dig TXT o-o.myaddr.l.google.com +short; sleep 61; done;

Sous Windows, exécutez la commande nslookup plusieurs fois. N’oubliez pas de noter la sortie à chaque fois.

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

2.    Vérifiez que le résolveur DNS prend en charge Anycast en utilisant le résultat de la commande précédente. 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 existe plusieurs emplacements périphériques pour les résolveurs DNS. L'emplacement périphérique d'un utilisateur est sélectionné en fonction de la latence optimale, ce qui peut entraîner une localisation inattendue pour l'adresse IP du résolveur.

3.    Trouvez l'adresse IP du client. Depuis l'ordinateur client, ouvrez un navigateur Internet, puis 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. N'oubliez pas de noter la sortie.

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 de Réponse de la sortie. Cette valeur est le serveur DNS le plus proche faisant la promotion d'Anycast. S'il n'y a pas de deuxième enregistrement TXT, le résolveur DNS ne prend pas en charge le sous-réseau edns0-client-subnet. S'il existe un deuxième enregistrement TXT, le résolveur DNS prend 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. Effectuez une recherche DNS pour le nouvel enregistrement. Consultez les journaux de 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 le TTL n'est pas de 60 secondes, la réponse est une réponse mise en cache. Répétez votre commande dig ou nslookup jusqu'à ce que la valeur TTL de réponse soit de 60 secondes.

7.    Si vous pouvez accéder à l'outil de vérification DNS 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 trouver le jeu d'enregistrements de ressources de latence renvoyé par Route 53.

Si le résolveur DNS ne prend pas en charge le sous-réseau 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 du sous-réseau client EDNS0 comme valeur dans l'outil. Choisissez Configuration supplémentaire, puis spécifiez le masque de sous-réseau.

**Remarque :**l'outil de vérification DNS Route 53 interroge directement la base de données de mesure de latence Route 53. La requête détermine la latence précalculée entre les régions AWS et un réseau Internet. L'outil n'envoie pas de requêtes DNS sur Internet ou à des résolveurs DNS. L'outil ne vérifie pas si le résolveur DNS prend en charge edns0-client-subnet. Les résultats de l'outil et ceux d'une requête DNS réelle peuvent différer.

8.    (Facultatif) si vous ne pouvez pas accéder à l'outil de vérification DNS Route 53, utilisez dig. À l'aide de dig, interrogez 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 de latence la plus faible à partir de votre adresse 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 changer au fil du temps en raison de modifications de la connectivité réseau et du routage. Par exemple, une demande acheminée vers la région de l'Oregon cette semaine peut être acheminée vers la région de l'Ohio la semaine prochaine.

9.    **Pour les résolveurs qui ne prennent pas en charge le sous-réseau edns0-client-subnet :**remplacez le résolveur DNS du client par un autre résolveur DNS récursif situé géographiquement plus près du client. Si le résolveur ne prend pas en charge le sous-réseau edns0-client-subnet, les requêtes DNS du client peuvent utiliser un résolveur DNS situé dans une zone géographique différente de celle du client. Ce scénario aboutit à un comportement de routage inattendu.

Si vous gérez le résolveur DNS, vérifiez la configuration du transfert. Vérifiez que vous ne transférez pas de requêtes DNS vers un autre résolveur 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 de MaxMind ou la base de données GeoIP de votre choix. Si l'adresse IP du sous-réseau client se trouve dans une zone géographique différente de celle du client, vous risquez de constater un comportement de routage inattendu.

10.    (Facultatif) si le résolveur DNS ne prend pas en charge edns0-client-subnet, passez à un résolveur DNS récursif public prenant en charge edns0-client-subnet. Comparez ensuite vos anciens résultats de réponse de routage à latence provenant de Route 53 à vos nouveaux résultats. Par exemple, deux résolveurs DNS publics qui prennent actuellement en charge le sous-réseau 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 surveillance de l’état de Route 53. Déterminez également si l'option Évaluer l'état de la cible (ETH) est activée (pour les enregistrements d'alias). Si l'une ou les deux sont vraies, Route 53 renvoie le point de terminaison sain présentant la latence la plus faible. Si tous les contrôles de surveillance de l’état échouent, seule la politique de routage est prise en compte.

Vérifiez l'état de votre surveillance de l’état Route 53 dans la console Route 53. Si l'ETH est activé, vérifiez l'état de santé du point de terminaison de l'enregistrement. Route 53 considère que le point de terminaison d'un Classic Load Balancer sur lequel l'ETH est activé est sain si au moins une instance de backend est saine. Pour les Application Load Balancers et Network Load Balancers, chaque groupe cible comportant des cibles doit contenir au moins une cible saine pour être considéré comme sain. Un groupe cible sans cible enregistrée est considéré comme défectueux. Si un groupe cible ne contient que des cibles défectueuses, l'équilibreur de charge est considéré comme défectueux.

**Exception :**si un équilibreur de charge d'application possède au moins un groupe cible sain et que tous les autres groupes cibles sont vides, Route 53 le considère comme sain.

Exemple

Vous disposez de deux enregistrements de routage basés sur la latence associés à des contrôles de surveillance de l’état de Route 53, l'un en Oregon et l'autre en Virginie du Nord. Lorsque la surveillance de l'état du point de terminaison de l'Oregon échoue, toutes les demandes sont acheminées vers le point de terminaison de Virginie du Nord, quelle que soit la localisation du client.

Informations connexes

Vérification des réponses DNS depuis Route 53

Comment puis-je déterminer si mon résolveur DNS public prend en charge l'extension de sous-réseau client EDNS ?

Comment puis-je résoudre les problèmes liés aux contrôles de surveillance de l’état de Route 53 ?

Pourquoi mon enregistrement d'alias pointant vers un Application Load Balancer est-il marqué comme défectueux lorsque j'utilise « Évaluer l'état de la cible » ?