DNS IPv6 : enregistrements AAAA, résolution dual-stack et bonnes pratiques

DNS est le point où un déploiement IPv6 fonctionne ou échoue. Publiez un enregistrement AAAA avant que votre connectivité IPv6 ne fonctionne, et les utilisateurs attendent à travers des timeouts. Sautez le DNS inverse, et les serveurs de messagerie rejettent votre trafic. Mal configurez la résolution dual-stack, et vous ralentissez le réseau au lieu de l'accélérer.

Ce guide couvre comment DNS fonctionne avec IPv6, ce qui casse, et comment le corriger avant que cela ne devienne un problème.

Enregistrements AAAA : l'équivalent IPv6 des enregistrements A#

Un enregistrement AAAA (prononcé « quad-A ») associe un nom d'hôte à une adresse IPv6. C'est l'équivalent IPv6 d'un enregistrement A, mais il contient une adresse de 128 bits au lieu de 32 bits.

Format et structure#

example.com.    3600    IN    AAAA    2001:db8::1

La structure correspond aux enregistrements A : nom, TTL, classe, type et adresse. L'adresse utilise la notation IPv6 standard avec des deux-points et des chiffres hexadécimaux.

Les zéros de tête dans chaque groupe peuvent être omis, et les groupes de zéros consécutifs se compriment en ::. Ces deux formats sont valides et identiques :

example.com.    IN    AAAA    2001:0db8:0000:0000:0000:0000:0000:0001
example.com.    IN    AAAA    2001:db8::1

Utilisez le format compressé. Il est plus facile à lire et moins sujet aux erreurs de saisie.

Interroger des enregistrements AAAA#

Interrogez les enregistrements AAAA de la même manière que les enregistrements A, spécifiez simplement le type.

Avec dig :

dig AAAA example.com
dig AAAA @2001:4860:4860::8888 example.com

Avec nslookup :

nslookup -type=AAAA example.com
nslookup -type=AAAA example.com 2001:4860:4860::8888

Avec host :

host -t AAAA example.com

Vous pouvez également utiliser notre outil de recherche DNS pour interroger simultanément les enregistrements A et AAAA et comparer les résultats.

Enregistrements AAAA vs A#

Les deux servent le même objectif — traduire des noms en adresses — mais ils diffèrent de manière importante :

Les enregistrements A et AAAA sont complètement indépendants. Ils peuvent avoir des TTL différents, pointer vers des serveurs différents, ou exister sans l'autre. Cette flexibilité est utile mais crée des opportunités de mauvaise configuration.

Résolution DNS dual-stack#

La plupart des réseaux fonctionnent en dual-stack : IPv4 et IPv6 fonctionnent simultanément. Lorsqu'un client recherche un nom d'hôte, il reçoit à la fois des enregistrements A et AAAA. Le système d'exploitation décide ensuite lequel utiliser.

Happy Eyeballs (RFC 8305)#

Les systèmes d'exploitation modernes implémentent Happy Eyeballs, un algorithme qui essaie à la fois IPv4 et IPv6 mais préfère IPv6 quand il fonctionne. L'algorithme :

