Mon blog

C'est vendredi, bientôt le week-end, détendons-nous avec un nom de domaine rigolo, 📪.ws. Oui, vous avez déjà vu des noms de domaines avec des émojis. Mais celui-ci a une particularité.

Un petit retour en arrière s'impose. D'abord, contrairement à une légende répandue, le DNS, le protocole qui résout les noms de domaine en informations concrètes, ce protocole n'est pas limité à l'ASCII, encore moins au sous-ensemble LDH (Letters-Digits-Hyphen) d'ASCII. On peut mettre n'importe quel octet dans un nom de domaine. Toutefois, le faire peut entrainer des surprises, parce qu'il n'existe pas d'encodage standard (si le DNS était créé aujourd'hui, UTF-8 serait l'encodage standard mais, à l'époque, ce n'était pas aussi clair) et surtout parce qu'il n'y a pas de règles de canonicalisation (depuis, le RFC 5198 fournirait certainement une solution mais, là encore, c'est trop tard). Et, surtout, pas mal d'applications (mais, répétons-le, pas le DNS lui-même) seraient surprises de recevoir des noms qui ne sont pas en ASCII. C'est pour ces raisons (que j'ai détaillées dans un autre article) que, si on veut de l'Unicode dans les noms de domaine (que l'on nommera alors IDN), on doit utiliser la norme décrite dans les RFC 5890 et suivants. Cette norme impose notamment :

• Une restriction des caractères autorisés, décrite dans le RFC 5892, en gros les lettres (toutes les lettres, pas uniquement celles d'ASCII), les chiffres et le tiret. Les symboles comme &, $ ou les émojis ne sont pas autorisés.
• Un encodage standard, Punycode, normalisé dans le RFC 3492. C'est ainsi que gémeaux.bortzmeyer.org se retrouve encodé en xn--gmeaux-bva.bortzmeyer.org et தளம்.பாராளுமன்றம்.இலங்கை est encodé xn--rlcuo9h.xn--wlcbmbhil0gb5a8kc.xn--xkc2al3hye2a.

Mais il y a les normes techniques (les RFC) et il y a la réalité. Il n'existe pas de police de l'Internet qui ferait régner l'ordre normatif et fusillerait les contrevenants qui violent les normes techniques. Si l'ICANN impose ce respect des normes dans les TLD qu'elle contrôle, ce n'est pas le cas dans les autres TLD. Donc, on voit des TLD (comme .ws) autoriser des noms théoriquement invalides comme i❤️tacos.ws.

Mais revenons à notre 📪.ws. Si nous essayons de résoudre ce nom en adresse IP avec l'outil dig (il faut une version compilée avec la gestion des IDN) :

% dig  A 📪.ws         
dig: 'xn--gu8h.ws.' is not a legal IDNA2008 name (string contains a disallowed character), use +noidnout
  

dig a protesté, et à juste titre, la norme (IDNA2008 : norme IDN in Applications, version 2008, c'est celle du RFC 5890) ne permettant pas les émojis. Comme dig nous le suggère, essayons avec l'option +noidnout qui lui dit de ne pas afficher d'Unicode en sortie :

% dig +noidnout A 📪.ws
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10659
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
;; QUESTION SECTION:
;xn--gu8h.ws.		IN A

Cette fois, on a une réponse (status: NOERROR) mais pas de données (ANSWER: 0). C'est parce que dig, comme il l'affiche dans sa répétition de la question, a converti en Punycode, comme dicté par la norme, et qu'il n'y avait pas de données pour le nom en Punycode. Maintenant, débrayons complètement IDN et essayons le nom dans son encodage natif ce qui, sur ma machine, est UTF-8 :

% dig +noidnout +noidnin A 📪.ws
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45985
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 9, ADDITIONAL: 7
...
;; QUESTION SECTION:
;\240\159\147\170.ws.	IN A

;; ANSWER SECTION:
\240\159\147\170.ws.	300 IN A 64.70.19.203
...

  

Cette fois, on a des données (et même deux, car il y a aussi la signature DNSSEC), et on récupère une adresse IP, 64.70.19.203. La question (\240\159\147\170.ws) est le nom en UTF-8, \240\159\147\170.ws étant bien la représentation en UTF-8 du caractère Unicode U+1F4EA, l'émoji « boite aux lettres ».

C'est donc un cas assez rare : un IDN qui a des données pour l'encodage UTF-8 mais rien en Punycode. (J'ai trouvé des noms qui avaient les deux.) À cause de cela, il est très probable que l'URL http://📪.ws/ ne marchera pas dans votre navigateur (qui, sans doute, suit la norme technique fidèlement).

John Shaft m'a mis sur la piste de l'explication de cette étrangeté. Le domaine encodé en UTF-8 n'existe pas, donc les serveurs faisant autorité pour .ws devraient répondre NXDOMAIN (No Such Domain). Mais .ws a un joker dans la zone et répond donc pour tous les noms inexistants avec cette adresse IP, 64.70.19.203.

Merci à Sean Conner pour avoir attiré mon attention sur ce domaine, dans le cadre d'une discussion sur le projet Gemini. Victor Héry m'a appris ensuite que ce nom de domaine faisait partie du projet Mailoji, une pure escroquerie (car les noms vendus aux pigeons ne marcheront que dans un environnement fermé et contrôlé par le vendeur).