Comment vérifier si un domaine prend en charge IPv6

Pour savoir si un domaine publie de l'IPv6, interrogez son enregistrement AAAA. Une réponse AAAA contient une adresse IPv6, tandis qu'une réponse A contient de l'IPv4. Voir un enregistrement AAAA prouve que le nom annonce un point de terminaison IPv6 dans la vue DNS que vous avez interrogée ; cela ne prouve pas que ce point de terminaison est joignable depuis tous les réseaux ni que le site web fonctionne correctement en IPv6. La publication DNS, le routage, les règles de pare-feu, TLS et la configuration applicative doivent tous être alignés. À l'inverse, l'absence de réponse AAAA signifie que le nom interrogé n'a pas renvoyé de données IPv6 à ce moment-là, et non que le domaine entier ou l'organisation n'a aucun déploiement IPv6.

Interroger le bon nom et le bon type d'enregistrement

Vérifiez le nom d'hôte que les utilisateurs visitent réellement, en regardant s'il commence par www ou s'il utilise un sous-domaine applicatif. Un domaine racine peut publier de l'IPv6 sans que www le fasse, ou l'inverse. Interrogez spécifiquement AAAA et comparez avec A pour déterminer si le nom est IPv4 uniquement, IPv6 uniquement ou à double pile (dual-stack). Si un CNAME est renvoyé, suivez la chaîne jusqu'à la cible ; l'alias lui-même peut ne pas afficher l'adresse. Répétez la recherche depuis un résolveur approprié si l'enregistrement vient d'être ajouté, et notez l'heure et le TTL pour distinguer un ancien résultat en cache d'une configuration qui n'a jamais atteint la zone faisant autorité.

Une adresse IPv6 s'écrit en groupes hexadécimaux séparés par deux-points, et les groupes de zéros consécutifs peuvent être compressés par un double deux-points. Cette notation peut sembler peu familière à côté de l'IPv4 en notation pointée. N'essayez pas de comparer des adresses IPv6 comme s'il s'agissait d'IPv4 et ne déduisez pas qu'une adresse est privée simplement parce qu'elle a un aspect différent. Si vous administrez le point de terminaison, vérifiez que l'adresse est attribuée à l'interface prévue, routée depuis Internet et autorisée par les pare-feu de l'hôte et du cloud. Publier un AAAA avant que le point de terminaison soit joignable peut faire échouer une partie des clients, selon leur comportement de sélection de connexion.

Tester séparément l'accessibilité du service

Après avoir confirmé l'enregistrement AAAA, testez l'application en IPv6 depuis un réseau qui dispose réellement d'une connectivité IPv6. Vérifiez que le serveur web écoute sur l'interface IPv6 et présente le bon certificat pour le nom d'hôte. Contrôlez les répartiteurs de charge, les paramètres du CDN, les groupes de sécurité et les pare-feu locaux ; IPv4 et IPv6 ont souvent des règles distinctes, donc autoriser une famille n'autorise pas automatiquement l'autre. Testez aussi les services dépendants comme les API et les hébergeurs d'images si la page charge des ressources depuis plusieurs domaines. Une recherche DNS fournit l'adresse de destination, mais ne peut tester aucune de ces conditions de transport ou d'application.

• Inspectez l'AAAA de chaque nom d'hôte important, pas seulement l'apex.
• Suivez les cibles CNAME jusqu'à trouver l'adresse publiée.
• Vérifiez les politiques de pare-feu et de routage IPv6 indépendamment de l'IPv4.
• Testez HTTPS en IPv6 avant d'annoncer largement l'enregistrement AAAA.
• Surveillez les deux familles d'adresses après des changements d'infrastructure ou de CDN.

Un déploiement double pile en toute sécurité

Un déploiement mesuré commence par confirmer que le fournisseur prend en charge IPv6 à chaque couche concernée : DNS, répartition de charge, pare-feu et connectivité vers l'origine. Testez d'abord un nom d'hôte de préproduction, puis validez depuis plusieurs réseaux compatibles IPv6. Surveillez les journaux applicatifs pour détecter les erreurs propres à une famille d'adresses et comparez les taux de réussite plutôt que de vous fier à un seul test. Gardez prêtes des étapes de retour arrière pour pouvoir retirer ou corriger un enregistrement AAAA s'il pointe vers un point de terminaison qui n'est pas prêt. Si l'environnement utilise un CDN, suivez les instructions de ce fournisseur et déterminez si le DNS public expose des adresses de la périphérie (edge) plutôt que votre origine.

Pour la relation entre les familles d'adresses, voyez comparaison des enregistrements A et AAAA et le guide IPv4 et IPv6 plus général. Pour vérifier la réponse publique, utilisez l'outil de recherche de domaine et lisez séparément les résultats IPv4 et IPv6. La distinction importante est simple : un enregistrement AAAA publié est un fait DNS ; la prise en charge d'IPv6 de bout en bout est une propriété du service qui doit être testée sur l'ensemble du chemin de connexion.

Attention aux déploiements IPv6 partiels

La préparation à IPv6 est souvent inégale au sein d'un même service. Le site web public peut avoir un enregistrement AAAA alors qu'une API, un rappel d'authentification, un hébergeur d'images ou un point de paiement reste en IPv4 uniquement. Cela peut produire une page qui commence à se charger mais échoue sur une dépendance pour les utilisateurs compatibles IPv6. Inventoriez tous les noms d'hôte utilisés par l'application et vérifiez la famille d'adresses prévue pour chacun. Si un CDN est placé devant plusieurs origines, précisez si IPv6 s'arrête à la périphérie (edge) ou se poursuit jusqu'au backend. Journalisez les échecs de connexion par famille d'adresses afin de distinguer un problème de route IPv6 d'une panne générale. Un déploiement progressif et un plan de retour arrière testé valent mieux que de publier largement l'AAAA et d'attendre que des clients signalent la première requête défaillante.