C-Root の2024年ルートゾーン停滞が突き付けた「公開鮮度」という説明責任

要約

Cogent の公表によると、C-Root が提供するルートゾーンは2024年5月18日以降、ルートゾーン公開サーバーの変更を追随しなくなった。C-Root チームが問題を知らされたのは5月21日15時30分（UTC）で、鮮度が全面的に回復したのは5月22日16時（UTC）だった。[1]
C-Root は本番の DNS 問い合わせに応答し続けたと Cogent は説明している。したがって、これは C-Root が数日間消失した事案ではない。到達可能なサービスが古い権威状態を返した「鮮度」の障害である。[1]
Cogent は、別目的の経路ポリシー変更がルートゾーン更新に副作用を及ぼし、同時に関連監視も沈黙させたと述べた。公開経路と観測経路が同じ障害領域に置かれていたことが、中心的な統制問題である。[1]
他のルート文字、エニーキャスト、再帰リゾルバーのキャッシュと再試行は、直ちに普遍的な障害へ発展する可能性を抑えた。しかし、冗長性は古いコピーを正しいコピーには変えない。[5][9][20]
当時の報道によれば、.govと.intで予定されていた DNSSEC アルゴリズム関連作業は延期された。これは両 TLD に障害が起きた証拠ではなく、ルート文字間の状態が一致しない状況で変更を重ねないための予防措置だった。[4]
SIDN Labs と NLnet Labs による後の検討では、初期の RSSAC047 監視実装はゾーンファイルの欠落を観測していたにもかかわらず、月次集計に事案を表出できなかった。公開されなかった版を中央値の計算から除外する設計は、重大な欠落を統計上見えなくし得る。[3][6][7]
修復の完了条件は「現在のゾーンに戻った」だけではない。公開経路と監視経路の分離、未公開版を必ず失敗として残す仕組み、拠点別の提供シリアル、ルート文字間比較、独立した警報経路、再発試験の証跡が必要である。

1. 何が起き、何が起きなかったのか

この事案を「ルートサーバーが4日間停止した」と要約すると、問題の本質を取り違える。Cogent の説明では、本番 DNS 問い合わせは無回答になっていない。C-Root というサービス識別子は到達可能で、問い合わせには応じていた。一方で、その応答に使われるルートゾーンの版が、5月18日以降に公開された変更を追わなくなっていた。[1]

可用性と鮮度は別の性質である。可用性は、パケットが届き、DNS として解釈できる応答が戻るかを問う。鮮度は、その応答が現在の権威状態を表しているかを問う。古いシリアルを持つゾーンであっても、応答時間は短く、形式は正しく、監視画面上の成功率も高く見えることがある。だからこそ、到達性だけを健康指標にすると、時間軸上の誤りを見逃す。

公開された時系列には明確な境界がある。Cogent は、5月18日以降に C-Root のルートゾーンが公開サーバー上の変更を追跡しなくなり、5月21日15時30分（UTC）にチームがその事実を知らされ、5月22日16時（UTC）に全面的な鮮度回復を確認したとしている。[1] 一方、経路ポリシーの具体的な差分、変更を実行した機器や自動化処理、各エニーキャスト拠点のシリアル履歴、警報の時系列、欠落した個々のルートゾーン変更は公表されていない。

したがって、確実に言えるのは、C-Root が古いルートゾーン状態を提供し、その状態が内部監視によって適時に顕在化しなかったということまでである。すべての C-Root 拠点が全期間に同一の古い状態だった、全利用者が影響を受けた、特定の委任変更が失敗した、と断定することはできない。意図的な改変、侵害、攻撃を示す公開証拠もない。

この限定は責任を曖昧にするためではない。むしろ、観測された統制失敗を正確に切り出すために必要だ。問題は動機の推測ではなく、権威データの受け取り、実装、提供、監視という連鎖の中で、古い状態が複数日にわたって稼働し続けたことである。

2. 一つの「ルート文字」は多数の稼働地点から成る

「ルートサーバー」という名称から、一台の装置や一か所の施設を想像してはいけない。ルートサーバーシステムには13の名称付き識別子、すなわちルート文字があり、それぞれが複数の地点からエニーキャストで提供され得る。C-Root はその一つで、Cogent Communications が運用する。同じサービスアドレスを複数地点から広告し、経路選択によって問い合わせを適切なインスタンスへ導く構成である。[5][16]

