Résumé

  • La version IP qui transporte une transaction DNS ne détermine pas la famille des adresses demandées : une requête AAAA peut circuler sur IPv4, et une requête A sur IPv6.
  • RFC 3596 a ajouté l’enregistrement AAAA de 128 bits et adapté certains traitements de réponse, tout en séparant le contenu DNS du chemin réseau suivi par la question.

Deux sens du mot « IPv6 »

Imaginez un résolveur qui envoie une question DNS dans un paquet IPv4 : « Quels enregistrements AAAA sont associés à ce nom ? » L’en-tête IPv4 décrit le trajet de ce message précis. Le type de la question demande des données d’adresse IPv6. Les deux sont compatibles. RFC 3596 affirme explicitement que la version IP utilisée pour interroger les enregistrements est indépendante de la version du protocole portée par ces enregistrements. RFC 4472 en formule la conséquence pratique : on peut interroger AAAA sur IPv4 et A sur IPv6.

Cette distinction paraît évidente jusqu’au moment où les deux couches sont confondues. La première version désigne l’enveloppe réseau de la requête. La seconde décrit le contenu d’un RR DNS. Si un serveur choisissait ses réponses selon le transport observé, il ferait dépendre les faits DNS du chemin emprunté, alors que ce chemin ne dit pas quelles adresses sont associées au nom.

La séparation fonctionne dans les deux sens. Un transport IPv6 n’oblige pas à demander AAAA : il peut porter une requête A. La version de l’adresse source ou destination du paquet ne prouve pas non plus que le demandeur saura utiliser une adresse retournée. Le standard définit l’indépendance ; il ne garantit ni l’accessibilité future ni le succès d’une connexion applicative.

Ajouter une donnée sans remplacer le transport

Le modèle DNS antérieur utilisait le RR A pour une adresse IPv4 de 32 bits. RFC 1886 a introduit AAAA pour stocker une adresse IPv6 de 128 bits et un mécanisme de recherche inverse. RFC 3152 a ensuite déplacé l’arbre inverse de IP6.INT vers IP6.ARPA. RFC 3596 a réuni ces changements, conservé le soutien à IPv4 et défini AAAA, type 28, comme un enregistrement contenant une adresse IPv6 complète.

Il s’agissait d’étendre les données de DNS, pas de créer un transport IPv6 propre aux messages DNS. Les questions et réponses continuaient d’utiliser le mécanisme DNS existant. Le transport IP pouvait être IPv4 ou IPv6, indépendamment du type A ou AAAA demandé. L’espace de noms mondial n’avait donc pas à se scinder en un « DNS IPv4 » et un « DNS IPv6 » dès que le DNS pouvait contenir les deux familles.

Un choix concurrent existait. Les enregistrements A6 permettaient de fragmenter une adresse et d’en relier les parties par DNS, ce qui pouvait réduire certaines mises à jour lors d’un changement de préfixe. Cette souplesse introduisait aussi des recherches en chaîne et des dépendances supplémentaires. RFC 3363 a consigné la décision de maintenir AAAA sur la voie des standards et de placer A6 et les bit labels au statut expérimental ; RFC 3364 expose les compromis. RFC 3596 a donc retenu un enregistrement d’adresse complet, plus direct à consulter, sans prétendre résoudre à lui seul le renumérotage ou le déploiement IPv6.

Les réponses avaient aussi leurs règles

RFC 3596 a également adapté le traitement de la section Additionnelle pour les requêtes NS, SRV et MX : des adresses A et AAAA pertinentes, disponibles localement, pouvaient être ajoutées. Une requête AAAA ne déclenche pas elle-même ce traitement. Un RR demandé directement et une adresse fournie comme donnée d’appui dans une autre réponse restent deux comportements distincts.

« Le serveur peut inclure » ne signifie pas que la réponse prouve l’existence de toutes les adresses. Les données locales peuvent manquer, un cache peut être incomplet, et un enregistrement DNS n’est pas un paquet de test. RFC 4472 déconseille de sélectionner ou filtrer les réponses selon la famille du transport : celle-ci ne correspond souvent pas à la famille des enregistrements nécessaires au client. Filtrer une famille sur cette base peut donner à un même nom des réponses différentes selon le chemin réseau de la requête.

Une réponse AAAA prouve seulement que DNS a retourné des données d’adresse IPv6 pour un nom. Elle ne prouve ni l’existence d’une route IPv6 depuis ce résolveur, ni qu’un service écoute à cette adresse, ni qu’un pare-feu autorise la session, ni que DNSSEC a validé ces données, ni que l’application s’est connectée. Le fait de recevoir la réponse via IPv4 ne dit pas davantage quelle version IP utilisera une éventuelle connexion au service.

Une frontière qui rendait la coexistence lisible

RFC 3596 se résume souvent à « DNS a reçu AAAA ». Son apport historique comprend aussi la préservation d’un invariant pendant l’ajout d’une nouvelle famille d’adresses : l’enveloppe du transport et la famille codée dans le RR sont deux dimensions indépendantes. Pendant la transition, un transport IPv4 pouvait récupérer des données IPv6, et un transport IPv6 des données IPv4, dans un espace de noms commun.

Les RFC définissent le mécanisme et la séparation attendue. Ils n’établissent ni la fréquence à laquelle les implémentations l’ont respectée, ni le comportement d’un résolveur donné, ni l’utilité simultanée des enregistrements A et AAAA d’un nom. Pour répondre à ces questions, il faut des preuves distinctes d’implémentation, de configuration, de mesure et d’accessibilité.

Sources : RFC 1034 ; RFC 1035 ; RFC 1886 ; RFC 3152 ; RFC 3363 ; RFC 3364 ; RFC 3596 ; RFC 3597 ; RFC 4472.