Résumé

  • Le 3 mai 2012, AFRINIC a commencé à servir exactement neuf zones inverses signées — six IPv4 et trois IPv6 — tout en laissant volontairement ouverte la liaison de confiance par les enregistrements DS dans les zones parentes.
  • La séparation des étapes constituait une mesure prudente de limitation du risque : elle permettait de tester le transfert, les réponses DNS ordinaires et les réponses DNSSEC avant l’activation de la chaîne complète, avec un mécanisme de retour à l’état non signé.
  • Cette prudence ne dispense pas d’une preuve publique de l’état de fonctionnement. Au contraire, elle rend nécessaires une matrice datée des tests, des observations par serveur et par zone, le statut du retour arrière et la clôture documentée des anomalies.
  • AFRINIC accomplissait ici une fonction de tenue technique et de coordination. L’utilité de cette fonction ne lui conférait aucun pouvoir souverain ou réglementaire ; son autorité pratique restait celle d’un opérateur privé dont les affirmations devaient correspondre à un service vérifiable.

Le geste du 3 mai, sans raccourci

Le changement intervenu le jeudi 3 mai 2012 peut être décrit avec une précision inhabituelle. AFRINIC avait annoncé la veille que la phase d’essai et la première phase de son déploiement DNSSEC étaient terminées. La deuxième phase devait alors commencer : les serveurs faisant autorité distribueraient des zones inverses signées plutôt que leurs versions non signées. Le périmètre annoncé comptait neuf zones déléguées par l’IANA. Six concernaient IPv4 — 41.in-addr.arpa, 196.in-addr.arpa, 197.in-addr.arpa, 102.in-addr.arpa, 105.in-addr.arpa et 154.in-addr.arpa — et trois concernaient IPv6 — 0.c.2.ip6.arpa, 3.4.1.0.0.2.ip6.arpa et 2.4.1.0.0.2.ip6.arpa.

Ce qui changeait était donc substantiel : les données distribuées pour ces neuf zones comportaient désormais les éléments produits par le signataire. Mais deux autres états n’étaient pas encore atteints. Les enregistrements DS dérivés des clés de signature de clé n’avaient pas encore été publiés dans les zones parentes in-addr.arpa et ip6.arpa. Les enregistrements DS des zones enfants des membres ne commençaient pas davantage à être publiés dans cette deuxième phase. Le plan d’AFRINIC réservait explicitement ces opérations à la troisième phase.

Cette chronologie interdit l’expression commode selon laquelle « DNSSEC était activé » si celle-ci laisse entendre une validation de bout en bout. Une zone peut distribuer des données signées sans qu’un résolveur disposant d’un point de confiance puisse authentifier une chaîne continue depuis ce point jusqu’à la zone concernée. La distinction n’est pas un raffinement terminologique. Le RFC 4033 rappelle qu’un résolveur conscient de DNSSEC a besoin d’une chaîne authentifiée issue d’un point de confiance configuré. Le 3 mai, les signatures étaient présentes dans le service de zone ; le pont DS parental restait volontairement non raccordé.

Le choix de séparer ces états donnait précisément sa valeur à la deuxième phase. Si une difficulté apparaissait dans la production, le transfert ou la distribution des zones signées, elle pouvait être observée avant d’engager l’étape de confiance parentale. Les requêtes DNS ordinaires devaient continuer à fonctionner. Les requêtes DNSSEC devaient retourner les données attendues. Les transferts entre maître et serveurs secondaires devaient rester cohérents. En conservant ces questions distinctes de l’ancrage parental, AFRINIC limitait le nombre de variables modifiées au même moment.

La bonne lecture du 3 mai tient ainsi dans une phrase sobre : AFRINIC a commencé à distribuer neuf zones inverses signées, dans un état transitoire annoncé, testable et réversible, mais pas encore sécurisé par une chaîne DNSSEC parentale complète. Cette phrase est moins spectaculaire qu’un slogan de lancement. Elle est aussi beaucoup plus utile à l’opérateur qui doit savoir ce qu’il peut observer, ce qu’il ne doit pas encore attendre et où chercher en cas de résultat surprenant.