この分散構成は容量と耐障害性を高める一方、説明に必要な証拠の粒度を細かくする。「C-Root が回復した」という識別子単位の表現だけでは、各地点がいつ、どの版を読み込み、どのシリアルを実際に返したかまでは分からない。ゾーン配布が中央の一段で止まったのか、特定の地域や経路だけが遅れたのか、各地点への到達性に差があったのかを判断するには、拠点別の記録が要る。

利用者影響の評価にも同じ注意が必要だ。再帰リゾルバーが問い合わせる先は、抽象的な文字ではなく、経路によって選ばれた実インスタンスである。通常、リゾルバーは複数のルート文字を利用でき、キャッシュによってルートへの問い合わせ回数も抑えられる。こうした仕組みは、一つのルート文字の停滞が直ちに全世界の名前解決停止へつながる可能性を低くした。[5][9][20]

しかし、他の構成要素が補ったことと、C-Root の状態が正しかったことは同義ではない。冗長性は利用者への損害を吸収できるが、誤った構成要素を正当化しない。共有システムが機能を継続したからこそ、障害を「無影響」と片付ける誘惑が生まれる。説明責任は、その誘惑に抗し、各運用者が自ら管理する文字の状態を証明することにある。

必要なのは、名称レベルと実行地点レベルを結ぶ記録である。どのゾーン版が各配布段階へ渡され、どの地点がいつ受領し、どのシリアルを応答し、どの経路変更の前後で観測可能性が変わったか。C-Root の回復宣言は、こうした実測値と結び付いて初めて再現可能な説明になる。

3. ルートゾーンは稼働する記録台帳である

ルートゾーンは単に DNS サーバーへ複製されるファイルではない。トップレベルドメインの委任先、到達に必要なグルーレコード、DNSSEC に関係する DS レコードなど、名前空間の入口を支える権威データを保持する。IANA の資料はルート管理と公開の面を示し、DNS の標準はゾーン、権威応答、参照の動作を定めている。[15][19][20]

これを「台帳」と呼ぶ理由は、ある組織に無限定な主権を認めるためではない。承認された委任やセキュリティ情報を、重複なく、正確に、継続して記録し、稼働するシステムへ反映する機能を指している。文書上は最新版が承認されていても、利用者が接する稼働系が古い版を返せば、制度上の状態と運用上の現実は分裂する。

利用者と外部観測者が検証できるのは、運用者の意図ではなく、実際に返されたバイト列、レコード、シリアルである。「最新版を提供するつもりだった」「内部では正常だと認識していた」という説明は、提供結果の代わりにならない。C-Root から返された古いシリアルこそが、事案中に外部から観測できた状態だった。

同時に、古い版に含まれていた具体的な差分を推測してはならない。ルートゾーンの更新には委任、グルー、DNSSEC 関連情報などが含まれ得るが、公開資料は C-Root が欠いた個々の変更を列挙していない。したがって、特定の TLD や利用者に生じた損害を導くことはできない。それでも、承認済みの状態が提供状態へ到達しなかった事実は、台帳の完全性に関わる。

運用者という地位や組織名は、古いデータを新しくしない。記録を預かる者に求められるのは、正確さ、連続性、変更履歴、セキュリティ情報の整合性を、実稼働の証拠で示すことだ。ここに、C-Root 事案を単なる一時的な設定ミスではなく、ネットワーク基盤の説明責任として扱う理由がある。

4. シリアル番号は鮮度を検証可能な状態にする

DNS ゾーンの SOA レコードにはシリアル値がある。シリアルは一つ一つのレコード内容が正しいことを単独で保証するものではないが、どの版が提供されているかを比較するための具体的な指標になる。期待されるルートゾーンのシリアルが進んでいるのに、あるルート文字だけが古い値を返し続けるなら、鮮度の乖離は測定できる。[7][20]

この性質により、「サービスは健康だった」という一般論を、検証可能な問いへ変換できる。公開側は何番の版をいつ提供したか。受信側はいつ受け取ったか。各配布段階とエニーキャスト地点はいつ読み込んだか。外部の各観測地点は何番を見たか。定めた時間内に版が現れなかった場合、誰にどの経路で警報が届いたか。これらは、感想ではなく時刻付き記録で答えられる。

重要なのは「現れなかった版」の扱いである。遅延時間は、版が実際に現れれば、公開時刻と観測時刻の差として計算できる。だが、ある版が一度も観測されなかった場合、それを「遅延値なし」として統計から落としてはならない。欠落はデータの不存在ではなく、「期待した状態が到達しなかった」という最も重要な結果である。

