Résumé

  • RFC 1464 proposait d’inscrire des couples nom=valeur dans des enregistrements TXT, solution lisible par des serveurs existants mais dépourvue de registre universel des noms d’attribut.
  • La réponse DNS ne démontrait donc que la présence de données sous un nom et à un instant donnés ; profil applicatif, autorité, cache, validation DNSSEC, décision et résultat restaient des preuves distinctes.

Le DNS savait déjà répondre. L’expérience consistait à lui demander de transporter une phrase qu’il n’avait pas besoin de comprendre.

RFC 1464, publié en mai 1993 avec le statut Experimental, partait d’une contrainte de diffusion. Les adresses d’hôte et les échangeurs de courrier possédaient des types et des structures reconnus. Une application désireuse de publier une information nouvelle pouvait demander un nouveau type de ressource, puis attendre que serveurs, bibliothèques et outils l’adoptent. Elle pouvait aussi employer TXT, déjà disponible, et placer la structure à l’intérieur du texte.

Le compromis était ingénieux. Le serveur conservait son rôle de transport typé au niveau TXT. Le consommateur recevait une convention supplémentaire : le premier signe égal non protégé séparait un nom d’attribut de sa valeur. Aucune mise à jour de la plupart des serveurs DNS n’était nécessaire. Mais l’absence de changement du serveur ne signifiait pas l’absence de nouvelle règle. La règle avait simplement migré dans la bibliothèque et l’application.

Le parseur créait l’attribut

Dans la représentation externe proposée, le propriétaire, la classe, le TTL et le type TXT précédaient une chaîne telle que printer=lpr5. Tous les caractères ASCII imprimables étaient admis dans le nom. Un accent grave protégeait un signe égal ou un autre accent grave lorsqu’il appartenait au nom. La comparaison ne tenait pas compte de la casse ; les espaces et tabulations placés aux extrémités du nom disparaissaient, sauf s’ils étaient eux-mêmes protégés.

La valeur obéissait à un régime plus simple. Tout ce qui suivait le premier signe égal non protégé en faisait partie, y compris d’autres signes égal et tous les espaces. L’application décidait si ces espaces étaient significatifs. L’erratum vérifié 5193 a corrigé un exemple qui doublait à tort l’accent grave dans une valeur : ce mécanisme de protection concernait le nom, pas le texte déjà situé après le séparateur. L’erratum 5194, conservé pour mise à jour du document, répare seulement l’alignement d’une ligne du tableau.

Un logiciel conforme pouvait ignorer une chaîne sans signe égal non protégé, ainsi qu’une chaîne commençant directement par =. RFC 1464 recommandait une routine spécialisée, analogue à gethostbyname, qui retirerait les protections du nom et pourrait retourner plusieurs valeurs ou plusieurs attributs.

Autrement dit, l’attribut n’existait pas seulement parce que les octets étaient présents. Il apparaissait après une décision de parsing. Un résolveur ordinaire pouvait restituer le TXT brut. Une bibliothèque RFC 1464 pouvait y voir un attribut. Un programme suivant une autre convention pouvait y voir autre chose. Le même RRset portait plusieurs possibilités d’interprétation, et le DNS ne choisissait pas entre elles.

Le nom n’avait pas d’autorité générale

Le document voyait le risque. Il envisageait un processus d’enregistrement des noms d’attribut connus afin de limiter les collisions : une liste mise à jour ou un mécanisme externe, par exemple des identifiants d’objet publiés. Il ne créait pourtant aucun registre.

Cette retenue avait deux effets opposés. Elle autorisait l’expérimentation locale sans guichet central. Elle empêchait aussi le texte de color=blue de devenir une proposition universelle. Le parseur savait isoler color et blue; il ignorait l’objet décrit, le vocabulaire permis, la version du schéma et l’autorité compétente pour déclarer cette couleur.

Le propriétaire d’une zone exerce un contrôle technique sur la publication. Ce contrôle ne lui confère pas automatiquement chaque pouvoir social ou commercial que le mot semble revendiquer. Une zone d’entreprise peut publier un contact, mais le droit de modifier le DNS n’est pas nécessairement un mandat pour conclure un contrat. Un domaine peut publier un état de service, sans que le serveur DNS observe la machine physique. Le chemin de délégation nomme une source opérationnelle ; il ne transforme pas la chaîne en fait incontestable.

Une seule requête ramenait les voisins

Selon RFC 1035, TXT contient une ou plusieurs chaînes de caractères, dont la sémantique dépend du domaine où elles se trouvent. La requête DNS sélectionne un nom de propriétaire, une classe et un type. Elle ne demande pas « l’attribut printer selon RFC 1464 ». Elle demande le RRset TXT, puis un logiciel inspecte son contenu.

Cette différence est au cœur de l’analyse publiée plus tard dans RFC 5507. Tout sous-typage interne oblige le client à récupérer l’ensemble du RRset avant de sélectionner les éléments pertinents. Une signature DNSSEC couvre cet ensemble ; la modification d’un usage peut donc affecter la signature du conteneur partagé. TXT ne possédait même pas de champ de sélection normalisé. RFC 5507 juge expressément que la tentative de RFC 1464 n’a pas réussi.

