La société Verisign, gestionnaire des domaines .com et .net, a modifié le 16 septembre sa politique de gestion en introduisant des jokers lui permettant d’associer tout domaine inexistant à l’une de ses propres machines d’adresse 64.94.110.11 . Ainsi, toute demande de résolution par le système d’annuaire « DNS » (Domain Name System) d’un domaine .com ou .net inexistant (tel que agenda2006.com) en une adresse IP se voyait indiquer la machine de verisign [1].

Une modification d’aussi bas niveau affecte donc toutes les applications utilisant cet annuaire, soit quasiment toutes celles utilisées aujourd’hui par des humains [2]. Outre les courriers électroniques dont le nom de domaine de l’un des destinataire est mal orthographié, on peut également mentionner certains filtres anti-spam qui vérifient l’existence du domaine de l’expéditeur avant d’accepter un courriel.

La motivation de Verisign est à l’image des dérives induites par l’implémentation de certains des rêves les plus fous des marchands sur l’internet. Il s’agit ici de rediriger les internautes saisissant mal un nom de domaine vers le service « SiteFinder », un annuaire de sites où il faut payer pour figurer. Nous sommes donc priés de comprendre qu’Internet est synonyme de web et que les internautes ne sont que des clients passifs de sites, qu’il convient d’assister par tous les moyens, même en mettant en péril le bon fonctionnement d’autres outils, et que le web est dorénavant un grand centre commercial ou les pauvres, les associations et autres saltimbanques n’ont pas droit de cité.

Le comportement de Verisign est également révélateur du mépris des « grands » (par le chiffre d’affaire) acteurs de l’industrie pour l’interopérabilité et, plus largement, pour les règles de vie commune. Verisign n’a en effet pas carte blanche pour la gestion des .net et des .com ; elle doit suivre un cahier des charges édicté par l’ICANN et respecter les normes de l’Internet, dont notamment le RFC 1034. Les jokers ou wildcards y sont clairement indiqués [3] comme pouvant s’appliquer à un sous-domaine, tel que *.temps-reels.net, mais pas à un domaine.

Parmis les problèmes qui peuvent survenir du fait de cette modification fort regrettable figure en bonne place la réception de messages mal adressés. Lors de l’envoi d’un courrier à un destinataire, un logiciel client de messagerie contacte typiquement le serveur SMTP de son domaine afin de lui demander de l’acheminer au destinataire. Dans le cas d’un particulier, ce serveur est généralement hébergé chez son FAI et s’appelle selon le cas smtp.wanadoo.net, smtp.nerim.net, etc.

Ce serveur recherche alors à quel(s) serveur(s) remettre le courrier. Pour simplifier, on évoquera ici le cas d’un unique destinataire. Pour se faire, il doit déterminer quels sont le ou les serveurs de courriers du domaine de destination. Ainsi, si le courrier est envoyé à test@agenda2006.com, le serveur va demander au système DNS de lui indiquer tous les champs « MX » (Mail Exchanger ou serveur SMTP) de ce domaine. Dans le cas où aucun enregistrement MX n’existe, une résolution de nom « ordinaire » (pour être précis, de type d’enregistrement « A ») est effectuée. Si elle réussit, le serveur de courrier tente de contacter l’éventuel serveur SMTP en écoute à cette adresse ; si elle échoue, un message d’erreur est retourné à l’expéditeur. Or la modification de Verisign porte justement sur ce dernier type de résolution : désormais, à tout nom de domaine en .com ou .net est associé une adresse IP valide.

Ainsi, il suffirait à Verisign de faire tourner un serveur de courrier acceptant les messages à destination de n’importe quel destinataire de n’importe quel domaine sur la machine d’adresse 64.94.110.11 pour intercepter tous les messages mal adressés. Le fait-elle ? Heureusement, il semble que non.

Afin d’étudier plus en détail le comportement de Verisign, un courrier a été envoyé à test@agenda2006.com, domaine inexistant. Le message d’erreur suivant nous a été retourné :

« 

On note surtout que le message d’erreur est « The domain you are trying to send mail to does not exist » (le domaine auquel vous essayez d’envoyer du courrier n’existe pas) et qu’il a été retourné à notre serveur SMTP suite à la commande « RCPT TO ».

