Mon blog

Le déploiement du protocole IPv6 est une opération de grande ampleur, qui n'a jamais eu d'équivalent sur Internet, et qui met en cause beaucoup de choses. Les normes qui spécifient le protocole ont donc intérêt à être accompagnées de documents comme notre RFC, qui résume les questions spécifiquement DNS pour IPv6.

Programmer des services IPv6 ou bien les déployer nécessite de lire beaucoup de RFC, si on veut connaitre toutes les normes applicables. Il est donc utile d'avoir des documents d'information comme notre RFC, qui fournit un point d'entrée unique sur les questions DNS qui se posent à IPv6.

Le RFC traite, entre autres, les points suivants :

• Représentation des adresses IPv6 dans le DNS, y compris des catégories d'adresses spécifiques à IPv6 comme les adresses link-local,
• Mauvais comportement de certains serveurs DNS (détaillé plus loin),
• Recommandations pour le nommage (un enregistrement IPv6 et un IPv6 pour www.bortzmeyer.org ou bien seulement un IPv4 et le IPv6 pour www.ipv6.bortzmeyer.org ?),
• Recommandations pour les résolveurs IPv6,
• Recommandations pour la mise à jour des zones droites (traduction de noms en adresses) et inverses (traduction d'adresses en noms via le domaine ip6.arpa).

Le problème des serveurs incorrects (déjà discuté dans le RFC 4074) est une des plaies d'IPv6. En effet, beaucoup de serveurs DNS ne répondent pas correctement lorsqu'ils reçoivent des requêtes de type AAAA (adresses IPv6, les adresses IPv4 étant dans des enregistrements de type A) ; ils ne répondent pas ou, pire, ils répondent que le domaine n'existe pas, même s'il a des enregistrements d'autres types (le bon comportement serait de renvoyer une réponse vide : ne pas avoir un enregistrement DNS d'un type donné n'est pas une erreur).

Ces serveurs incorrects sont souvent des appliances, boîtes fermées, non documentées et non gérées, qu'il est très difficile de mettre à jour une fois qu'elles ont été déployées. Un résolveur IPv6 peut donc être obligé, en violation des normes, d'ignorer une réponse négative et de reessayer avec un autre type d'enregistrements.

Enfin le RFC rappelle que le transport utilisé pour atteindre le serveur de noms (IPv4 ou IPv6) n'a pas de rapport avec le type de données demandé : en effet, une machine qui interroge le DNS en IPv4 peut parfaitement être capable de faire de l'IPv6 et réciproquement. En outre, le client que voit le serveur DNS n'est en général pas le client final mais son cache récursif local. Ce serait donc une erreur de renvoyer préferentiellement des enregistrements A (IPv4) si la question arrive en IPv4.