Summary

  • Publié en juin 1999 comme Best Current Practice, le RFC 2606 réservait .test, .example, .invalid et .localhost à des usages distincts. Il consignait aussi la réservation par l'IANA de example.com, example.net et example.org.
  • Un nom improvisé dans un réseau d'essai peut devenir un domaine réel ailleurs; un exemple de manuel peut finir dans un programme en service. La réservation fixe une frontière durable entre la fiction technique et les adresses attribuables.

Le personnage le plus imprudent d'un manuel technique est parfois l'adresse fictive. Elle ne demande rien, ne signe rien et se glisse parfaitement dans une ligne de configuration. Quelques mois plus tard, cette ligne accompagne le logiciel chez un client. L'adresse qui servait de décor est devenue une destination. Le DNS, lui, n'a jamais lu la note de bas de page précisant que tout cela était imaginaire.

En juin 1999, D. Eastlake et A. Panitz ont publié le RFC 2606, devenu BCP 32. Leur problème était concret: comment tester le DNS et écrire des exemples sans choisir par hasard le futur nom de quelqu'un d'autre? Le texte décrit un laboratoire qui crée localement un domaine de premier niveau alors inutilisé. Si ce nom est ensuite introduit dans le DNS mondial, le laboratoire se retrouve avec sa propre version du territoire; des requêtes destinées au domaine public risquent de rencontrer le décor local. Une application d'essai peut aussi sortir du laboratoire et continuer à viser ce qu'elle croyait être un nom sans existence publique.

La solution tenait dans quatre étiquettes de premier niveau. .test servait aux essais de code lié au DNS. .example donnait une place aux illustrations et à la documentation. .invalid permettait de fabriquer un nom manifestement invalide. .localhost conservait l'usage local traditionnel associé à l'adresse de bouclage dans les implémentations hôtes. Ces étiquettes ne formaient pas une pile de synonymes. Le RFC leur attribuait des fonctions différentes, comme quatre tiroirs dont on connaît le contenu avant de les ouvrir.

Trois autres noms complétaient ce mobilier: example.com, example.net et example.org. Le RFC notait que l'IANA les avait réservés comme exemples sous des domaines de premier niveau familiers. Un rédacteur pouvait ainsi écrire une adresse ayant l'allure d'un vrai site sans emprunter le nom d'une organisation inconnue. La ressemblance était précisément l'intérêt de l'exercice. On pouvait montrer une URL ordinaire dans un formulaire, une notice ou un morceau de code, avec une destination prévue pour ce rôle.

Il faut distinguer les étages. Dans boutique.example, le dernier élément du nom porte lui-même la réservation destinée aux exemples. Dans example.com, .com appartient au DNS ordinaire; c'est le nom example situé dessous qui a été mis de côté. Cette différence évitait de raconter la mauvaise histoire. Le RFC ne décrétait pas que tous les noms en .com étaient des accessoires de théâtre. Il donnait trois accessoires précis aux auteurs.

La section consacrée à la sécurité révèle le ressort comique du dossier. Des logiciels expérimentaux peuvent quitter leur réseau de test. Des adresses présentées comme « seulement » illustratives peuvent être programmées et diffusées. Un nom inventé trop librement peut un jour rencontrer un véritable titulaire, avec des intérêts attachés à cette adresse. Pour réduire ces collisions, le texte proposait une réponse de greffier: réserver quelques cases, publier leur usage, ne plus les laisser dans le lot des noms ordinaires. Il fallait donc une procédure réelle pour protéger le faux.

L'IANA explique encore aujourd'hui que les domaines example qu'elle entretient peuvent être repris dans la documentation sans autorisation préalable. Ils restent indisponibles à l'enregistrement ou au transfert. Elle fournit une page d'information à ces adresses, tout en déconseillant de bâtir une application qui dépendrait de ce service web. La réservation continue de faire son travail administratif; la page d'accueil n'est pas un contrat d'hébergement pour les programmes d'autrui.