Résumé

  • Le rapport initial du PDP 1 prévoit qu’un bureau d’enregistrement effectue un contrôle des domaines associés lorsqu’il dispose d’éléments exploitables montrant qu’un nom non compromis sert à un abus DNS. Le texte est en consultation, pas encore adopté.
  • La huitième recommandation exige une conformité démontrable, mais laisse facultatifs les six éléments de preuve cités et interdit de prescrire un format. Un schéma minimal, confidentiel au niveau du dossier et agrégé au niveau public, préserverait la souplesse sans sacrifier la comparaison.

L’enquête commence par un nom, mais la politique veut empêcher qu’elle s’y arrête artificiellement.

Lorsqu’un bureau d’enregistrement reçoit des éléments exploitables établissant qu’un domaine a été enregistré pour une campagne d’hameçonnage, le contrat actuel lui impose déjà de traiter ce cas. Le rapport initial publié par le groupe de travail de la GNSO ajoute une bifurcation : si le texte devient un jour une politique de consensus, le bureau devra aussi examiner les autres noms raisonnablement associés au même compte, au même titulaire ou à la même activité coordonnée.

Ce contrôle, appelé Associated Domain Check ou ADC, ne serait ni une fouille mondiale ni une présomption automatique de culpabilité. Il resterait limité au portefeuille du même bureau d’enregistrement. Un hébergement partagé, un service de confidentialité ou un revendeur commun ne suffirait pas à établir que plusieurs noms sont dirigés par le même acteur malveillant.

Le déclencheur est lui-même borné. La première recommandation exige des éléments exploitables concernant les formes d’abus DNS définies dans le Registrar Accreditation Agreement. Elle exclut les domaines compromis : un site créé à des fins légitimes puis détourné à l’insu de son titulaire ne déclenche pas, par ce seul fait, la même obligation de recherche autour du compte.

Les recommandations suivantes laissent au bureau le choix d’une enquête raisonnable. Il utilise ce qui lui est normalement accessible : données de compte, informations du titulaire, motifs de nommage, serveurs de noms, séquences d’enregistrement, analyse interne ou signaux fournis par un tiers. Il n’est pas tenu de produire des données qu’il ne détient pas légalement. Un revendeur peut effectuer certaines étapes, mais la responsabilité contractuelle demeure chez le bureau accrédité.

Cette marge n’est pas un défaut à effacer. Une règle identique pour tous pourrait encourager la collecte inutile de données personnelles ou multiplier les faux rapprochements. Le délai reste donc « prompt » selon la gravité, l’ampleur, la complexité et le risque de dommage collatéral, sans nombre universel d’heures.

La vraie fragilité se trouve ailleurs : dans la manière de conserver la preuve de cette discrétion.

Un contrôle peut être vérifiable sans être comparable

La recommandation préliminaire 8 dit que chaque bureau doit pouvoir démontrer sa conformité au moyen des documents qu’il conserve dans son activité ordinaire. Elle énumère six éléments qui peuvent suffire : le déclencheur et son heure ; la réalisation et la date du contrôle ; les informations examinées ; l’existence et le nombre de domaines associés ; l’action prise, s’il y en a une ; enfin le caractère raisonnable et proportionné de la procédure.

Mais ces éléments restent formulés comme des possibilités. Le texte ajoute que la politique ne doit pas prescrire de format documentaire. Chaque bureau doit décrire son processus interne et le remettre à l’ICANN si celle-ci le demande.

Il serait faux d’en conclure qu’aucun audit n’est possible. Un contrôleur peut lire un dossier interne, demander des précisions et juger un cas. Le projet veut précisément éviter un nouveau système lourd de conservation et une accumulation de données sur les titulaires.

Le problème apparaît lorsque plusieurs dossiers doivent produire une mesure commune. Une heure de déclenchement peut désigner la réception du signal chez un bureau et sa validation par un analyste chez un autre. Une case vide peut signifier zéro domaine associé, donnée inaccessible, contrôle interrompu ou résultat non consigné. Une décision de suspension peut écraser le constat antérieur d’association, alors que l’enquête et la mesure de mitigation sont deux actes distincts.

Or la recommandation 7 prévoit une évaluation deux ans après la mise en œuvre. Le futur Implementation Review Team devra définir des données agrégées et une ligne de base. Le rapport reconnaît avec raison que le volume global d’abus ne prouvera pas à lui seul l’effet causal de la politique. Encore faut-il que les états internes aient le même sens avant de les additionner.

