Pourquoi le trafic de mon contenu Web a-t-il été acheminé vers l’emplacement périphérique CloudFront incorrect ?

Brève description

CloudFront achemine le trafic en fonction de la catégorie de tarifs de la distribution, des bases de données de géolocalisation associées et de la prise en charge d’EDNS0-Client-Subnet. En fonction de la combinaison de ces facteurs, les visiteurs de votre site Web peuvent être redirigés vers un emplacement périphérique inattendu. Cela peut augmenter la latence globale pour récupérer un objet depuis un emplacement périphérique CloudFront.

Pour résoudre les problèmes liés au trafic qui est acheminé vers un emplacement périphérique inattendu, vérifiez ce qui suit :

• La catégorie de tarifs prend en charge l'emplacement périphérique que vous attendez.
• Le résolveur DNS prend en charge le routage Anycast.
• Le résolveur DNS prend en charge EDNS0-Client-Subnet.

Résolution

La catégorie de tarifs prend en charge l'emplacement périphérique attendu

Vérifiez les emplacements périphériques inclus dans la catégorie de tarifs de votre distribution CloudFront. Pour inclure d'autres emplacements périphériques, modifiez votre catégorie de tarifs.

Le résolveur DNS prend en charge le routage Anycast

Si le résolveur DNS prend en charge le routage Anycast, il utilise plusieurs emplacements périphériques. Étant donné que l’emplacement périphérique d'un demandeur est basée sur une latence optimale, vous pouvez observer un emplacement inattendu pour l'adresse IP du résolveur.

Pour vérifier si le résolveur DNS prend en charge Anycast, exécutez plusieurs fois l'une des commandes suivantes.

Systèmes d'exploitation (OS) autres que Windows :

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

Windows :

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

Si la sortie inclut la même adresse IP chaque fois que vous exécutez la commande, cela signifie que le résolveur DNS ne prend pas en charge Anycast. Si la sortie inclut une adresse IP différente chaque fois que vous exécutez la commande, le résolveur DNS prend en charge Anycast.

Le résolveur DNS prend en charge EDNS0-Client-Subnet

Exécutez l'une des commandes suivantes pour vérifier si le résolveur DNS prend en charge EDNS0-Client-Subnet.

Systèmes d'exploitation autres que Windows :

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

Windows :

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

Remarque : Vérifiez la valeur TTL et veillez à exécuter la commande à l'expiration du TTL. Sinon, vous pourriez obtenir une réponse mise en cache à partir du résolveur récursif.

Si le résolveur DNS ne prend pas en charge EDNS0-Client-Subnet, la sortie est similaire à ce qui suit :

$ dig +nocl TXT o-o.myaddr.l.google.com  +short
"192.0.2.1"

Dans l'exemple précédent, 192.0.2.1 correspond à l'adresse IP du serveur DNS le plus proche qui a utilisé Anycast. Le résolveur DNS ne prend pas en charge EDNS0-Client-Subnet.

Pour vous assurer que le trafic de votre site Web est acheminé vers l’emplacement correct, effectuez l'une des actions suivantes :

• Modifiez le résolveur DNS en un résolveur DNS récursif situé géographiquement plus près des clients de votre site Web.
• Passez à un résolveur DNS qui prend en charge EDNS0-Client-Subnet.

Si le résolveur DNS prend en charge EDNS0-Client-Subnet, la sortie contient un sous-réseau client tronqué (/24 or /32) destiné au serveur de noms faisant autorité CloudFront :

$ dig +nocl TXT o-o.myaddr.l.google.com @8.8.8.8 +short
"192.0.2.1"
"edns0-client-subnet 198.51.100.0/24"

Dans l'exemple précédent, 192.0.2.1 correspond à l'adresse IP du résolveur DNS le plus proche. La plage client-sous-réseau utilisée pour répondre à une requête DNS est 198.51.100.0/24.

Même si votre résolveur DNS prend en charge EDNS0-Client-Subnet, le trafic de votre site Web peut toujours être incorrectement acheminé. Pour résoudre ce problème, associez une base de données de géolocalisation publique à la plage client-sous-réseau qui envoie la requête au résolveur DNS. Si le résolveur DNS transmet la version tronquée des adresses IP client aux serveurs de noms CloudFront, CloudFront vérifie une base de données basée sur plusieurs bases de données de géolocalisation publiques.

Vous devez mapper correctement les adresses IP dans la base de données de géolocalisation afin que les requêtes soient correctement acheminées.

Si le résolveur DNS prend en charge le sous-réseau eDNS0-Client-Subnet, exécutez la commande de recherche DNS suivante pour déterminer l'emplacement périphérique vers lequel le trafic est acheminé :

$ dig dftex7example.cloudfront.net. +short
13.224.77.109
13.224.77.62
13.224.77.65
13.224.77.75

Puis, exécutez une recherche DNS inversée sur les adresses IP renvoyées par la commande précédente :

$ dig -x 13.224.77.62 +short
server-13-224-77-62.man50.r.cloudfront.net.

Dans l'exemple précédent, le trafic est acheminé vers l'emplacement périphérique de Manchester.

Conseil : Pour un test supplémentaire, vous pouvez utiliser un résolveur DNS public qui prend en charge EDNS0-Client-Subnet, tel que 8.8.8.8, 8.8.4.4 ou 1.1.1.1. Envoyez des requêtes avec des adresses IP d’emplacement périphérique au résolveur DNS public. Puis, vérifiez les résultats des requêtes DNS pour savoir si CloudFront dispose des informations correctes concernant votre EDNS0-Client-Subnet.