fr

Vers la prochaine génération du système de gestion de la zone racine

19 mai 2022
Par Kim DaviesKim Davies

Il y a un peu plus de 10 ans, la Société pour l'attribution des noms de domaine et des numéros sur Internet (ICANN) a contribué au lancement du système de gestion de la zone racine (RZMS), une suite de composants interdépendants qui a modernisé la gestion de la zone racine du système de noms de domaine (DNS). Parmi les améliorations qu'il a apportées, citons l'automatisation de nombreuses étapes du traitement, ce qui a entraîné une amélioration de la précision et une réduction des délais de traitement. Une autre amélioration a été le lancement d'un portail en libre-service qui permet aux gestionnaires de domaines de premier niveau (TLD) d'effectuer eux-mêmes des tâches courantes.

Les origines du RZMS remontent au début des années 2000. Ce système a bien répondu à son objectif, mais au fil du temps, nos besoins se sont accrus et certaines conceptions intégrées au système original ont limité notre capacité à faire évoluer la plateforme. Le lancement du programme des nouveaux domaines génériques de premier niveau (gTLD) a considérablement augmenté le nombre de TLD dans la zone racine, ce qui a également modifié les modes de travail de certains de nos clients. Certaines organisations assurent désormais la gestion de centaines de TLD et ont besoin de nouveaux outils qui les aident à simplifier la gestion de leurs portefeuilles. Nous voyons aussi apparaître de nouveaux types de demandes qui n'existaient pas auparavant, comme les mises à jour fréquentes des clés de signature pour les TLD.

L’équipe de l'organisation ICANN en charge de l'ingénierie et des technologies de l'information, qui développe le RZMS, a pris la décision de reconstruire toute la plateforme depuis ses fondations, afin de créer un système modulaire moderne qui serait plus facile à adapter aux besoins futurs. Une petite équipe de projet interfonctionnelle a passé les dernières années à construire ce système, qui est maintenant sur le point d'être achevé et lancé.

En plus de reproduire toutes les fonctionnalités existantes sur une architecture moderne, nous avons apporté quelques changements clés au système dans cette version initiale, qui apporteront des améliorations significatives pour nos clients. Les plus importantes sont :

  • Un nouveau modèle de contact qui identifie les personnes autorisées à interagir avec l'Autorité chargée de la gestion de l’adressage sur Internet (IANA) et ce, séparément des contacts administratifs et techniques qui sont publiés pour la communauté générale. En faisant la distinction entre ces fonctions, nous offrons une grande flexibilité aux gestionnaires de TLD pour qu’ils configurent leurs rôles et responsabilités en fonction de leurs besoins organisationnels. Les gestionnaires de TLD peuvent également personnaliser le nombre d'approbations nécessaires pour chaque type de demande de changement, ainsi que les représentants autorisés à approuver les différents types de demandes.
  • Le nouveau modèle offre également des avantages importants en matière de sécurité en permettant aux individus d'avoir leur propre compte. Nous exigerons aux utilisateurs de notre système de se connecter avec leurs identifiants pour approuver les demandes, plutôt que notre pratique précédente qui consistait parfois à autoriser les approbations en cliquant simplement sur un lien dans un courriel.
  • Le test de conformité de l'infrastructure TLD, dit aussi processus de « contrôle technique », a été séparé dans un système indépendant. Le fait de séparer les contrôles techniques du RZMS nous permettra de les faire évoluer (par exemple en ajoutant de nouveaux tests pour identifier d'autres configurations TLD problématiques), ainsi que d'en optimiser la performance, afin que les tests puissent s'exécuter plus rapidement.
  • Une interface préliminaire de programmation d'applications permettra aux gestionnaires de TLD de construire ou d'utiliser des outils pour communiquer par programmation avec notre système. Les fonctionnalités initiales se concentrent sur des mises à jour en masse, afin que les organisations qui gèrent de nombreux TLD puissent effectuer des opérations sur plusieurs TLD de manière efficace.

