Summary

  • Trois exercices EBERO lancés entre 2016 et 2017 ont enregistré des interruptions DNS simulées de 11 h 55 à 1 jour, 9 h 05. Le rétablissement le plus lent de l’annuaire RDDS a demandé 5 jours, 17 h 58; la fonction de dépôt sous séquestre a pris jusqu’à 8 jours, 3 h 21.
  • La recommandation SSR2 24.1 réclamait un exercice complet au moins chaque année, avec scénarios, données, étapes, échéances, cas d’exception et publication des résultats. En novembre 2022, le conseil d’ICANN l’a tenue pour pleinement mise en œuvre en invoquant les anciens exercices et les clauses contractuelles de préparation.
  • Le document de mise en œuvre de janvier 2023 et le rapport du deuxième trimestre 2026 ne donnent aucun résultat daté d’un exercice ultérieur dans leur exposé de 24.1. Une nouvelle série publique permettrait de voir si les délais et les problèmes repérés ont réellement changé.

Un sauvetage, cinq fonctions, plusieurs délais

Quand l’opérateur d’un domaine générique de premier niveau risque de ne plus assurer ses fonctions essentielles, ICANN peut déclencher le dispositif EBERO et confier temporairement l’arrière-plan technique à un fournisseur de secours. Il faut remettre le DNS en service, maintenir une zone correctement signée, assurer le système d’enregistrement partagé, servir les données d’enregistrement et poursuivre les dépôts de sauvegarde. Aucune case unique « service rétabli » ne raconte ce passage de relais. Les données peuvent encore attendre leur nouvel opérateur lorsque la résolution DNS fonctionne déjà.

En 2017, ICANN a fait mieux qu’une déclaration de confiance. Sa présentation publique des exercices donne des dates et des durées. Trois domaines en cours de résiliation ont servi aux tests commencés le 26 janvier 2016, le 25 avril 2017 et le 21 septembre 2017. Ils n’avaient pas de titulaires ordinaires: un seul nom était enregistré par le registre dans chacun. Les opérateurs ont consenti aux essais avant le retrait de ces domaines de la zone racine. Trois fournisseurs EBERO différents sont intervenus. Le seuil de panne de départ était simulé; les durées publiées ne sont donc pas des coupures subies par une clientèle.

Les écarts sont le sujet de l’histoire. Le DNS et DNSSEC étaient rétablis sur les serveurs de secours après 3 h 46, 9 h 11 et 3 h 59. Le changement dans la zone racine n’arrivait qu’après 8 h 22, 1 jour et 5 h 05, puis 7 h 55. ICANN a calculé une indisponibilité DNS totale simulée de 12 h 22, 1 jour et 9 h 05, puis 11 h 55, en écartant les effets du cache. Allumer un serveur de remplacement et faire pointer la racine vers lui sont deux opérations distinctes; cette distance se mesure en heures.

Pour le système d’enregistrement, l’écart grandit. Le dépôt de données a été mis à disposition d’ICANN après 1 jour et 7 h 31, 2 jours et 19 h 36, puis 1 jour et 14 h 22. Le service d’enregistrement partagé est revenu après 1 jour et 23 h 03, 2 jours et 22 h 14, puis 4 jours et 18 h 29. Le RDDS a suivi plus tard encore: sa durée totale d’indisponibilité selon la mesure de l’exercice atteint 5 jours et 17 h 58 dans le troisième essai. La fonction de séquestre clôt les trois exercices après 5 jours et 21 h 53, 8 jours et 2 h 34, puis 8 jours et 3 h 21.

Un tableau vert sur le DNS seul aurait dissimulé presque toute cette séquence.

ICANN a aussi publié le nombre de problèmes découverts: 44, 37 et 20, soit 101 observations additionnées sur trois essais, sans preuve que chacune désigne un défaut unique. La diapositive suivante indique que certains avaient été ou étaient en cours de correction. Elle ne fournit pas, à cet endroit, un registre daté des corrections puis de leur nouveau test. Ce sont pourtant ces problèmes, et non la simple existence des exercices, qui rendent leur répétition intéressante.

La clause annuelle et le tampon « terminé »

En janvier 2021, l’équipe de révision SSR2 a demandé un contrôle plus exigeant. Sa recommandation 24.1 voulait tester de bout en bout l’ensemble du dispositif EBERO à intervalles prédéfinis, au moins annuellement. Le plan devait annoncer les jeux de données, les états successifs et les échéances, faire travailler les parties concernées sur les chemins d’exception et publier les résultats. L’idée n’était pas de prouver éternellement la capacité avec un essai ancien. Elle était de donner à la communauté un relevé renouvelé de la chaîne de secours.

Le conseil d’ICANN a approuvé la recommandation comme pleinement mise en œuvre en novembre 2022. Il a retenu les essais antérieurs et les accords avec les prestataires, qui prévoient la possibilité d’exercices de préparation annuels. Les responsables de la mise en œuvre avaient clarifié qu’il n’était pas question de tester sur des domaines actifs porteurs d’inscriptions. Cette limite protège des tiers et n’empêche pas de mesurer un exercice sur des domaines en fin de vie, comme ICANN l’avait fait. Ce qu’elle ne fournit pas, c’est le relevé d’un nouvel essai.

Le document de mise en œuvre publié le 6 janvier 2023 détaille son raisonnement. Il cite les trois tests historiques et les clauses des contrats, puis donne comme date finale la décision du conseil en 2022. Sa ligne « mise en œuvre achevée » porte « n/a » et ses jalons « n/a ». Aucun exercice postérieur daté avec résultats et suivi des défauts n’y figure. Le rapport d’ICANN pour le deuxième trimestre 2026 reprend la possibilité contractuelle de réaliser un exercice chaque année et maintient 24.1 dans la colonne des recommandations terminées. Son passage sur 24.1 ne donne pas non plus une nouvelle série de mesures.

La page actuelle du programme EBERO présente les accords des fournisseurs et le manuel de transition. Elle énumère les cinq fonctions à protéger et désigne ICANN comme responsable du déclenchement. Sa liste de documents publics ne constitue pas une série annuelle de comptes rendus d’essais. Un contrat peut fixer un rendez-vous; il ne peut pas dire combien de temps le prochain dépôt mettra à arriver ni si le problème numéro 44 a disparu.

Le conseil a donc fermé une recommandation portant sur une pratique répétée à partir de preuves d’une pratique passée et d’une capacité juridique future. ICANN a réellement testé son système; c’est pour cela que le manque d’une comparaison récente compte. Les chiffres de 2017 créent un point de départ exigeant. Il suffirait de publier pour chaque nouveau test sa date, le fournisseur, les données utilisées, les branches d’exception, l’heure du retour de chaque fonction et la résolution des problèmes antérieurs. Un tel relevé montrerait une amélioration, une stagnation ou un nouveau défaut.

Le mot « terminé », lui, n’indique que la décision de classer le dossier.

Sources