要約

  • KSK-2024は2026年10月11日、予定どおりDNSルートゾーンへの署名を開始した。ICANNは広範な運用障害の兆候を確認していないとしている。
  • この公開ステータスが確認するのはルートゾーンの切り替えであり、すべてのリゾルバーが新鍵を採用したことでも、局所的な失敗が皆無だったことでもない。KSK-2017は後続の失効・削除手順まで有効な信頼アンカーとして残る。

「切り替え成功」には複数の意味がある

ICANNのKSKロールオーバー情報は、10月11日14:00 UTCにKSK-2024がルートゾーンへの署名を始めたと記録する。同ページは、広範な運用障害の兆候は確認されておらず、監視を続けるとも述べる。IANAも新鍵をアクティブとし、KSK-2017は署名を終えたと記載する。重要な事実だが、記述の射程を超えて解釈してはならない。

ルートゾーンの署名鍵が変わったからといって、検証を行うすべての再帰リゾルバーが後継鍵を受け入れたことにはならない。ルートゾーンは署名済みのDNSデータを公開し、再帰リゾルバーは利用者に代わってその正当性を検証する。検証には、チェーンをたどる起点となるローカルの信頼アンカーが必要だ。新しい署名状態を検証する時点でKSK-2024を使える状態にしていなければ、そのリゾルバーでDNSSEC検証が失敗する可能性がある。そのリゾルバーを使う利用者は影響を受け得るが、世界中のルートゾーンやDNS全体が停止したことを意味しない。

少なくとも四つの証拠レイヤーを分けて考える必要がある。ルートゾーンにおける鍵の公開・署名状態、各リゾルバーにおける信頼済み鍵の状態、その状態を作るソフトウェアと更新機構、そして利用者が観測する名前解決の結果である。一つのレイヤーの記録を、別のレイヤーの受領証として扱うことはできない。

長い準備期間は自律分散するリゾルバーのためにある

IANAはKSK-2024を有効化よりかなり前に公開した。鍵は2025年1月11日にルートゾーンへ加わり、RFC 5011に従うリゾルバーが信頼する時期は同年2月10日とされた。旧鍵が署名を続ける間に、新鍵を発見し受け入れる機会を約2年間設けたことになる。ICANNの7月のガイドは、報告したリゾルバーの95％超が切り替え前にKSK-2024を認識または採用したとした。この数値は報告者の準備状況を示すもので、全リゾルバーの調査結果でも、切り替え後の成功率でもない。

RFC 5011は「公開済み」と「信頼済み」が異なる状態である理由を示す。自動更新を行うリゾルバーは、検証済みDNSKEYセットに新鍵が含まれるのを確認し、追加の保留期間を経て、その後の検証済みセットにも鍵が残っていることを確かめてから信頼アンカーとして受け入れる。保留期間は最低30日で、元のTTLに関する規則も適用される。各リゾルバーは自ら見て保存したデータから状態を作る。中央のスケジュールは採用の時間を与えられるが、ローカルファイル、ソフトウェア設定、分散した全機器の検証結果を認証するものではない。

2018年の経緯はこの境界を示している。ICANNの検証報告によると、最初の切り替えは、ISPやネットワーク事業者が使う多数のリゾルバーが未準備だとする直前のデータを受け、延期された。2018年の切り替え後もDNSKEYクエリーの傾向は一部の未準備リゾルバーを示したが、重大な障害は確認されず、利用者から見える影響も小さかった。同報告はさらに、リゾルバーは各運営者が管理するため、ルートゾーン運営者がすべての要素を測定・制御する方法はなかったと説明する。だからこそ、2026年の発表は普遍的な成功ではなく、広範な障害の兆候がないという観測にとどめている。

10月は署名の切り替えであり、ライフサイクルの終わりではない

鍵の移行はまだ続く。IANAの現行予定では、KSK-2017は2026年10月11日に署名を終えたが、有効な信頼アンカーとして残る。2027年1月11日にREVOKEビットを公開し、3月22日にルートゾーンから削除する予定だ。これらは後続の別個の状態遷移であり、リゾルバーごとの挙動も伴う。10月の署名変更を、旧鍵の即時削除や旧鍵への信頼の全面終了と呼ぶべきではない。

更新経路も一様ではない。自動更新、ベンダーのソフトウェアパッケージ、手動で維持するアンカーファイル、機器ファームウェア、マネージドリゾルバーなどがある。一つの組織が複数の経路を同時に使う場合もある。パッケージが公開されても導入されたとは限らず、設定ファイルに鍵があっても更新が永続化されるとは限らない。一つのテスト拠点で問い合わせが成功しても、すべての利用者経路を代表するわけではない。それぞれ独立に確認すべき運用状態だ。

ICANNは検証型リゾルバーの運営者に対し、KSK-2024（Key Tag 38696）が信頼アンカー設定に存在することを確認し、自動更新の成功を前提にしないよう促す。IANAは署名済みXML形式の信頼アンカーファイルを鍵パラメーターの規範的な情報源とし、ベンダーの手順に従うよう案内する。ローカルで確認すべき対象は明確だが、リゾルバー全体の証拠は分散したままだ。

公開記録が示すこと、示さないこと

公開記録から言えるのは三点だ。新鍵は予定日にルートゾーンの署名を引き継いだ。ICANNのステータス更新時点で広範な運用障害の兆候は観測されていなかった。旧鍵の失効と削除は今後の予定である。一方、リゾルバー単位の一覧、切り替え後の全体母数、世界全体の採用率、影響を受けた利用者数は公開されていない。障害報告が公開されていないことから、リゾルバーや利用者が誰も問題に遭わなかったと推論することもできない。

ステータスを軽視する必要はない。記述を適切な規模に保てばよい。ルート運営者は署名状態と自ら観測した信号を報告できる。再帰リゾルバー運営者は自分の信頼状態と検証挙動を示せる。ベンダーはパッケージや自動更新の配布を説明できる。サービス事業者は自社利用者への影響を観測できる。それぞれ視野が異なり、単独で全体を語ることはできない。

予定どおりのロールオーバー後に問うべきなのは、式典や日付が守られたかだけではない。証拠の連鎖が実際に鍵へ依存するシステムまで届くか、残る廃止手順に明確な復旧経路があるかである。2026年の公開情報は好ましいが限定的だ。ルート鍵は予定どおり切り替わり、広範な障害は観測されていない。残る確認はリゾルバーとサービス単位で行い、2027年1月と3月の節目も評価する必要がある。