Un peu de rangement dans le DNS : en
2000, un nouveau type d'enregistrement DNS, le
A6, avait été créé pour gérer plus facilement les
adresses IPv6 dans le DNS. N'ayant finalement
pas marché comme espéré, il vient d'être officiellement abandonné. Le
, qui le normalisait, devient « intérêt historique seulement ».
Le type officiel pour représenter les adresses
IPv6 dans le DNS était
le AAAA, introduit par le
(aujourd'hui ). Très proche du type
A d'IPv4, il n'offrait pas
de services particuliers, par exemple pour gérer la rénumérotation
d'un réseau. Si on avait dans son fichier de zone :
www IN AAAA 2001:db8:33::1
mail IN AAAA 2001:db8:33::fada
et qu'on passe du réseau 2001:db8:33::/48 au
2001:db8:bad::/48, il fallait faire un
rechercher/remplacer pour changer toutes les adresses. Le type
A6, du , fournissait un système
plus souple, découplant le préfixe et l'adresse.
Évidemment, le fait d'avoir deux types pour les adresses IPv6 a
entraîné pas mal de confusion (section 2.5). Il est même possible que cela ait
contribué au retard du déploiement d'IPv6. En
2002, les et critiquaient A6 et il était reclassé
« expérimental ». Cela n'a apparemment pas suffit à éclaircir les
choses et notre met aujourd'hui
A6 comme « d'intérêt historique seulement », ce
qui devrait enlever toute ambiguité. Le seul type pour représenter les
adresses IP dans le DNS est donc AAAA.
Mais que reprochait-on à A6, finalement ? La
section 2 de ce RFC résume les principaux problèmes (le donne davantage de détails) :
- Latence accrue au moment de la résolution de noms (puisque
A6 implique plusieurs requêtes DNS
non-parallélisables, et sur des
serveurs différents),
- Probabilité d'échec plus élevée (il suffit qu'une des
sous-requêtes de la chaîne échoue pour que la résolution soit
impossible),
- Difficultés associées au franchissement de frontières
administratives : certes, le principe même d'A6
était de permettre de déléguer plus facilement, en mettant les
différents enregistrements nécessaires dans des organisations
différentes. Mais l'expérience d'A6 (comme celle
des enregistrements de colle dans la zone parente, ou celle des
PTR de in-addr.arpa) a
montré qu'il était très difficile de synchroniser de tels
enregistrements « trans-frontières » et qu'ils se prêtaient mal à
l'automatisation,
- Complexité de la maintenance puisque le changement d'un
composant A6 peut affecter de nombreuses adresses
IP, qu'on ne voit pas (le reste des données peut être dans une autre
zone, et même avoir des TTL différents, rendant
la prévision des résultats difficile),
- Et enfin risques de sécurité, la résolution d'un nom en adresse
IPv6 dépendant de davantage d'acteurs ; la compromission de l'un d'eux
pouvait affecter beaucoup de monde.
La section 3 décrit l'usage effectif d'A6,
depuis que certaines versions de BIND (de 9.0 à
9.2, puis abandonné dans les versions ultérieures) ont
ajouté la gestion de ce type d'enregistrements. De même, certaines
versions de la GNU libc ont fait des requêtes
A6. Mais, aujourd'hui, l'analyse du trafic
sur deux serveurs DNS de la racine montre très peu de trafic
a6 Les statistiques sur les serveurs de
.fr gérés par
l'AFNIC montrent que A6
n'a pas disparu. Il ne fait certes
que 0,2 % des requêtes (contre 8 % pour AAAA)
mais il est le dixième type d'enregistrement
demandé, devant des types comme SPF, SSHFP,
NAPTR ou DNSKEY, normalement bien plus
« officiels ». Cela illustre le conservatisme des administrateurs
système (qui gardent en production de très vieilles versions de leurs logiciels).
La section 4 expose les conséquences de la reclassification de
A6 comme n'ayant qu'un intérêt historique. Les
gérants de zone DNS doivent retirer ces enregistrements (s'ils
existaient encore), les clients DNS doivent arrêter de demander des
A6 et les
serveurs DNS doivent désormais traiter ce type comme inconnu () lors de la réception d'une requête. (Le type
A6 faisait partie de ceux pour lesquels le
serveur DNS devait faire un traitement spécial.) Comme c'est déjà
largement le cas, ce RFC n'aura sans doute pas de conséquence pratique.