Résumé

  • Un NSID prouve qu’un répondant DNS a joint certains octets à une réponse donnée ; il ne prouve ni le nom d’hôte, ni la machine physique, ni le site, ni la version logicielle, ni la permanence de cette identité.
  • Pour devenir exploitable, cette observation doit être reliée à quatre reçus : la transaction originale, le point d’observation et l’heure, la table de correspondance de l’opérateur, puis le périmètre exact de l’action autorisée.

Quand l’adresse ne désigne plus un serveur

Une adresse IP reste une excellente destination de service. Elle n’est plus nécessairement le nom opérationnel d’un équipement. Avec l’anycast, plusieurs nœuds annoncent la même adresse et le routage conduit chaque paquet vers l’un d’eux. Derrière un répartiteur, plusieurs processus ou machines peuvent également partager la même façade. Le RFC 4786 appelle « zone d’attraction » la région topologique qui atteint un nœud particulier ; cette zone dépend du point de départ et peut changer.

Le DNS révèle particulièrement bien cette ambiguïté. Ses échanges UDP tiennent souvent dans une requête et une réponse indépendantes. Une modification de route entre deux requêtes ne casse donc pas forcément une session visible : elle peut simplement faire répondre une autre instance. Le RFC 3258 avertit que deux questions adressées à la même adresse partagée ne sont pas garanties d’atteindre le même serveur. Un ping, un traceroute ou une connexion TCP séparée offrent encore moins de certitude sur le processus qui a traité la question DNS.

C’est le problème précis posé par Suzanne Woolf et David Conrad dans le RFC 4892, publié comme document d’information en 2007. Leur objectif n’était pas d’inventer une identité universelle des machines, mais d’aider un exploitant confronté à une réponse périmée, divergente ou lente au sein d’un ensemble distribué.

La différence se joue dans la formulation. « Le service atteint à cette adresse a fourni cette réponse » découle de l’échange observé. « Cette machine physique a fourni cette réponse » ajoute une affirmation de topologie. L’adresse ne suffit pas à franchir cet intervalle.

Le piège de la deuxième question

Les opérateurs de BIND disposaient déjà d’une convention commode. Une requête TXT de classe CHAOS vers HOSTNAME.BIND. pouvait renvoyer un nom configuré. ID.SERVER. supprimait la référence explicite à BIND tout en gardant la même logique. Le mécanisme a de vrais avantages : il reste dans le protocole DNS, passe normalement par les mêmes filtres et laisse à l’opérateur le choix de ce qu’il divulgue.

Mais l’étiquette arrive lors d’une seconde transaction. Entre la réponse suspecte et la question d’identification, le routage anycast peut basculer, le répartiteur choisir un autre backend ou l’instance défaillante se retirer. L’enquêteur obtient alors deux éléments authentiquement observés, mais qui concernent deux répondants différents.

L’erreur résiste aux vérifications superficielles. L’adresse de service est la même. Le second serveur a bien produit l’étiquette. La route paraît plausible. Pourtant, rien ne relie cette étiquette à la première réponse. L’adresse commune, justement, est le point que l’architecture distribuée a rendu non unique.

Le RFC 4892 exige donc que l’identification puisse voyager avec la réponse opérationnelle elle-même. Une question dédiée reste possible, mais elle ne remplace pas cette association. Joindre la preuve à l’événement observé est une contrainte de causalité, pas un confort d’interface.

Les exigences de Woolf et Conrad

Le document ne se contente pas de normaliser l’orthographe d’un nom CHAOS. Il transforme les défauts de la pratique en critères de conception.

Le mécanisme devait appartenir au DNS, être indépendant d’une implémentation et pouvoir accompagner une question normale. Il devait être simple à activer comme à désactiver et se prêter à des contrôles d’accès. Il ne devait pas obliger un opérateur à publier un nom de maintenance ou une adresse unicast privée pour distinguer deux instances. Enfin, une solution devait pouvoir accueillir une authentification sans prétendre qu’une chaîne lisible était déjà authentique.

