Résumé

  • Le groupe de travail de l’ICANN propose qu’un bureau d’enregistrement examine les domaines associés après avoir obtenu des éléments exploitables montrant qu’un nom qu’il gère sert à un abus DNS défini. Le projet exige une enquête, pas une sanction automatique de tous les noms reliés.
  • Quarante-deux contributions publiques ont donné lieu à 533 réponses classées, dont environ 85 % favorables parmi les treize propositions et recommandations. Ces réponses éclairent la suite du processus ; elles ne constituent ni une règle définitive ni un vote de l’ensemble des titulaires et internautes.

Sortir du traitement nom par nom

Le contrat d’accréditation des bureaux d’enregistrement impose déjà une action lorsqu’un bureau dispose d’éléments exploitables indiquant qu’un nom qu’il parraine est utilisé pour un abus DNS. Les mesures doivent être rapides et appropriées à la situation, en tenant compte du dommage et des effets collatéraux possibles. L’avis de conformité de l’ICANN de 2024 explique cette obligation ; l’amendement mondial au contrat définit l’abus DNS comme les logiciels malveillants, les botnets, l’hameçonnage, le pharming et les pourriels lorsqu’ils servent à diffuser l’une des autres formes visées.

Cette obligation actuelle concerne le nom pour lequel les éléments existent. Une campagne peut pourtant s’appuyer sur un portefeuille : un domaine est signalé, tandis que d’autres noms associés au même acteur ne sont pas examinés. Le rapport initial du groupe de travail GNSO du 18 août propose une vérification des domaines associés (ADC) pour combler cette lacune. Après avoir établi qu’un nom parrainé sert à un abus DNS, le bureau devrait examiner si des noms associés dans son propre portefeuille sont eux aussi utilisés à cette fin.

La différence entre vérifier et sanctionner est essentielle. Un lien indique au bureau où chercher ; il ne tranche pas ce que fait le nom suivant. Le texte demande une enquête raisonnable pour déterminer si les domaines associés servent à un abus. Il ne prévoit pas qu’un nom soit suspendu parce qu’il partage un compte, un titulaire déclaré, un serveur de noms ou un revendeur avec le nom déclencheur. Il n’impose pas non plus de recherche entre bureaux d’enregistrement ni de base centrale de tous les domaines d’un titulaire.

Il s’agit d’une proposition, et non d’une nouvelle obligation déjà applicable. La page de consultation de l’ICANN a été actualisée avec un rapport de synthèse du 9 octobre. Celui-ci indique que le groupe n’avait adopté aucune modification du texte préliminaire et devait commencer l’examen des commentaires à ICANN87, à Bali. Le groupe doit encore rédiger son rapport final ; le Conseil de la GNSO doit l’examiner ; puis le Conseil d’administration de l’ICANN devrait étudier son adoption avant qu’une politique consensuelle puisse entrer en vigueur. La présentation du processus de l’ICANN distingue ces étapes.

Un lien est une hypothèse à vérifier

Le projet ne fixe pas un test d’identité unique. Les critères proposés comprennent les données du titulaire ou du compte, des indices d’activité technique ou coordonnée, les habitudes d’enregistrement, les serveurs de noms et les informations raisonnablement accessibles au bureau. Le texte reconnaît que les indicateurs varient selon les cas et qu’aucun indice isolé ne prouve l’association dans toutes les situations. L’enquête doit rester pratique et proportionnée aux éléments et à l’ampleur apparente de l’abus.

Cette souplesse répond à une difficulté concrète. Certaines campagnes utilisent plusieurs noms de manière coordonnée ; d’autres peuvent y ressembler parce que des clients indépendants partagent un hébergeur, un service de confidentialité, un revendeur ou une infrastructure. Un attribut commun peut constituer une piste utile, mais il peut aussi être banal pour des usages légitimes. Deux domaines enregistrés depuis le même compte ne démontrent pas, à eux seuls, que les deux servent une activité malveillante.

Le déclencheur est plus exigeant qu’une accusation. La recommandation 1 s’appuie sur les éléments exploitables prévus par le contrat et exclut les domaines compromis du déclenchement d’une ADC. Le rapport distingue un nom enregistré à des fins abusives d’un nom légitime pris ou exploité ensuite à l’insu de son titulaire. Les indications autorisent des éléments récents, intermittents ou récurrents ; lorsqu’un comportement n’est pas observable en continu, le signalement devrait étayer le schéma allégué. L’objectif est d’éviter deux erreurs : ignorer une campagne crédible ou lancer une enquête étendue sur la base d’un signal spéculatif.

