J'utilise Amazon CloudFront pour distribuer mon contenu Web. Toutefois, le trafic vers mon site Web est acheminé vers le mauvais emplacement périphérique. Comment résoudre ce problème ?
Brève description
CloudFront achemine le trafic en fonction de la catégorie de prix de la distribution, des bases de données de géolocalisation associées et de la prise en charge d'EDNS0-Client-Subnet. Selon la combinaison de ces facteurs, les utilisateurs de votre site Web peuvent être acheminés vers un emplacement périphérique inattendu. Cela peut augmenter la latence globale de récupération d'un objet à partir d'un emplacement périphérique CloudFront.
Pour résoudre les problèmes de routage vers un emplacement périphérique inattendu, vérifiez les points suivants :
- La catégorie de prix prend en charge l'emplacement périphérique attendu.
- Le résolveur DNS prend en charge le routage Anycast.
- Le résolveur DNS prend en charge EDNS0-Client-Subnet.
Solution
La catégorie de prix prend en charge l'emplacement périphérique attendu
Vérifiez les emplacements périphériques inclus dans la catégorie de prix de votre distribution CloudFront. Vous pouvez mettre à jour la catégorie de prix de votre distribution si vous souhaitez inclure d'autres emplacements périphériques.
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. Cela signifie que l'emplacement périphérique d'un demandeur est basé sur une latence optimale, ce qui peut entraîner un emplacement inattendu pour l'adresse IP du résolveur.
Pour vérifier si le résolveur DNS prend en charge Anycast, exécutez l'une de ces commandes plusieurs fois :
Remarque : Dans ces exemples de commandes, veillez à remplacer example.com par le nom de domaine du résolveur DNS que vous utilisez.
Sous Linux ou macOS, exécutez une commande dig, comme dans l'exemple suivant :
dig +nocl TXT o-o.myaddr.l.example.com
Sous Windows, exécutez une commande nslookup, comme dans l'exemple suivant :
nslookup -type=txt o-o.myaddr.l.example.com
Si la sortie inclut la même adresse IP chaque fois que vous exécutez la commande, 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 ne prend en charge Anycast. Cela peut être la raison de l'emplacement périphérique inattendu.
Le résolveur DNS prend en charge EDNS0-Client-Subnet
Pour déterminer comment éviter un routage incorrect, commencez par vérifier si le résolveur DNS prend en charge EDNS0-Client-Subnet en exécutant l'une des commandes suivantes :
Remarque : Dans ces exemples de commandes, veillez à remplacer example.com par le nom de domaine du résolveur DNS que vous utilisez.
Sous Linux ou macOS, exécutez une commande dig, comme dans l'exemple suivant :
dig +nocl TXT o-o.myaddr.l.example.com
Sous Windows, exécutez une commande nslookup, comme dans l'exemple suivant :
nslookup -type=txt o-o.myaddr.l.example.com
Remarque : vérifiez la valeur TTL et veillez à exécuter la commande lorsque la durée de vie expire. Sinon, vous pouvez obtenir une réponse mise en cache de la part 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.example.com +short
"192.0.2.1"
Dans l'exemple précédent, 192.0.2.1 est l'adresse IP du serveur DNS le plus proche qui utilise Anycast. Ce résolveur DNS ne prend pas en charge EDNS0-Client-Subnet. Pour éviter un routage incorrect, vous pouvez effectuer l'une des actions suivantes :
- Remplacez un résolveur DNS par un résolveur DNS récursif situé géographiquement plus près des clients de votre site web.
- Passez par 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 ou /32) vers le serveur de noms faisant autorité CloudFront, similaire à ce qui suit :
$ dig +nocl TXT o-o.myaddr.l.example.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 est l'adresse IP du résolveur DNS le plus proche. En outre, la plage client-subnet est 198.51.100.0/24 et est utilisée pour répondre aux requêtes DNS. Pour éviter un routage incorrect lorsque le résolveur DNS prend en charge EDNS0-Client-Subnet, vérifiez qu'une base de données de géolocalisation publique est associée à la plage client-subnet envoyant 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. Les adresses IP doivent être correctement mappées dans la base de données de géolocalisation afin que les demandes soient acheminées correctement.
Si le résolveur DNS prend en charge EDNS0-Client-Subnet, vous pouvez vérifier l'emplacement périphérique vers lequel le trafic est acheminé en commençant par résoudre votre CNAME CloudFront en exécutant une commande de recherche DNS telle que dig :
$ dig dftex7example.cloudfront.net. +short
13.224.77.109
13.224.77.62
13.224.77.65
13.224.77.75
Ensuite, exécutez une recherche DNS inverse 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 ou 8.8.4.4. Envoyez des requêtes avec des adresses IP d'emplacement périphérique au résolveur DNS public. Ensuite, vérifiez les résultats des requêtes DNS pour voir si CloudFront dispose des bonnes informations sur votre EDNS0-client-subnet.