実務上は、遅延指標と完全性指標を分けるべきだ。遅延指標は観測済み版が閾値内に現れたかを示す。完全性指標は期待版数、観測版数、欠落版数、最古の未解決欠落の経過時間を示す。中央値やパーセンタイルは通常時の傾向把握に有用だが、欠落を消してよい理由にはならない。

さらに、集計前のルート文字別、観測地点別の時系列を保存する必要がある。全体の多数が正常なら、全体平均は良好に見える。だからこそ、一つの文字の逸脱を全体値へ溶かさず、異常な系列をそのまま調査対象として残す設計が欠かせない。

5. 経路ポリシー変更が配布と観測を同時に傷つけた

Cogent は、別目的で行われた経路ポリシー変更の副作用が事案につながり、関連する監視も沈黙したと説明した。[1] ただし、公表資料には対象ルート、プレフィックス、装置、ポリシー記述、自動化ジョブ、担当者は示されていない。ゾーン転送通信を直接遮断したのか、公開サーバーへの到達性を変えたのか、共通の中間依存を壊したのかも確定できない。

ここで分析できるのは、Cogent 自身が示した統制パターンである。一つのネットワーク変更が、最新版を受け取る経路と、受け取れない状態を検知する仕組みの双方に影響した。配布と観測が同じ障害領域を共有していれば、障害が発生した瞬間に、障害を知らせる計器まで見えなくなる。緑色の画面は正常を意味せず、監視対象への視線を失っただけかもしれない。

経路ポリシーは DNS サービスの外側にある単なる配管ではない。どの終端へ到達できるか、どの経路を通信が通るか、どの観測点からサービスが見えるかを決める、直接の制御面である。変更審査が顧客向け問い合わせの到達性だけを確認し、ゾーン取得、基準シリアル取得、監視、警報、ロールバック管理の経路を確認しなければ、今回のような空白が生まれる。

「DNS とは無関係な変更」というチケット上の分類も防壁にはならない。事業上の目的が DNS と無関係でも、転送状態を共有していれば運用上は密接に関係する。説明責任は、変更名や担当部署ではなく、実際の依存関係に沿って配分されなければならない。

変更前試験では、少なくとも二つを独立して検証する必要がある。第一に、ルートゾーン取得経路が変更後も利用でき、新しいシリアルを受け取れること。第二に、監視が公開側の基準値と実サービスの双方を観測し、比較できることだ。そのうち最低一系統は変更対象の経路ポリシーに依存させない。二つが同時に消えたら、展開を停止または自動的に戻すべきである。

6. 監視は「経路」と「集計」の二か所で失敗し得る

第一の監視問題は Cogent の運用境界内で起きた。公表説明では、経路変更が関連監視を沈黙させた。[1] 第二の問題は、より広い測定枠組みの集計方法から明らかになった。SIDN Labs と NLnet Labs が初期の RSSAC047 監視実装を検討したところ、測定系はゾーンファイルの欠落を捉えていたにもかかわらず、生成された月次報告は2024年5月の停滞を表面化できなかった。[3]

原因となった集計の考え方は示唆的である。公開遅延を観測値の中央値で要約し、一度も公開されなかったゾーンファイルは遅延値を持たないため計算対象から外した。多数の通常公開が短時間で完了していれば、中央値は良好になる。数日間の欠落は「非常に長い遅延」として寄与せず、値そのものがないものとして消える。[3][6][7]

これは、テレメトリー収集と統制が同じではないことを示す。生データのどこかに異常の痕跡があっても、報告規則が運用者の知りたい失敗を表現しなければ、ダッシュボードは安心を作る装置になる。中央値が悪いのではない。典型値を尋ねる統計に、例外の完全性を監視する仕事まで担わせたことが問題だ。

監視設計は、少なくとも次の問いを別々に扱う必要がある。「観測できた版の典型的な公開遅延はどの程度か」「期待した版はすべて現れたか」「最も古い未解決欠落は何時間続いているか」「どのルート文字と観測地点が乖離しているか」。二つ目以降の問いは、中央値だけでは答えられない。

欠測にも状態を与えるべきである。観測装置そのものが停止した、参照シリアルを取得できなかった、対象へ到達できなかった、対象は応答したが古いシリアルだった、という状態は互いに違う。すべてを空欄にすると、障害の所在が分からない。監視不能もまた警報対象であり、通常値として扱ってはならない。

7. RSSAC047 が分ける正確性と公開遅延

