Site Finder

Tous les utilisateurs d'Internet qui tentaient d'accéder à des domaines non enregistrés dans l'espace des domaines .com et .net ont été redirigés vers un portail web de VeriSign contenant des informations sur les produits de VeriSign et des liens vers des sites partenaires. Cela a permis à VeriSign d'encaisser des revenus publicitaires et de vendre ses produits, en particulier à des utilisateurs souhaitant enregistrer des noms de domaine. Ces redirections ont détourné, chaque jour, vers VeriSign des millions de demandes dirigées vers des domaines inexistants. C'était comme si VeriSign possédait effectivement tous les domaines .com et .net qui n'avaient pas été achetés et pouvaient les utiliser comme des plates-formes publicitaires.

VeriSign a décrit le procédé comme une façon d'améliorer l'expérience de navigation Web pour les utilisateurs inexpérimentés. Les critiques de VeriSign ont qualifié cette affirmation d'hypocrite. Ce détournement a conduit à une augmentation spectaculaire de la quantité de trafic Internet arrivant sur verisign.com. Selon la société de mesure du trafic Web Alexa, au cours de l'année précédant le changement, verisign.com se situait autour du 2 500^e site Web le plus populaire. Dans les semaines qui ont suivi le changement, le site est entré dans le top 20 des sites les plus populaires et a même atteint le top 10 à certains moments[1].

Le détournement a généré une tempête de controverses parmi les opérateurs de réseaux et les bureaux d'enregistrement de domaines concurrents, en particulier sur les listes de diffusion influentes du NANOG et de l'ICANN. Les opposants à cette tactique affirmaient :

• que la redirection était contraire au bon fonctionnement du DNS, à la politique de l'ICANN et à l'architecture Internet en général ;
• que VeriSign rompait son lien de sa confiance avec la communauté Internet en utilisant l'architecture technique à des fins de marketing ;
• que la redirection violait divers RFC et perturbait certains services Internet, tels que le courrier électronique et le filtrage du spam (les filtres ne pouvaient pas valider les noms de domaine) ;
• que la redirection équivalait à du typosquattage lorsque le domaine non enregistré en cours de résolution est une faute d'orthographe pour un domaine enregistré célèbre ;
• que VeriSign abusait de son contrôle technique sur les domaines .com et .net et se plaçait de facto en position de monopole ;
• que VeriSign violait ses contrats d'exploitation des domaines .com et .net ;
• que le service Site Finder présumait que tout le trafic DNS provenait de clients Web, ignorant le fait que le DNS est utilisé par d'autres applications telles que les imprimantes en réseau, les logiciels FTP et les applications de communication dédiées ; si les utilisateurs de ces applications entraient accidentellement un mauvais nom d'hôte, au lieu d'une erreur host not found, ils recevraient une erreur délai d'attente de requête, donnant l'impression que le serveur existait, mais ne répondait pas ; aucune déclaration de VeriSign à l'appui de Site Finder n'a même reconnu l'existence de trafic DNS non causé par des clients Web, bien qu'ils aient publié des détails d'implémentation qui mentionnaient ce trafic[2] ;
• que Site Finder contenait des conditions générales d'utilisation qui stipulaient que l'utilisateur acceptait les conditions en utilisant le service ; cependant, comme une erreur d'adresse provoquait automatiquement l'utilisation du service, les utilisateurs ne pouvaient pas refuser d'accepter les conditions.

D'autres opposants étaient préoccupés par le fait que le service Site Finder était entièrement écrit en anglais et n'était donc pas accessible aux non-anglophones.

Le Internet Architecture Board a rédigé un document détaillant de nombreux arguments techniques contre les registry-level wildcards[3]. Ces arguments ont été utilisés par l'ICANN dans le cadre de ses actions sur ce dossier.

Un certain nombre de solutions de contournement ont été développées pour désactiver localement les effets de Site Finder sur une base de réseau. Plus particulièrement, l'Internet Systems Consortium a développé une version du logiciel DNS BIND qui pouvait être configuré par les fournisseurs de services Internet pour filtrer les wildcard DNS de certains domaines. Ce logiciel a été déployé par un certain nombre de fournisseurs de services Internet.

Le 4 octobre 2003, à la suite d'une communication musclée de l'ICANN, VeriSign a désactivé Site Finder. Cependant, VeriSign a fait des déclarations publiques suggérant qu'il pourrait changer cette décision à l'avenir. Le 27 février 2004, VeriSign a déposé une poursuite contre l'ICANN, affirmant que l'ICANN avait outrepassé ses pouvoirs. La poursuite concernait non seulement Site Finder, mais aussi le controversé Wait Listing Service de VeriSign. La demande a été rejetée en août 2004. Des parties de la poursuite se sont poursuivies et ont abouti à un règlement entre VeriSign et l'ICANN le 1^er mars 2006, qui comprenait « un nouvel accord de registre relatif au fonctionnement du registre .com »[4].

Le 9 juillet 2004, le Security and Stability Advisory Committee (Comité consultatif sur la sécurité et la stabilité) de l'ICANN a rendu les conclusions de son enquête sur le service Site Finder. Le comité a proposé que le service ne devrait pas être déployé avant que l'ICANN et / ou les communautés d'ingénieurs appropriées aient eu l'opportunité d'examiner l'implémentation proposée, et que les registres de noms de domaine qui fournissaient un tel service devaient les interrompre.

• (en) « VeriSign's Site Finder Implementation document (PDF) »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}
• (en) VeriSign's announcement to NANOG of their wildcard DNS changes
• (en) ICANN Advisory Concerning Demand to Remove VeriSign's Wildcard of 3 October 2003
• (en) Slashdot discussion regarding Site Finder
• (en) Internet Software Consortium announcement of "delegation-only" feature that can be used to igno
• re gTLD wildcards
• (en) Washington Post (27.02.2004): Suit Challenges Powers of Key Internet Authority
• (en) Findings of ICANN SSAC on Site Finder service (PDF)