L'une des décisions que nous avons prises pour le nouveau modèle de contact est de limiter les comptes aux personnes. Cela signifie que chaque personne utilisant le système aura son propre nom d'utilisateur et son propre mot de passe, plutôt qu'un mot de passe partagé par plusieurs personnes. Chaque gestionnaire de TLD pourra créer autant de comptes dont il aura besoin pour ses représentants, et les registres publics (comme ceux qui apparaissent dans les registres WHOIS) pourront toujours être liés à des postes plutôt qu'à une seule personne.

Fonctionnalités futures

Nous estimons que ces fonctionnalités répondent aux améliorations les plus urgentes demandées par nos clients, mais nous savons qu'il y a encore beaucoup à faire. Nous avons dû faire des choix pour déterminer les nouvelles fonctions sur lesquelles nous devions nous concentrer pour terminer et lancer cette itération de la plateforme, et celles que nous devions reporter à une date ultérieure dans notre feuille de route de développement.

L'authentification multifactorielle fait partie des fonctionnalités reportées qui présentent un intérêt particulier. Nous savons que certains de nos clients s’y intéressent de plus en plus, mais nous devons nous assurer que nous la mettons en œuvre de manière prudente et réfléchie de sorte à renforcer la sécurité de la zone racine. L'authentification multifactorielle implique la prise en compte de nombreuses considérations importantes, notamment le fait de s'assurer qu'elle fonctionne pour des personnes dans n'importe quel pays du monde et pour des clients susceptibles de ne pas nous contacter pendant de nombreuses années.

Le projet d'étude sur le processus de mise à jour de la zone racine est l'une des raisons pour lesquelles nous avons décidé de reporter ce travail et de l'examiner plus attentivement. Dans cette étude, l’expert indépendant ne recommande pas d'ajouter l'authentification multifactorielle traditionnelle dans la zone racine et note que certaines protections uniques que nous avons dans notre processus fournissent déjà des protections que l'authentification multifactorielle est censée ajouter. Nous pensons qu'il peut être utile d'ajouter des options d'authentification multifactorielle à l'avenir et nous comptons sur des dialogues futurs pour cibler correctement notre travail dans ce domaine.

Cette étude a identifié un certain nombre d'autres aspects du processus de mise à jour de la zone racine où des améliorations pourraient être apportées. Nous étudierons le rapport final de plus près afin de mieux éclairer nos travaux futurs. Par exemple, les experts chargés de l’étude ont souvent reçu des commentaires suggérant d'améliorer la façon dont les contrôles techniques sont effectués afin que la découverte de problèmes mineurs ne retarde pas inutilement le traitement. Nous avons exploré des moyens de classer les problèmes en fonction de leur gravité et de permettre aux gestionnaires de TLD d'écarter eux-mêmes des problèmes potentiels lorsque ceux-ci sont susceptibles d'avoir un impact mineur, ce qui devrait améliorer considérablement la situation.

Prochaines étapes

Dans le cadre des travaux préparatoires à ce nouveau système, l'IANA s'adressera directement à un grand nombre de ses clients pour leur parler de l'impact de ce système. L'une des plus grandes préparations consiste à identifier comment basculer de l'ancien modèle de contact vers le nouveau sans inconvénient pour personne.

Pour les TLD qui disposent de nombreux comptes différents, nous chercherons des moyens de les regrouper sous un seul nom d'utilisateur et un seul mot de passe pour chaque personne. Nous ferons de même lorsqu’un travail de consolidation sera nécessaire dans les cas où plusieurs adresses électroniques sont associées à une même personne.

Une autre amélioration du nouveau modèle de contact consistera à ajuster le format des champs d'adresse postale dans notre base de données. Nous prévoyons de contacter les TLD pour qu'ils clarifient leurs adresses.

En plus de cette discussion autour du déploiement de la nouvelle version auprès de nos clients, nous sommes impatients de recueillir vos commentaires sur le fonctionnement du système et d'intégrer régulièrement ces retours dans les futures versions.

Authors

Kim Davies

Kim Davies

VP, IANA Services and President, PTI
Read biographyRead biography