Résumé

  • La RFC 1101 reliait noms de réseaux, numéros et niveaux de sous-réseaux au moyen de PTR dans des noms IN-ADDR.ARPA d’hôte zéro ; un A pouvait porter le masque qui permettait de chercher l’étage suivant.
  • Le texte séparait les noms choisis localement de l’index des numéros attribués par le NIC. Une réponse DNS pouvait décrire une association située ; elle n’attribuait pas le numéro, ne suivait pas un renommage et ne démontrait ni contrôle actuel ni résultat de service.

La petite absence dans l’héritage de HOSTS.TXT

La RFC 1101 de P. Mockapetris part d’un manque très exact. Le DNS était extensible et avait repris de nombreuses fonctions de HOSTS.TXT, mais pas la conversion entre noms et numéros de réseaux. Le mémo d’avril 1989 propose une méthode précise pour cette conversion et, séparément, des idées expérimentales pour des index plus généraux d’identifiants et de nombres. La méthode de noms de réseaux est un standard proposé ; les « Yellow Pages » sont une piste expérimentale. Il ne s’agit pas de donner à chaque nombre un sens humain universel, mais de permettre à un administrateur de publier, dans un périmètre déterminé, une étiquette choisie à côté d’un nombre. Un outil de diagnostic peut alors rendre une investigation lisible sans conclure à la propriété, au contrôle, au routage ou au service.

Nommer près de l’endroit où le nom est tenu

Le débat caché sous la syntaxe était administratif. L’ancien espace plat de noms se prêtait à une régulation centrale, parallèle à celle des numéros. La RFC rapporte qu’une majorité préférait le contrôle local des noms de réseaux. Elle reprend la syntaxe élargie des noms d’hôtes et autorise un administrateur à créer des noms dans le domaine qu’il contrôle. Ce choix n’a pas simplifié les libellés : ils deviendraient aussi compliqués que les noms d’hôtes. Il a en revanche gardé leur entretien auprès du contexte qui leur donne sens. ARPANET.ARPA. est dans le document un exemple historique de ce choix ; ce n’est pas une définition perpétuelle du réseau ni une concession du numéro vers lequel une entrée peut pointer.

Pour lire dans l’autre sens, il fallait une autre adresse de dossier. Partir d’une IP ne permettait pas de deviner quel domaine local interroger. La RFC a donc réutilisé l’arbre IN-ADDR.ARPA, où la délégation déjà organisée par les adresses pouvait aussi porter la description inverse. Une nouvelle hiérarchie mondiale aurait ajouté un centre de gravité inutile.

L’hôte zéro : une fiche, pas une destination

La forme proposée était <numéro-hôte-zéro-inversé>.IN-ADDR.ARPA. PTR <nom-de-réseau>. Le nom de réseau portait le PTR réciproque. Si un réseau était encore découpé, un A au même endroit contenait le masque du sous-réseau. Les formes 0.0.0.10.IN-ADDR.ARPA. et 0.0.2.128.IN-ADDR.ARPA. ne sont que les exemples pédagogiques imprimés dans la RFC. Le zéro du champ hôte n’est pas transformé en machine accessible. Il fournit une case reconnaissable de l’arbre DNS, où l’on peut attacher une description et vérifier son existence. Le PTR joint une entrée orientée vers le nombre à un nom maintenu localement. Il ne configure pas un routeur, ne confère aucun droit et ne fait pas du nom l’identité juridique ou opérationnelle du nombre.

Le A est tout aussi circonscrit. Dans cette proposition il transporte un masque lorsqu’il existe un niveau de sous-réseau supplémentaire. La procédure classful de l’époque masquait l’adresse, inversait les octets et demandait le PTR. Si le masque-A était renvoyé, le lecteur reprenait l’adresse d’origine pour chercher plus bas ; son absence arrêtait la recherche. C’est une procédure historique de lecture, non une attestation de topologie présente, de chemin actif ou de résultat de livraison.

Trois liens ne constituent pas une souveraineté

La RFC autorisait aussi un nom d’organisation à contenir des PTR vers une ou plusieurs entrées d’hôte zéro. On obtenait donc trois sens : nom de réseau vers numéro, numéro vers nom, organisation vers enregistrements de réseaux. Chacun est utile parce qu’il reste une réponse limitée. L’association sous un domaine est un fait sur cette publication. Le nom de réseau est un fait sur une désignation locale. La réponse est un fait sur une requête, un algorithme et un moment.

Rien de cela ne prouve seul, ni par simple addition, la propriété actuelle, une relation sociétaire, la garde matérielle, l’autorisation, une route BGP, la réception d’un paquet ou l’effet d’une application. Le document rend les enregistrements plus honnêtes en les laissant petits.

Le mémo reconnaît une tension pratique : les tables centrales pouvaient être plus cohérentes, tandis que les données distribuées pouvaient être plus opportunes et maintenables. Un format de registre ne supprime pas le travail de garder les faits justes. Il lui donne un périmètre et laisse le lecteur voir d’où vient une affirmation.

Le numéro attribué ne dictait pas le nom retenu ensuite

La partie YP exprime la frontière sans détour. La RFC imagine des arbres DNS pour des paires identifiant-nombre : ports, systèmes autonomes, protocoles ou réseaux attribués. Chaque clé doit déclarer son type de départ et d’arrivée ; un nombre seul n’est pas encore une signification. Le NIC aurait pu tenir des domaines YP pour consigner ses décisions d’attribution. Mais le texte précise que ces domaines cartographieraient les noms et numéros attribués, non les noms que les organisations se donnent elles-mêmes. Ils ne suivraient pas automatiquement un renommage par les nouveaux détenteurs. L’attribution et la dénomination locale restent deux faits.

Une liste centrale peut apporter une preuve solide de sa propre décision. Une zone locale peut apporter une preuve solide de l’étiquette qu’elle publie. Aucune des deux ne permet, sans preuve distincte, de conclure à l’opérateur actuel, au service offert, à la route ou au résultat d’une transaction. Un registre décrit dans sa limite ; il ne fabrique pas les faits additionnels.

La bonne échelle de lecture

La RFC 1101 renseigne sur une proposition de 1989. Son modèle classful, ses exemples et ses domaines YP ne décrivent pas le DNS d’aujourd’hui. Sa discipline reste précieuse : donner à une correspondance une provenance, un sens et une portée, sans lui charger les décisions qu’elle ne contient pas. Le réseau devient plus intelligible lorsque nom publié, numéro attribué, route observée et résultat prouvé restent des propositions distinctes.

Sources et limite de preuve

Cette analyse utilise RFC 1101, RFC 1034 et RFC 1035. Elles attestent la proposition de 1989, non des données DNS actuelles, ni le contrôle, l’identité, la propriété, la route, l’accessibilité ou la performance présents.