Les recommandations 2 à 4 maintiennent l’étape suivante au niveau de l’enquête. Le bureau examinerait les informations auxquelles il peut raisonnablement accéder dans son activité habituelle, notamment les données contractuelles, ses systèmes techniques et les signalements. Le projet n’exige pas que chaque catégorie de données soit vérifiée dans tous les cas, ni que le bureau produise des informations qu’il ne détient pas normalement. Il précise aussi qu’une vérification raisonnable ne doit pas devenir une revue systématique de tout le portefeuille.

Une recherche plus large peut se justifier lorsque les éléments suggèrent une campagne plus vaste ; son ampleur doit suivre la preuve, et non la précéder.

Cette séquence compte, car association et abus sont deux propositions distinctes. Le fait que deux domaines partagent un compte peut justifier de vérifier si le même acteur les contrôle. Il ne montre pas que le second nom est utilisé pour l’hameçonnage, un logiciel malveillant, le pharming, un botnet ou la diffusion de pourriels. La vérification ne s’achève que lorsque le bureau examine le nom associé au regard de la définition de l’abus, et pas lorsqu’il trouve un champ commun.

Le bureau reste responsable à travers la chaîne de revendeurs

La proposition situe le devoir dans le portefeuille des noms parrainés par le bureau. Elle autorise celui-ci à confier certaines étapes au revendeur, à partir des informations accessibles à ce dernier, mais laisse le bureau responsable de ses obligations contractuelles. Un acteur demeure donc identifiable pour le contrôle de conformité de l’ICANN, tandis que le travail peut être réalisé là où se trouvent les données utiles sur le client.

Le commentaire du Registrar Stakeholder Group soutient globalement le projet tout en demandant des précisions. Il estime que l’efficacité doit se mesurer à l’évolution des menaces d’abus DNS, et non au nombre de contrôles effectués, de noms suspendus ou de dossiers de conformité ouverts. Cette distinction est importante : l’activité d’un processus n’est pas son impact.

Le commentaire d’Openprovider soutient un socle fondé sur des éléments vérifiables mais expose une difficulté opérationnelle. Dans certains modèles de gros, le bureau détient les données d’enregistrement et techniques tandis que le revendeur détient la relation client, la structure des comptes ou d’autres informations. Le bureau peut donc répondre d’un processus dont les indices utiles se trouvent ailleurs. Openprovider interroge également la pertinence d’éléments anciens et le rôle de celui qui décide si un domaine a été compromis plutôt qu’enregistré à des fins malveillantes. Un taux d’approbation global ne répond pas à ces questions de mise en œuvre.

La règle de responsabilité ne fonctionne que si l’autorité et les capacités correspondent. Un bureau ne peut démontrer un examen proportionné si la politique attend silencieusement des données auxquelles il ne peut légalement ou contractuellement accéder. Mais il ne peut pas non plus effacer sa responsabilité en transférant le travail au revendeur. La règle finale devrait préciser les éléments minimaux que le bureau peut raisonnablement obtenir, les tâches qu’un revendeur peut réaliser et le point où une donnée manquante limite l’enquête sans constituer une preuve de culpabilité.

Les garanties doivent résister à l’épreuve de l’exécution

Le texte prévoit plusieurs protections : respect du droit applicable et des contrats, proportionnalité et minimisation des données, prudence face aux fausses associations par les services de confidentialité, les revendeurs ou les infrastructures partagées, et prise en compte de l’impact sur le titulaire. Il propose un examen au bout de deux ans afin d’évaluer la cohérence du socle, la possibilité de contrôler la conformité et la contribution des vérifications à l’identification et à la perturbation des campagnes.

Le projet prévoit également des traces ordinaires : le déclencheur, le moment où l’examen commence, les informations consultées, le nombre de noms associés trouvés, les mesures prises le cas échéant et les raisons du caractère proportionné de l’enquête. Aucun format unique n’est imposé et le bureau n’aurait pas à construire un vaste système de données inédit. Il devrait maintenir une description de son processus interne, accessible à l’ICANN sur demande. Ces contrôles forment une piste d’audit, mais sa qualité dépend de la séparation entre indice d’association et constat d’abus.