Une frontière de phase devenue observable

L’échange public des 7 et 8 mai donne chair à cette différence. Mark Elkins a signalé qu’une zone inverse IPv6 de la liste exposait des enregistrements DNSKEY, alors qu’il ne voyait pas encore d’enregistrement DS pour sa zone enfant. Son observation ne prouvait ni panne ni mauvaise exécution. Elle révélait, depuis l’extérieur, la limite exacte entre les données signées déjà distribuées et la continuité de confiance qui n’était pas encore établie.

Alain Aina a répondu que le service se trouvait en phase 2. Il a précisé que la phase 3 comprendrait l’envoi des DS vers ip6.arpa et in-addr.arpa, ainsi que le début de la publication des DS des membres, une fois la phase 2 achevée. Cette réponse datée est importante pour deux raisons. D’abord, elle évitait de transformer l’absence d’un DS attendu par l’opérateur en faute imaginaire de son côté. Ensuite, elle confirmait publiquement que l’état incomplet était intentionnel et conforme au séquencement annoncé.

L’épisode montre ce qu’une bonne nomenclature de phases peut accomplir. « Phase 2 » n’était pas seulement un numéro de calendrier : le terme désignait une combinaison déterminée de propriétés. Les zones étaient signées et distribuées ; les contrôles de transfert et de réponse devaient être menés ; la délégation DS parentale et les DS des membres restaient absents. Une réponse précise pouvait donc relier l’observation d’un opérateur à cet état connu.

Mais le même épisode montre aussi la limite d’une étiquette. Le fait qu’une personne puisse nommer correctement la phase ne prouve pas, à lui seul, que chacune des neuf zones avait été contrôlée sur chaque serveur faisant autorité, à chaque instant pertinent. Il ne fournit pas les numéros de série observés, la liste complète des réponses attendues et reçues, ni le relevé des écarts. Il n’établit pas non plus que toutes les conclusions prévues par le plan ont été publiées. La phase est un modèle de l’état ; elle ne remplace pas la mesure de cet état.

C’est ici que l’échange public prend une portée institutionnelle. AFRINIC demandait aux opérateurs de valider et de signaler commentaires, problèmes et résultats. Cette ouverture était utile parce que le service inverse ne se résume pas à ce qu’un coordinateur croit avoir déployé. Il existe dans les réponses effectivement obtenues par des acteurs répartis, dans la cohérence des serveurs, dans la propagation des numéros de série et dans la capacité des clients à continuer leurs requêtes ordinaires. Une observation extérieure, même limitée à un cas, peut donc vérifier une frontière que l’annonce seule ne suffirait pas à rendre concrète.

Cependant, l’appel aux retours ne doit pas devenir un substitut à l’instrumentation du responsable du service. Les opérateurs peuvent fournir des points d’observation divers, mais ils ne disposent pas nécessairement d’une vue complète de tous les serveurs ou de tous les contrôles internes. La responsabilité centrale demeure de définir les résultats attendus, d’exécuter des tests déterministes, de dater les écarts et de publier une clôture intelligible. La participation élargit la visibilité ; elle n’efface pas l’obligation de tenir un registre opérationnel cohérent.

Le meilleur argument en faveur du déploiement progressif

Il serait injuste de présenter l’absence des DS parentaux comme la preuve d’un lancement défectueux. Le contre-argument est fort : cette absence était le dispositif même de limitation du risque. AFRINIC ne cherchait pas à faire passer une chaîne inachevée pour une chaîne complète. Son annonce et son plan distinguaient les étapes. En distribuant d’abord les zones signées, l’équipe pouvait éprouver le comportement des serveurs et des transferts sans rendre immédiatement la validation parentale dépendante du nouvel état.

Le plan prévoyait des contrôles concrets : cohérence des transferts entre maître et secondaires, requêtes DNS ordinaires sur tous les serveurs de noms, requêtes DNSSEC sur tous ces serveurs, puis documentation des conclusions et des enseignements. Il prévoyait également un retour arrière adapté à l’état « signé sans DS parental ». En cas de besoin, une fenêtre de maintenance devait être annoncée avec une description technique ; les zones non signées, débarrassées de leurs données DNSSEC et portant un numéro de série SOA plus élevé, devaient remplacer les zones signées ; un rapport détaillé devait expliquer la cause et l’exécution.

