Héberger un nom de domaine avec caractères composés

Nous avons vu, dans un précédent article, qu’on pouvait parfaitement avoir un nom de domaine comportant des caractères composés. C’est le cas de, par exemple, réussir-en.fr, académie-française.fr, ou bien d’autres. Ces noms se manipulent comme tous les autres noms de domaine et peuvent, parmi d’autres usages, servir pour le Web, avec des URL, des adresses Web, comme http://réforme-retraites.gouv.fr/. Pour l’utilisateur final, ces noms sont des noms de domaine comme les autres et ne présentent pas de particularité, sauf si on se heurte à des logiciels très anciens ou bogués. Mais, pour la technicienne ou le technicien qui configure les logiciels permettant l’hébergement de ces noms, et des services qui y sont associés, ce n’est pas toujours le cas : souvent, il faut traiter de manière différente ces noms.

Cet article est donc destiné à ces techniciens et techniciennes, par exemple l’administratrice système d’un serveur HTTP devant servir un site Web dont le nom de domaine comporte ces caractères composés (ou « caractères diacritiques », ou « caractères Unicode »). L’article se focalise sur les logiciels libres comme Apache ou Nginx, puisque l’essentiel de l’infrastructure des services Internet repose sur eux.

Petit rappel technique

D‘abord, révisons très rapidement ces IDN (Internationalized Domain Names). Le principe est que le DNS (Domain Name System) ne va manipuler que des noms LDH (Letters-Digits-Hyphens, où les lettres sont limitées à celles de la norme ASCII, sans caractères composés, donc). Ce choix permettait de s’assurer que les anciens logiciels ne recevraient jamais de caractères composés. Pour cela, les noms en Unicode (le terme technique est U-label) sont encodés en Punycode, un encodage qui permet de représenter tout nom en LDH (le terme technique est A-label). Ainsi, le nom académie-française.fr (le U-label) sera représenté en Punycode par xn—acadmie-franaise-npb1a.fr (le A-label). Dans un monde idéal, l’administratrice système n’aurait à manipuler que des noms en Unicode. Dans le monde réel, bien des logiciels exigent de l’administrateur qui les configure qu’il utilise la forme en Punycode.

Heureusement, des outils existent pour faciliter la conversion d’une forme dans l’autre. Ainsi, la GNU libidn2 vient avec un outil en ligne de commande, idn2, qui permet ces conversions :

% echo académie-française.fr | idn2

xn—acadmie-franaise-npb1a.fr

% echo xn--ducation-90a.gouv.fr | idn2 -d

éducation.gouv.fr

Pourquoi le 2 à la fin ? Parce que nous en sommes actuellement à la version 2 de la norme IDN. L’ancien outil, nommé idn tout court, gérait la version 1. Des problèmes peuvent se poser avec des noms dont le comportement est différent entre la version 1 d’IDN et la version 2. C’est le cas du ß allemand (eszett), présent dans quatre noms dans .fr :

% echo außensteckdose.fr | idn2

xn—auensteckdose-cdb.fr

% echo außensteckdose.fr | idn

aussensteckdose.fr

Le ß était transformé en un double s en IDN 1 alors qu’il est gardé tel quel en IDN 2. Autre cas où des différences peuvent apparaître, celui des écritures qui n’ont été intégrées à la norme Unicode qu’après la sortie de la version 1 d’IDN. C’est notamment le cas de l’écriture tifinagh, qui ne marche tout simplement pas en IDN 1 :

% echo « ⴰⵣⵓⵍ.bortzmeyer.fr » | idn2

xn--4lj0cra7d.bortzmeyer.fr

% echo « ⴰⵣⵓⵍ.bortzmeyer.fr » | idn

idn: idna_to_ascii_4z: String preparation failed

L’eszett pose un problème supplémentaire : l’aller-retour (traduction du U-label en A-label puis du A-label en U-label) n’est pas possible en IDN version 1, où le A-label devient un nom de domaine ASCII classique. D’où, par exemple, le message d’erreur du langage de programmation Python « UnicodeError: (‘IDNA does not round-trip’, b’xn--auensteckdose-cdb’, b’aussensteckdose’) ».

DNS

Passons maintenant à l’action et créons ces noms. Vous pouvez les créer en sous-domaine d’un domaine que vous avez déjà (comme ⴰⵣⵓⵍ.bortzmeyer.fr ci-dessus) ou bien les enregistrer auprès d’un registre qui accepte ces caractères (tous ne le font pas, et ceux qui le font n’acceptent pas forcément tous les caractères possibles, renseignez-vous auprès du registre).