RSSAC047v2 は、ルートサーバーシステムの正確性と公開遅延を異なる測定対象として扱う。正確性は期待される情報が返されるかを問い、公開遅延は新しいルートゾーン版が利用可能になるまでの時間を問う。[6][7] この区別は、C-Root が到達可能でありながら古かったという事実に直接対応する。

応答の有無だけを調べる監視では、C-Root は利用可能に見える。期待する現行ゾーンと応答を比較すれば、古いシリアルは正確性の問題として見える。公開から提供までの時間を測れば、複数日に及ぶ遅れは公開遅延の問題として見える。同じパケット交換でも、問いの立て方によって検知できる失敗が変わる。

ただし、標準や諮問文書を使って、公開資料にない法的結論を後付けしてはならない。現時点の資料だけでは、Cogent が特定の契約条項、RSSAC 閾値、法的義務に違反したと断定できない。これらの文書が有用なのは、広い期待を観測可能な性質へ変えるからである。運用者はその性質に基づいて試験し、例外を記録し、回復を証明できる。

RSSAC002 が示す共通測定の考え方も重要である。[8] ルート運用者と研究者が比較可能な時刻、識別子、測定条件を使わなければ、事後検証は相互に結び付かない複数の画面へ分裂する。鮮度事案では、どの版をいつ期待し、どの文字・地点からいつ観測したかを同じ時間基準で残す必要がある。

月次の一つの数値を公開するだけでは説明責任を果たせない。生の観測、欠落版の標識、計算規則、除外条件、警報閾値を保存し、第三者が「なぜ正常または異常と判断したか」を再現できるようにする。欠測の扱いが見えない指標は、重大な例外に対する保証にはならない。

8. DNSSEC は鮮度の時間的コストを高める

DNSSEC は DNS に署名付きレコードと検証動作を加える。RFC 4033、RFC 4034、RFC 4035は、セキュリティサービス、関連レコード、署名の時刻フィールド、権威サーバーと検証リゾルバーの役割を定める。ルートゾーンは、署名された TLD の DS レコードを公開し、署名付きルートデータを配布するため、信頼の連鎖における重要な位置を占める。[11][12][13]

古いルートゾーンは、古いセキュリティ情報を含む可能性がある。しかし、可能性とこの事案で実現した結果を混同してはならない。C-Root が期限切れ署名を提供した、特定ドメインの検証が失敗した、攻撃者が乖離を悪用した、と示す公開証拠はない。リスクは、期待状態と提供状態の差が時間とともに広がることにあり、攻撃成功を確認したことにはない。

署名には開始時刻と終了時刻があり、運用者は有効な材料が継続するよう更新やロールオーバーを計画する。[12] 停滞が十分長く続けば、古いコピーが時刻境界へ近づいたり、新しい委任変更を欠いたりする可能性はある。だが、実際にどの版とレコードが欠けたかは公開されていないため、2024年5月の具体的結果として断定できない。

当時の報道では、.govと.intで予定されていた DNSSEC アルゴリズム関連作業が延期された。[4] 妥当な読み方は、障害発生の証拠ではなく安全のための変更抑制である。一つのルート文字が異なる状態を提供している間にセキュリティ上重要な変更を重ねれば、観測結果の説明、問題切り分け、ロールバック判断が難しくなる。鮮度が揃うまで待つことは、不確実性を増やさないための統制だった。

この延期は、利用者の全面障害がなくても、鮮度不足が共有基盤の変更能力を下げることを示す。損失は無回答件数だけでは測れない。正当な保守作業の延期、調整コスト、信頼低下も、権威状態を確証できないことから生じる運用上の影響である。

9. 冗長性は影響を抑えたが、責任を閉じなかった

ルートサーバーシステムは複数のルート文字、多数のエニーキャスト地点、再帰リゾルバーのキャッシュによって耐障害性を得ている。RFC 7720はルートネームサービスの要件を扱い、RFC 8806はローカルルートサービスの文脈を示す。[9][10] 一つの構成要素や経路に問題があっても、DNS 全体が直ちに停止しないための仕組みである。

C-Root 事案でも、その耐性は意味を持ったと考えられる。Cogent は本番 DNS 問い合わせが無回答にならなかったとし、公開報道にも世界的な DNS 停止を立証するものはない。[1][4] 他のルート文字を利用でき、キャッシュ済み情報が多くの問い合わせを満たし、すべての名前解決が最新のルート変更を必要とするわけではなかった。

ここから「実害がなかったので統制上の問題もない」と結論するのは誤りである。耐障害性は、共有システムが利用者サービスを継続できたかを答える。説明責任は、各運用者が自らの構成要素の正しさを証明し、逸脱を速やかに検出できたかを答える。全体が一つの運用者の誤りを吸収しても、その運用者の監視設計が十分だったことにはならない。

外部の多様性が繰り返し誤りを覆い隠すと、見えない依存債務が生まれる。他の文字が補うことを前提に、自分の公開や監視の弱さを測らなくなるからだ。冗長な構成では、利用者影響が小さいうちに内部の欠陥を強く検知することが、むしろ重要になる。

必要なのは内部設計の画一化ではない。多様性は障害の共通原因を減らし得る。各文字が、現在のシリアル、応答の正確性、公開時間、拠点別状態、インシデント証跡という共通の外部特性を示せることが重要だ。冗長性は利用者を守り、監視は逸脱を見逃さない。この二つは代替関係ではない。

10. 責任は実際の制御範囲に沿って分ける

基盤事案では、単一の責任主体を探す議論に流れやすい。しかし、C-Root の事案には制御範囲の地図が必要である。関係者はそれぞれ別の部分を管理しており、公開証拠は一人の個人責任や一つの組織による全工程支配を示していない。

Cogent は C-Root のネットワーク、経路ポリシー、ゾーン公開の受け取り、監視、復旧を制御していた。自社の説明が、経路ポリシー変更と監視の沈黙をその境界内に置いている以上、Cogent には、C-Root がどのように現行状態へ戻り、同じ結合障害をどう防止または検知するのかを示す責任がある。[1][16]

ルートゾーンメンテナーは、権威ルートゾーン版の作成と配布を制御する。IANA の資料と関連手順は、ルート管理、信頼アンカー、KSK 運用、ルート運用者などの役割を説明している。[15][17][18][19] しかし、公開証拠はメンテナーが C-Root の受信失敗を引き起こしたとは示していない。他のルート文字が現行データを提供していたという比較は、受信・提供側の境界に焦点を置く。それでも完全な検証には、公開側が何をいつ配布したかという記録が必要である。

他のルート運用者は、自らのコピーとインスタンスを管理した。現行状態を提供したことは全体影響を減らし、比較の基準を与えた。Cogent 内部の経路変更に責任を負うわけではないが、ルート運用者コミュニティには、文字間乖離を発見し、共通監視から学ぶ利益がある。2024年7月の運用者会合記録には、Cogent による説明と C-Root の公表への参照があり、同会合では警報システムの試験も行われた。[2] ただし、その試験だけで5月の全失敗経路が恒久的に解消したとは証明できない。

再帰リゾルバー運用者は、問い合わせ先の選択、キャッシュ、再試行、ローカルルート構成、DNSSEC 検証を制御する。これらは利用者の露出を左右したが、C-Root を古くした原因ではない。TLD 運用者は、自らの委任や DNSSEC 変更をいつ実施するかを決め、状況に応じて延期できる。

この分解は、責任逃れと過剰な帰責の双方を防ぐ。共有システムの耐性は Cogent の責任を消さず、Cogent の責任は同社をすべてのルートゾーンレコードやリゾルバー判断の作成者にしない。各主体が、自ら操作できる制御と証拠について答えることが、最も実効的な説明責任である。

11. 検知とインシデント指揮は影響経路から独立させる

Cogent の時系列では、C-Root が5月18日以降に変更追随を止めた後、チームが問題を知らされたのは5月21日だった。[1] 公開された短い説明だけでは、通知者、正確な開始時刻、内部警報の発報・確認履歴は分からない。確かなのは、関連監視が沈黙し、外部からの通知まで停滞状態が継続したという運用上の構図である。

ルート運用者が、自ら提供するシリアルと期待シリアルの違いを知るために、外部者の連絡を必要としてはならない。外部観測は重要だが、内部証拠を代替するのではなく、独立して確認し、異議を唱える層であるべきだ。公開工程は期待版を知っており、実サービスの SOA は継続的に問い合わせられる。この二つを比較すれば、利用者の障害報告より早く乖離を知ることができる。

基本統制は独立シリアル検査である。変更対象となるネットワークの外側に置いた複数の観測点から C-Root へ問い合わせ、SOA シリアルと時刻、応答元の経路的特徴を記録する。それをルートゾーン公開側の参照値および他のルート文字と比較する。版が閾値内に現れなければ、後の版で追いついても、その欠落を消さず、独立したインシデント記録として残す。

