Résumé

  • RFC 3467 rappelait que le DNS résout des identifiants réseau exacts et uniques ; il n'a pas été conçu pour deviner une personne, un produit ou une ressource à partir d'une demande floue.
  • La « couche de recherche » proposée séparait la découverte de la résolution, mais ne constituait ni un protocole achevé, ni une norme, ni la preuve d'un déploiement.

Un annuaire peut hésiter, un résolveur doit trancher

Une personne qui cherche « l'atelier Martin près du vieux port » peut accepter plusieurs réponses, corriger une faute et demander un contexte géographique. Un résolveur DNS ne mène pas cette enquête. Il reçoit un nom construit et un type d'enregistrement, parcourt une hiérarchie distribuée et rend les données associées. Cette discipline est une qualité lorsque la question est exacte ; elle devient un mauvais substitut à la recherche lorsque la question ne l'est pas.

Le mémo Informational de John Klensin, publié sous le numéro RFC 3467, relisait en 2003 le rôle du Domain Name System. Il ne prétendait pas livrer une solution. Son résumé disait qu'il proposait seulement un cadre et invitait la communauté à penser plus largement. L'auteur qualifiait aussi son histoire de partiellement révisionniste : les raisons des décisions anciennes avaient été peu documentées et les souvenirs pouvaient diverger.

Ce n'était pas un constat d'effondrement. Le texte observait que les performances et la fiabilité restaient acceptables et qu'il existait peu de signes d'une dégradation grave. Son alerte portait sur l'accumulation de missions. À chaque demande nouvelle, il paraissait tentant d'utiliser le DNS parce qu'il était déjà universellement disponible, même lorsque sa structure ne convenait pas aux données.

Le contrat historique du DNS

Le prédécesseur était une table d'hôtes recopiée fréquemment. Les noms évitaient de mémoriser des adresses numériques, restaient stables quand la topologie imposait un changement d'adresse et pouvaient désigner un hôte doté de plusieurs connexions. La table centralisée ne passait plus à l'échelle. Le DNS conserva des noms uniques et non ambigus, tout en distribuant la consultation et l'administration dans une hiérarchie. De nouveaux types d'enregistrements pouvaient s'y ajouter.

Cette souplesse n'en faisait pas un annuaire universel. RFC 3467 décrivait un système destiné aux ressources du réseau, non principalement aux personnes, marques, produits ou documents. Le format pouvait transporter des données binaires, mais les applications avaient hérité de conventions beaucoup plus étroites sur les noms utilisables. Pouvoir stocker une valeur n'établissait ni que cette valeur devait être là, ni que le DNS savait la rechercher intelligemment.

Le texte employait alors une formule sévère : le DNS était devenu une « base de données de commodité ». Son implantation était un avantage réel, mais pas une preuve d'adéquation. Une hiérarchie de clés exactes, des caches et une autorité publique unique imposent des contraintes qui diffèrent de celles d'un moteur de découverte.

L'égalité binaire ne mesure pas la ressemblance utile

À la fin d'une résolution DNS, deux noms concordent selon des règles déterminées ou ne concordent pas. Une recherche humaine peut exiger des variantes orthographiques, des écritures différentes, des règles locales, des attributs et plusieurs candidats classés. Elle peut aussi devoir chercher dans les valeurs et non seulement dans la clé. RFC 3467 réunissait ces tensions : noms commerciaux aplatis, nombreux noms sur un même hôte, réponses dépendant de la proximité, informations personnelles à accès différencié et internationalisation.

L'internationalisation montrait particulièrement bien la frontière. La préparation d'une chaîne peut éliminer certaines variantes avant une comparaison exacte. Elle ne devine pas l'intention. Une normalisation définie conduit à une forme comparable ; une recherche approximative accepte que plusieurs objets restent plausibles. Confondre les deux transforme une décision culturelle ou contextuelle en résultat d'infrastructure.

Le DNS n'était pas davantage un moteur général de recherche par valeur. IQUERY, ancienne opération destinée à retrouver les noms associés à un enregistrement, fut rendue obsolète après une mise en œuvre faible et des difficultés opérationnelles. Cela ne supprimait pas les mécanismes précis comme la résolution inverse d'adresse ; cela confirmait seulement qu'une base DNS ne se parcourait pas comme un catalogue arbitraire.

Deux étapes et deux preuves

RFC 3467 esquissait donc une séparation. Une couche de recherche ou d'annuaire recevrait la formulation humaine, pourrait utiliser langue, pays et autres attributs, puis rendrait un ensemble de noms candidats. Après sélection par l'utilisateur ou son agent, le DNS résoudrait le nom exact retenu.

Chaque étape produirait une preuve différente. Le résultat d'annuaire atteste qu'un candidat a correspondu à une requête selon un index, des règles et un instant. La réponse DNS atteste qu'un contexte de résolution a obtenu des enregistrements pour une clé exacte. Un bon classement ne prouve pas l'identité du sujet ; une réponse DNS valide ne prouve pas que le premier choix était juste ; une connexion réussie ne prouve ni l'autorisation ni l'intention.

L'annuaire introduisait aussi son propre pouvoir. Son index pouvait vieillir, son classement refléter des intérêts commerciaux, et ses règles locales produire des résultats différents. Le mémo exigeait une protection contre les modifications non autorisées et reconnaissait que chaque couche supplémentaire offrait une nouvelle possibilité de compromission. La séparation clarifiait les responsabilités, elle ne supprimait pas le risque.

La frontière reste la contribution durable

RFC 3467 n'a ni standardisé cet annuaire, ni démontré sa migration, ni déclaré que toute extension du DNS était fautive. Sa contribution consistait à refuser une question unique pour deux besoins. L'Internet commun a besoin d'identifiants stables et exactement résolus. Les humains ont besoin d'outils tolérants pour les découvrir.

L'audit doit donc conserver la requête initiale, son contexte, la liste des candidats, le choix effectué, le nom DNS exact, le contexte du résolveur, la réponse, le point d'accès contacté et l'effet observé. Une réponse exacte prouve qu'une clé a été résolue. Elle ne prouve pas que cette clé exprimait ce que la personne voulait dire.

Sources