1. Interroge DNS pour les enregistrements A et AAAA
2. Commence à se connecter à l'adresse IPv6 en premier
3. Attend 50-250 ms (dépend de l'implémentation)
4. Si IPv6 ne s'est pas encore connecté, lance une connexion IPv4 en parallèle
5. Utilise la connexion qui se termine en premier

Cette approche équilibre performance et fiabilité. IPv6 obtient la préférence, mais un IPv6 cassé ne bloque pas longtemps les connexions.

Ordre de résolution#

L'ordre dans lequel les clients interrogent les enregistrements et tentent les connexions varie selon l'OS et la configuration.

La plupart des systèmes Unix/Linux :

• Interrogent A et AAAA simultanément ou AAAA en premier
• Préfèrent les adresses IPv6 si elles existent
• Contrôlé par /etc/gai.conf (configuration getaddrinfo)

macOS :

• Interroge les deux types d'enregistrements en parallèle
• Implémente Happy Eyeballs strictement
• Préfère fortement IPv6 quand disponible

Windows :

• Interroge les deux types d'enregistrements
• Préfère IPv6 par défaut (configurable via le registre)
• Implémente Happy Eyeballs depuis Windows 8

Navigateurs :

• Chrome et Firefox implémentent leur propre Happy Eyeballs
• Ne se fient pas uniquement au comportement de l'OS
• Peuvent mettre en cache les résultats de résolution de manière agressive

Quand IPv6 gagne (ou perd)#

IPv6 gagne généralement la course quand :

• La connectivité IPv6 est native (pas tunnelée)
• Le routage IPv6 est direct sans sauts supplémentaires
• La destination est bien connectée via IPv6

IPv6 perd quand :

• Il est tunnelé (6to4, Teredo) avec latence ajoutée
• Le routage prend des chemins plus longs qu'IPv4
• Le serveur est mal connecté via IPv6
• Des problèmes de pare-feu ou de middlebox ralentissent les connexions

Tester le comportement dual-stack#

Forcez IPv4 ou IPv6 pour tester le comportement :

# Forcer IPv4
curl -4 https://example.com
 
# Forcer IPv6
curl -6 https://example.com
 
# Laisser l'OS choisir
curl https://example.com

Comparez les temps de réponse. Si IPv6 est significativement plus lent, enquêtez sur les problèmes de routage ou de connectivité avant de publier largement les enregistrements AAAA.

DNS64 et NAT64#

DNS64 synthétise des enregistrements AAAA à partir d'enregistrements A, permettant aux réseaux IPv6 uniquement d'accéder aux services IPv4 uniquement. Il fonctionne avec NAT64, qui traduit les paquets entre IPv6 et IPv4.

Comment fonctionne DNS64#

Lorsqu'un client IPv6 uniquement interroge un nom d'hôte :

1. Le serveur DNS64 reçoit la requête
2. Vérifie l'existence d'un enregistrement AAAA
3. Si AAAA existe, le retourne normalement
4. Si seul un enregistrement A existe, synthétise un enregistrement AAAA en utilisant un préfixe spécial
5. Le client se connecte à l'adresse IPv6 synthétisée
6. La passerelle NAT64 traduit la connexion vers IPv4

Le préfixe bien connu : 64:ff9b::/96#

Le préfixe DNS64 le plus courant est 64:ff9b::/96, défini dans RFC 6052. Les 32 derniers bits de l'adresse incorporent l'adresse IPv4.

Exemple de synthèse :

Enregistrement A :    192.0.2.1
Préfixe :             64:ff9b::/96
Enregistrement AAAA : 64:ff9b::192.0.2.1
                      ou 64:ff9b::c000:201 (en hexa)

Certains réseaux utilisent d'autres préfixes comme 2001:db8::/96 ou des plages personnalisées. Le préfixe doit être configuré de manière cohérente sur DNS64 et NAT64.

Quand vous avez besoin de DNS64/NAT64#

DNS64 est essentiel pour :

• Les réseaux mobiles IPv6 uniquement (courant avec T-Mobile, AT&T)
• Les centres de données IPv6 uniquement accédant aux services IPv4 hérités
• Tester le comportement des clients IPv6 uniquement

Vous n'avez pas besoin de DNS64 si :

• Votre réseau est dual-stack
• Tous les services auxquels vous accédez ont IPv6 natif
• Vous pouvez imposer IPv6 sur tous les services backend

Limitations et pièges#

DNS64 casse plusieurs choses :

La validation DNSSEC échoue – L'enregistrement AAAA synthétisé ne correspond pas à la zone signée. Les serveurs DNS64 doivent supprimer les signatures DNSSEC, réduisant la sécurité.

Les applications qui incorporent des adresses IP cassent – Si une application reçoit une adresse IPv4 dans JSON, XML ou d'autres formats de données, DNS64 ne la traduira pas. L'application essaie de se connecter à une adresse IPv4 depuis une pile IPv6 uniquement et échoue.

Les load balancers et CDN sont confus – DNS64 fait apparaître tous les clients comme provenant de l'adresse de la passerelle NAT64. La géolocalisation, la limitation de débit et l'identification client cassent.

Les référencements et redirections échouent – Si une réponse DNS inclut des adresses IPv4 dans des sections supplémentaires (comme des enregistrements de colle NS), les clients ne peuvent pas les atteindre.

DNS inverse (enregistrements PTR)#

Le DNS inverse mappe une adresse IPv6 vers un nom d'hôte. Ce n'est pas obligatoire pour la connectivité mais requis pour les serveurs de messagerie et utile pour la journalisation et les outils de sécurité.

La zone ip6.arpa#

Le DNS inverse IPv6 utilise le domaine ip6.arpa. Chaque nibble (4 bits, ou un chiffre hexadécimal) de l'adresse devient une étiquette dans le nom de domaine, écrit en ordre inverse.

Convertir des adresses au format PTR#

Prenez l'adresse IPv6 complète non compressée, inversez-la nibble par nibble et ajoutez ip6.arpa.

Exemple : 2001:db8::1

Étape 1 : Développer en forme complète :

2001:0db8:0000:0000:0000:0000:0000:0001

Étape 2 : Écrire tous les nibbles :

2 0 0 1 0 d b 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

Étape 3 : Inverser l'ordre :

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 b d 0 1 0 0 2

Étape 4 : Séparer avec des points et ajouter ip6.arpa :

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

C'est le nom de l'enregistrement PTR. Il pointe vers votre nom d'hôte.

Interroger le DNS inverse#

Avec dig et conversion automatique :

dig -x 2001:db8::1

Interroger directement l'enregistrement PTR :

dig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Avec host :

host 2001:db8::1

Déléguer le DNS inverse#

Les zones DNS inverses sont déléguées par votre FAI ou RIR. Si vous avez un /48, vous contrôlez un espace DNS inverse /48. La plupart des fournisseurs vous permettent de le gérer via une interface web ou vous permettent d'exécuter vos propres serveurs DNS pour la zone inverse.

Pour les allocations plus petites (comme un /64), certains FAI gèrent les enregistrements PTR individuels pour vous. Contactez-les avec l'adresse et le nom d'hôte.

Erreurs DNS courantes avec IPv6#

Publier AAAA sans IPv6 fonctionnel#

C'est l'erreur numéro un. Vous activez IPv6 sur un serveur, créez l'enregistrement AAAA et supposez que ça fonctionne. Mais si le pare-feu bloque IPv6, le routage est cassé ou le serveur n'écoute pas réellement sur IPv6, les clients attendent des timeouts.

Symptôme : Chargements de sites web lents, surtout sur les réseaux mobiles qui préfèrent IPv6.

Correction : Testez la connectivité depuis plusieurs réseaux IPv6 externes avant de publier l'enregistrement AAAA. Utilisez notre outil Ping pour vérifier l'accessibilité.

Oublier le DNS inverse#

Le DNS direct fonctionne bien, mais vous sautez le DNS inverse. Cela casse la livraison de courrier, perturbe l'analyse des logs et semble peu professionnel.

Symptôme : Rejet de courrier, erreurs « Reverse DNS lookup failed ».

Correction : Configurez les enregistrements PTR pour toutes les adresses de serveur. Vérifiez avec dig -x depuis plusieurs emplacements.

Décalage de TTL entre A et AAAA#

Votre enregistrement A a un TTL de 3600 secondes, mais AAAA a 300. Quand vous mettez à jour DNS, les clients obtiennent des résultats incohérents pendant des heures.

Symptôme : Certains clients résolvent vers les anciennes adresses, d'autres vers les nouvelles. Difficile à dépanner.

Correction : Faites correspondre les TTL pour les enregistrements A et AAAA. Ils doivent être identiques. Baissez les deux avant de faire des changements, puis augmentez-les à nouveau après.

Le pare-feu bloque DNS via IPv6#

Votre serveur DNS a une adresse IPv6 et un enregistrement AAAA, mais le pare-feu bloque UDP et TCP port 53 via IPv6. Les clients ne peuvent pas l'interroger.

Symptôme : Les requêtes DNS échouent depuis les clients ou réseaux IPv6 uniquement.

Correction : Autorisez UDP et TCP port 53 pour IPv4 et IPv6. Testez depuis un hôte IPv6 uniquement. Rappelez-vous que DNS via TCP est obligatoire, pas optionnel.

Configuration dual-stack incomplète#

Vous configurez les enregistrements AAAA pour votre site web mais pas pour votre CDN, serveurs de messagerie ou points de terminaison API. Les utilisateurs obtiennent des résultats mixtes.

Symptôme : Le site principal fonctionne via IPv6, mais le contenu intégré, les appels API ou le courrier basculent vers IPv4, perdant les avantages de performance.

Correction : Activez IPv6 pour tous les services dans la chaîne, pas seulement le front-end. Testez les workflows complets depuis des clients IPv6 uniquement.

Adresses IPv4 codées en dur dans la configuration#

Votre DNS se résout bien, mais les fichiers de configuration d'application contiennent des adresses IPv4 codées en dur. Les services cassent quand les clients IPv6 uniquement essaient de se connecter.

Symptôme : L'application échoue avec des erreurs de connexion sur les réseaux IPv6 uniquement.

Correction : Utilisez des noms d'hôte, pas des adresses IP, dans les fichiers de configuration. Laissez DNS se résoudre vers la famille d'adresses appropriée.

Bonnes pratiques#

Testez minutieusement avant de publier#

Avant d'ajouter des enregistrements AAAA au DNS de production :

1. Vérifiez que le service écoute sur IPv6 : netstat -an | grep :80 (ou votre port)
2. Testez depuis une adresse IPv6 externe : curl -6 https://[2001:db8::1]/
3. Vérifiez que les règles de pare-feu autorisent le trafic IPv6
4. Vérifiez que le routage est correct avec traceroute6
5. Testez depuis plusieurs réseaux IPv6 (mobile, haut débit, centre de données)

Ne supposez pas que ça fonctionne parce que l'OS a une adresse IPv6.

Faites correspondre les TTL pour les enregistrements A et AAAA#

Définissez des TTL identiques. Cela maintient un comportement de cache cohérent et simplifie les mises à jour DNS.

example.com.    3600    IN    A       192.0.2.1
example.com.    3600    IN    AAAA    2001:db8::1

Si vous devez changer les adresses, baissez le TTL 24-48 heures avant le changement, effectuez la mise à jour, puis augmentez-le à nouveau.

Configurez le DNS inverse#

Configurez les enregistrements PTR pour toutes les adresses IPv6 publiquement routables. C'est requis pour les serveurs de messagerie et utile pour tout le reste.

Travaillez avec votre FAI ou RIR pour déléguer la zone inverse. Gardez les enregistrements PTR synchronisés avec le DNS direct — ils doivent correspondre.

Surveillez les deux protocoles#

Suivez le volume de requêtes DNS, les temps de réponse et les taux d'erreur séparément pour les enregistrements A et AAAA. Surveillez la résolution via le transport IPv4 et IPv6.

Configurez des alertes pour :

• Les requêtes AAAA échouant alors que les requêtes A réussissent
• Les différences de temps de réponse entre IPv4 et IPv6
• Les baisses soudaines de volume de requêtes IPv6

Une surveillance séparée détecte les problèmes avant que les utilisateurs ne se plaignent.

Utilisez des serveurs DNS compatibles IPv6#

Vos serveurs DNS doivent répondre aux requêtes via IPv4 et IPv6. Configurez les deux familles d'adresses même si votre réseau n'est pas encore entièrement dual-stack.

Testez depuis des clients IPv6 uniquement. Un nombre surprenant de serveurs DNS ont des enregistrements AAAA mais n'acceptent pas réellement les requêtes via IPv6.

Implémentez DNSSEC avec précaution#

DNSSEC fonctionne avec IPv6, mais DNS64 le casse. Si vous utilisez DNS64 dans votre réseau, vous ne pouvez pas valider DNSSEC sur les enregistrements synthétisés.

Pour les déploiements en production, concevez pour le dual-stack natif et évitez DNS64 dans la mesure du possible.

Articles connexes#

• Les fondamentaux d'IPv6 – Comprenez l'adressage IPv6 et en quoi il diffère d'IPv4
• Dépannage IPv6 – Diagnostiquez et corrigez les problèmes de connectivité IPv6 courants
• Liste de contrôle pour le déploiement IPv6 – Guide complet pour déployer IPv6 en production

Questions fréquentes#