Ce constat architectural ne permet pas d’affirmer qu’aucun code n’a jamais suivi la proposition. Il explique pourquoi un séparateur interne ne suffisait pas à organiser durablement un espace commun. Deux applications pouvaient employer le même nom pour des concepts différents, appliquer des règles incompatibles aux doublons ou supposer que les autres chaînes TXT n’existaient pas. Les limites de taille ou de nombre imposées par certains serveurs, déjà signalées par RFC 1464, transformaient aussi la coexistence en concurrence pour un même RRset.

Le TTL rendait la vérité temporelle

Un attribut placé dans DNS héritait de son système de cache. La zone faisait autorité pour une version donnée. Le serveur autoritatif la servait. Un résolveur récursif l’observait et pouvait la conserver pendant le TTL. L’application interrogeait ce résolveur à un autre instant, puis gardait parfois sa propre copie.

Dire « le DNS indiquait mode=off » ne précise donc pas la date de l’observation, le TTL restant, la source de récursion, le RRset complet ni le moment où une décision a été exécutée. Une intention nouvelle peut être correcte dans la zone et absente d’un cache encore valide. Une valeur ancienne peut avoir été exactement reçue et être déjà inadaptée à une action urgente.

Il faut conserver les horloges au lieu de les aplatir. Le reçu DNS prouve ce qui a été remis par un chemin de résolution à un instant. Il ne prouve pas que le monde n’a pas changé avant l’action.

DNSSEC ne certifie pas la phrase

RFC 1464 ne discutait pas la sécurité. Les extensions DNSSEC ont ensuite apporté l’authentification d’origine et la protection d’intégrité des données DNS sous une chaîne de confiance. RFC 4033 précise qu’elles n’apportent pas de confidentialité.

Une validation réussie répond à une question importante : le RRset est-il cohérent avec le chemin DNS authentifié et intact selon les ancres acceptées ? Elle ne définit pas le mot situé avant le signe égal. Elle ne vérifie pas la machine, la personne ou l’état juridique évoqué par la valeur. Elle ne décide pas si l’administrateur de zone était autorisé à prendre cette décision pour l’application.

Il est donc possible de recevoir un RRset authentifié, de le parser correctement et de refuser néanmoins son effet. La politique locale peut exiger une autre preuve, une fenêtre de fraîcheur plus courte ou une confirmation dans le protocole cible. À l’inverse, une organisation peut accepter un résultat non validé dans un contexte limité, à condition de ne pas le présenter ensuite comme une attestation DNSSEC.

Le contexte est devenu une partie du protocole

Les usages ultérieurs de TXT n’ont pas fait disparaître la convention clé-valeur. Ils l’ont enfermée dans des contextes plus précis.

RFC 6763 définit, pour DNS-Based Service Discovery, un profil où chaque paire occupe sa propre chaîne constituante. Les clés sont définies par type de service, les clés inconnues sont ignorées et les doublons suivent la première occurrence. Le nom d’hôte et le port appartiennent à SRV, non à une duplication TXT. Lorsque le protocole applicatif sait négocier ses capacités, le TXT doit surtout faciliter la découverte plutôt que remplacer ce dialogue.

Cette grammaire ressemble à RFC 1464, mais elle n’en fait pas une interprétation globale. Le type de service fournit précisément la portée qui manquait à l’expérience générique.

RFC 6950 décrit le passé mouvementé des usages applicatifs de TXT et la difficulté de distinguer leurs enregistrements. La spécialisation des noms de propriétaire est devenue un outil de séparation. RFC 8552 a ensuite normalisé le modèle AttrLeaf : un nom commençant par un soulignement crée une branche réservée, et la combinaison du nom global souligné avec le type de RR est enregistrée auprès de l’IANA. Une requête directe récupère le RRset pertinent au lieu d’une masse indifférenciée.

Même ce registre ne donne pas tout le sens. RFC 8552 indique que l’emplacement ne définit pas les règles détaillées de son contenu ; la spécification de chaque application reste nécessaire. La coordination a changé de niveau : du mot libre à la branche enregistrée, puis de la branche au profil du consommateur.

La publication n’était pas le déploiement

Le statut Experimental de RFC 1464 est une limite documentaire. Le texte prouve qu’une convention a été proposée, avec une syntaxe et une interface de bibliothèque imaginée. Il ne fournit pas un recensement des implémentations, des zones ou des attributs réellement utilisés.

Le fonctionnement exigeait du code des deux côtés de la frontière sémantique : un producteur devait écrire une forme attendue ; un consommateur devait la rechercher, la parser et partager sa définition. Une recommandation ne rendait pas ces programmes compatibles. Le signe égal n’acquérait un effet qu’au moment où un système exécuté l’interprétait.

Voilà pourquoi RFC 1464 reste instructif même sans lui attribuer un succès qu’il ne revendique pas. Il montre qu’une couche commune peut demeurer minimale, mais que les décisions laissées au-dessus d’elle doivent être nommées. Sans ce travail, la souplesse se transforme en ambiguïté invisible.