Résumé

  • Le RFC 1788 proposait d'interroger directement chaque adresse unicast par les messages ICMP 37 et 38 afin de ne plus dépendre uniquement d'un arbre DNS inverse mal tenu.
  • Une réponse vide, un TTL, un identifiant recopié et une adresse source précise bornaient une observation ; ils ne certifiaient ni propriétaire, ni personne, ni route autorisée.
  • En 2013, le RFC 6918 a déprécié le mécanisme parce qu'il n'avait jamais été largement implémenté ou déployé : l'obligation écrite n'avait pas produit l'adoption.

Donner un sens au silence

Une application veut afficher le nom d'un correspondant ou enrichir un journal de sécurité. Elle consulte l'adresse inverse et attend. Si la zone n'est pas déléguée, si l'enregistrement manque ou si l'administration du bloc d'adresses ne suit pas celle du domaine, l'attente peut devenir la partie la plus visible du programme.

Le RFC 1788 partait de cette difficulté concrète. Il constatait que les données IN-ADDR n'étaient pas entretenues avec assez de régularité et que l'adressage sans classe séparait davantage la délégation inverse de l'arbre des noms ordinaires. Sa proposition consistait à déplacer la question : au lieu de demander à une hiérarchie distincte quel nom correspond à l'adresse, envoyer la question à l'adresse elle-même.

Le résultat vide était essentiel. La réponse pouvait contenir zéro, un ou plusieurs noms de domaine pleinement qualifiés. Quand l'hôte n'en connaissait aucun, il devait tout de même répondre. Le demandeur recevait alors une indication faisant autorité que, pour ce répondant et à cet instant, aucun nom n'était connu.

Cette autorité restait étroite. Elle supprimait l'ambiguïté entre « je ne connais aucun nom » et l'absence de réponse. Elle ne créait ni preuve DNSSEC, ni titre de propriété, ni vérité perpétuelle. Le mot qualifiait le statut de la réponse dans ce protocole, pas une souveraineté sur l'identité.

La route comme index, pas comme certificat

Le mécanisme utilisait une requête ICMP de type 37 et une réponse de type 38. Chaque adresse unicast devait être interrogée séparément. Le routage amenait le paquet jusqu'à la machine utilisant l'adresse ; c'est en ce sens que le RFC présentait la route comme l'index de la base de données.

La réponse devait avoir pour adresse source exactement l'adresse de destination de la requête. L'identifiant et le numéro de séquence étaient recopiés afin de rapprocher réponse et question ; ils pouvaient aussi valoir zéro. Ces règles construisaient une correspondance observable : telle adresse a reçu telle question et a produit telle réponse.

Elles n'établissaient pas tout ce que les outils de sécurité aiment déduire d'un nom. Une route ne prouve pas que l'annonce du préfixe est légitime. Une interface ne prouve pas l'identité d'une personne. Un nom fourni par un logiciel ne prouve pas l'organisation propriétaire. Une réponse directe ne réalise pas automatiquement la vérification entre DNS direct et DNS inverse.

Le RFC 1788 le reconnaissait en matière de sécurité. Il envisageait IPsec pour protéger l'échange et une signature cryptographique obtenue par le DNS direct pour vérifier la réponse. Il disait aussi clairement que le routage n'était pas un mécanisme de sécurité. Le chemin transportait l'assertion ; il ne la rendait pas vraie.

Le paquet imposait ses propres omissions

Lorsque plusieurs noms étaient connus, ils devaient en principe tous être donnés. Mais un nom qui ne tenait pas dans le MTU de la réponse était omis. Une réponse pouvait donc être correcte selon les règles tout en ne représentant pas l'ensemble complet imaginé par l'application.

Le TTL renforçait cette limite temporelle. Il était codé comme une valeur signée en complément à deux, pour des raisons historiques. Il indiquait une durée de réutilisation possible. Il ne mesurait ni la qualité de l'administration, ni la durée de vie de la machine, ni la permanence du lien entre une adresse et une institution.

Cette distinction relève de la « couche de réalité » au sens de Heng Lu. Le paquet est un fait observable. L'interprétation institutionnelle qu'on lui ajoute est un autre objet. Si un journal conserve seulement « nom vérifié » sans l'adresse interrogée, l'heure, le TTL, le résultat vide ou rempli et la méthode d'authentification, il transforme un reçu borné en symbole plus puissant que sa source.

Le RFC 792 avait déjà prévenu que l'ICMP ne rendait pas IP fiable. Le datagramme initial peut disparaître ; le message de contrôle aussi. Un délai expiré ne prouve donc pas que la fonction n'existe pas. Il peut signifier perte, filtrage, politique de sécurité ou absence d'implémentation. La réponse vide, le silence et le refus administratif sont trois faits distincts.

Le groupe devait ne rien recevoir

