Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Avoir un TLD à soi, d'accord, mais s'en servir ?

Première rédaction de cet article le 25 mars 2009


L'ICANN avait annoncé à l'occasion de sa réunion de Paris en juin 2008, un assouplissement important des conditions de création de nouveaux TLD. Si l'assouplissement n'est pas aussi important que ce que la presse avait prétendu à l'époque (et il semble en outre actuellement très ralenti par l'opposition active des titulaires de marques déposées), le dossier reste néanmoins ouvert. Mais il semble qu'un petit aspect technique est passé relativement inaperçu, la difficulté à utiliser des noms de domaines composés d'un seul élément.

Contrairement à ce qu'a toujours prétendu l'ICANN pour justifier son immobilisme, il n'existe aucune raison technique pour ne pas créer des milliers ou des dizaines de milliers de TLD. La racine du DNS est une zone comme une autre et, même en créant dix TLD par jour, en vingt ans, la racine resterait loin derrière la majorité des zones des TLD.

Mais la discussion s'était toujours focalisée sur des TLD à délégation comme .fr ou .com, où personne n'exploite le TLD lui-même, tout se fait dans des sous-domaines comme example.com ou bortzmeyer.fr. Avec le nouveau plan de libéralisation des TLD, au contraire, on pourrait voir des TLD pour une seule entreprise, sans délégation de sous-domaines. On suppose que certaines des entreprises intéressées envisagent d'utiliser des noms de domaines composés d'un seul élément. Si l'entreprise se nomme Example, Inc., elle va vouloir le TLD example et probablement espère t-elle communiquer sur des adresses de courrier comme president@example ou des adresses Web http://example. Mais cela a peu de chances de marcher.

Comment, de telles adresses ne sont pas légales ? Elles violeraient un RFC ? Pas du tout, elles sont tout à fait légales mais il y a la norme technique et la pratique. Dans l'Internet tel qu'il est aujourd'hui, ces adresses ne marcheront que partiellement.

Un nom de domaine est en effet composé de plusieurs éléments (labels en anglais, voir le RFC 1034). Ainsi, munzer.bortzmeyer.org a trois éléments, munzer, bortzmeyer et enfin org, qui est le TLD. En représentation textuelle, par exemple sur une carte de visite, les éléments sont séparés par des points. Un nom de domaine à un seul élément est légal, il ne comprend dans ce cas aucun point. example ou dk sont ainsi des noms de domaine (seul le second existe réellement, c'est le TLD du Danemark). Ces noms, à un, deux, trois ou davantage d'éléments, sont tous égaux pour le DNS et fonctionnent tous aussi bien.

Mais il n'y a pas que le DNS, les titulaires achètent des noms de domaine pour des applications. Commençons par le courrier électronique. L'écrasante majorité des serveurs de courrier sont configurés (et c'est l'option par défaut, dans bien des cas) pour regarder si le nom de domaine (ce qui est à droite du @ dans une adresse de courrier) comporte un point ou pas. S'il n'en a pas, ils ajoutent en général le nom de domaine de leur organisation. Si je travaille sur une machine du domaine bortzmeyer.org et que je tente d'écrire à president@example, le serveur de messagerie (dans l'exemple ici, un Postfix tout à fait standard), réécrit l'adresse puis me dit :

<president@example.munzer.bortzmeyer.org> (expanded from <president@example>):
    Host or domain name not found. Name service error for
    name=example.munzer.bortzmeyer.org type=AAAA: Host not found

On peut argumenter que je suis en tort et que je devrais régler mon serveur mieux que ça. Sans doute. Mais comme je suis loin d'être le seul dans ce cas, la conclusion est claire : si le Président met uniquement sur sa carte de visite president@example, il ne recevra pas beaucoup de courrier. Et il ne pourra pas s'inscrire sur beaucoup de sites Web qui demandent une adresse de courrier et souvent, exigent que le nom de domaine de l'adresse comporte au moins un point.

Et pour le Web ? Il souffre d'un problème analogue. Beaucoup de navigateurs (ou bien de relais) ajoutent un TLD (souvent .com) après les noms de domaine composés d'un seul élément. Firefox est un peu plus intelligent, il teste d'abord si le nom de domaine a une adresse IP. Ainsi, http://dk/ fonctionne (les danois ont mis une adresse à leur TLD) mais http://fr ne donne pas le résultat attendu. Comme il n'y a pas d'adresse IP associée, le navigateur ajoute .com d'autorité et on va ensuite visiter le site Web d'un cabinet d'avocats états-uniens. Subtilité Firefoxienne : http://fr/ donne le résultat correct. Avez-vous remarqué quel est le caractère qui diffère ? Avant de tester vous-même, n'oubliez pas que le résultat exact dépend de beaucoup de choses : version exacte de Firefox, utilisation ou non d'un relais, etc.

En conclusion, qu'une entreprise (je n'ai parlé que des entreprises car les tarifs de l'ICANN - plus de 180 000 dollars US uniquement pour déposer le dossier - excluent les associations, les particuliers étant de toute façon explicitement interdits de candidature) veuille son TLD, pourquoi pas, cela ne gêne personne. Mais qu'elle n'espère pas trop pouvoir utiliser des adresses où le nom de domaine serait uniquement le TLD.

Une discussion amusante sur Stack Overflow sur ce sujet : Pourquoi mon nom composé d'un seul composant ne marche pas ?. Un article très récent sur ce sujet est « Domain Names Without Dots » de Paul Vixie. Une autre étude (assez bien faite techniquement mais très orientée vers la sur-régulation ICANNienne) est le rapport 053 du SSAC. Un exemple de faille de sécurité amusante dans les produits Microsoft, avec des domaines d'un seul composant, est l'article « Top-Level Universal XSS ».

Dans ses règles finales, l'ICANN a finalement interdit de mettre des adresses au sommet de la zone (sans justification technique, comme d'habitude avec l'ICANN).

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)