Une grammaire commune, pas un algorithme commun

La solution la plus étroite consiste à normaliser la preuve de la transition et non la méthode d’enquête.

Un reçu de dossier protégé peut utiliser un identifiant pseudonyme et conserver la version de la politique, la classe et l’heure du déclencheur, l’éventuelle exclusion d’un domaine compromis, l’ouverture et la clôture, la frontière entre bureau et revendeur, les catégories de signaux examinées ou indisponibles, le nombre de noms évalués, les résultats d’association, la décision de mitigation ou de non-action, les protections de confidentialité, l’empreinte de l’ensemble probatoire, le rôle responsable et l’historique de révision ou de correction.

Cette fiche ne doit pas publier les noms de domaine, l’identité d’un titulaire ou d’un rapporteur, ni les seuils techniques du bureau. Elle n’impose pas la pondération des signaux. Elle permet seulement de distinguer les états : signal reçu, contrôle ouvert, périmètre établi, résultat rendu, action séparée, correction conservée.

Le niveau public peut alors rester très mince. Des statistiques agrégées indiqueraient combien de déclencheurs valides ont ouvert un ADC, combien de contrôles ont abouti à chaque classe de résultat, combien ont rencontré une donnée légalement indisponible, et combien ont été corrigés. Les petites cellules seraient masquées. Aucun classement des bureaux ne devrait être publié sans dénominateur ni explication de la composition des cas.

Le dossier protégé sert à ICANN Contractual Compliance. L’agrégat sert à l’évaluation de la politique. Aucun des deux ne doit devenir un fichier public d’accusations ou une base transversale de surveillance des titulaires.

Le rapport de 2026 ne modifie encore aucun contrat

Les amendements mondiaux entrés en vigueur en avril 2024 exigent déjà une action rapide et appropriée contre un abus DNS étayé. L’avis de l’ICANN permet à Contractual Compliance de demander une liste détaillée de pièces dans une enquête. Les tableaux mensuels publient déjà des agrégats sur les plaintes, notifications et motifs de résolution.

Ces statistiques ne mesurent pas les ADC. Le tableau de juin 2026 précède la future obligation et ne peut servir de preuve de son efficacité. Il montre seulement qu’une surface publique d’agrégation existe déjà.

La consultation actuelle ferme le 28 septembre. Ensuite viennent le rapport final, l’examen par le Conseil de la GNSO, un éventuel vote du Conseil d’administration puis la mise en œuvre. Les désignations de consensus du président du groupe de travail décrivent l’état de ce groupe ; elles ne sont ni une adoption ni une garantie de résultat.

Ce calendrier rend le choix documentaire urgent sans rendre la politique acquise. Définir une interface minimale aujourd’hui coûte peu. Tenter d’harmoniser, deux ans plus tard, des journaux qui n’ont jamais distingué les mêmes états risque de laisser des trous impossibles à combler.

La décentralisation exige des raccords précis

Un système distribué n’a pas besoin d’un centre qui choisit chaque outil. Il a besoin de raccords compréhensibles. Ici, le raccord relie le déclencheur à l’enquête, l’enquête au résultat, le résultat à la mitigation et la correction à la décision antérieure.

Tout le reste peut rester local : équipes, logiciels, critères licites, seuils internes et traitement des preuves. La politique peut ainsi imposer une vérification sans imposer une machine unique. Elle peut protéger la proportionnalité sans renoncer à l’attribution. Ce qui manque n’est pas une base gigantesque, mais un petit langage portable pour dire exactement ce qui s’est passé.

Sources

  1. Consultation publique de l’ICANN
  2. Annonce de l’ICANN
  3. Rapport initial du DNSAM PDP 1, 18 août 2026
  4. Page du projet DNS Abuse Mitigation PDP 1
  5. Charte du DNS Abuse Mitigation PDP 1
  6. Page des amendements mondiaux de 2024
  7. Avis de l’ICANN sur les obligations relatives aux abus DNS
  8. Tableau de conformité sur les abus DNS, juin 2026
  9. Programme de l’ICANN contre les abus DNS
  10. Présentation du processus d’élaboration des politiques de la GNSO
  11. Procédures actuelles du Conseil de la GNSO