Résumé

  • Publiée en février 2013, la RFC 6761 a créé le registre des noms de domaine à usage spécial de l’IANA. Pour chaque nouvelle réservation, le texte impose sept réponses distinctes, de l’usager au bureau d’enregistrement.
  • Les premiers noms recensés provenaient des anciennes réservations et des zones de recherche inverse des adresses privées. La conduite attendue varie : localhost renvoie à la boucle locale, invalid reçoit une réponse négative, et les zones privées peuvent trouver leur réponse à l’intérieur d’un réseau.
  • En 2017, la RFC 8244 a décrit le défaut de coordination entre IETF et ICANN et le flou de l’« usage technique ». Une désignation officielle ne prouve pas ce que fait un résolveur installé.

Un tampon ne répond à aucune requête

Supposons qu’un développeur saisisse un nom dans un programme d’essai. Le programme peut le transmettre à une bibliothèque, qui interroge un résolveur récursif, lequel peut chercher un serveur faisant autorité. Pendant ce temps, un bureau d’enregistrement décide si le nom peut être vendu. Chaque acteur voit la même chaîne de caractères. Chacun dispose d’un autre levier. Écrire « usage spécial » dans un registre ne transforme pas ces leviers en mécanisme unique.

La RFC 2606 avait réservé en 1999 des noms destinés aux essais, aux exemples, à l’échec attendu et à l’hôte local. Elle protégeait les utilisateurs contre la collision entre un nom inventé et un domaine vivant. La RFC 6761, en février 2013, a repris le dossier au niveau des machines : quel composant reconnaît le nom, quelle réponse produit-il et doit-il interroger l’extérieur ? Il ne s’agissait plus seulement de soustraire une chaîne à la vente.

Le nouveau registre de l’IANA a commencé avec les noms déjà réservés et les zones de recherche inverse liées aux adresses privées. Chaque inscription pointe vers un texte de référence. Cette architecture ressemble à un index de décisions plutôt qu’à une commande envoyée aux serveurs. Le résolveur du lecteur n’ouvre pas le registre à chaque requête pour y chercher un ordre.

Sept questions à sept endroits

Une nouvelle désignation doit être portée par un document adopté suivant la procédure « Standards Action » de l’IETF ou approuvé par l’IESG. La RFC 6761 lui demande d’identifier précisément les noms concernés et de répondre à sept catégories. L’usager doit-il reconnaître ce nom ? Le logiciel d’application doit-il le traiter autrement ? La bibliothèque de résolution doit-elle réagir ? Le serveur DNS cache ? Le serveur faisant autorité ? L’exploitant DNS ? Enfin, le registre ou le bureau d’enregistrement doit-il refuser une demande ?

Le formulaire a de l’esprit : il oblige le demandeur à chercher les coûts là où ils tombent. Pour une zone privée de recherche inverse telle que 10.in-addr.arpa, l’application et l’API de résolution doivent continuer à envoyer la requête normalement au serveur cache configuré. Celui-ci, par défaut, doit éviter de remonter la question aux serveurs publics et répondre localement. Il peut aussi offrir un réglage pour un réseau privé qui possède un serveur faisant autorité. Voir une requête sortir de l’application est donc conforme au chemin prévu ; il faut suivre le paquet jusqu’au bon poste.

Pour localhost, les requêtes d’adresse doivent être traitées localement et retourner l’adresse de boucle. Pour invalid, la réponse négative doit arriver sans promenade inutile dans le DNS public. La même étiquette « réservé » couvre donc des réponses et des lieux de décision différents. Un test sur un seul résolveur public ne peut pas raconter la vie de tous les noms du registre. Il faut nommer le suffixe, le type de requête et le composant observé.

La liste de l’IANA comprend aujourd’hui localhost, invalid, local, onion, home.arpa et des zones inverses privées, chacun accompagné de sa référence. La diversité est le point important. Certains noms conservent un traitement DNS avec une règle dans le résolveur récursif ; d’autres exigent une résolution locale ou un contexte applicatif particulier. La RFC 6761 n’a jamais réduit la catégorie aux domaines de premier niveau, ni ordonné une sortie uniforme du DNS.

Quand le nom quitte son contexte

Le dossier prend une autre dimension lorsqu’un nom local voyage. Une personne copie un nom interne dans un message. Le destinataire le saisit sur un autre réseau. Les octets sont intacts, mais l’environnement qui donnait un sens au nom a changé. Le résultat peut pointer ailleurs ou ne pointer nulle part. La RFC 8244 utilisait ce genre de rupture pour montrer qu’une réservation engageait les logiciels et les pratiques, pas seulement une case administrative.

Quatre ans après la création du registre, ce texte de 2017 a dressé un état des problèmes. Il relevait une relation de liaison entre IETF et ICANN sans procédure formelle de coordination pour ces attributions. Il relevait aussi l’absence de définition commune de l’« usage technique ». Les deux organisations occupaient des places dans la gestion de l’espace de noms, mais aucune ne pouvait empêcher un tiers d’utiliser une chaîne sans demander la permission.

Le mémoire mentionnait encore des usages informels devenus visibles après coup : un nom employé en interne fuit vers l’extérieur ; un nom local finit par rencontrer une attribution officielle ; un concepteur ignore la procédure ou prévoit un refus. Cette liste ne chiffre aucun déploiement. Elle explique pourquoi le dossier bien rangé du registre pouvait rencontrer une réalité déjà en circulation. Avant de juger un produit précis, il manque sa configuration datée et la trace de requêtes envoyées pour le nom concerné.

Voilà la contradiction savoureuse de cette histoire : l’administration pouvait déclarer un nom spécial avec une grande précision, tandis que les machines chargées de lui donner ce caractère étaient réparties entre plusieurs propriétaires. Les sept questions de 2013 visaient à faire apparaître cette répartition avant l’inscription. L’inventaire de 2017 montrait que la porte d’entrée institutionnelle, elle aussi, devait être examinée.