Le protocole excluait la diffusion et le multicast. Toute requête destinée à une adresse de groupe devait être abandonnée silencieusement. Autrement, l'idée d'un serveur présent sur chaque machine pouvait transformer une question en tempête de réponses.

Cette règle montre le coût caché du mot « chaque ». L'universalité du serveur restait compatible seulement avec un déclencheur strictement unicast : une adresse, une requête, une voie de retour. Le mécanisme de découverte ne pouvait pas être élargi naïvement sans amplifier le trafic et l'exposition.

La surface opérationnelle dépassait pourtant le format du paquet. Il fallait du code dans les hôtes, les routeurs et les équipements embarqués ; des politiques de pare-feu ; des outils de diagnostic ; des interfaces pour les applications. Le RFC recommandait justement qu'un hôte fournisse une interface à cette fin. Une spécification courte supposait ainsi une coordination très large.

Le « MUST » qui n'a pas peuplé le réseau

Le RFC 1788 ne présentait pas le serveur comme une option. « Every host and router MUST implement » était une exigence universelle. Or le registre IANA actuel marque les types 37 et 38 comme dépréciés, et le RFC 6918 explique pourquoi : ils n'ont jamais été largement implémentés ou déployés.

Il faut respecter la précision de cette phrase. Elle ne signifie pas qu'aucun programme n'a jamais répondu. Elle ne désigne pas une cause unique et ne distribue pas de culpabilité. Elle constate qu'une densité d'adoption suffisante n'est pas apparue pour transformer la fonction en dépendance commune.

Le problème d'amorçage est visible. Une application ne peut pas compter sur un message auquel peu d'hôtes répondent. Un constructeur investit moins dans une fonction que les applications n'utilisent pas. Les filtres ICMP peuvent la rendre invisible. Les interfaces DNS existent déjà. Enfin, une réponse directe apporte de nouvelles questions de confidentialité, d'authentification et de cohérence des noms.

Le RFC 6918 a ensuite formalisé l'équilibre atteint. Il a observé que la dépréciation pouvait aider au filtrage. La norme tardive n'a donc pas seulement commenté un passé ; elle a donné aux opérateurs une raison supplémentaire de fermer cette surface.

Une comparaison IPv6 plus prudente

Le RFC 4620 a plus tard défini les requêtes IPv6 Node Information à titre expérimental. Il citait l'idée IPv4 antérieure, mais resserrait fortement sa portée : diagnostic, débogage et administration de réseau. Le DNS restait l'autorité mondiale pour les noms.

Le nouveau contrat utilisait un nonce, limitait la portée par défaut, prévoyait confidentialité et limitation de débit, et avertissait que les informations apprises ne devaient pas soutenir une décision de sécurité sans authentification supplémentaire. Le TTL du nom de nœud devait être zéro.

Ce n'était pas la survie discrète du RFC 1788. C'était une autre expérience, conçue après avoir vu les risques du renseignement direct fourni par un nœud. Le document ne prouve d'ailleurs pas lui-même une adoption généralisée.

L'autorité venait des machines qui répondaient

La doctrine de Running-Code Primacy de Heng Lu offre ici une lecture précise. Une norme peut décrire un comportement obligatoire pour toute implémentation qui prétend suivre le protocole. Elle ne peut pas, par la force du vocabulaire normatif, installer ce comportement dans des systèmes contrôlés indépendamment.

Le RFC 1788 possédait la couche symbolique : numéro publié, types attribués, dessin du paquet, obligation universelle. Il n'a pas acquis la couche opérationnelle : une population assez dense de réponses pour devenir un service fiable. Dix-huit ans plus tard, le registre symbolique a été corrigé pour correspondre au réseau réel.

Minimum Initial Specification, Localized Future Decision et Voluntary Adoption ajoutent une leçon. Le paquet était minimal, mais la décision d'adoption ne l'était pas. Elle devait se répéter localement sur presque chaque hôte et chaque routeur, au milieu de politiques et d'incitations différentes. La petite taille d'un en-tête ne mesure pas le poids de coordination.

Cette grille est contemporaine ; elle ne prouve pas l'intention subjective des auteurs de 1995. Elle n'interdit pas non plus les exigences normatives. Un MUST reste indispensable pour rendre prévisible un protocole effectivement adopté. La faute de catégorie consiste seulement à confondre la portée de l'exigence avec la preuve que le monde l'a acceptée.

La réponse vide du RFC 1788 demeure donc une belle idée : transformer l'incertitude en résultat explicite. Son histoire plus vaste est plus sévère. Pour que le silence ait un sens partagé, il fallait d'abord que presque toutes les machines sachent parler. Le texte leur en donnait l'ordre ; le code en fonctionnement n'a jamais constitué l'assemblée nécessaire.

Sources