Résumé

  • Dans une future phase de gouvernance pleinement habilitée, la fonction Security Incident Reporting pourrait suspendre l'activité d'un RSO lorsque, dans un cas extrême, son non-respect des règles menace sensiblement le Root Server System. Cette phase n'est pas aujourd'hui établie par les documents publics examinés.
  • La révocation relève d'une autre fonction, Designation and Removal : mesures correctives, recommandation au Council, décision finale et retrait ordonné des sources DNS décrites dans RSSAC030. Le modèle ne dit pas si une suspension touche ces sources, si un recours la met en pause ni comment le statut est rétabli.
  • Avant Milestone 12, le Council devrait adopter un relevé versionné de suspension et de retour. Sa partie publique porterait l'autorité, la portée, l'horloge, le recours et l'issue ; les éléments susceptibles d'aider un attaquant resteraient dans une annexe protégée.

Le mot le plus lourd du rapport

Le rapport final du RSS Governance Working Group compte 86 pages, trois phases et treize jalons. Il décrit des communautés participantes, un Council, un Secretariat et cinq fonctions. Au milieu de cette architecture apparaît une mesure qui n'est ni une recommandation ni un rapport : suspendre les opérations d'un Root Server Operator.

La future fonction SIR pourrait enquêter, demander des données, imposer des améliorations de sécurité, faire respecter les politiques et ordonner des mesures correctives. Dans les cas extrêmes où un manquement ferait peser une menace importante sur le système racine, elle pourrait aller jusqu'à la suspension.

L'hypothèse n'est pas absurde. Une gouvernance de sécurité qui observe un danger sans pouvoir le contenir serait incomplète. Le DNS racine n'est pas un laboratoire où l'on peut attendre la fin d'une longue procédure pendant qu'un risque se propage.

Mais le rapport ne précise pas ce que l'ordre suspend. S'agit-il du statut de l'organisation dans la structure de gouvernance ? De l'exécution d'une obligation déterminée ? D'un ensemble d'instances ? De la fourniture du service attaché à un identifiant de racine ? Ou d'une modification dans les sources qui rendent l'opérateur visible au DNS mondial ?

Surtout, le document ne nomme pas le rétablissement. Il décrit l'enquête, la correction, le recours et, par une autre voie, la révocation. Il ne crée pas l'état par lequel un opérateur corrigé, innocenté ou revenu à un niveau de risque acceptable retrouve formellement sa position.

L'absence n'est pas une accusation contre un opérateur. Elle n'établit pas non plus que le pouvoir existe déjà. C'est un travail de conception à terminer avant que l'architecture ne soit habilitée.

Une autorité différée par construction

Le calendrier du modèle empêche de lire la suspension comme un pouvoir actuel d'ICANN, du RSSAC ou d'IANA.

La phase d'Initiation forme le Council et le Secretariat. Son autorité reste volontairement limitée. La phase d'Establishment doit ensuite préciser les fonctions, adopter leurs chartes, créer les politiques de sécurité, définir l'évaluation des opérateurs, organiser la désignation et la révocation, financer le système et bâtir les mécanismes de responsabilité.

La marche vers la phase de Governance suppose davantage qu'une simple annonce. Les onze premiers jalons doivent être achevés et documentés dans une évaluation publique. Les politiques centrales doivent être ratifiées. Une consultation publique doit précéder le vote. Les communautés participantes sont consultées en vue d'un consensus, puis le Council constate formellement que la structure est prête. Ce n'est qu'alors que Milestone 12 lui confère une pleine autorité de gouvernance.

Dans la trace publique examinée, le groupe de travail a approuvé son rapport le 18 février 2026 et l'a transmis deux jours plus tard à la communauté, au Board d'ICANN, à l'IETF/IAB, au RSSAC et aux opérateurs. La présidente du Board a remercié le groupe et évoqué « la suite du chemin ». Sa lettre ne constitue pas une décision d'adoption. Le plan financier anticipait lui aussi une adoption et subordonnait l'implémentation à des décisions ultérieures du Board.

La formule correcte est donc : le modèle prévoit un pouvoir futur. Dire qu'un organe actuel peut déjà l'exercer confondrait une proposition, sa réception et son exécution.

SIR contient le danger ; DNR tranche le statut

La séparation entre SIR et DNR est l'un des choix les plus utiles du modèle.

SIR part d'un incident de sécurité. Il définit le signalement, les examens après incident, les contrôles, les audits, l'atténuation des vulnérabilités et l'information du public. Son horloge est celle de l'urgence. Dans la phase de Governance, il peut ordonner une action rapide et suspendre lorsque le seuil extrême est atteint.

DNR part d'une inquiétude de performance ou d'un manquement constaté par la fonction de suivi et d'évaluation. Il examine, organise une correction dans des délais fixés et ne recommande la révocation qu'après des possibilités suffisantes de remédier au problème. Le Council doit approuver l'issue. DNR coordonne ensuite l'arrêt ordonné et le retrait des sources DNS, en relation avec IANA.