Ce dernier point sépare la donnée signée dans le DNS de la signalisation de canal. DNSSEC protège des ensembles de ressources et leur chaîne de validation ; il ne transforme pas automatiquement un attribut ajouté par le répondant en identité certifiée. Le RFC 4892 reconnaît ce manque et demande que la conception puisse y répondre, tout en laissant la confidentialité à la main de l’opérateur.

Le RFC 4892 ne demande aucune allocation IANA. Il fixe un cahier des charges. Le RFC 5001, publié ensuite et rédigé par Rob Austein, définit l’option NSID. Suzanne Woolf y est remerciée, mais elle n’en est pas l’autrice. Cette précision n’est pas accessoire : le sujet entier consiste à ne pas étendre une provenance au-delà de ce qu’elle établit.

Ce que NSID établit vraiment

Le résolveur ajoute une option NSID vide dans une requête EDNS. Un serveur qui comprend la demande et décide d’y répondre place son identifiant dans la réponse. Les octets appartiennent alors à la transaction étudiée. C’est un gain décisif sur ID.SERVER., car il supprime l’intervalle où une autre instance aurait pu être choisie.

Le protocole s’arrête toutefois à ce lien. Le contenu NSID est une suite d’octets opaque dont la syntaxe et la sémantique relèvent de l’implémentation et de l’opérateur. Il peut s’agir d’un nom réel, d’une adresse, d’un nombre aléatoire conservé, d’une valeur renouvelée, d’un bloc chiffré ou de n’importe quels octets. L’affichage hexadécimal imposé par le RFC 5001 vise à préserver exactement les données, non à leur donner un sens universel.

Une valeur peut donc désigner une machine, mais aussi un processus, un conteneur, un groupe derrière un répartiteur, un site ou un nœud anycast. Elle peut survivre à un redémarrage ou être recréée. Deux unités peuvent accidentellement partager la même valeur. Une même unité peut en changer. Ce sont des propriétés de gestion, pas des propriétés déduites du paquet.

NSID n’est pas transitif. Si un client interroge un résolveur récursif, l’identifiant éventuellement renvoyé concerne ce résolveur. Il ne révèle pas automatiquement le serveur faisant autorité consulté en amont. Le résolveur peut mener sa propre requête NSID, mais ce sera un autre saut et un autre reçu. EDNS étant lui-même de portée saut par saut, cette frontière est architecturale.

Enfin, le canal n’est pas automatiquement authentifié. Le RFC 5001 renvoie les besoins d’intégrité vers une protection de canal telle que TSIG. Une valeur signée ou chiffrée statique peut encore être rejouée. Elle ne prouve pas davantage la fraîcheur, le lieu physique ou la responsabilité administrative.

Quatre reçus plutôt qu’un grand nom

Le premier reçu associe la réponse à l’étiquette. Il conserve la question, la réponse et les octets NSID bruts. Si l’option n’était pas demandée, le rapport doit laisser l’instance indéterminée au lieu de lui attribuer après coup la réponse d’une seconde question.

Le deuxième reçu fixe le point d’observation : source de la mesure, adresse de service visée, transport et horodatage. Deux points de mesure peuvent atteindre deux zones d’attraction différentes sans que l’un des résultats soit faux.

Le troisième reçu appartient à l’opérateur. Une table versionnée relie le jeton opaque à l’unité voulue et indique ses dates d’effet. Sans cette chronologie, la réutilisation d’un identifiant après reconstruction crée une continuité fictive. Sans la table, le jeton reste utile pour regrouper des réponses, mais pas pour nommer un actif.

Le quatrième reçu limite l’action. Le mapping doit dire s’il vise un processus, un hôte, un pool, un site ou un nœud anycast. Cette granularité détermine ce qui peut être inspecté, drainé, redémarré ou isolé. Un identifiant de processus ne justifie pas à lui seul le retrait de la route d’un site complet.

Cette chaîne ne diminue pas NSID. Elle lui rend sa vraie valeur : détecter un répondant atypique, rapprocher des journaux et orienter l’enquête sans transformer une étiquette contrôlée par l’opérateur en passeport de machine.

Sources