Cette architecture mérite d’être reconnue comme une démarche prudente. Un changement touchant un service réparti ne gagne rien à l’activation simultanée de toutes ses dépendances si les étapes peuvent être isolées. La capacité de revenir à des zones non signées, tout en faisant avancer le numéro de série, répondait à un besoin de continuité : les serveurs secondaires devaient pouvoir reconnaître la version de remplacement comme plus récente. Le préavis et la description technique devaient, quant à eux, réduire l’ambiguïté pour ceux qui observaient la transition.

Rien dans les sources disponibles n’établit qu’un tel retour arrière ait été déclenché. Rien ne démontre non plus une panne, un incident de sécurité, une compromission de clé ou une exploitation. Il faut résister à la tentation de fabriquer un drame pour donner du poids au sujet. La valeur analytique de l’événement vient au contraire de ce que le séquencement ordinaire met à nu : même lorsqu’un changement paraît raisonnable et se déroule sans incident publiquement attesté, il existe plusieurs états de sécurité possibles, et ces états doivent être décrits sans les confondre.

Admettre la solidité du contre-argument ne réduit pas l’exigence de transparence. Cela la renforce. Si la deuxième phase a été conçue comme une expérience contrôlée, le public opérationnel doit pouvoir voir ce qui a été testé, quand, sur quel serveur, avec quel résultat et selon quel critère de sortie. La prudence d’une architecture se démontre par ses observations et sa capacité de clôture, pas seulement par l’intention annoncée de procéder prudemment.

La question n’est donc pas : AFRINIC aurait-elle dû éviter les étapes ? Les éléments disponibles indiquent au contraire que les étapes avaient une logique technique claire. La question est : quelle preuve publique permet de savoir que l’état provisoire correspondait réellement à sa définition et que les conditions de passage avaient été satisfaites ? Un plan donne les contrôles à mener. Une annonce donne une date de départ. Un échange montre au moins une observation extérieure et une réponse. Il manque encore, dans les sources publiques examinées, le tableau complet des résultats et la clôture finale promise pour cette phase.

La primauté de l’état en fonctionnement

Un registre technique a une tentation naturelle : traiter son propre acte de publication comme l’événement déterminant. Il charge une configuration, annonce une date et nomme un nouveau statut. Pourtant, le DNS est jugé ailleurs — dans les réponses rendues par les serveurs faisant autorité et reçues par les résolveurs. La réalité utile ne réside pas dans le document qui dit que neuf zones doivent être signées ; elle réside dans les neuf zones effectivement servies, avec des signatures cohérentes, par l’ensemble des serveurs concernés.

La primauté du code en fonctionnement ne signifie pas que les documents soient inutiles. Elle leur assigne une fonction plus rigoureuse. Une annonce doit décrire l’état attendu. Un plan doit définir les contrôles et le retour arrière. Un registre de résultats doit comparer l’attendu à l’observé. Les retours d’opérateurs doivent alimenter cette comparaison. Enfin, une clôture datée doit dire si les critères ont été remplis, quelles anomalies ont été rencontrées et ce qui demeure ouvert. La documentation ne crée pas la réalité ; elle rend la réalité vérifiable.

Cette hiérarchie protège aussi contre l’ambiguïté du mot « sécurisé ». Le 3 mai, les signatures pouvaient être demandées et observées, mais la chaîne depuis un point de confiance parental n’était pas encore présente. Selon la question posée, une réponse pouvait donc être « oui » ou « pas encore ». Les zones servent-elles des données signées ? Oui, pour les neuf zones annoncées, selon l’acte et les observations disponibles. La validation peut-elle s’appuyer sur des DS publiés dans les zones parentes ? Non, pas dans l’état de phase 2 décrit. Les DS des membres sont-ils publiés ? Non, cette action était annoncée pour la phase suivante.

