Résumé

  • NSID associe un identifiant d'instance à la réponse DNS examinée. Une question d'identité posée après coup à la même adresse pourrait atteindre un autre serveur.
  • L'identifiant est une suite d'octets dont le sens relève de l'exploitant. Sa copie exacte compte davantage qu'une présentation immédiatement compréhensible.
  • Chaque échange DNS garde son propre périmètre : le résolveur récursif se désigne lui-même, sans livrer une chaîne certifiée des serveurs consultés en amont.

Le zéro qu'une interface ne doit pas effacer

Un identifiant peut commencer par un octet nul. Il peut en contenir plusieurs. Un logiciel qui le traite comme une chaîne de caractères terminée par zéro risque alors de transmettre un fragment au lieu de la valeur entière. Le texte obtenu semblera peut-être plus propre ; l'indice sera moins fidèle.

Cette question de copie occupe une place importante dans RFC 5001, la spécification NSID publiée par R. Austein en août 2007. La représentation demandée est hexadécimale, avec deux chiffres par octet. Les comparaisons portent sur les données binaires. La copie ne doit pas supposer une terminaison par zéro.

Une telle précision pourrait paraître disproportionnée pour un mécanisme censé simplement dire quel serveur a répondu. Elle révèle au contraire le projet : l'usager n'a pas à connaître la nomenclature de l'exploitant. Il doit pouvoir lui faire parvenir, sans perte, la référence que celui-ci sait interpréter. L'interopérabilité porte sur la transmission de l'indice, non sur une signification universelle.

Une adresse ne suffit plus à désigner un interlocuteur

Le problème devient visible lorsqu'une adresse dessert plusieurs instances. L'anycast permet à des nœuds distincts d'annoncer une même adresse de service. Le routage choisit où la requête arrive. Ce choix n'est pas nécessairement celui de la distance géographique minimale ; il ne signifie pas non plus que chaque paquet change systématiquement de destinataire.

Dans RFC 4786, publié en décembre 2006, J. Abley et K. Lindqvist exposaient les conséquences opérationnelles de cette organisation. Le service restait accessible par une adresse stable, mais le diagnostic devait ajouter une variable : le nœud effectivement rencontré. Un traceroute pouvait renseigner, sans garantir que les conditions observées étaient celles de la requête initiale.

Le document préconisait donc une identification à l'intérieur du protocole de service, ainsi que des observations distribuées associant identité du nœud, disponibilité et performances. Il évoquait les travaux NSID alors en cours. Il serait anachronique d'y voir la référence à un RFC 5001 déjà publié : la recommandation opérationnelle précédait sa version définitive.

Une réponse exacte à une question trop tardive

Les administrateurs disposaient déjà de conventions DNS. Une requête TXT de classe CHAOS visant HOSTNAME.BIND. pouvait obtenir un identifiant configurable. ID.SERVER. évitait la référence à une implémentation particulière. VERSION.BIND. concernait quant à lui la version du logiciel, ce qui n'est pas la même question.

Ces conventions avaient des qualités : simplicité, utilisation de DNS et contrôle local de la divulgation. Leur faiblesse n'était pas de donner nécessairement un faux nom. Elles demandaient un échange supplémentaire. Si cet échange atteignait une autre instance, son résultat pouvait être vrai tout en étant sans rapport avec la réponse que l'on voulait expliquer.

Les exigences de RFC 4892, de juin 2007, décrivent précisément ce risque. Deux questions adressées au même point de service peuvent aboutir sur des serveurs différents, par routage anycast ou répartition de charge. Un diagnostic utilisant un autre protocole ne rend pas la corrélation plus certaine.

Il fallait donc pouvoir demander l'identité dans une requête opérationnelle ordinaire, sans classe ni espace de noms séparés. Il fallait aussi laisser l'administrateur activer, désactiver ou restreindre la réponse, et éviter de l'obliger à révéler un nom de maintenance ou une adresse unicast privée. Le besoin portait sur une association utile, pas sur l'inventaire public de toute une infrastructure.

Demander sans choisir la réponse

NSID utilise l'extension EDNS. Le client place une option NSID vide dans le pseudo-enregistrement OPT de sa requête. Le serveur qui la prend en charge et accepte de répondre joint son identifiant à l'OPT de cette même réponse.

Le vide est une règle, non un oubli. Le demandeur ne doit pas fournir de contenu NSID ; le serveur doit ignorer tout contenu qu'il recevrait malgré cette interdiction. Ce n'est donc ni un défi à recopier, ni une consigne pour choisir une instance précise, ni un nom proposé par le client à son interlocuteur.