Dans le premier cas, tout va dépendre du logiciel que vous utilisez pour l’avitaillement de vos noms de domaine. Peut-être gère-t-il bien les noms en Unicode et peut-être pas . Il faudra alors utiliser les A-labels. Par exemple, si vous éditez directement un fichier de zone à la syntaxe standard, il est probable que le serveur DNS n’acceptera pas l’Unicode et vous devrez mettre la forme en Punycode dans le fichier de zone (d’où l’intérêt d’outils comme idn2 cité plus haut). Voici un exemple, avec un commentaire qui indique le nom en Unicode :

; ⴰⵣⵓⵍ

xn--4lj0cra7d IN CNAME serveur.internautique.fr.

En effet, le DNS autorise tous les caractères dans un nom de domaine, et un nom en Unicode, avec un encodage comme UTF-8, serait probablement pris comme tel par le serveur, ce qui dérouterait les applications qui voudraient, elles, pratiquer la conversion en Punycode.

Si vous enregistrez un nom auprès d’un registre de noms de domaine, vous passerez souvent par un BE (Bureau d’Enregistrement). Tout va alors dépendre de ce BE et de son logiciel. J’ai testé avec deux importants BE de .fr et, dans les deux cas, tout se passe bien, l’interface Web me permet de taper et de lire les noms sous leur forme Unicode normale, certainement plus agréable que le Punycode. Notez que certains registres exigeront que vous indiquiez quelle est l’écriture utilisée pour le nom (latine, tifinagh, cyrillique, etc), et interdiront le mélange d’écritures.

J’ai aussi testé l’API d’un gros BE (Bureau d’Enregistrement de noms de domaine) et ait été agréablement surpris de voir que les IDN étaient correctement gérés. Je peux envoyer de l’Unicode (des U-labels) et tout se passe bien.

Si vous hébergez ce nom de domaine sur vos propres serveurs de noms, là encore, cela dépendra des logiciels utilisés. Vous serez peut-être obligé de configurer le serveur de noms en utilisant les A-labels. En effet, rappelez-vous que, contrairement à une légende répandue, le DNS a toujours autorisé n’importe quels caractères, sans être limité à ASCII. Si on met dans un fichier de zone café.example, le serveur de noms ne sait pas forcément si c’est un U-label qui doit être traduit en Punycode, ou bien s’il faut le garder tel quel. Avec certains serveurs, comme BIND, c’est le second comportement qui est adopté, ce qui peut provoquer des surprises.

Une fois le nom enregistré, pour l’interroger, plusieurs client DNS gèrent les IDN. Avec le classique dig, dans sa version 9.11 :

Même chose pour kdig, dans sa version 2.7.6.

Par contre, drill (version 1.7.0) ne comprend pas et ne gère pas correctement le nom. On peut arguer qu’il s’agit d’un outil de déboguage, conçu pour des informaticiens et des informaticiennes, et qu’il n’est donc pas indispensable qu’il sache faire ce qu’on peut faire avec un peu de shell Unix :

Enfin, d’autres clients DNS sont mis en œuvre sous forme d’une page Web et, par exemple, le DNS Looking Glass gère les IDN : regardez https://dns.bortzmeyer.org/réussir-en.fr.

Whois

On peut aussi vouloir utiliser d’autres services liés au nom de domaine, comme whois. Le client GNU whois n’a pas de problèmes avec les IDN :

% whois potamochère.fr

%% This is the AFNIC Whois server.

domain: potamochère.fr

domain-ace: xn--potamochre-66a.fr

domain-idn: potamochère.fr

registrar: GANDI

created: 2013-09-09T12:12:45Z

last-update: 2019-08-09T09:26:17Z

Même chose avec les autres interfaces de recherche d’information sur un nom de domaine, par exemple via le Web (ici, à l’Afnic), les noms en Unicode sont bien gérés.

Web

Mais, évidemment, on ne crée pas un nom de domaine uniquement pour mettre des informations dans le DNS. On veut l’utiliser pour des services, pour de la présence en ligne. Par exemple, on veut mettre un site Web. Là encore, la question de savoir si on pourra utiliser les beaux U-labels (café-bien-serré.fr) plutôt que les tristes A-labels (xn—caf-bien-serr-dhbk.fr) dépendra du logiciel utilisé. Avec Nginx (version 1.16.1), il faut mettre la forme Punycode (xn—caf-bien-serr-dhbk.fr) dans la directive server_name du fichier de configuration. Même chose avec Apache (version 2.4.38). S’il permet, lui, de mettre la forme Unicode normale dans la directive ServerName, cela ne donne pas le résultat attendu. (Une astuce amusante est de mettre le U-label en ServerName pour documenter, et le A-label en ServerAlias, pour que ça fonctionne.) Le fichier de configuration, lui, peut se nommer avec le nom Unicode (par exemple www.potamochère.fr.conf), les directives apache comme Include n’ont pas de problème avec cela.