Ces deux logiques ne doivent pas être fusionnées. La protection immédiate du système ne peut attendre le jugement définitif sur la qualité d'un opérateur. Inversement, une mesure d'urgence ne devrait pas produire silencieusement les effets d'une révocation qui exige une procédure plus protectrice.

La difficulté est la garde du dossier entre les fonctions. Une suspension peut conduire à une correction réussie, à un recours, à une mesure plus étroite ou à une saisine de DNR. Le modèle ne désigne pas l'acte qui transfère le dossier, l'autorité qui maintient l'état intermédiaire ni la décision qui clôt la suspension.

Une correction terminée est une preuve technique. Le rétablissement est une décision autorisée. Sans liaison obligatoire, l'une peut exister sans l'autre.

Trois sources DNS donnent un sens concret au statut

RSSAC030 tient sur une page, mais il empêche de traiter « suspension » comme une simple étiquette institutionnelle.

Le document identifie trois sources maintenues par l'opérateur des fonctions IANA : le fichier root hints, la zone racine et la zone root-servers.net. Elles relient les noms du service racine aux adresses IPv4 et IPv6 contrôlées par les opérateurs. L'inclusion dans ces sources identifie l'organisation comme RSO et permet aux clients de découvrir le service selon le dispositif commun.

Le modèle renvoie expressément à RSSAC030 pour la révocation par DNR. Il ne le fait pas pour la suspension par SIR.

Il faut donc séparer au moins trois couches : le statut de gouvernance, l'état opérationnel et l'état des sources racine. Une décision peut suspendre un statut sans effacer une entrée. Une réponse à incident peut isoler une composante sans révoquer l'organisation. Une modification du fichier root hints ou des deux zones est une action technique identifiable, qui doit avoir sa propre autorité et sa propre voie de retour.

Cette précision protège les deux côtés. Elle évite qu'un opérateur présente une sanction administrative comme la disparition du service. Elle évite aussi que la structure produise un retrait de fait en utilisant un mot provisoire là où DNR et le Council sont normalement requis.

Un recours ne décide pas à lui seul de l'état en production

Le modèle prévoit que les RSO et d'autres parties peuvent contester les décisions de SIR devant le Council. DNR dispose également d'une voie de recours directe. Les recommandations de révocation sont soumises à l'approbation finale du Council. Des examens par les pairs et des évaluations externes sont envisagés.

Ces garanties comptent, mais elles ne répondent pas à l'exploitation.

Le dépôt d'un recours suspend-il la mesure ? Le Council peut-il accorder une suspension provisoire de la sanction ? L'opérateur continue-t-il une partie du service pendant l'examen ? Une décision favorable rétablit-elle automatiquement la totalité du statut antérieur ? Après une vulnérabilité, faut-il un contrôle technique distinct avant le retour ? Qui certifie la fin de la correction ?

Le temps du recours et celui du réseau ne sont pas identiques. Un examen contradictoire peut prendre plusieurs jours. La limitation d'un danger peut exiger quelques minutes. Le système a donc besoin de trois réponses différentes : une mesure immédiate, un état provisoire explicite et un jugement ultérieur sur la continuation ou le retour.

Si ces réponses sont consignées dans des fichiers séparés, l'état réel dépendra de conversations et de mémoire. C'est exactement le moment où une infrastructure critique a besoin d'une source commune.

La transparence peut rester compatible avec le secret de sécurité

RSSAC062 fixe une limite utile. Ce texte de 2025 concerne les incidents qui affectent matériellement la disponibilité, l'intégrité ou la confidentialité du système racine. Il précise que le signalement ne doit pas gêner l'atténuation : la résolution de l'incident vient en premier.

Un rapport détaillé peut contenir des éléments marqués selon le Traffic Light Protocol. Les informations susceptibles d'aider une attaque future doivent être exclues. Les canaux de dépôt doivent être authentifiés et confidentiels. En parallèle, la structure devrait publier rapidement une version publique TLP:Clear.

La future procédure peut donc publier l'exercice du pouvoir sans révéler l'exploit. Le public a besoin de connaître la base, le seuil général, la portée, la durée et l'issue. Il n'a pas besoin d'une clé privée, d'une topologie interne, de journaux bruts ni du détail d'une vulnérabilité non corrigée.

Une annexe protégée conserve les faits opérationnels. La fiche publique indique son dépositaire, son niveau d'accès et, lorsque c'est sûr, son empreinte d'intégrité. La confidentialité protège le système ; elle ne doit pas rendre invisible la durée d'une mesure coercitive.

La meilleure défense du modèle oblige à compléter la boucle

Le modèle peut répondre qu'il s'agit précisément d'un Functional Model. Les politiques détaillées seront écrites pendant l'Establishment Phase par des personnes capables de concilier exploitation, confidentialité, autonomie des opérateurs et coordination avec IANA. Cette souplesse est rationnelle.

Il peut aussi rappeler la force de ses garde-fous : seuil extrême, menace significative, fonctions séparées, correction avant révocation, recours devant le Council, rapports annuels, examen par les pairs, audit externe et consultation avant l'habilitation.

