Résumé

  • La RFC 3172 plaçait .arpa au premier niveau afin de limiter le nombre de dépendances DNS nécessaires avant d’atteindre les données d’infrastructure. Elle soumettait ses serveurs aux exigences opérationnelles de la racine sans confondre les deux zones.
  • En 2001, plusieurs serveurs racine faisaient aussi autorité pour .arpa. Le texte qualifiait cet arrangement de susceptible de changer et signalait le déplacement prévu des données .arpa et in-addr.arpa hors de ces serveurs.
  • La permanence utile concernait le nom, les règles et la continuité de résolution. Politique de l’IAB, coopération d’ICANN, administration de l’IANA, délégation, chargement de zone, réponse DNS et résultat applicatif demeuraient des preuves distinctes.

Une adresse stable pour une machine remplaçable

.arpa n’était pas conçu comme un domaine générique où chacun viendrait nommer un hôte. La RFC 3172 le décrivait comme une racine limitée destinée à des objets de protocole : adresses inversées, numéros ou autres identifiants structurés devenaient des clés DNS permettant de retrouver un nom ou une donnée nécessaire à l’infrastructure.

Le choix du premier niveau répondait à un problème concret. Enfouir une telle zone sous plusieurs parents administratifs aurait obligé le résolveur à dépendre de chacun d’eux avant même de découvrir les serveurs du service recherché. Avec .arpa, la chaîne maximale restait courte : la racine indiquait les serveurs autoritaires, puis ceux-ci répondaient.

Cette économie de parcours n’accordait aucun titre perpétuel aux machines de la racine. La racine publiait la délégation de .arpa; elle n’avait pas besoin d’héberger le contenu de la zone. Inversement, un serveur autoritaire pour .arpa pouvait respecter une discipline très exigeante sans devenir un serveur de la zone racine.

Une exigence héritée n’est pas une identité héritée

La RFC 3172 appliquait aux serveurs .arpa les exigences de la RFC 2870, alors consacrées aux serveurs racine, et prévoyait que leurs révisions futures s’appliqueraient elles aussi. Ce renvoi exprimait l’importance du service : disponibilité, exactitude et exploitation prudente ne devaient pas être inférieures sous prétexte que la zone était spécialisée.

Mais deux services soumis à la même barre opérationnelle ne forment pas un seul service. Une norme commune ne donne pas la même compétence politique. Une machine commune ne confond pas les contenus. Un tableau de supervision qui voit le même hôte répondre à deux zones décrit une configuration, non une constitution.

Cette distinction empêche trois raccourcis. La criticité ne prouve pas que l’opérateur actuel est irremplaçable. La cohabitation ne prouve pas que la zone doit rester sur le même parc. Le respect des exigences de la racine ne prouve pas que l’autorité sur les sous-domaines appartient aux exploitants des serveurs racine.

Le texte annonçait la fin de la cohabitation

La RFC ne dissimulait pas l’état de 2001 : beaucoup de machines autoritaires pour la racine servaient également .arpa. Elle ajoutait que cet arrangement changerait probablement. Elle décrivait aussi le travail de l’IAB avec ICANN, l’IANA et les registres régionaux pour retirer des serveurs racine les enregistrements de .arpa et in-addr.arpa, conformément à la recommandation d’usage exclusif de la racine.

Autrement dit, le document qui proclamait le caractère critique de la zone refusait précisément d’en faire un argument d’immobilité. Le nom devait continuer à résoudre. Le parc de machines pouvait évoluer.

Une migration réussie exigeait toutefois davantage qu’une décision. Le parent devait publier les nouveaux NS et les données de raccordement nécessaires. Les nouveaux serveurs devaient charger la bonne génération de zone, répondre de manière autoritaire, être accessibles depuis des réseaux différents et rester cohérents. Les caches devaient expirer. Les anciennes machines pouvaient continuer à recevoir des requêtes pendant l’intervalle. Les applications dépendantes devaient obtenir le même service utile.

RFC 3172 ne fournit pas le journal de cette exécution. Elle ne donne ni heure de bascule, ni mesure de trafic, ni résultat DNSSEC, ni rapport d’incident. Elle définit une direction et des responsabilités. Transformer cette prescription en preuve de réalisation reviendrait à confondre la carte et le trajet.

Les verbes institutionnels ne sont pas synonymes

L’IAB, en coopération avec ICANN, assumait la responsabilité de gestion décrite par le texte. L’IANA assurait l’administration opérationnelle dans le cadre consigné par la RFC 2860. Un nouveau sous-domaine devait normalement être défini par une spécification IETF de la filière Standards, avec une section IANA Considerations décrivant son nom, son mappage, ses règles d’administration et ses critères d’entrée. Après examen de l’IESG, l’IAB demandait l’action correspondante à l’IANA. La gestion d’un enfant pouvait être déléguée à une entité compétente.

« Définir », « approuver », « demander », « administrer », « déléguer » et « servir » ne désignent donc pas le même pouvoir. Une organisation pouvait fixer la catégorie d’usage sans éditer la zone. Une autre pouvait appliquer la modification sans exploiter tous les serveurs. L’exploitant d’un enfant pouvait gérer ses données sans gouverner le parent.

Les trois exemples de l’époque le montrent. in-addr.arpa suivait la délégation IPv4. ip6.arpa suivait l’allocation IPv6 vers les registres régionaux. e164.arpa reliait les numéros téléphoniques aux URI dans un cadre de liaison différent. Leur parent commun assurait une structure, pas une fusion de leurs régimes.

Vérifier une migration sans fabriquer une propriété

Pour reconstruire un état, il faut conserver le document qui autorise l’usage, la décision correspondante, la version de la zone parente, l’ensemble NS publié, les éventuelles données glue, la version de la zone enfant, la configuration réellement chargée et des observations faites depuis des points définis. Il faut ensuite distinguer la réponse autoritaire, la validation du résolveur et le résultat reçu par l’application.

Un ancien serveur qui répond encore n’est pas forcément encore délégué. Un nouveau serveur présent dans le parent peut être mal configuré. Un numéro de série identique n’établit pas que tous les chemins réseau fonctionnent. Une réponse valide ne prouve pas que l’application a poursuivi son activité. Chacune de ces propositions a son propre reçu.

La RFC 9120 a ultérieurement mis à jour les exigences relatives aux serveurs de .arpa, tandis que la RFC 7720 a remplacé la RFC 2870 pour la racine. Les pages actuelles de l’IANA montrent l’état contemporain. Elles empêchent de présenter 2001 comme le présent, mais elles ne reconstituent pas automatiquement chaque étape intermédiaire.

Les notes de Lu Heng offrent ici une grille déclarée, postérieure aux RFC. Les mandats, les écritures administratives, les délégations, les configurations et les effets appartiennent à des couches de réalité liées mais non substituables. La priorité au code en fonctionnement réclame l’observation du service réel. La continuité du registre protège la fonction coordonnée, non l’éternité d’un gardien ou d’un serveur particulier.

Sources et limites

Les sources ont été figées le 2 octobre 2026, heure de Shanghai. Elles établissent la conception de 2001, la cohabitation déclarée et son caractère transitoire, ainsi que les textes ultérieurs. Elles n’établissent aucun calendrier complet de migration, aucune panne, aucun gain de latence, aucune performance d’opérateur ni aucun résultat applicatif précis.