Résumé

  • Publiée en août 2007, la RFC 5001 définit l’option DNS NSID. Une requête EDNS vide demande au serveur de joindre son identifiant à la réponse qu’il fournit, s’il choisit de le faire.
  • Plusieurs machines peuvent partager l’adresse d’un service anycast. Une nouvelle requête peut en atteindre une autre. L’identifiant placé dans la réponse contestée appartient à cet échange précis, au saut précis où il a été demandé.
  • Le document d’exploitation de L-Root publié en 2014 décrit des réponses NSID contenant le nom complet du nœud. Le registre IANA attribue le code EDNS 3 à cette option ; il ne fixe pas le contenu des octets retournés.

Le témoin suivant n’avait rien vu

L’adresse du serveur est identique sur deux captures. La première réponse est fausse, la seconde correcte. On pourrait conclure que le serveur s’est repris. Dans un service DNS distribué par anycast, l’adresse représente une porte commune. Des machines différentes peuvent se tenir derrière cette porte, avec des copies différentes des données, des états différents ou des pannes différentes. Le chemin réseau décide à laquelle parler. La même chaîne de chiffres sur les deux paquets ne constitue pas un journal de présence.

La recommandation d’exploitation de l’anycast de 2006 signale le besoin d’identifier le nœud lorsqu’un client rencontre un problème. Une interrogation spéciale envoyée après la réponse fautive peut obtenir un nom de machine. Elle risque aussi d’obtenir le nom d’une autre machine : entre les deux requêtes, la route ou l’équilibrage de charge a changé. Le diagnostic a alors un témoin très sûr de lui, mais absent au moment des faits.

La RFC 5001 a choisi de faire voyager l’identité avec la réponse examinée. Son motif est concret : plusieurs serveurs de noms partagent parfois une seule adresse IP, et les requêtes DNS ne conservent pas une session qui relierait les interrogations suivantes à la première machine. Le serveur qui répond peut insérer une information d’identité dans ce même message. La réponse et la déclaration du répondant se retrouvent dans une capture unique.

Un champ vide à l’aller, des octets au retour

Le résolveur place une option NSID vide dans le pseudo-enregistrement OPT d’EDNS. Il ne doit mettre aucune donnée d’identification dans sa demande. Le code d’option 3 figure dans le registre IANA. Un serveur qui comprend la demande et accepte d’y répondre joint des octets NSID à sa réponse. Il ignore les données qu’un client aurait malgré tout placées dans la requête. Il n’envoie jamais spontanément de NSID à un résolveur qui n’en a pas demandé.

Aucune forme de nom n’est imposée aux octets. La norme les traite comme une suite opaque. Le serveur peut indiquer son nom de machine, son adresse de maintenance, un identifiant stable aléatoire, un pseudonyme calculé, une valeur renouvelée, des données signées ou chiffrées. La question est standardisée ; la quantité d’information rendue publique reste une décision de l’exploitant. Un nom lisible facilite l’enquête d’un client. Un pseudonyme permet de distinguer deux nœuds sans publier l’inventaire interne. Une valeur qui change peut limiter les rapprochements que font des tiers.

Ce choix a des conséquences opérationnelles. Une adresse de maintenance révélée à chaque demande offre un plan des machines protégées derrière l’adresse commune. Un identifiant interne peut suffire à ouvrir un ticket précis, à condition que l’exploitant conserve la table qui le relie à son nœud. La section de sécurité de la RFC situe ce signalement de canal hors de la protection DNSSEC des données DNS. Pour trancher un différend sur l’authenticité de la déclaration, il faut une protection du canal ou des archives d’exploitation qui la corroborent.

L-Root a choisi le nom plutôt que le secret

Les responsables de L-Root ont décrit en janvier 2014 les mécanismes effectivement déployés pour reconnaître ses nœuds anycast. Dans leur installation, le NSID contenait le nom d’hôte complet du nœud ayant répondu. Le document montre une sortie de dig où des octets hexadécimaux correspondent à un nom tel que ytz01.l.root-servers.org. L’option opaque de la norme est devenue, dans ce service, une étiquette publique compréhensible.

Le même document présente aussi les requêtes HOSTNAME.BIND et ID.SERVER. Elles peuvent faire connaître le nœud qui répond à cette seconde interrogation. Si le routage change entre deux échanges, ce nœud n’est pas nécessairement celui qui a livré la réponse suspecte. NSID sur la requête suspecte évite ce divorce entre le problème et son auteur déclaré. Le client peut transmettre au service d’exploitation la réponse fautive et le nom observé dans un seul ensemble de preuves.

Ce récit établit ce que L-Root documentait en 2014. Il ne fournit pas un inventaire actuel de tous les serveurs racine. Pour attribuer une réponse réelle, on conserve la requête, le retour, les octets NSID, l’heure, le transport et la source. Le lien entre le nom retourné et une machine précise relève ensuite des archives de l’opérateur.

Le résolveur récursif parle en son propre nom

NSID fonctionne saut par saut. Une application qui interroge un résolveur récursif avec cette option demande l’identité de ce résolveur. Celui-ci peut poser une autre question NSID à un serveur faisant autorité ; cette deuxième demande appartient à une autre conversation DNS. Le nom que le résolveur renvoie à l’application n’est pas automatiquement celui du serveur qu’il a consulté en amont. La RFC interdit également d’ajouter NSID à une réponse adressée à un client qui ne l’a pas demandé.

Pour retrouver le serveur faisant autorité derrière une réponse récursive, il faut une capture ou un journal de l’échange amont. Le marqueur ne dresse aucune chaîne de tous les intermédiaires. Cette limite précise évite de transformer un nom local en faux certificat de parcours. Même au bon saut, l’octet fourni identifie la façon dont le répondant se présente ; les données de configuration et les journaux de service établissent pourquoi il a répondu différemment.

L’adresse commune a cessé d’être un alibi

La RFC 5001 ne modifie pas l’adresse que connaît le client. Elle ajoute un champ facultatif à la réponse produite par une machine donnée. IANA garde le numéro de l’option ; l’exploitant choisit ce qu’elle dit ; le résolveur choisit de la demander et de conserver le résultat avec la réponse. Voilà une répartition nette du travail de preuve.

Le serveur peut refuser la révélation. Les octets supplémentaires peuvent aussi contribuer à la troncature d’une réponse DNS. Une capture sans NSID prouve simplement qu’aucun identifiant n’a été retourné dans cet échange ; la machine reste à retrouver par d’autres traces. L’exploitant qui souhaite garder ses noms internes peut fournir un pseudonyme, ou accepter que le client ne dispose pas de cette clé de diagnostic.

L’année 2007 a offert une solution modeste à un problème aggravé par les services distribués : attacher un nom au message que l’on conteste. Une nouvelle question posée à l’adresse commune peut rencontrer un autre serveur, parfaitement innocent du premier résultat. Le paquet initial, lui, garde la déclaration de celui qui a parlé.