Une matrice d’état évite que ces réponses soient écrasées dans une seule case. Elle distingue au minimum le contenu servi, la cohérence de distribution, la continuité des requêtes ordinaires, la réponse aux requêtes DNSSEC, la présence du DS parental, la présence des DS enfants et la disponibilité du mécanisme de retour. Chacune de ces dimensions répond à un risque différent. Une signature absente n’est pas la même chose qu’un transfert incohérent ; un DS parental absent par conception n’est pas la même chose qu’un DS attendu mais introuvable après activation.

Dans cette perspective, l’observation de Mark Elkins n’était ni une attaque contre le déploiement ni un simple détail. Elle constituait un test de lisibilité institutionnelle. L’état attendu était-il assez clairement défini pour que l’absence du DS reçoive une explication précise ? La réponse d’Alain Aina montre que oui, au moins sur ce point : le DS n’était pas censé être présent en phase 2. Mais cette réussite ponctuelle invite à généraliser la méthode. Toute propriété pertinente devrait pouvoir être reliée aussi nettement à une observation et à une attente datée.

La primauté de l’état observable limite enfin les extrapolations de légitimité. Une institution peut être compétente dans l’exploitation d’un service sans que cette compétence se transforme en mandat général. Elle peut prouver qu’elle a servi des zones signées, répondu à des opérateurs et prévu un retour arrière. Elle ne prouve pas, par ces actes, qu’elle possède un pouvoir politique sur les réseaux qui utilisent ces données. La réussite technique, lorsqu’elle est établie, mérite crédit ; elle ne produit pas une souveraineté par accumulation.

Un teneur de registre privé, pas un souverain

AFRINIC intervenait ici comme teneur de registres techniques et coordinateur privé. Sa position lui permettait de produire et de distribuer les zones inverses correspondant à son périmètre, de planifier la transition et de répondre aux opérateurs. Cette fonction est importante. Elle concentre des tâches dont la cohérence compte pour de nombreux réseaux. Mais importance et souveraineté ne sont pas synonymes.

Le changement du 3 mai n’était ni une loi, ni une sanction, ni un jugement. Il ne reposait sur aucun pouvoir de police, de confiscation ou de réglementation étatique. C’était un acte d’exploitation d’une infrastructure de coordination. Sa légitimité pratique devait donc être évaluée selon des critères étroits et vérifiables : le service continuait-il à répondre ? Les données signées étaient-elles distribuées de façon cohérente ? Les opérateurs savaient-ils que le DS parental n’était pas encore présent ? Le retour à l’état antérieur était-il possible ? Les anomalies recevaient-elles une réponse datée ?

Cette conception mince de la coordination n’amoindrit pas le rôle technique. Elle le protège contre la dérive rhétorique. Un teneur de registre inspire confiance lorsqu’il décrit fidèlement ce qu’il fait, expose les limites de l’état courant et rend ses décisions opérationnelles contrôlables. Il fragilise cette confiance s’il laisse une annonce cérémonielle se substituer aux preuves ou s’il transforme une nécessité de sécurité circonscrite en prétention à commander plus largement.

Les règles de sécurité peuvent justifier des contraintes précises. Pour maintenir l’intégrité d’un service de zones, il est raisonnable d’exiger certains formats, d’ordonner les changements, de tester la cohérence et de suspendre une étape lorsqu’un résultat ne correspond pas à l’attendu. Mais ces contraintes ne valent que par leur rapport direct à la continuité et à l’intégrité du service. Elles ne créent pas une permission générale de punir, de gouverner des membres ou de revendiquer un statut supérieur à celui d’un coordinateur technique.

La différence importe économiquement. Les réseaux et services s’appuient sur le DNS inverse dans leurs opérations. Une transition incohérente peut augmenter le temps de diagnostic, susciter des interprétations contradictoires et déplacer les coûts vers des opérateurs qui ne contrôlent pas la zone parente. Si le coordinateur dit seulement qu’une fonction est « lancée », chaque acteur doit reconstituer l’état réel à partir de ses propres observations. Si le coordinateur publie une matrice précise, les mêmes acteurs peuvent distinguer un état transitoire prévu d’un écart qui mérite investigation.