La redondance du système racine rend en outre plausible l'isolement temporaire d'un composant pour protéger l'ensemble. Une gouvernance qui n'aurait jamais cette option pourrait être trop lente face à un danger réel.

Ces arguments ne justifient pas un état sans fin. Ils indiquent où le terminer. Milestone 7 doit produire les règles de sécurité et d'escalade. Milestone 8 doit construire la révocation, la procédure régulière et les recours. Milestone 10 couvre la responsabilité et les procédures complémentaires. L'évaluation des onze jalons devrait refuser le passage si ces trois blocs ne forment pas une chaîne continue.

La primauté du code en fonctionnement formulée par Heng Lu apporte ici un test de portée : une autorité institutionnelle ne devrait pas déclarer davantage que l'effet technique minimal qu'elle peut définir et vérifier. « Suspendu » doit donc pointer vers un changement concret et réversible, pas vers une puissance symbolique laissée à l'interprétation.

Sa distinction sur la continuité évite l'erreur inverse. La priorité est la continuité du service, de la chaîne de sécurité et des utilisateurs, non la préservation automatique de chaque pouvoir du gouvernant ou de chaque statut de l'opérateur. Une suspension peut protéger l'ensemble. Une voie de retour claire protège cet objectif contre sa propre inertie.

Créer un relevé de suspension et de retour

Avant Milestone 12, le Council devrait adopter une fiche versionnée commune à SIR, au Council, à DNR et, le cas échéant, à IANA et au Root Zone Maintainer. Elle s'ouvre au moment de la mesure avec un minimum public, puis s'enrichit à mesure que le risque se stabilise. Elle ne retarde jamais l'atténuation.

La partie publique devrait indiquer :

  • l'identifiant stable du dossier et le RSO concerné ;
  • l'autorité, la version de politique et le rôle institutionnel responsable ;
  • la classe non sensible du déclencheur et le recours éventuel à l'urgence ;
  • la portée exacte sur le statut, le service, l'infrastructure et les sources racine ;
  • l'heure d'effet, la durée initiale maximale et le prochain examen obligatoire ;
  • les mesures prises pour préserver la continuité collective ;
  • l'état public des corrections ;
  • la garde et la classification des preuves protégées ;
  • le recours, la demande de sursis et la décision sur ce sursis ;
  • l'autorité et les critères du retour ;
  • le test de préparation technique et l'examen indépendant ou par les pairs ;
  • chaque prolongation et son motif ;
  • l'issue datée : retour, restriction plus étroite, mesure remplacée ou transfert à DNR ;
  • toute action distincte sur les sources par IANA ou le RZM, avec sa base et son état de réversion.

Le vocabulaire doit empêcher les équivalences abusives. Recours déposé ne veut pas dire sursis accordé. Correction accomplie ne veut pas dire retour autorisé. Transmis à DNR ne veut pas dire révocation approuvée. Révocation approuvée ne veut pas dire sources déjà modifiées.

La fiche doit aussi écrire les états négatifs : aucune action sur les sources, aucun recours, aucune décision de retour. Un champ vide ne permet pas de savoir si l'événement n'a pas eu lieu, s'il est retardé ou si personne n'en est responsable.

Ce relevé ne donne pas un veto à l'opérateur. Il ne livre pas les éléments d'attaque. Il n'accorde pas au public la conduite d'un incident. Il impose seulement qu'un pouvoir temporaire ait une autorité, une portée, une horloge et une sortie.

Limites de la preuve

Les sources examinées ne montrent ni adoption formelle du modèle, ni passage à la phase de Governance, ni suspension d'un opérateur selon ce cadre. Elles n'établissent aucun manquement d'un RSO actuel et ne donnent pas aux organes existants le pouvoir décrit pour l'avenir.

L'absence du mot rétablissement n'empêche pas la future charte de créer une procédure. Elle montre que cette procédure doit être vérifiée avant l'habilitation. Le sens exact de la suspension reste ouvert ; le présent Article ne prétend donc pas qu'elle modifie nécessairement le fichier root hints, la zone racine ou root-servers.net.

Enfin, la transparence proposée porte sur l'état institutionnel. Les faits susceptibles d'aider un attaquant ou de révéler des données opérationnelles légitimement protégées peuvent et doivent rester confidentiels.

Sources

  1. ICANN — The Root Server System Governance Structure, 18 février 2026
  2. ICANN — Governance Principles for the Root Server System
  3. Brad Verd — remise du rapport final du GWG
  4. Tripti Sinha — réponse de la présidente du Board d'ICANN
  5. ICANN Public Comment — Functional Model for Root Server System Governance
  6. RSSAC030 — Statement on Entries in DNS Root Sources
  7. RSSAC058 — Success Criteria for the RSS Governance Structure
  8. RSSAC062 — Security Incident Reporting
  9. RSSAC055 — Principles Guiding the Operation of the Public Root Server System
  10. ICANN — projet de plan opérationnel et financier FY2027–2031
  11. Heng Lu — Running-Code Primacy
  12. Heng Lu — The Registry Continuity Fallacy
  13. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile