要約

  • 2026年11月3日20時07分から22時50分UTCまで、RIPE NCCのRFC 8181公開サービスは委任CAの発行者を認識できず、公開要求に「Unknown publisher」を返した。
  • 定期保守後、Krillが発行者設定を読み込める状態になるより先に起動した。既存リポジトリの中身は保たれ、修復後はCA側の公開が自動で再開した。

受付係だけ先に着席した

RIPE NCCの障害報告には、ソフトウェアが動いていることと仕事ができることの差がはっきり出ている。保守中の再起動でストレージが遅くなり、登録された発行者の設定がKrillに届く前に公開サービスが立ち上がった。委任CAから要求が来ても、受付側には名簿がない。結果は全件「Unknown publisher」。20時07分から22時50分UTCまで、2時間43分にわたり新しいオブジェクトを受け付けられなかった。

委任CAの利用手順を読むと、この入口の位置が分かる。運用者はCAと秘密鍵を自分で持ち、RIPE NCCのPublication as a Serviceを公開先に選べる。CAが署名したROA、マニフェスト、失効リストなどは、この経路を通ってリポジトリへ届く。鍵の管理は運用者、受け取りと配信は登録機関。今回壊れたのは両者が接続する一点だった。

RIPE NCCによれば、公開済みのリポジトリ内容は影響を受けなかった。拒否されたCAも修復後に自動で公開を再開した。だから既存ファイルを読む側と、今まさに書き換えたい側では体験が違う。昨日のROAが見えていても、今日の変更が公開されたことにはならない。報告には影響を受けたCAの数も対象オブジェクトの一覧もない。個別の更新を確かめるには、CAの再試行結果と公開先の実物を照合する必要がある。

保守終了の時計と公開成功の時計

同日のRPKI Dashboard保守記録は21時06分CET、つまり20時06分UTCに完了と表示された。公開サービス側の障害開始はその1分後の20時07分UTCだ。二つは別のサービス項目であり、障害報告はDashboardの保守票そのものを原因と断定していない。それでも「保守作業が終わった」という時刻を「登録済みCAが公開できる」という確認に読み替えてはならないことを、この並びは示す。

発見の経路も重要だ。会員からの連絡を受け、RIPE NCCの24時間対応技術者が正しい設定をKrillから利用できるようにした。RIPE NCCは、Krillの起動前に設定を必ず用意すること、RFC 8181部分の監視を増やすことを改善策に挙げる。プロセスの生存監視では、名簿なしで動く受付係を見逃す。実際に登録された発行者の要求を通す確認が必要になる。

サービス条件は、この公開経路をRIPE NCCの役割として定めている。委任CAが鍵を保有する自由は、登録機関の受付がそのCAを認識して初めて実務上の自由になる。