La responsabilité est donc proportionnelle à la centralité de la fonction, non à une autorité politique imaginaire. Plus un enregistrement commun est utilisé, plus son gardien doit réduire l’incertitude autour des changements. Cela exige de la sobriété dans les revendications et de la richesse dans les preuves. Le gardien n’a pas besoin de se présenter comme gouverneur ; il doit montrer que le registre correspond au service en fonctionnement.

Les neuf zones comme neuf unités de preuve

L’annonce regroupait neuf zones dans un même commencement de phase. Pour la communication, ce regroupement est naturel. Pour le contrôle, il est insuffisant. Chaque zone constitue une unité distincte dont la version signée doit être produite, transférée et servie. Le fait qu’une zone IPv6 expose des DNSKEY, comme l’a observé un opérateur, ne démontre pas à lui seul que les huit autres zones répondaient partout de la même manière.

La distinction entre six zones IPv4 et trois zones IPv6 compte d’abord comme délimitation du périmètre, pas comme invitation à spéculer sur des comportements différents. Les sources ne fournissent pas un relevé comparatif complet entre ces deux familles. Elles permettent toutefois de demander la même série de preuves pour chacune : zone attendue, numéro de série observé, cohérence des transferts, réponse DNS ordinaire, réponse DNSSEC, statut du DS parental, statut des DS enfants et état de préparation du retour arrière.

Le plan de déploiement fournit une ossature à cette demande. Il mentionne la cohérence des transferts entre maître et secondaires, les requêtes ordinaires et DNSSEC sur tous les serveurs, ainsi que la documentation des conclusions et enseignements. Ce sont des catégories de contrôle pertinentes. Ce que les archives accessibles ne livrent pas, c’est leur résultat exhaustif. Il manque un relevé contemporain couvrant les neuf zones sur tous les serveurs faisant autorité. Il manque également le document final qui fermerait la boucle entre le plan et le résultat.

Il faut être exact sur la portée de cette lacune. Elle ne prouve pas que les contrôles n’ont pas été effectués. Elle signifie que les sources publiques disponibles ne permettent pas de vérifier qu’ils l’ont tous été, ni de connaître leurs résultats détaillés. L’absence de preuve publique n’est ni la preuve d’un échec ni une raison d’inventer un incident. C’est une limite de décision : un opérateur extérieur peut confirmer certains phénomènes, mais pas reconstruire avec certitude l’ensemble de l’état de service.

Cette nuance est centrale pour une gouvernance honnête. Une institution ne devrait pas recevoir un certificat de réussite sur la seule base de son intention. Elle ne devrait pas davantage être condamnée sur la seule base d’un document manquant. La réponse appropriée consiste à définir le niveau de confiance permis par les pièces disponibles. Ici, la confiance est forte sur le plan annoncé, la date de début, le périmètre des neuf zones et la séparation entre phases. Elle est plus faible sur l’exécution exhaustive de chaque contrôle et sur la clôture documentée.

Une lecture par unité de preuve rendrait aussi le retour arrière plus intelligible. Le mécanisme publié décrivait le remplacement des zones signées par des zones non signées avec un numéro de série supérieur, après préavis et pendant une fenêtre de maintenance, puis la publication d’un rapport détaillé. Les sources ne disent pas qu’il fut utilisé. Un registre d’état aurait néanmoins pu indiquer, pour chaque zone, que les artefacts de retour étaient prêts et que la procédure avait été vérifiée. La réversibilité annoncée gagnerait alors le statut de capacité observée plutôt que de simple promesse.

Ce que les archives établissent — et ce qu’elles n’établissent pas

Les archives contemporaines offrent quatre sortes de preuves. L’annonce datée établit ce qu’AFRINIC disait vouloir commencer le 3 mai et nomme exactement les neuf zones. Le plan de déploiement décrit la différence entre la distribution des zones signées et la publication ultérieure des DS parentaux, ainsi que les familles de tests prévues. Le plan de retour détaille le mécanisme envisagé pour revenir à des zones non signées. Enfin, l’échange entre opérateurs montre une observation extérieure et la réponse qui la relie à la frontière de phase.

