-
Consultations
-
Commandes publiques de l'Afnic
-
Documents de référence
-
Statistiques
-
Publications
-
Blog
- Brexit et .fr
- Radioscopie du .RE
- Les marques répondent présentes au 2nd rendez-vous du Cercle des .marque
- À propos de l’attaque sur les résolveurs DNS de FAI français
- Utiliser l'open data de l'Afnic : exemple avec le terme COVID
- Héberger un nom de domaine avec caractères composés
- L’éligibilité d’un titulaire situé sur le territoire du Royaume-Uni post BREXIT
- Peut-on avoir des caractères composés dans un nom de domaine ?
- Le fonctionnement de l'Afnic pendant le confinement
- Quels domaines de premier niveau ont une adresse IP ?
- Lala Andriamampianina nous a quittés
- 6 conseils pour éviter les piratages de son site web
- Résolutions 2020: l'Afnic se met à l'elliptique
- À la recherche des nTLD low cost
- Balade au cœur du .paris - à la découverte de sa communauté
- Le .ORG – une autre perspective
- Retour sur le succès de la première rencontre du Cercle des .marque
- Facteurs clés de succès des extensions internet : une grille d’analyse
- [Vidéo] Retour sur le Forum de la Gouvernance Internet (FGI) France 2019
- Un petit exemple d'utilisation des données ouvertes de l'Afnic
- Réflexions sur les modèles économiques des « nouveaux TLD »
- 30 ans, des succès, et des risques ; le Web, l'URL et le futur
- [Success stories] Renforcer son infrastructure pour l’adapter à ses ambitions
- 1er février 2019 : le DNS va-t-il trembler ?
- [Success stories] Ils ont fait le choix d’une extension internet personnalisée
- [Success stories] Le .museum, une extension internet historique redynamisée
- Les grandes étapes pour lancer efficacement votre .marque
- 6 secrets pour améliorer le renouvellement des noms de domaine
- [Vidéo] Retour en images sur l'IGF 2018 Paris
- Le .MARQUE pour optimiser l'expérience client
- L’Afnic s’implique dans la sécurité du DNS au niveau international
- Remplacement de la clé KSK de la zone racine : Êtes-vous prêts ?
- Comment la SNCF a mis en oeuvre sa nouvelle stratégie digitale avec oui.sncf ?
- Projet de R&D: classification automatique des abus en matière de noms de domaine
- Mémorisation auditive des noms de domaine
- Quelles actions mener face aux abus sur les noms de domaine ?
- Usurpation d’identité par nom de domaine : ce que fait l’Afnic
- Cybersquatting, Spam, Phishing… les différents types d’abus sur noms de domaine
- [Vidéo] Retour sur le Forum de la Gouvernance de l'Internet France 2018
- Les extensions internet personnalisées : quelles opportunités pour les marques ?
- Comment éviter l'irrecevabilité dans la procédure SYRELI
- Quels sont les termes anglophones les plus utilisés dans les domaines en .FR ?
- Sécurité des noms de domaine, l'exemple des cryptomonnaies
- Test de personnalité : êtes-vous prêts pour le RGPD ?
- Les extensions comme le .alsace ont-elles un effet sur le SEO local ?
- Quels sont les termes les plus utilisés dans les noms de domaine en .fr ?
- Les 11 endroits incontournables où votre adresse internet doit apparaitre !
- Quels moyens d'actions pour les ayants-droits non éligibles à la charte du .fr ?
- Litige sur un nom de domaine: la reconnaissance des droits d'une AOC dans SYRELI
- Pourquoi utiliser un nom de domaine sous une nouvelle extension ?
- L'Afnic, une communauté avant tout !
- La défense des droits de la personnalité dans la procédure SYRELI
- Le prochain round des nouveaux gTLD, c’est pour quand ?
- Pourquoi venir à l’Afnic Forum ?
- Résolveur public de DNS-sur-TLS Yeti
- 2016, début d’un nouveau cycle pour l’Afnic
- Le .fr vient de franchir le cap des 3 millions de noms de domaine
- Mon expérience au sein du service Juridique de l'Afnic
- [Vidéo] 4 conseils pour réussir le lancement de votre entreprise sur Internet
- Futur de l’ICANN: Ni privatisation, ni internationalisation, ni supervision
- Excellence à l’Afnic – le coming out
- Offre exclusive : votre nom de domaine 100% Remboursé* !
- Intervention à l'occasion de la remise du plan de transition IANA
- Afnic Football Club
- 8 astuces pour bien choisir son nom de domaine
- IPv6 et DNSSEC ont 20 et 19 ans. Même combat et mêmes défis !?
- Le projet Yeti d'expérimentation d'une racine DNS
- L.45-2 1° du CPCE : Quand le nom de domaine porte atteinte à la loi
- Comment éviter de se faire voler son nom de domaine par email ?
- Responsabilité et transition IANA : les coulisses
- République numérique : Ceci n’est pas une consultation publique
- Faut-il une approche globale pour les marques territoriales françaises ?
- Ne vendez plus de noms de domaine !
- abc.xyz : erratum.xyz
- abc.xyz : et pendant ce temps en France ?
- abc.xyz : pourquoi pas alphabet.com ? (Version théorie du complot)
- abc.xyz : le succès controversé du .xyz
- Communication institutionnelle : une tension permanente ?
- abc.xyz : pourquoi pas alphabet.com ?
- alphabet.xyz : comment Alphabet a acheté son nom de domaine ?
- abc.xyz : pas d’inquiétude, nous sommes aussi en train de nous habituer à ce nom
- La transition IANA franchit une étape majeure à Buenos Aires
- Une journée dans la vie de la communauté habilitée ICANN
- Transition IANA : la machine est lancée, mais l'échéance approche
- La Chine, une mutation à pas de géant
- Vers un DNS moins indiscret
- Les Parl : mettez toutes les chances de votre côté
- Icann : la gouvernance pour quoi faire ?
- ICANN Singapour. Un débat au bout du monde
- Synthèse de la table-ronde Afnic sur la solidarité numérique
- Mesurer la « qualité » de l'accès à l'Internet, mission difficile
- Réforme de l'Icann, la boite de Pandore est ouverte
- Comment se porte l'Internet en France ?
- Forum sur la Gouvernance de I’Internet : Que faire ?
- Spam suffit !
- Icann : ne bougez plus !
- Escroqueries et usurpations d’identité, expérience d’un rapporteur SYRELI
- La reforme des régions ne sonnera pas la fin des geoTLD français
- Que retenir de NETmundial ?
- Avis de changement à l'Afnic !
- Suggestions pour une transition IANA réussie
- Sur la gouvernance de l'Internet, les Etats Unis jouent la carte Icann
- Retour vers le futur du service juridique de l’Afnic
- Pourquoi les territoires veulent-ils leur place sur Internet ?
- Vers une nécessaire rationalisation du « panier gTLDs » des registrars ?
- L'éléphant IANA est dans la salle
- Syreli fête ses deux ans
- 2014 : changement de jalons pour le système de nommage
- Le système de nommage de GNUnet
- Gouvernance de l’Internet : Au travail !
- La responsabilité sociétale et l'ADN des ccTLDs
- Mais que fait l'Afnic ?
- Conseil d'Etat, Léon Blum, Lawrence Lessig et l'Afnic
- Qui est derrière le Whois ?
- Registrars Atlas 2013, ce qu'il faut retenir
-
FAQ
-
Lexique
-
Certificats
Héberger un nom de domaine avec caractères composés
08 juin 2020 - Par Stéphane Bortzmeyer
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.
Ce nom de domaine
est-il disponible ?
Actualités
- 16 mars 2021 L'Afnic rejoint le Think Tank Renaissance numérique
- 12 mars 2021 L’Afnic et Internetstiftelsen prolongent leur projet collaboratif Zonemaster j...
- 11 mars 2021 Le .FR en 2020 : accélération de la transformation numérique des entreprises ...
- 1 mars 2021 Rapport Internet des Objets & Souveraineté Numérique
- 12 février 2021 L’Afnic marraine de l’émission Connecte Ta boîte de France Num