Or, la commande RCPT TO est utilisée pour indiquer le destinataire du message, avant d’envoyer son contenu. Si l’on se substitue à notre serveur de courrier et que l’on se connecte directement, avec la commande telnet, au serveur de courrier de la machine associée aux domaines non existant par verisign, on obtient la trace suivante :

Trois commandes ont été tapées (rapidement) par nos soins :
  HELO temps-reels.org : annonce du nom du domaine desservi par nos soins
  MAIL FROM :<secsec@temps-reels.org> : adresse de l’expéditeur
  RCPT TO :<test@agenda2006.com> : adresse du destinataire.

Le serveur de Verisign retourne alors le message d’erreur indiquant que le domaine de destination n’existe pas.

On peut donc vérifier que :
  le contenu du message n’a pas été envoyé
  que le nom de l’émetteur et du destinataire du message ont par contre été bien envoyés.

Si le message au complet n’est donc pas intercepté, les noms des correspondants le sont, ce qui est déjà une violation de la confidentialité de nos communications. À noter que certains serveurs SMTP se présenteraient de manière anormale et enverraient les données quelque soit la répons à la commande RCPT TO. Une raison de plus de préférer un logiciel libre tel que Postfix ?

L’ICANN a, après une réflexion de plusieurs jours, pris position [4], demandant à Verisign de suspendre volontairement son service, en attendant des conclusions plus détaillées de ses comités quant aux perturbations techniques induites et quant aux contrats de gestion des registres .com et .net. Le 22 septembre, le joker de redirection vers le « service Sitefinder » était toujours en place. À noter que certains acteurs commerciaux ont rapidement entamé des poursuites contre Verisign [5]. Aux États-Unis, ce genre de problème concernant l’ensemble de la communauté ne pourrait-il donc être résolu que par le petit bout de la lorgnette, en se basant uniquement sur des considérations commerciales ? Le 3 octobre, l’ICANN change de ton et ordonne à VeriSign de restaurer le fonctionnement antérieur au plus tard dimanche 4 novembre à 1 heure du matin (heure de paris). L’ICANN indiquait que, dans le cas contraire, elle prendrait les mesures nécessaires pour faire respecter le contrat la liant à VeriSign. VeriSign se soumettra à cette injonction .

Il est intéressant de noter que les milieux du logiciel libre ont réagi au quart de tour, proposant rapidement des modifications de la plupart des serveurs DNS libres afin de rétablir l’ancien comportement (d’autres parades sont également mentionnées dans la section « Que peut-on faire ? » de cet article de ZDnet). Il aurait été encore plus intéressant d’observer le comportement des autres grands acteurs américains produisant des serveurs de noms, tel que Microsoft si cette anomalie avait persisté.

D’une manière plus générale, cette affaire pose à nouveau la question de l’unicité du DNS. Combien de temps pourrons-nous accepter de dépendre d’un système centralisé, contrôlé par une société étrangère ? L’Internet, de par sa nature décentralisée privilégiant les communications point à point, nous offre portant la possibilité de facilement nous affranchir, en utilisant par exemple notre propre annuaire distribué, notre propre DNS.

[1] [ ZDNet « Verisign fait un hold-up sur tous les noms de domaines qui n’existent pas encore » http://www.zdnet.fr/actualites/internet/0,39020774,39124125,00.htm

[2] O1net « VeriSign accapare le no man’s land de l’Internet » - (http://www.01net.com/article/216831.html

[3] The contents of the wildcard RRs follows the usual rules and formats for RRs. The wildcards in the zone have an owner name that controls the query names they will match. The owner name of the wildcard RRs is of the form "*.", where is any domain name. should not contain other * labels, and should be in the authoritative data of the zone. The wildcards potentially apply to descendants of , but not to itself. Another way to look at this is that the "*" label always matches at least one whole label and sometimes more, but always whole labels. - RFC 1034

[4] ICANN « Advisory Concerning VeriSign’s Deployment of DNS Wildcard Service » - http://www.icann.org/announcements/advisory-19sep03.htm

[5] ZDNet « Verisign et son nouveau service Site Finder déjà attaqués en justice » - http://www.zdnet.fr/actualites/internet/0,39020774,39124353,00.htm