Résumé

  • RFC 5855 a donné aux zones inverses IPv4 et IPv6 des espaces de noms de serveurs distincts et du glue dans la zone parente, rendant possible une exploitation sur deux ensembles de serveurs.
  • Le RFC n’impose pas cette séparation. Le choix des opérateurs relève d’une fonction de l’IANA ; deux noms différents ne démontrent ni des routes ni des domaines de panne indépendants.

Pour retrouver le nom associé à une adresse, un résolveur ne commence pas par demander l’enregistrement PTR. Il doit d’abord suivre la délégation de la zone inverse et atteindre ses serveurs faisant autorité. Cette étape préalable est une partie du service. Si l’adresse d’un serveur de noms ne peut être obtenue, la recherche échoue avant que le PTR entre en jeu.

C’est ce chemin que RFC 5855, Nameservers for IPv4 and IPv6 Reverse Zones, a cherché à rendre plus direct. Publié en mai 2010 comme Best Current Practice et cosigné par Joe Abley et Terry Manderson, le texte décrivait une situation où un sous-ensemble des serveurs racine desservait IN-ADDR.ARPA, tandis que des systèmes exploités par APNIC, ARIN, ICANN, LACNIC et le RIPE NCC desservaient IP6.ARPA.

La proposition attribue à chaque arbre inverse un espace de noms stable. Les serveurs IPv4 sont nommés sous IN-ADDR-SERVERS.ARPA ; ceux d’IPv6 sous IP6-SERVERS.ARPA. La zone ARPA parente publie le glue IPv4 et IPv6 correspondant. Le résolveur peut ainsi obtenir les adresses des serveurs au moment où il reçoit la délégation, au lieu de lancer une résolution supplémentaire pour découvrir un serveur de la zone IP6.ARPA.

La différence se voit dans les exemples de requêtes du RFC. L’ancienne référence IP6.ARPA pouvait arriver sans glue dans la section additionnelle. Le résolveur devait alors résoudre à son tour le nom d’un des serveurs avant de pouvoir interroger la zone inverse. RFC 5855 traite cette dépendance comme un problème d’exploitation du chemin de délégation : des noms dédiés et des adresses dans la zone parente rendent le parcours plus explicite. La modification touche une étape rarement visible, mais que chaque recherche inverse doit franchir.

Le document compare aussi le coût d’encodage des noms de serveurs. Dans l’exemple historique IPv6, les noms d’enregistrements NS occupent 74 octets ; l’ensemble proposé sous IP6-SERVERS.ARPA en occupe 39. Il s’agit de tailles encodées dans le format DNS, pas d’une mesure de latence ou de disponibilité. La comparaison montre comment des suffixes communs peuvent être compressés dans une référence souvent consultée et comment la destination des adresses de serveurs devient plus lisible.

La séparation des noms devait aussi permettre de séparer les opérations. Le RFC indique que les zones IPv4 et IPv6 peuvent être déléguées à deux ensembles de serveurs distincts, de façon à réduire le risque qu’une panne de l’un affecte les recherches de l’autre famille. Mais le texte ne l’exige pas et ne prescrit pas deux entreprises, deux sites, deux fournisseurs de transit ou deux itinéraires. Il précise même que l’espace de noms des serveurs et la zone inverse correspondante peuvent partager leur sort au sein d’une famille. Une frontière de nommage ouvre une option ; elle ne prouve pas une indépendance physique ou réseau.

Le RFC est tout aussi précis sur la décision restante. Sa section IANA enregistre les délégations et le glue, mais indique que le choix des opérateurs est hors du périmètre du document et relève d’une fonction de l’IANA au titre du mémorandum d’accord IETF–ICANN. La norme décrit donc une interface technique et le passage de responsabilité qui l’accompagne. Elle ne certifie ni qui exploite chaque serveur aujourd’hui ni le degré d’indépendance réel entre les ensembles.

Le rôle de Manderson se situe de part et d’autre de cette frontière. Il a cosigné le RFC, que le Datatracker de l’IETF répertorie parmi ses RFC. Une histoire ultérieure du RSSAC indique qu’il a pris la direction du département DNS Operations d’ICANN en 2013 ; l’équipe a ensuite rejoint ICANN IT et pris le nom DNS Engineering en 2014. Une interview d’ICANN le présente alors comme directeur. Ces éléments attestent une expérience opérationnelle ; ils ne démontrent pas qu’il aurait conçu, choisi ou déployé seul les opérateurs visés par le RFC.

Cette limite rend le texte plus instructif. Il distingue ce qu’un protocole peut nommer de ce qu’un arrangement entre opérateurs doit décider. Pour savoir si les recherches IPv4 et IPv6 échouent réellement de façon indépendante, il faut examiner les ensembles NS en service, le glue, l’hébergement, les routes et les réponses observées. Deux suffixes différents dans une norme ne suffisent pas.

Sources