Résumé

  • Dans le scénario d’expiration étudié par le groupe technique d’ICANN, le nom DNS est retiré de la résolution, mais son équivalent dans un autre système peut rester actif si le titulaire le souhaite et si les règles de ce système le permettent.
  • Cette séparation oblige un service à préciser qui commande chaque changement, quelles preuves montrent que les systèmes ont atteint l’état attendu et comment éviter une réattribution pendant qu’un ancien nom reste utilisable ailleurs.

Une expiration, plusieurs décisions

La fiche d’un nom affiche une date d’expiration. Elle ne raconte pas tout ce qui doit se produire à cette date. Imaginons que le titulaire laisse expirer exemple.tld dans le DNS tout en choisissant de conserver le nom identique dans un autre système. Ce cas figure dans le rapport provisoire du Technical Study Group (TSG); il ne décrit pas un incident constaté. Le nom DNS est retiré de la résolution mondiale. Le nom alternatif peut rester actif, si son propre système ne le fait pas expirer et si le titulaire souhaite le conserver.

Le scénario inverse n’est pas une suppression instantanée non plus. Si le nom alternatif ne doit pas être maintenu, le rapport décrit une désactivation dans tous les systèmes, puis la désallocation et la sortie du dispositif d’intégration. Ce n’est qu’ensuite que le nom redevient disponible. L’expiration devient ainsi une suite de décisions concernant la continuité, le contrôle et le moment où une autre personne peut obtenir la même chaîne.

Le principe « même chaîne, même contrôleur » est utile au premier regard. Il l’est moins lorsqu’il faut répondre à une question temporelle: qui contrôle le nom pendant qu’un renouvellement, un transfert ou un retrait est en cours? Un instantané peut montrer deux chaînes identiques. Il ne prouve ni qui a lancé le changement, ni si tous les systèmes l’ont accepté, ni si le contrôleur est resté le même pendant la transition.

Un rapport technique n’est pas une autorisation

ICANN a chargé le TSG d’examiner si un registre pourrait associer un gTLD du DNS mondial à la même chaîne dans un système de nommage alternatif, sans compromettre la sécurité et la stabilité du DNS. Le rapport du 10 août 2026 porte la mention de projet. Il n’approuve pas un service et ne consacre pas une architecture particulière. Il examine notamment un système d’enregistrement partagé, ou SRS, et des opérations réparties autour d’une source unique de vérité, la USoT.

La page de consultation d’ICANN rappelle que chaque opérateur de registre doit passer individuellement par la procédure RSEP. Le rapport du TSG doit éclairer les évaluations futures et des clauses contractuelles qui feront l’objet d’une consultation distincte. Les observations sur le projet ont fermé le 21 septembre; la page publique indique le 16 novembre 2026 comme date prévue pour le rapport.

Une étude commune peut éviter de répéter les mêmes analyses techniques. Elle ne démontre pas que deux registres ont la même architecture, qu’ils savent observer les mêmes données ou qu’ils disposent des mêmes moyens pour corriger une incohérence. C’est à la demande de service et aux clauses propres à chaque opérateur de transformer la règle générale en engagement vérifiable.

Là où l’état échappe au registre

Dans le modèle SRS, les changements des deux noms peuvent passer par un mécanisme contrôlé par le registre. Un objet unique associé à un titulaire unique rend la relation plus lisible. Mais le TSG précise qu’un SRS partagé ne suffit pas, à lui seul, à prouver l’identité du contrôleur. Il faut des données adaptées ou un lien technique et contractuel fiable.

Une architecture répartie peut laisser les informations dans plusieurs systèmes et faire appel à une USoT. Cette option évite de centraliser tous les dossiers; elle doit toutefois montrer comment les participants voient le même contrôleur et ce qui fait foi lorsqu’une mise à jour n’est pas encore terminée. Une source commune ne résout pas la question si personne ne sait quel état appliquer pendant une panne ou un retard.

