Résumé

  • ICANN recueille, du 10 août au 21 septembre 2026, les avis sur le premier rapport de son Technical Study Group consacré au rapprochement entre des gTLD du DNS mondial et des systèmes de nommage alternatifs.
  • Le modèle repose sur un couple « chaîne + titulaire » : partout, le nom doit rester identique et relever de la même partie, grâce à un registre d’inscription partagé ou à une source de vérité logiquement unifiée malgré une architecture distribuée.
  • Le texte ne cautionne pas l’intégration. Chaque opérateur devra encore obtenir un accord par la procédure RSEP ou par le processus applicable au cycle 2026, puis des clauses contractuelles feront l’objet d’une nouvelle consultation.
  • Une question de politique publique reste hors du mandat technique : les noms déjà présents dans un système alternatif pourraient devoir être réservés côté DNS, donc devenir indisponibles avant même toute activation dans le DNS.

Une question préalable, pas un lancement

L’annonce du 11 août peut facilement être lue comme l’ouverture d’un pont entre le DNS et les noms fondés sur une chaîne de blocs. Le dossier est beaucoup plus étroit. Depuis 2022, des opérateurs de registres existants et de possibles candidats au prochain cycle de gTLD demandent à ICANN s’ils pourront associer leur chaîne DNS à la même chaîne dans un ou plusieurs systèmes alternatifs. ICANN a donc réuni un groupe technique pour traiter une classe précise de service de registre.

Le périmètre ne couvre ni chaque identifiant de portefeuille, ni chaque pseudonyme d’application, ni toutes les racines alternatives. Il porte sur un opérateur de gTLD qui commande la même chaîne dans le DNS mondial et dans les systèmes qu’il souhaite intégrer. Le groupe doit déterminer si cette configuration peut respecter les exigences de sécurité et de stabilité de la Registry Services Evaluation Policy, la RSEP.

Le calendrier confirme le caractère provisoire de l’exercice. La consultation a commencé le 10 août et se termine le 21 septembre à 23 h 59 UTC. Le document du 10 août est marqué « DRAFT » et présenté comme un rapport initial. Le groupe juge qu’une intégration du même nom par le même titulaire ne devrait pas créer de risque significatif au sens de la RSEP si les contrôles opérationnels sont effectifs. Il précise aussitôt qu’il ne recommande ni ce mécanisme plutôt qu’un autre, ni même le principe d’une intégration.

Cette réserve est essentielle. Elle empêche de transformer « peut être exploité en sécurité » en « doit être accepté » ou « est déjà approuvé ».

La contrainte centrale porte sur le contrôle

Le rapport nomme son modèle « string+controller integration ». Pour que deux systèmes soient intégrés, la chaîne doit être la même et le titulaire doit rester le même. À défaut, le nom doit être réservé exclusivement à ce titulaire dans les systèmes où il n’est pas activé. Si cette cohérence ne peut être garantie, le système n’entre pas dans la catégorie étudiée.

La règle s’applique aussi aux noms placés sous le TLD. Une inscription, un transfert, une suspension ou une désactivation ne doit jamais permettre à deux parties incompatibles de commander ce que l’utilisateur peut percevoir comme le même nom. Pour les noms internationalisés, les variantes et les Label Generation Rules doivent être traitées avant l’intégration : des règles de normalisation différentes rendraient la promesse d’identité trompeuse.

Deux architectures sont envisagées. La première fait du Shared Registration System du registre la commande d’inscription commune. Les systèmes alternatifs deviennent en quelque sorte des extensions du registre classique. Ce choix conserve une chaîne connue entre registre, bureaux d’enregistrement et titulaires, mais il suppose d’étendre EPP pour agir sur le nouvel état et RDAP pour le rendre consultable.

La seconde architecture peut distribuer les données et les opérations. Elle n’exige pas une base centrale unique ; elle exige une source de vérité unifiée au sens logique. Aucune composante ne doit pouvoir modifier le nom de manière à rompre l’identité de la chaîne ou du titulaire. Un portefeuille, un identifiant durable ou une preuve cryptographique peut attester le contrôle. Un règlement distribué peut aussi ralentir une mise à jour et imposer un état d’attente au registre DNS.

Le candidat doit surtout montrer que les participants ne peuvent pas casser la cohérence sans instruction ou accord du titulaire. Une chaîne de blocs ne vaut donc pas décentralisation de la responsabilité. Même si plusieurs prestataires exploitent les composants, le rapport maintient l’opérateur de registre comme entité juridique responsable. L’infrastructure peut être distribuée ; la responsabilité contractuelle ne doit pas s’évaporer entre protocoles et sous-traitants.

Le premier conflit de droits apparaît déjà