Ensemble, ces pièces soutiennent une conclusion limitée mais solide : le 3 mai correspondait au début d’un état « zones signées servies, DS parental non encore publié, DS des membres non encore publié ». Elles soutiennent aussi l’idée que cet état était volontaire, annoncé et assorti d’une logique de test et de retour. Elles ne soutiennent pas l’affirmation d’une validation DNSSEC complète à cette date.

Plusieurs éléments restent inconnus. Les archives accessibles ne contiennent pas le ticket interne de changement, ni la liste de toutes les personnes ayant approuvé l’opération. Elles ne contiennent pas une série complète de mesures pour chaque zone et chaque serveur. Elles ne disent pas si un retour arrière a été invoqué pendant la deuxième phase. Elles ne fournissent pas le registre d’incidents, même vide, qui permettrait de conclure à l’absence documentée d’anomalies. Elles ne livrent pas davantage le rapport final de conclusions et d’enseignements annoncé par le plan.

La page actuelle d’AFRINIC retenue dans le plan à long terme n’était plus disponible à l’adresse sélectionnée au moment de la vérification du 12 août 2026. L’analyse repose donc sur les archives de la liste de diffusion et sur des captures contemporaines datées. Ce fait n’invalide pas les documents capturés, mais il souligne une autre dimension de la responsabilité : les preuves d’un changement d’infrastructure doivent rester durablement accessibles, car leur utilité dépasse la fenêtre immédiate du déploiement.

La discipline consiste à ne pas combler ces blancs par des présomptions. On ne peut pas dire qu’une panne s’est produite. On ne peut pas dire qu’aucun problème n’a existé. On ne peut pas affirmer que tous les tests ont réussi. On peut dire qu’un opérateur a vu des DNSKEY sans voir encore le DS de sa zone enfant, et qu’AFRINIC a expliqué que ce résultat correspondait à la deuxième phase. On peut dire que le plan prévoyait des tests et un retour arrière. Au-delà, le degré de certitude diminue.

Cette retenue n’est pas une faiblesse éditoriale. Elle est le cœur d’une analyse de gouvernance fondée sur les faits. Le coordinateur doit éviter de faire passer son intention pour un résultat ; l’observateur doit éviter de faire passer une lacune documentaire pour une défaillance. Des critères identiques s’appliquent aux deux : nommer la source de chaque affirmation, séparer ce qui était prévu de ce qui a été observé et indiquer clairement ce qui demeure indémontré.

Le coût de l’ambiguïté pour les opérateurs

Dans une transition par étapes, l’ambiguïté se paie en temps. Un opérateur qui voit une signature mais ne trouve pas de DS peut envisager plusieurs explications : une erreur locale, une propagation incomplète, une configuration de zone enfant incorrecte ou un état transitoire voulu par le parent. Sans description précise, il doit tester chacune de ces hypothèses. Avec une matrice datée indiquant « signatures présentes, DS parental attendu : non, DS des membres attendu : non », une grande partie de ce diagnostic devient immédiate.

Le 7 mai, la question de Mark Elkins et la réponse du 8 mai illustrent cette économie d’information. La réponse a ramené l’observation à la chronologie prévue. Elle a donc réduit l’incertitude. Mais un système de responsabilité mûr ne devrait pas dépendre uniquement de la disponibilité d’une personne capable de répondre sur une liste. L’information structurante devrait être publique avant que chaque opérateur ait à reformuler la même question.

La continuité des requêtes ordinaires représentait un autre enjeu. Le plan incluait explicitement leur contrôle sur tous les serveurs, en plus des requêtes DNSSEC. Cette séparation rappelle que l’introduction d’une fonction de sécurité ne doit pas faire disparaître la fonction de base qu’elle vise à protéger. Un déploiement peut produire des signatures correctes et échouer malgré tout si les réponses ordinaires deviennent incohérentes ou indisponibles. La sécurité n’est pas une couche cérémonielle ; elle doit coexister avec le service réel.

