Un enregistrement AAAA associe un nom d'hôte à une adresse IPv6, l'équivalent de l'enregistrement A pour l'IPv4, et c'est ce qui permet aux clients dual-stack d'atteindre un site via le protocole le plus récent.
Qu'est-ce qu'un enregistrement AAAA ?
Un enregistrement AAAA (parfois appelé "quad-A") est défini par la RFC 3596 et stocke une adresse IPv6 de 128 bits pour un nom d'hôte, exactement le rôle que joue un enregistrement A pour une adresse IPv4 de 32 bits. Un domaine peut posséder les deux types d'enregistrement en même temps pour le même nom : c'est le principe du "dual-stack", un seul nom d'hôte, deux adresses, deux versions de protocole.
L'enregistrement lui-même ne porte ni priorité ni poids. Un nom d'hôte peut avoir plusieurs enregistrements AAAA, et les résolveurs sont libres de les renvoyer dans n'importe quel ordre ; la plupart des serveurs de noms font d'ailleurs tourner l'ordre à chaque requête.
- AAAA contient une adresse IPv6 complète, écrite sous forme hexadécimale compressée (par exemple 2606:4700::6810:85e5)
- Un domaine avec A et AAAA est dual-stack ; un domaine uniquement en AAAA est IPv6 uniquement, encore rare sur les sites grand public en France
- Le nom cible d'un AAAA doit se résoudre directement, jamais via un CNAME, la même contrainte que la RFC 1034 impose aux enregistrements A
Dual-stack et happy eyeballs
Quand un nom possède à la fois un A et un AAAA, un client dual-stack (connecté en IPv4 et en IPv6) doit choisir quelle famille d'adresse essayer en premier. Fait naïvement, ce choix ralentit la connexion : si l'IPv6 est cassé quelque part sur le chemin, un client qui attend l'expiration complète du délai IPv6 avant de basculer vers IPv4 peut rester bloqué plusieurs secondes.
La RFC 8305 décrit la solution, connue sous le nom de Happy Eyeballs. Le client interroge à la fois les enregistrements A et AAAA, lance la connexion vers l'adresse IPv6 en premier, puis déclenche une tentative de secours en IPv4 après un court délai (couramment 250 ms) si la première tentative n'a pas encore abouti. La connexion qui aboutit en premier gagne, l'autre est abandonnée. Les navigateurs modernes et la plupart des résolveurs système appliquent ce mécanisme par défaut, notamment sur les box grand public en France (Freebox, Livebox), ce qui explique pourquoi publier un AAAA casse rarement quoi que ce soit pour les visiteurs restés en IPv4 : un client sans vraie connectivité IPv6 devrait basculer vers l'A en quelques centaines de millisecondes.
Le scénario que Happy Eyeballs cherche à éviter reste visible quand un AAAA est publié mais en réalité injoignable, par exemple un pare-feu qui ignore silencieusement le trafic IPv6 au lieu de le refuser explicitement. Un abandon silencieux (par opposition à un refus de connexion immédiat) est le pire cas pour n'importe quel client, même ceux qui implémentent correctement Happy Eyeballs, car il faut alors attendre l'expiration d'un délai au lieu de recevoir un signal immédiat pour changer de famille d'adresse.
AAAA à l'apex de la zone
L'apex de la zone (le domaine nu, comme exemple.fr plutôt que www.exemple.fr) ne peut pas porter de CNAME selon la RFC 1034, car l'apex doit aussi contenir les enregistrements SOA et NS, et un CNAME doit être le seul enregistrement présent sur son nom. AAAA à l'apex contourne entièrement cette restriction, puisqu'il s'agit d'un type d'enregistrement normal qui cohabite avec SOA et NS sur le même nom ; il n'a pas besoin des contournements ALIAS/ANAME que certains hébergeurs DNS ont conçus spécifiquement pour simuler un CNAME sur l'apex.
Les hébergeurs qui proposent A et AAAA sur l'apex, comme ceux qui ne proposent que A (ou un ALIAS) sur l'apex en renvoyant AAAA vers www, sont deux configurations légitimes. Ce qui compte pour la cohérence, c'est que toute adresse publiée sur un nom pointe vers un service qui répond réellement sur cette version de protocole, car un AAAA obsolète pointant vers une adresse IPv6 désaffectée ne basculera pas de lui-même comme le ferait une chaîne de CNAME rompue.
Lire les résultats d'une recherche AAAA
Chaque ligne de résultat AAAA affiche le type d'enregistrement, l'adresse IPv6 résolue et, quand le résolveur le renvoie, un TTL en secondes. Il n'y a pas de champ priorité ou poids sur un AAAA, contrairement à MX ou SRV, car les enregistrements d'adresse ne portent aucune préférence d'ordre dans le protocole.
| Champ | Exemple de valeur | Signification |
|---|---|---|
| Type | AAAA | Type d'enregistrement, toujours AAAA pour cette requête |
| Valeur | 2606:4700::6810:85e5 | L'adresse IPv6 résolue, sous forme compressée |
| TTL | 300 | Durée en secondes pendant laquelle un résolveur peut mettre cette réponse en cache |
Problèmes fréquents avec AAAA
- Aucun enregistrement AAAA : le domaine est en IPv4 uniquement. Ce n'est pas une erreur, cela signifie simplement que les clients IPv6 uniquement (certains opérateurs mobiles, certains réseaux IoT) basculent vers une passerelle NAT64/DNS64 si elle est configurée, ou échouent si ce n'est pas le cas
- AAAA publié mais injoignable : l'adresse est annoncée dans le DNS mais rien ne répond dessus, souvent un équilibreur de charge ou un pare-feu pas encore configuré pour l'écouteur IPv6 correspondant à l'IPv4
- Contenu différent derrière A et AAAA : certaines configurations de CDN ou d'hébergement servent par erreur un contenu ou un certificat TLS différent selon la famille d'adresse utilisée par le client, généralement à cause d'une configuration restée à l'ancien état sur l'une des deux pattes du dual-stack
- TTL resté très court ou très long après une migration : un TTL court est normal pendant une bascule vers une nouvelle plage IPv6, mais le laisser bas durablement ajoute une charge de requêtes inutile sur les serveurs faisant autorité
Questions fréquentes
Ajouter un enregistrement AAAA casse-t-il l'accès pour les visiteurs restés en IPv4 ?
Non. Les clients IPv4 uniquement ignorent simplement le AAAA et utilisent l'enregistrement A comme avant. Les clients dual-stack avec Happy Eyeballs (RFC 8305) essaient les deux et retiennent celui qui se connecte en premier : ajouter un AAAA s'ajoute au A, il ne le remplace pas.
Un nom d'hôte peut-il avoir un AAAA sans avoir d'enregistrement A ?
Oui, un hôte purement IPv6 est valide et de plus en plus fréquent pour des services internes ou back-end. Pour un site public, cela reste rare, car cela exclut les clients IPv4 sauf si une passerelle NAT64/DNS64 se trouve en amont du réseau.
Pourquoi ma recherche AAAA ne renvoie rien alors que la recherche A fonctionne ?
Cela signifie que le domaine n'a pas encore publié d'adresse IPv6. C'est un choix de configuration, pas un défaut : beaucoup de domaines fonctionnent indéfiniment en IPv4 seul et ne renverront jamais d'enregistrement AAAA tant que l'exploitant n'en ajoute pas un explicitement.
Un enregistrement AAAA peut-il pointer vers une cible CNAME ?
Non. Comme un enregistrement A, un AAAA doit se résoudre directement vers une adresse ; la RFC 1034 impose qu'un nom portant un CNAME n'ait aucun autre type d'enregistrement, donc un nom d'hôte est soit un CNAME, soit porteur de A/AAAA, jamais un mélange des deux sur le même nom.
Pourquoi deux recherches AAAA sur le même domaine renvoient-elles parfois les adresses dans un ordre différent ?
De nombreux serveurs faisant autorité font tourner l'ordre des enregistrements AAAA multiples à chaque réponse (round-robin), et les caches de résolution sur le chemin peuvent aussi les réordonner. C'est un comportement normal de répartition de charge, pas un défaut, et cela correspond à ce que font aussi plusieurs enregistrements A.
L'IPv6 est-il indispensable pour qu'un domaine fonctionne correctement ?
Non. Un domaine qui ne porte que des enregistrements A fonctionne parfaitement pour la grande majorité du trafic internet aujourd'hui. L'AAAA devient pertinent pour atteindre les réseaux IPv6 uniquement ou qui privilégient l'IPv6, plus fréquents chez les opérateurs mobiles et dans les réseaux qui n'ont plus de plage IPv4 à allouer, une situation de plus en plus courante chez les opérateurs français.