Résumé

  • L’essor des nouveaux gTLD, les portefeuilles comptant parfois des centaines de domaines et les mises à jour DNSSEC fréquentes ont transformé la charge que le RZMS devait absorber.
  • La refonte a ajouté des seuils d’approbation par type de demande, des requêtes simultanées, une API et des contrôles techniques indépendants ; les gestionnaires de TLD restent responsables de règles adaptées et de la continuité des comptes.

Analyse

Davantage de demandes ont changé la nature du travail

L’ancien RZMS n’était pas un échec. Il automatisait déjà plusieurs étapes, améliorait la précision du traitement et réduisait les délais, tout en offrant aux gestionnaires de TLD un portail libre-service pour les opérations courantes. La pression venait d’une charge différente : le programme des nouveaux gTLD avait accru le nombre de délégations, certaines organisations géraient des portefeuilles de plusieurs centaines de domaines, et les changements de clés DNSSEC devenaient plus fréquents.

En mai 2022, Davies a indiqué que l’équipe Ingénierie et technologies de l’information d’ICANN avait décidé de reconstruire la plateforme selon une architecture modulaire. Une petite équipe pluridisciplinaire a mené le projet pendant plusieurs années. Son récit expose le raisonnement et les choix de fonctionnement ; il ne prétend pas qu’il a développé seul le système. L’enjeu était de laisser le service absorber de nouveaux types de demandes sans enfermer chaque évolution dans un flux fixe.

Pourquoi remplacer une plateforme qui fonctionnait

Le système précédent avait déjà automatisé plusieurs étapes, amélioré la précision du traitement et donné aux gestionnaires un portail en libre-service. Mais l’environnement avait changé : davantage de TLD, des portefeuilles pouvant compter des centaines de domaines, et des mises à jour fréquentes de clés de signature DNSSEC. Selon Davies, l’équipe d’ingénierie et des technologies de l’information d’ICANN a choisi une reconstruction modulaire, menée par une petite équipe transversale. Son billet décrit les décisions de conception ; il ne prétend pas qu’il a personnellement codé la plateforme.

L’élément important n’est pas le mot « nouveau », mais la manière dont le système répartit les pouvoirs. Le gestionnaire peut définir les personnes autorisées et le nombre de validations requis selon la demande. Le journal des versions de l’IANA indique que la première version a permis plus de deux approbateurs, des seuils différents et une API. L’API répond aux besoins des gestionnaires qui automatisent des opérations répétitives, mais elle reste soumise aux droits du compte.

La frontière des rôles compte aussi au moment de l’exécution. L’IANA décrit sa mission comme l’attribution des gestionnaires, l’enregistrement des données techniques de délégation et la publication d’un registre. La vue d’ensemble de la zone racine distingue le Root Zone Database, registre des TLD et de leurs informations, des données DNS de la zone racine diffusées dans un fichier séparé. Une autorisation dans RZMS peut faire avancer une demande ; elle n’efface ni l’examen du processus ni les étapes de mise en œuvre.

La sécurité dépend aussi du moment où l’on perd l’accès

L’authentification multifacteur n’a pas été imposée dès le lancement de 2022. Davies a expliqué ce report par une contrainte moins visible qu’une attaque : il fallait une solution utilisable partout dans le monde et par des clients qui pouvaient ne pas ouvrir leur compte pendant des années. Une procédure de sécurité qui rend impossible la récupération d’un compte utile peut devenir un risque opérationnel.

L’étude de processus publiée en juillet 2022 par un consortium mené par JAS Global Advisors a recueilli des avis plus nuancés qu’un simple appel à généraliser MFA. Dans son enquête, 82 % des répondants jugeaient suffisantes les mesures alors en place ; 18 % signalaient des faiblesses possibles, certains proposant MFA. Ces proportions décrivent les répondants de cette étude, pas l’ensemble des gestionnaires ni la situation actuelle. Le rapport abordait aussi le fait qu’à l’époque le processus de demande n’était pas réservé à une liste fixe de contacts.

Davies s’est appuyé sur ce contexte pour expliquer pourquoi MFA n’avait pas été ajouté d’emblée comme exigence générale.

Le calendrier a ensuite évolué. En janvier 2025, Davies a annoncé MFA et la vérification d’identité comme fonctions facultatives. Les règles actuelles de l’IANA, révisées en juillet 2026, exigent la vérification pour activer MFA ou utiliser l’API, mais pas pour les autres usages de RZMS. La vérification soutient aussi la récupération d’un compte. Un prestataire conserve les images de pièce d’identité et de selfie sept jours au plus ; l’IANA conserve le nom légal, la date de naissance et le résultat de la vérification tant que le compte est actif.

Ce détail interdit deux raccourcis : dire que MFA est obligatoire pour toute utilisation, ou dire qu’aucune donnée personnelle ne reste chez l’IANA. La politique associe une preuve d’identité plus forte à un mécanisme de récupération, mais elle fait aussi entrer des données personnelles dans la durée de vie du compte.

Le changement d’échelle déplace la responsabilité vers les gestionnaires

Les seuils configurables et les demandes simultanées rendent le service plus adaptable, mais le logiciel ne peut pas choisir une règle d’approbation adaptée à chaque organisation. Le gestionnaire de TLD doit tenir sa liste à jour, décider combien de personnes approuvent chaque type de demande et prévoir la récupération des comptes peu utilisés. Trop peu d’approbateurs crée un point de blocage ; trop en exiger peut retarder une opération courante.

L’API étend ce dispositif aux opérations programmatiques, sans contourner les autorisations du compte. L’environnement Operational Test and Evaluation de l’IANA permet d’éprouver une intégration avant la production. Les contrôles de conformité technique restent eux aussi distincts de l’autorisation : une configuration conforme ne valide pas à elle seule une demande, et une approbation ne remplace ni l’examen technique ni la mise en œuvre.

Cette limite compte parce que le RZMS n’est qu’une partie de la gestion de la zone racine. L’IANA désigne les gestionnaires de TLD, enregistre les données techniques de délégation et publie la Root Zone Database, distincte du fichier DNS de la zone racine. Le journal de juin 2026 indique la version 3.6.1. L’apport durable de la refonte est un flux de travail adaptable, pas la garantie que chaque organisation le configurera correctement. Sa performance dépend de la capacité des règles locales, de la récupération des comptes et des essais techniques à suivre le rythme de la charge.

Sources