Résumé

  • Le groupe d’étude technique de l’ICANN examine un cas circonscrit : une même chaîne dans le DNS mondial et dans un ou plusieurs systèmes alternatifs, sous le contrôle d’une même partie et coordonnée par l’opérateur de registre.
  • Son rapport initial recommande d’imposer un plan d’arrêt et constate que l’intégration ne paraît pas appartenir aux cinq fonctions critiques reprises par un opérateur EBERO.
  • La consultation publique se termine le 21 septembre 2026. Le texte reste un projet : il ne constitue ni politique adoptée, ni service approuvé, ni constat d’échec.

Un nom peut sembler identique dans deux univers techniques et pourtant ne plus appartenir à la même personne. C’est cette possibilité qui transforme une question d’architecture en question de gouvernance.

Le groupe d’étude technique de l’ICANN n’a pas tenté de régler tout le paysage des systèmes de nommage alternatifs. Son rapport du 10 août isole un montage précis. La chaîne utilisée comme gTLD dans le DNS mondial doit être la même dans l’autre système, selon des règles explicites, et une même partie doit en garder le contrôle. L’opérateur du registre coordonne l’ensemble, même s’il sous-traite des briques techniques.

Le document estime que ce montage peut éviter des problèmes importants de sécurité ou de stabilité à condition de respecter des contrôles opérationnels stricts. Il n’endosse pas pour autant le principe de l’intégration, n’écarte pas d’autres mécanismes et ne promet pas l’absence de risque.

L’arrêt change des droits, pas seulement des serveurs

Le modèle distingue plusieurs états : nom disponible, enrôlé, attribué, réservé, actif, désactivé, suspendu ou neutralisé. Ces mots empêchent de réduire l’opération à un interrupteur. Arrêter les réponses d’un service n’indique pas si le nom alternatif demeure attribué, s’il reste réservé au titulaire actuel, s’il redevient disponible ou si un ancien contrôleur conserve encore un moyen d’action.

La cohérence doit donc porter simultanément sur la chaîne, l’état et le contrôleur. Lorsqu’un nom est attribué dans un système, son équivalent ne peut rester libre ailleurs au bénéfice d’une autre partie. Quand le titulaire change dans le DNS, la synchronisation doit empêcher que l’identité intégrée reste aux mains du précédent titulaire.

Le projet de l’IETF consacré aux intégrations de noms de domaine décrit le même risque sous un autre angle. Expiration, transfert, changement de DNSSEC ou perte d’un élément de validation peuvent désynchroniser les systèmes. Une vérification correcte à l’entrée ne suffit pas pour toute la durée de vie. Ce projet reste un travail en cours et non une règle de l’ICANN, mais son analyse explique pourquoi la sortie mérite un contrôle propre.

Le filet EBERO s’arrête avant l’intégration

L’ICANN active un Emergency Back-end Registry Operator lorsqu’un registre risque de ne plus maintenir cinq fonctions critiques. Il s’agit de la résolution DNS, du Shared Registration System, du service de données d’enregistrement, du dépôt sous séquestre et du maintien d’une zone correctement signée avec DNSSEC.

Le rapport du groupe considère que l’intégration à un système alternatif se situe probablement hors de cette liste. Elle ne devrait donc pas survivre à une reprise par EBERO. Ce constat ne critique pas EBERO : il trace son mandat. Il interdit surtout de vendre une continuité générique du registre comme si elle couvrait automatiquement chaque service ajouté autour du DNS.

La réponse proposée par le rapport est de définir les capacités offertes et la manière de les désactiver si le montage cesse d’être viable. Tant qu’il n’existe pas un corpus solide d’expérience opérationnelle, le plan d’arrêt devrait être obligatoire dans l’évaluation du service de registre.

Cette obligation constitue une bonne porte d’entrée. Mais un plan peut dépendre d’un prestataire indisponible pendant la crise, oublier un état intermédiaire, demander une dernière action à un titulaire qui a déjà quitté le service ou ne jamais avoir été répété en conditions réalistes. La présence du document ne dit pas si la sortie fonctionne.

Le RSEP ne doit pas prêter son autorité au résultat

L’intégration étudiée entrerait dans le Registry Services Evaluation Policy. Ce processus permet à un opérateur de registre d’ajouter, modifier ou retirer un service, tandis que l’ICANN examine d’éventuels enjeux significatifs de sécurité, de stabilité et de concurrence.

Le rapport ajoute une limite utile : on ne peut diminuer ses exigences techniques minimales au motif que leur coût fragilise le modèle économique. Une version affaiblie constituerait un autre service et devrait recevoir sa propre évaluation. La même honnêteté doit valoir pour l’arrêt. Un essai incomplet ne devient pas réussi parce que le mot « arrêt » a été redéfini après coup.

La consultation en cours ne ferme aucune de ces décisions. La première période de commentaires se termine le 21 septembre. La charte prévoit ensuite une seconde version et une nouvelle consultation à l’automne, puis un rapport final en janvier 2027. Ce calendrier exprime une intention, pas l’accomplissement de ces étapes.

Aucune source examinée ne montre qu’un registre précis exploite déjà ce montage, qu’un incident s’est produit, qu’EBERO a dû gérer une telle intégration ou que deux contrôleurs se sont effectivement séparés. La question est justement préventive : quel témoin faudra-t-il conserver avant que la mémoire et les journaux deviennent indispensables ?

Sources