Le modèle technique a une conséquence qui dépasse le schéma d’architecture. Lorsqu’un système alternatif possède déjà des noms au moment de son rapprochement avec un TLD, les chaînes correspondantes doivent être inscrites dans l’ensemble intégré. Côté DNS, cela signifie au minimum les réserver, même si elles ne seront jamais publiées dans une zone DNS.

Le rapport reconnaît que cette exigence technique peut avoir des effets de politique et les laisse expressément hors de son champ. C’est ici que la coordination devient potentiellement une règle d’allocation. La réservation évite qu’un titulaire DNS et un titulaire alternatif incompatibles reçoivent le même signe dans un service présenté comme intégré. Mais elle retire aussi un nom du marché DNS. Inversement, une inscription DNS peut contraindre l’usage du système alternatif.

Il faut alors répondre à des questions que la preuve technique ne tranche pas : quelle antériorité compte, comment notifier une partie, qui paie une réservation défensive, comment corriger une preuve erronée, et quelle voie de recours existe lorsque les deux systèmes revendiquent des histoires différentes ?

La mission d’ICANN donne une limite utile. Ses statuts lui permettent de coordonner ce qui est raisonnablement nécessaire à l’ouverture, à l’interopérabilité, à la résilience, à la sécurité ou à la stabilité du DNS. Le rapport rappelle lui-même qu’ICANN n’est pas responsable de tout système de nommage relié à Internet et que son intervention ne doit pas dépasser le point où le système alternatif affecte le DNS mondial.

Le principe de coordination minimale défendu par Lu Heng clarifie la séparation. L’unicité, la preuve du contrôle, l’audit de l’état et la continuité peuvent légitimement former une couche commune. La priorité commerciale entre revendications anciennes, l’usage acceptable et la valeur d’un nom ne deviennent pas des compétences communes par simple effet de l’intégration. Une incompatibilité technique peut justifier de ne pas créer deux contrôleurs. Les conséquences plus larges exigent un décideur identifié, l’expression des parties touchées, une motivation et un recours.

Chaque autorisation restera individuelle et contractuelle

La consultation n’est pas une licence générale. ICANN indique que chaque opérateur devra déposer sa propre demande RSEP, ou suivre la voie du nouveau cycle de gTLD. La RSEP examine les risques pour la sécurité, la stabilité et la concurrence. Le rapport commun doit éviter de refaire à grands frais la même analyse de base pour chaque dossier ; il ne supprime pas l’examen du montage particulier.

Les obligations finales ne sont pas encore écrites. ICANN prépare en parallèle des amendements aux accords de registre. Un projet final du rapport et les clauses proposées doivent faire l’objet d’une consultation ultérieure. La charte prévoit une seconde période de commentaires, puis une publication finale en janvier 2027. Il reste donc impossible de connaître précisément les preuves exigées, la fréquence des contrôles, les délais de correction, les sanctions ou les recours.

La sortie mérite autant d’attention que l’entrée. Le rapport recommande un plan obligatoire d’arrêt de l’intégration. Il observe aussi que ce service ne semble pas appartenir aux fonctions critiques maintenues par le dispositif Emergency Back-End Registry Operator. En cas de défaillance grave d’un registre, le DNS pourrait continuer sous EBERO tandis que la composante alternative s’arrêterait.

Pour un service vendu comme « un seul nom dans plusieurs systèmes », cette rupture est une question de gouvernance centrale. Il faut annoncer quelle copie survit, comment les données devenues obsolètes sont traitées, ce que conserve le titulaire et comment les utilisateurs sont informés. L’identité du nom est une promesse permanente, pas une caractéristique du jour de lancement.

Ce que les consultations doivent encore séparer

La première consultation peut tester les mécanismes : preuve du titulaire, synchronisation, délais de règlement, noms internationalisés, visibilité RDAP, transfert, suspension, EBERO et arrêt. Une contribution utile devrait montrer une trajectoire de panne concrète, plutôt que se contenter d’être favorable ou hostile aux noms fondés sur une chaîne de blocs.

La consultation contractuelle devra distinguer quatre actes. Le groupe technique conclut qu’un dessin peut être sûr. ICANN accepte ou refuse un service particulier. Le contrat définit la surveillance et l’exécution. Enfin, une règle de politique décide du sort des noms ou des titulaires affectés. Ces actes n’ont ni le même auteur, ni le même fondement, ni le même recours.

Le rapport initial a le mérite de remplacer un slogan de « pont entre deux mondes » par une contrainte vérifiable, une entité responsable et un problème d’arrêt. Il gardera sa légitimité s’il conserve cette modestie. La faisabilité technique peut ouvrir une évaluation. Elle ne peut pas attribuer, à elle seule, le droit de contrôler le seuil.

Sources