La réponse est facultative. À l'inverse, un serveur ne doit pas envoyer NSID si le client ne l'a pas demandé. Une réponse DNS dépourvue de cet indice ne démontre donc ni une panne, ni l'absence d'anycast, ni l'existence d'une instance unique. Prise en charge, activation, demande et retour effectif doivent rester quatre constats séparés.

Le registre des paramètres DNS de l'IANA réserve le code d'option EDNS 3 à NSID. Il ne distribue pas les identifiants des machines. Cette distinction est décisive : on normalise un emplacement commun, pas le contenu du répertoire interne de chaque exploitant.

Le résolveur ne parle pas au nom de toute la récursion

Lorsqu'un poste demande NSID à un résolveur récursif, il demande l'identité de ce résolveur. Celui-ci peut, de son côté, demander un identifiant aux serveurs faisant autorité qu'il interroge. Les deux opérations restent indépendantes. L'identifiant reçu en amont n'est pas transféré comme réponse à la demande d'identité du poste.

NSID est expressément non transitif. Le terme « saut » désigne ici les deux extrémités d'un échange DNS, non les routeurs IP traversés. Il n'existe pas de carnet de voyage dans lequel chaque participant à la résolution ajouterait sa signature.

La clarification ultérieure d'EDNS dans RFC 6891, en avril 2013, aide à comprendre cette limite. OPT contient des informations de contrôle propres à une transaction, et non des données de zone. Il ne doit pas être mis en cache, transmis comme tel ou conservé dans un fichier maître.

On peut en déduire qu'un résolveur répondant à partir de son cache peut fournir son propre NSID pour l'échange présent. Cette valeur ne désigne pas le serveur faisant autorité qui avait alimenté le cache auparavant. Confondre les deux transformerait une observation actuelle en preuve historique qu'elle n'a jamais été conçue pour apporter.

L'opacité laisse des choix, pas une absence de coûts

L'exploitant peut choisir un nom, une adresse, une valeur aléatoire, un code évolutif ou d'autres octets. Aucun de ces formats n'est imposé. Cette liberté permet de fournir une référence exploitable sans exposer une topologie complète, mais ne résout pas automatiquement la confidentialité.

Le hachage d'une adresse IPv4 conserve un espace d'entrée de 32 bits. Le hachage d'un nom prévisible peut aussi permettre des essais. À l'autre extrême, un identifiant aléatoire persistant exige une correspondance interne fiable. Si tous les nœuds héritent du même identifiant dans leur configuration, ils deviennent indiscernables malgré des réponses parfaitement conformes.

Une valeur qui change ne prouve pas à elle seule que le routage ou le matériel a changé. Une valeur stable ne constitue pas davantage un numéro de série mondial. L'interprétation dépend de la politique locale d'attribution, de rotation et de conservation. Le protocole fournit le moyen de transporter la référence ; il ne vérifie pas la qualité de cette politique.

La même retenue s'impose en matière de sécurité. RFC 5001 évoque des contenus signés ou chiffrés, sans en faire une recette complète. Un bloc statique peut être rejoué. Le texte situe NSID parmi les informations de canal, hors de la protection DNSSEC en tant que telle, et évoque une protection du canal telle que TSIG lorsqu'une garantie d'intégrité est nécessaire. Une réponse DNSSEC valide ne rend donc pas automatiquement authentique l'identifiant adjacent.

Ce que montre une implémentation, et ce qu'elle ne montre pas

La référence de configuration BIND consultée, identifiée comme version 9.20.27, distingue deux réglages. server-id choisit ce que le serveur révèle via NSID ou ID.SERVER ; sa valeur par défaut est none, avec notamment une possibilité d'utiliser le nom d'hôte. request-nsid, désactivé par défaut, demande des identifiants dans les requêtes itératives et permet d'en journaliser le retour.

Il ne s'agit pas d'un bouton qui rendrait toute la chaîne récursive identifiable. Révéler son propre indice et en recueillir chez autrui sont deux décisions. Les pages de manuel BIND décrivent aussi dig +nsid : l'outil ajoute la demande, sans contraindre le serveur ni certifier la valeur reçue.

Ces documents attestent une possibilité d'utilisation. Ils ne mesurent ni son activation dans une installation donnée, ni sa diffusion mondiale. Même la présence d'un code dans le registre ne dispense pas d'observer les réponses réelles.

Enfin, les octets ajoutés occupent de la place. NSID peut rapprocher une réponse des limites de troncature, mais ne modifie pas les règles DNS correspondantes et n'impose pas de tronquer uniquement pour inclure cet élément facultatif. Le diagnostic complète le service ; il n'en remplace pas la finalité.

L'apport de NSID tient ainsi à une discipline discrète : conserver ensemble la réponse et l'indice qui permet de la situer. Il vaut mieux un code incompréhensible mais exact, attaché au bon échange, qu'un nom très lisible obtenu auprès du mauvais interlocuteur.