ICANN a autorisé la sortie de .NAME. Environ 22 000 noms étaient encore à bord.

Résumé

• La demande RSEP 2026013 déposée par Verisign le 15 avril 2026 prévoit de cesser les nouveaux enregistrements de troisième niveau sous .NAME, puis de résilier et supprimer les noms existants. ICANN l’a approuvée le 7 mai et a autorisé son déploiement par lettre le 28 juillet. Cette lettre rapporte l’estimation de Verisign d’environ 22 000 enregistrements, dont la majorité serait inutilisée.
• ICANN n’a relevé aucun problème significatif de sécurité ou de stabilité du DNS, ni de concurrence, dans les limites de la procédure RSEP. Son personnel a expliqué que l’effet sur chaque titulaire, bien que connu, ne fait pas partie des critères. Un comité a recommandé le rejet d’un premier recours; ICANN a ensuite joint six demandes pour un examen commun. Les documents publics examinés ne donnent ni date définitive d’arrêt du service ni preuve que les noms ont déjà été effacés.

Une case du formulaire face à une autre

La demande originelle de Verisign explique pourquoi l’opérateur veut partir : usage en baisse, soutien limité des bureaux d’enregistrement, efficacité accrue pour l’exploitation de .NAME. La description ne cache pas le mécanisme. Après l’arrêt, aucun nouveau nom de troisième niveau ne sera accepté et les noms existants seront résiliés puis supprimés. Un lecteur peut suivre l’effet jusqu’à la ligne de registre.

Quelques pages plus loin, à la question de l’effet sur le cycle de vie des noms de domaine, la réponse est « aucun ». Une inscription que son titulaire pouvait renouveler doit pourtant s’arrêter avant sa prochaine décision de renouvellement. Verisign emploie peut-être « cycle de vie » au sens technique des états de suppression; son dossier ne pose pas cette définition à côté de la réponse. Il laisse cohabiter l’absence d’effet dans une case et la destruction de la classe d’enregistrements dans une autre. Cette contradiction documentaire mérite plus qu’un sourire devant un formulaire mal rempli.

La sortie contient une horloge. Verisign promet d’avertir les bureaux d’enregistrement au moins 90 jours avant la fin du service et de leur envoyer un rappel au moins 30 jours auparavant. Elle leur promet aussi une assistance. Elle dit avoir consulté oralement un groupe choisi de bureaux représentant la majorité des utilisateurs du service. Aucun d’eux n’aurait signalé de problème de sécurité, de stabilité ou de concurrence. Ces consultations apportent la perspective des intermédiaires commerciaux; le dossier ne décrit pas une consultation directe des titulaires de noms déjà enregistrés.

La différence entre arrêter les nouvelles ventes et fermer les anciens comptes est décisive. Un nom comme prénom.nom.name appartient à une architecture de troisième niveau qui peut avoir duré des années. Le titulaire peut l’avoir mis dans une adresse électronique, un compte, un logiciel ou un document. Fermer la porte aux futurs clients ne rompt rien de tout cela. Mettre fin aux enregistrements existants peut le faire, à des degrés que les statistiques d’usage agrégées ne mesurent pas.

Un examen calibré pour le réseau, pas pour chaque nom

La lettre d’ICANN du 28 juillet fixe la chronologie. ICANN a approuvé la demande le 7 mai et l’a affichée le lendemain. Son examen a conclu que le projet ne soulevait pas de problème significatif pour la sécurité ou la stabilité du DNS, ni pour la concurrence, selon les critères RSEP. Le renouvellement du contrat .NAME étant en cours, ICANN a envoyé une lettre d’autorisation plutôt que de modifier immédiatement le contrat. Verisign est ainsi libre de supprimer le service selon sa demande.

La même lettre reprend le chiffre d’environ 22 000 enregistrements. Elle attribue à Verisign l’affirmation que la majorité est inutilisée. C’est une estimation de l’opérateur, pas un recensement indépendant de chaque usage. Une majorité inactive ne dit rien des besoins de la minorité encore active. On peut effacer beaucoup de lignes inutiles et une seule ligne dont dépend un mécanisme de récupération de compte. Le document officiel ne fournit ni inventaire vérifié de ces dépendances ni bilan de migrations accomplies.

ICANN n’a pas découvert ce nombre après coup. La recommandation du comité des mécanismes de responsabilité, le BAMC, précise que les échanges préparatoires avec Verisign portaient aussi sur ces quelque 22 000 noms. Elle conclut que le personnel a examiné les renseignements pertinents et recommande de rejeter la demande de réexamen 26-2. L’enjeu n’est donc pas de raconter une institution trompée par un chiffre caché. L’institution connaissait la conséquence, mais son test officiel n’était pas construit pour juger ce qu’elle ferait aux titulaires pris individuellement.