Le retour arrière répondait à la même logique économique. Une procédure annoncée réduit le temps de décision lorsque l’état s’écarte de l’attendu. Elle précise comment remplacer les zones, comment faire reconnaître la nouvelle version grâce au numéro de série et comment informer les opérateurs. Pourtant, sa seule existence sur une page ne suffit pas à établir qu’elle était exécutable à tout moment. La préparation des zones de remplacement, l’identification des responsables et l’existence d’une fenêtre possible auraient gagné à être indiquées comme des états contrôlés.

La transparence réduit également le risque d’une attribution erronée des coûts. Si un coordinateur présente l’ensemble comme achevé alors qu’un lien de confiance est encore volontairement absent, les membres peuvent passer du temps à chercher une faute dans leur propre environnement. À l’inverse, si la phase est décrite exactement, un DS absent n’est pas automatiquement traité comme un incident. Le langage du statut devient ainsi une composante de la fiabilité : il oriente les efforts de diagnostic vers la bonne couche.

La leçon dépasse le cas DNSSEC sans devenir un cours général sur le protocole. Tout service commun évolue par changements dont les effets sont distribués. L’institution qui tient le registre possède une vue et un pouvoir d’action particuliers ; les opérateurs possèdent d’autres points d’observation. La meilleure coordination met ces perspectives en correspondance au moyen d’états mesurables. Elle ne demande pas la confiance parce qu’elle est centrale. Elle gagne une confiance limitée parce que ses annonces peuvent être vérifiées.

La responsabilité d’un lancement incomplet par conception

Un état incomplet par conception n’est pas un état fautif. Il devient problématique seulement si son incomplétude est cachée, mal comprise ou impossible à distinguer d’une défaillance. Sur ce point, les documents d’AFRINIC étaient plus précis que ne le sont souvent les annonces technologiques. Ils indiquaient que les DS parentaux viendraient plus tard et que les zones n’étaient pas encore sécurisées par DNSSEC au sens de la chaîne complète. L’échange public confirme que cette distinction pouvait être invoquée lorsqu’une question concrète surgissait.

Cette précision constitue la meilleure défense de la démarche. Elle montre que l’institution n’avait pas besoin de prétendre que tout était terminé pour revendiquer un progrès réel. Servir des zones signées était déjà un changement technique. Le tester séparément avait une valeur propre. Une gouvernance crédible accepte de nommer un état intermédiaire au lieu de comprimer plusieurs seuils dans un seul récit de réussite.

Pourtant, un état intermédiaire impose davantage de métadonnées opérationnelles, pas moins. Il faut pouvoir répondre à quatre questions : quel sous-ensemble a changé ? Quelles propriétés doivent déjà être vraies ? Quelles propriétés ne doivent pas encore être vraies ? Quel événement autorisera le passage à l’état suivant ? Pour le 3 mai, les trois premières réponses sont largement accessibles. La quatrième reste moins étayée publiquement, faute d’un relevé complet des critères de sortie et de leur satisfaction.

Le lancement ne devrait donc pas être considéré comme un instant unique. Il s’agit d’une suite d’états, chacun avec son périmètre, ses invariants, ses tests et sa porte de sortie. L’annonce du 2 mai ouvrait la phase. Les observations et contrôles devaient en établir la réalité. Une clôture devait ensuite expliquer les conclusions et les enseignements. Sans cette dernière pièce, l’histoire publique contient le départ et un aperçu du trajet, mais pas le procès-verbal complet de l’arrivée.

Il serait tentant de franchir la frontière du sujet en racontant l’étape suivante. Ce serait une erreur. La question ici n’est pas ce qui a été activé plus tard, mais ce qui était vrai le 3 mai et pendant l’état de phase 2 rendu visible par l’échange des 7 et 8 mai. Préserver cette limite est précisément la méthode défendue : ne jamais emprunter au futur une propriété qui n’appartenait pas encore au service observé.

La responsabilité se mesure alors à une fidélité temporelle. Une déclaration peut être exacte le 3 mai et inexacte une semaine plus tard ; l’inverse est tout aussi possible. Un registre public doit dater les changements, conserver les anciens états et permettre à un opérateur de savoir quelle attente était raisonnable au moment de son observation. Les archives de listes remplissent partiellement cette fonction. Un registre de service structuré l’aurait accomplie de manière plus directe.