Cette séparation a des conséquences sur les services. Un nom peut servir au courrier électronique, à des comptes clients, à de l’information publique ou à d’autres activités légitimes même si une partie a été compromise ou détournée. L’avis de 2024 de l’ICANN avertit qu’une suspension peut interrompre des contenus légitimes et des services associés. L’ADC proposée ajoute une obligation d’enquête ; elle ne remplace pas la règle existante qui commande de choisir une mesure adaptée au nom concerné et au dommage collatéral possible.

Prendre une correspondance de portefeuille pour un motif suffisant de suspension transformerait le contrôle limité en sanction plus large que celle décrite dans le rapport.

La mesure des résultats reste la faiblesse à résoudre. Le projet prévoit un examen après deux ans et envisage des données agrégées issues du service conformité contractuelle de l’ICANN, de son bureau technique et des bureaux d’enregistrement. Il reconnaît aussi que les menaces évoluent et qu’il est difficile d’attribuer les variations générales des abus DNS à une seule règle. Le nombre de contrôles ou d’avis prouverait qu’un processus a été exécuté, mais pas que des campagnes ont été perturbées, que des associations erronées ont nui à des utilisateurs légitimes ou que les acteurs ont simplement changé de bureau et de tactique.

Ce que signifie — et ne signifie pas — le chiffre de 85 %

Le rapport de synthèse de l’ICANN recense 42 contributions. Quarante et une ont fourni des réponses classées sur huit recommandations et cinq indications, soit 533 réponses catégorisées. Environ 85 % soutenaient le texte ou son intention avec des modifications ; 3 % réclamaient un changement substantiel ; aucune réponse ne choisissait « ne pas soutenir / supprimer » ; et 12 % relevaient de la catégorie « autre ». Le soutien variait d’environ 78 à 90 % selon les propositions.

Ces chiffres ont leur importance. Ils montrent un large soutien parmi les personnes et organisations qui ont contribué et fournissent au groupe un dossier conséquent à examiner. Mais 533 correspond à des réponses portant sur des éléments individuels, et non à 533 personnes indépendantes ; le rapport précise lui-même que les catégories ne restituent pas toutes les nuances. Vingt-six contributions ajoutaient des observations hors du questionnaire structuré, et des personnes favorables ont soulevé des questions de périmètre, de garanties, de revendeurs, de documentation et de mesure.

Les commentaires nourrissent la décision ; ils ne sont pas la décision.

Cette distinction institutionnelle ne revient pas à écarter la participation. Le groupe GNSO peut élaborer une recommandation dans le cadre de son mandat. Les personnes qui commentent peuvent éprouver les hypothèses, rendre visibles des conséquences oubliées et proposer des formulations. Le Conseil et le Conseil d’administration interviennent ensuite dans le processus publié. Séparer la participation de l’autorisation attribue un rôle à chaque étape ; cela ne rend pas les contributions sans effet. Ici, le rapport indique explicitement qu’aucune modification n’avait encore été adoptée à la suite des commentaires.

La prochaine version devrait donc répondre aux questions que ces contributions mettent au jour. L’association repose-t-elle sur des indices pertinents pour la campagne ou sur un attribut partagé par commodité ? Chaque nom examiné fait-il l’objet d’une évaluation propre de l’abus ? Le bureau peut-il expliquer ce qu’il a consulté et pourquoi le périmètre était proportionné ? La délégation au revendeur donne-t-elle accès aux éléments utiles tout en maintenant une responsabilité claire ? L’examen ultérieur saura-t-il distinguer perturbation utile, volume d’activité et dommage collatéral ?

La meilleure idée du projet n’est pas « examiner chaque nom relié à un domaine signalé ». C’est une escalade limitée : des éléments exploitables concernant un nom parrainé peuvent justifier une enquête proportionnée sur les noms que ces éléments relient à la même activité, tandis que toute conclusion suivante requiert encore son propre soutien. Si la règle finale préserve cette limite, elle peut traiter les campagnes par portefeuille sans transformer un faible indice en culpabilité héritée.

Sinon, la souplesse conçue pour aider les bureaux à détecter ces campagnes rendra difficile de savoir, pour les titulaires, les autorités et l’ICANN, quand une piste est devenue un verdict.