IPv6 annonce le DNS : l’adresse arrive, pas le résolveur

Résumé

SLAAC pouvait donner à un hôte IPv6 une adresse et une route sans lui fournir le résolveur récursif nécessaire pour convertir les noms en destinations.
RDNSS a déplacé la découverte du résolveur dans les Router Advertisements ; DNSSL a ajouté les suffixes de recherche, puis les normes ont fixé les durées, l’ordre des sources et la prise en charge.

Une adresse n’est pas un résolveur

Un hôte IPv6 peut posséder une adresse valide, un préfixe et un routeur par défaut, puis échouer avant d’atteindre un site : il n’a aucun résolveur récursif à consulter pour savoir où mène le nom du site. Le réseau lui a indiqué où envoyer les paquets. Il ne lui a pas encore indiqué où poser ses questions de nommage.

Neighbor Discovery et Stateless Address Autoconfiguration couvraient la première partie. Les Router Advertisements transportaient les informations du lien ; SLAAC permettait à l’hôte de former une adresse sans bail d’adresse DHCPv6. Le DNS suivait une autre voie. En 2007, RFC 5006 indiquait que DHCP était le seul mécanisme DNS de l’IETF sur la voie des Standards Track. Pour un ordinateur qui changeait de réseau sans fil, remplacer manuellement le résolveur à chaque étape était une mauvaise affaire.

RFC 5006 proposait une autre voie, mais la classait Experimental : un Router Advertisement IPv6 pouvait contenir une option Recursive DNS Server, ou RDNSS. L’hôte recevait l’adresse du résolveur dans le même message que les paramètres du lien. Aucun second échange de protocole n’était requis. Le routeur devait tout de même être configuré ; le RFC ne lui apprenait pas à trouver son propre DNS.

Le routeur s’est mis à annoncer les noms

En 2010, RFC 6106 a fait passer les options DNS au statut Standards Track et ajouté DNSSL, la liste des suffixes de recherche. RDNSS fournissait une ou plusieurs adresses de résolveurs. DNSSL fournissait les suffixes qu’un hôte pouvait ajouter à un nom non qualifié demandé par une application. Un ordinateur portable pouvait recevoir son préfixe, son routeur, son résolveur et sa liste de recherche dans les mêmes Router Advertisements.

DHCPv6 n’a pas disparu. RFC 6106 présente DHCPv6 et les RA comme des mécanismes qui peuvent coexister et convenir à des réseaux ou configurations différents. RFC 8106 a ensuite demandé à l’hôte de conserver une liste ordonnée lorsque plusieurs RA ou DHCP apportent des informations DNS. Les réglages DNS statiques choisis par l’utilisateur restent un autre choix. Le problème devient l’ordre des sources, pas la victoire d’un mécanisme unique.

Une minuterie a révélé la perte de paquets

Les entrées RDNSS et DNSSL ont une durée de vie. À l’expiration, l’hôte supprime l’entrée : une annonce vaut donc bail d’information DNS, pas réglage permanent. RFC 6106 encadrait cette durée par rapport à l’intervalle maximal des Router Advertisements. Publié en 2017, RFC 8106 constate que l’ancienne borne basse de deux fois cet intervalle pouvait laisser expirer les options DNS sur des liens très sujets aux pertes. Il assouplit la borne et fixe une valeur par défaut plus élevée, trois fois l’intervalle.

Le changement paraît petit dans un schéma de paquet et grand dans le journal d’incident d’un opérateur : l’adresse et la route peuvent rester valides alors que l’entrée du résolveur disparaît. Une application peut sembler privée de réseau alors que l’hôte atteint toujours directement une adresse IP.

La prise en charge est devenue une exigence IPv6

Le niveau d’exigence a suivi le mécanisme. En 2011, RFC 6434 disait que les implémentations SHOULD prennent en charge l’option DNS des RA. En 2019, RFC 8504 disait que les nœuds IPv6 MUST la prennent en charge. La voie allait d’une option expérimentale à une capacité requise : une adresse seule ne suffisait pas à fournir un service Internet utilisable.

Les règles de source donnent à cette fonction son véritable levier. RFC 8106 demande à l’hôte de conserver une liste ordonnée des informations reçues par RA et par DHCP ; les informations DHCP apparaissent normalement en premier. Un RA protégé par SEND passe avant une source DHCP non authentifiée. Un réglage DNS statique de l’utilisateur peut prendre le dessus sur les informations annoncées.

Ces RFC établissent l’évolution de la conception et des exigences ; ils ne fournissent aucun recensement officiel des hôtes utilisant RDNSS, donc le nombre de clients déployés ne peut pas être indiqué.