Résumé

  • La RFC 8552, publiée en mars 2019 comme meilleure pratique actuelle, a décrit les branches DNS commençant par un trait de soulignement. Elles limitent le sens d’enregistrements placés sous un domaine parent ; l’étiquette soulignée la plus proche de la racine a une portée mondiale.
  • Le registre IANA protège le couple « type d’enregistrement, étiquette globale ». L’examen par un expert vérifie l’unicité du couple et la précision de sa description. Les étiquettes inférieures relèvent de la spécification propre à cette branche.
  • La RFC 8553 a mis les anciens textes, notamment les modèles SRV et URI, en accord avec ce registre tout en préservant logiciels et pratiques déjà en service. L’inscription coordonne les noms ; la zone faisant autorité et la requête du client montrent le service réellement utilisé.

Les octets TXT avaient trop de métiers

Le DNS n’attribue pas une signification obligatoire à chaque morceau d’un nom et n’impose pas un seul emplacement par type d’enregistrement. Cette liberté a permis de publier de nouveaux usages sans réclamer chaque fois un nouveau code de type. Elle a également rempli certains emplacements de données sans rapport les unes avec les autres. Un client demandant TXT au nom parent pouvait recevoir un amas dont il lui restait à démêler l’usage.

La RFC 8552 décrit la solution par l’adresse plutôt que par le format des octets. Un protocole place ses enregistrements sous une branche telle que _nom.exemple.org, située sous le domaine auquel les données s’appliquent. La requête vise cette branche et reçoit l’ensemble destiné à ce protocole. Le type d’enregistrement reste TXT, SRV ou URI ; sa position lui donne un sens plus étroit.

Le signe au début de l’étiquette sert aussi de frontière visible. Selon les règles de nommage des hôtes invoquées par la RFC, une étiquette précédée de ce signe ne ressemble pas à un nom d’hôte ordinaire. Le protocole dispose ainsi d’une étagère d’attributs sous le domaine, sans faire passer l’attribut pour une machine supplémentaire. Le changement relève de la convention de nommage à l’intérieur du DNS, pas d’un nouveau paquet DNS.

Une première utilisation célèbre existait déjà. En février 2000, la RFC 2782 a défini des recherches SRV sous la forme _Service._Proto.Name, avec des préfixes destinés à éviter les collisions avec les étiquettes d’hôtes. La découverte de services fondée sur DNS a ensuite repris cette convention. Leurs textes expliquent comment chercher un service. La question de 2019 était plus large : qui empêche plusieurs protocoles indépendants de réserver le même emplacement global pour des significations concurrentes ?

Le premier tiroir commun

Une branche peut contenir plusieurs étiquettes soulignées. Celle qui se trouve le plus près de la racine DNS est dite globale ; les autres sont définies dans son périmètre. C’est ce premier tiroir que plusieurs concepteurs peuvent vouloir occuper. Un protocole garde la liberté de régler ses propres sous-tiroirs, mais il doit éviter qu’un autre usage emploie la même entrée globale avec le même type d’enregistrement.

La RFC 8552 a donc institué le registre IANA des noms de nœuds DNS soulignés à portée mondiale. Trois colonnes suffisent : type RR, nom du nœud, référence. L’unicité porte sur le couple type et nom global. Deux services peuvent partager un type RR à condition d’utiliser des noms globaux différents. Le même nom peut aussi être associé à des types RR différents. Ce n’est ni une interdiction générale du trait de soulignement ni un inventaire de toutes les feuilles d’un protocole.

La procédure est un examen par expert. Celui-ci vérifie que la demande est claire et que le couple n’est pas déjà pris. Le texte écarte du périmètre de cet examen un jugement général sur la valeur technique de la spécification candidate. Une case libre garantit seulement l’absence de collision dans ce registre. Elle ne garantit ni qu’un opérateur ait publié des enregistrements, ni qu’un client sache les interpréter.

La liste actuelle de l’IANA renvoie aux textes qui définissent les emplacements globaux. Pour connaître les étiquettes situées plus bas, il faut lire le protocole cité. Pour savoir si un domaine utilise effectivement le protocole, il faut interroger sa zone faisant autorité. Le tableau, le document et la zone répondent à trois questions distinctes. Les confondre fabrique des diagnostics élégants et faux.

Le registre est arrivé après les locataires

La convention avait déjà vécu avant d’obtenir son registre. Plusieurs RFC avaient introduit des noms soulignés chacune de leur côté. Publiée en même temps que la RFC 8552, la RFC 8553 a réparé cette bibliographie dispersée. Elle a signalé dans les anciens textes le nouveau guichet intégré et adapté les modèles qui servaient à créer les noms globaux des enregistrements SRV et URI.

Le correctif n’a pas exigé de renommer les zones en service. La RFC 8553 dit expressément préserver les logiciels et les pratiques d’exploitation existants. La règle nouvelle organise les attributions futures et indique aux lecteurs d’anciens textes où vérifier une attribution. Elle ne transforme pas magiquement les réponses DNS du jour de sa publication.

Cette chronologie sépare notre sujet de l’histoire des SRV. La RFC 2782 répond à la question « où se trouve le service ? ». Les deux documents de 2019 répondent à « qui peut donner un sens global à cette branche avec ce type RR ? ». Un client peut choisir le bon serveur à partir d’un enregistrement SRV ; encore faut-il que les concepteurs n’aient pas attribué l’emplacement de départ à deux règles incompatibles.

Le registre s’arrête à la frontière nécessaire. Il ne dicte pas chaque nom situé sous l’étiquette globale. Il ne remplace pas le type RR et ne valide pas le contenu qu’un opérateur place dans sa zone. Il coordonne la case partagée ; la spécification du protocole régit ce qu’on peut ranger plus bas. C’est une intervention étroite, et c’est précisément ce qui la rend vérifiable.

Les sources officielles établissent la convention et la nouvelle autorité d’attribution. Pour affirmer qu’un service nommé l’a employée, il manque une capture datée de sa zone faisant autorité et une requête de client sur le nom et le type attendus. Le registre fournit l’adresse de la règle ; les paquets montrent son application.