Les minutes du BAMC du 24 août sont plus nettes encore. Le personnel y explique que l’évaluation de sécurité et de stabilité concerne le DNS dans son ensemble, pas chaque enregistrement. L’effet sur les titulaires était compris, mais n’entre pas dans les critères d’acceptation d’une demande RSEP. Le personnel dit également que cette procédure ne prévoit pas de voie formelle pour les commentaires de tiers. Verisign avait parlé avec certains bureaux d’enregistrement; les personnes dont les noms allaient disparaître ne possédaient pas de siège défini dans ce contrôle.

La lettre de juillet précise où ICANN s’arrête. Son analyse RSEP est bornée par le texte de la politique et ne couvre pas les autres effets possibles de la fin d’un service. Une note renvoie la relation avec les titulaires aux bureaux d’enregistrement. L’opérateur annonce aux bureaux; les bureaux avertissent leurs clients; ICANN a jugé la demande recevable dans son périmètre. Chacun peut produire une attestation sur sa portion de chaîne. Il reste à réunir ces attestations en un calendrier qu’un titulaire puisse utiliser.

Six recours pour une sortie autorisée

La première demande de réexamen, 26-2, contestait les autorisations relatives aux noms de troisième niveau et à une prestation distincte de transfert de courriels sous .NAME. Cette seconde prestation est le sujet de RSEP 2026014; sa disparition peut se cumuler avec celle d’un nom, mais les deux dossiers ne sont pas interchangeables. Le BAMC a estimé en août que la première demande ne démontrait pas un défaut de procédure ou une dépendance à une fausse information justifiant le réexamen. Des remèdes demandés, comme une consultation publique ou la conservation des inscriptions jusqu’à leur échéance payée, débordaient selon lui la voie de réexamen ou relevaient des contrats entre bureaux et titulaires.

Une autre demande, déposée par Patrik Fältström, décrit la situation d’un titulaire qui utilise un nom de troisième niveau depuis plus de vingt-cinq ans. Son propos sépare nettement l’arrêt des nouvelles inscriptions de l’extinction des anciennes. Il soulève aussi une hypothèse de sécurité : si le nom de deuxième niveau correspondant devenait plus tard enregistrable par un autre, pourrait-il recréer le même troisième niveau sous un nouveau contrôle? C’est un risque soulevé par le requérant, pas un détournement constaté. Il demande que le sort des inscriptions existantes soit examiné avant leur disparition.

La notification d’ICANN du 14 octobre a joint les demandes 26-2, 26-5, 26-6, 26-7, 26-9 et 26-10. Le BAMC puis le Conseil les examineront ensemble. D’autres demandes recevables et déposées dans les délais pourraient être ajoutées. La recommandation d’août n’était donc pas la décision finale sur cet ensemble. Elle constitue une étape dans une procédure qui s’est élargie.

La table officielle RSEP affiche bien « approuvé » pour 2026013. Elle n’est pas un journal de suppression. La demande date d’avril, l’approbation de mai, l’autorisation de juillet; il faut encore la notification et l’exécution. Les pièces publiques vérifiées ici n’établissent pas une date finale d’arrêt ni le nombre de noms déjà supprimés.

L’intermédiaire qui doit faire arriver la nouvelle

Le choix des destinataires du préavis produit une responsabilité concrète. Un bureau peut compter les inscriptions qu’il gère et transmettre un message. Il ne connaît pas nécessairement tous les usages d’un nom ancien dans les logiciels, les messages, les clés de récupération et les habitudes de son titulaire. Ce dernier peut savoir ce qu’il utilise aujourd’hui, mais ignorer toutes les traces laissées depuis vingt ans. Une fermeture qui passe du registre au bureau puis au titulaire doit transporter davantage qu’une date abstraite.

Le texte de Verisign dit que les clauses du contrat qui prévoient les noms de troisième niveau doivent rester en place jusqu’à la fin de tous ces enregistrements. ICANN annonce que la suppression du service sera ensuite reflétée dans le contrat renouvelé. Entre la lettre qui permet d’agir et ce futur texte contractuel, une fenêtre demeure. On pourrait y inscrire la règle de renouvellement transitoire, la preuve des notifications, l’état final des noms et la protection contre la reprise éventuelle d’un nom identique sous un autre contrôle.

Sans ces éléments, le contrat peut enregistrer la fermeture après que ses conséquences sont devenues irréversibles.