Le changement de titulaire « interne » étudié dans le rapport donne une mesure concrète du problème. Si le registraire gère les coordonnées du titulaire dans ses propres outils, il peut effectuer le changement sans que le registre l’apprenne. L’intégration dépend alors du respect du contrat, sauf si le registre dispose d’un identifiant persistant ou d’une autre preuve. Si les deux noms sont des objets séparés rattachés à des contrôleurs différents, le rapport évoque une commande unique qui transfère les deux objets comme une solution possible.

Les événements ne sont pas interchangeables. Le TSG estime qu’une suspension doit s’appliquer simultanément aux systèmes intégrés. Il distingue certaines désactivations externes, par exemple liées à un abus ou à une ordonnance judiciaire, du clientHold demandé par un registraire, qui ne devrait pas désactiver automatiquement tous les noms associés. Une mise à jour technique qui effacerait ces distinctions transformerait une règle de gouvernance en état opaque.

Les commentaires demandent des preuves lisibles

Un commentaire d’Unregistry, publié sur le site d’ICANN, soutient la conclusion générale du groupe mais juge les attentes destinées aux utilisateurs moins développées que les contrôles côté registre. Il propose notamment de rendre visible l’état de l’intégration et de préciser la réponse en cas d’échec de synchronisation. C’est la position d’un participant, pas un constat consensuel.

Le ministère indien de l’Électronique et des Technologies de l’information demande des conditions mesurables avant l’approbation RSEP: états de transaction définis, maîtrise des opérations non résolues, mécanismes de repli, plan d’arrêt testé, précautions avant réattribution et essais de sécurité indépendants. Ces suggestions appartiennent à cette contribution; elles ne sont pas devenues des règles d’ICANN.

L’Intellectual Property Constituency relève que les questions de protection des droits restent ouvertes à un débat plus large. La frontière est essentielle. Une preuve technique peut établir que deux états sont coordonnés sans décider qui a droit au nom, si le recours contre une collision est suffisant ou à qui un utilisateur doit s’adresser.

Un examen individuel devrait donc demander: qui peut renouveler, transférer, suspendre ou supprimer le nom? Quelle règle autorise l’action? Quel accusé de réception vient de chaque système? Combien de temps un résultat partiel peut-il durer? Qu’est-ce qui empêche la réattribution DNS pendant que l’ancien nom reste actif ailleurs? Comment un titulaire conteste-t-il une incohérence?

Garder la trace de chaque transition

Le dossier utile n’est pas une copie de plus de la fiche d’enregistrement. C’est une trace de la transition: rôle qui l’a demandée, version de la règle appliquée, état précédent et état visé, systèmes concernés, identifiant de transaction, accusés de réception, ordre ou heure des événements, conduite à tenir en cas de reprise ou de blocage, notification et voie de réexamen. L’utilisateur n’a pas besoin de voir des données personnelles pour savoir si le nom intégré est actif, retiré, suspendu ou en cours de résolution. L’auditeur, lui, doit pouvoir vérifier pourquoi.

Cette trace est une recommandation éditoriale, non une exigence adoptée par le TSG. Elle répond à un problème de mandat: le registraire connaît le client, le registre contrôle la publication DNS et l’opérateur du système alternatif peut exécuter l’autre moitié du changement. Si le lien casse, le titulaire en supporte le coût pratique, alors même qu’il peut ne voir ni les journaux ni le contrat entre opérateurs.

Les règles RSEP et leurs notes de mise en œuvre prévoient déjà une description du service et de ses effets pour les utilisateurs externes. L’épreuve de la prochaine étape sera d’ajouter à la base technique du TSG des conditions que chaque service peut tester avant son lancement et que des tiers peuvent contrôler lorsque les circonstances changent. « Même chaîne, même contrôleur » décrit un invariant; la gouvernance commence quand le dossier explique comment il reste vrai à travers les transitions.

Sources