エニーキャストを考慮し、観測点は異なる経路を通るようにする。運用者側では、各配布層または各地点がどの版を読み込んだかを把握する。ダッシュボードは最古と最新のシリアル、確認済み地点数、証拠のない地点、参照値との差を同時に示すべきだ。一つの「現在」の表示だけでは、部分的な停滞を隠し得る。

警報と指揮系統にも経路独立性が要る。ページング、インシデント連絡、管理アクセスが、公開を壊したものと同じ経路ポリシーに依存すれば、一つの変更がサービス依存と対応能力を同時に奪う。少なくとも一つの通知経路、管理経路、外部観測経路を別の障害領域に置き、定期試験で実際に届くことを確認する。

指揮の開始条件は利用者からの苦情だけではなく、状態差で定義する。期待版の未到達、観測点間のシリアル不一致、基準値の取得不能、独立監視の消失をそれぞれ発火条件にする。開始後は、変更凍結、担当者割当、影響範囲の測定、ロールバックまたは修復、下流への通知、復旧証拠の保存へ進む。これにより、監視の欠測そのものが行動を促す。

12. 変更管理は隠れた依存関係まで試験する

経路ポリシーの変更審査は、到達性、トラフィックエンジニアリング、顧客プレフィックス、フィルターに集中しがちである。C-Root 事案は、内部サービスの依存も同じ審査に含める必要を示した。問い合わせトラフィックが流れ続けても、ゾーン取得、テレメトリー収集、基準値取得、外部プローブ、警報配信が失われることがある。

変更前の依存関係図には、ルートゾーン取得経路、期待シリアルの参照元、各監視経路、警報伝達、ロールバック用管理アクセスを含める。変更前後に各依存を個別に試験し、問い合わせ応答だけが成功しても変更を完了扱いにしない。鮮度と観測性を明示的な受け入れ条件にする。

段階展開も有効である。限定した地点や経路に新ポリシーを適用し、独立観測点が鮮度と到達性を比較する。期待版の到達、監視の継続、警報試験の成功を確認してから範囲を広げる。安全なカナリアを構成できないなら、その制約自体をリスクとして記録し、シミュレーション、保守時間帯、強い自動ロールバックで補う。

ロールバック条件は測定可能でなければならない。例えば、期待シリアルが定めた時間内に現れない、参照経路が失われる、独立プローブ間で結果が割れる、変更前に稼働していた監視が消える、といった条件である。本番問い合わせの無回答だけを条件にすると、今回の「応答するが古い」障害を検出できない。

公開資料は、Cogent が当時カナリア、依存関係図、自動ロールバックを使っていたかどうかを示していない。したがって、これらは欠如を断定する所見ではなく、公表された結合失敗から導く改善案である。説明力のある事後報告なら、どの統制が存在し、なぜ副作用を捕捉できず、何を変更したかを示すはずだ。

13. 回復と恒久的な修復を分けて証明する

Cogent の公表は、鮮度が5月22日16時（UTC）に全面回復したという高水準の時系列と原因説明を与える。[1] これは重要な回復情報である。しかし、同じ失敗経路が再び成立しないことまで示す恒久対策の証拠ではない。7月のルートサーバー運用者会合で説明と警報試験が行われたことも、共有学習の材料ではあるが、一つの試験から全対策の有効性を推定することはできない。[2]

修復資料には、変更識別子、影響した依存関係、各監視が沈黙した時刻、各公開が失敗した時刻、拠点別シリアル履歴、是正操作、独立試験の結果が必要である。機微な設定値を伏せても、出来事の順序、統制ロジック、確認方法は残せる。公開できない詳細と、説明に不可欠な証拠を区別すべきだ。

主張は観測値に結び付ける。「16時に全地点が新鮮だった」とするなら、その時点の地点別シリアルを保存する。「監視経路を分離した」とするなら、公開経路に障害を与えても別経路の観測と警報が機能する試験を示す。「集計規則を修正した」とするなら、未公開版が従来の報告ではどう消え、新しい報告ではどう失敗になるかを比較する。

証拠は版管理し、時間を置いて再試験する。一度の成功は、その瞬間の状態しか証明しない。ゾーン版の欠落、転送経路の喪失、一つの監視ネットワークの停止、拠点間の不一致を定期的に演習し、警報、指揮、ロールバック、対外連絡の結果を記録する。基盤が変わるたびに、独立性が失われていないかを再確認する。

回復は現在のデータへ戻す。恒久的な修復は、再発を早期に検知し、封じ込め、証拠をもって説明できることを示す。この二つを分けなければ、外部者は短い声明と再発が目立っていない事実だけから安全性を推測するしかない。