Mais méfiez-vous des divers scripts et programmes utilitaires écrits trop vite. Ainsi, le script a2ensite sur le système d’exploitation Debian ne fonctionne qu’avec les noms LDH (pas de caractères en dehors d’ASCII). Si par contre on met les liens symboliques nécessaires à la main, il n’y a pas de problème avec l’Unicode. D’autre part, des directives au serveur, comme Redirect sur Apache, nécessitent d’indiquer le A-label (Punycode), sinon, c’est de l’Unicode qui est envoyé au client, et certains, comme curl, ne comprennent pas une telle redirection.

Et les clients Web pour tester ? curl et wget ne font pas d’histoires avec l’Unicode dans l’URL :

curl est un peu plus favorable à l’IDN : même quand on utilise l’option -v (verbose), curl continue à afficher la forme Unicode du nom, ce que ne fait pas wget.

Notez que tous les clients HTTP envoient, dans l’en-tête Host:, le nom sous sa forme Punycode. Ce n’est pas très grave, puisque ce dialogue HTTP n’est pas vu par les utilisateurs directement. Au passage, notez qu’il est difficile de s’appuyer sur les normes techniques dans l’espoir de savoir ce qui doit apparaître dans cet en-tête Host:, car celles-ci sont fort complexes sur ce sujet.

Et pour les logiciels de supervision comme Nagios ou Icinga ? Le monitoring plugin check_http demande, dans ses paramètres, du Punycode. Si on lui donne un autre encodage, il ne fait aucun traitement, il l’envoie tel quel, ce qui typiquement provoque une erreur HTTP 400 (requête invalide).

Certificats

Et pour les demandes de certificats ? Si vous voulez que votre site Web puisse être authentifié, vous avez besoin d’un certificat pour votre nom de domaine et, selon l’autorité de certification que vous utilisez, vous devrez demander avec la forme « normale » (académie-française.fr) ou bien avec la forme en Punycode (acadmie-franaise-npb1a.fr). Notez que, dans le cas de l’exemple choisi, académie-française.fr, il semble qu’il n’y ait pas de certificat, mais je suppose qu’il y en aura un un jour.

Par exemple, l’autorité de certification Let’s Encrypt refuse les noms Unicode (« Domain name contains an invalid character »), il faut tout mettre en Punycode.

Même chose pour certains services très utiles quand on gère des certificats comme crt.sh, une interface Web d’accès aux journaux du service Certificate Transparency. Si on entre de l’Unicode, crt.sh dit simplement qu’il n’a pas trouvé de certificat, il aurait fallu indiquer en Punycode.

Courrier électronique

Le courrier électronique pose un problème différent de celui du Web. C’est une technologie plus ancienne et, comme il n’y a pas de communication de bout en bout, il est plus difficile de négocier avec son correspondant. Notez aussi qu’il y a deux problèmes distincts dans les adresses de courrier électronique, un pour la partie locale du nom (stéphane, dans l’hypothétique adresse stéphane@internet-en-coopération.fr) et un pour le nom de domaine. Punycode ne s’applique qu’au nom de domaine.

Le cadre général pour des adresses de courrier en Unicode se nomme EAI, pour Email Addresses Internationalization. Il est normalisé depuis 2012. Mais, disons-le tout de suite, en pratique, on ne peut guère compter dessus : peu de logiciels sont configurés pour le gérer, et il y a peu de chance pour que vous puissiez utiliser votre domaine IDN pour le courrier électronique. Comme le note l’interface Web d’un BE (Bureau d’Enregistrement) quand on enregistre un domaine IDN, « Sachez que les adresses e-mails risquent de ne pas fonctionner avec un domaine contenant un ou des caractères spéciaux [sic] ».

Conclusion

L’idéal serait bien sûr que l’administratrice système, tout comme l’utilisateur ordinaire, puisse manipuler de l’Unicode normal et ne jamais voir la forme en Punycode, avec son xn--. Mais ce n’est clairement pas le cas aujourd’hui, et diverses raisons liées à l’inertie de l’Internet et à la nécessité de ne pas casser les habitudes pré-existantes font qu’en pratique, on ne peut pas se passer de Punycode et qu’on doit être préparé à le voir et à le manipuler.