概要
- ICANN の2018年10月の DNSSEC ルートキー署名鍵ロールオーバーは、DNSSEC 検証リゾルバが DNS ルートを検証するために使用する公開トラストアンカーを変更した。ICANN のロールオーバーページによると、変更後に最新のルートトラストアンカーを持たないリゾルバは DNS クエリを解決できなくなる。これにより、準備状況は狭義の暗号管理タスクではなく、継続性の問題となった。
- 最も強力な説明責任の事実は延期である。ICANN は当初予定していた2017年10月のロールオーバーを、新たに利用可能となった RFC 8145テレメトリが、ISP やネットワーク事業者の使用する多数のリゾルバが準備できていない可能性を示唆したため延期した。この決定は、隠れた事業者の準備問題を公開ガバナンス記録へと変えた。
- ICANN はその後、理事会承認、パブリックコメント、継続的なアウトリーチ、技術分析、改訂計画を経て、2018年10月11日に実施した。ICANN はイベント後、観測された少数の問題は迅速に軽減され、ロールバックを必要とするシステム障害を示すものではなかったと発表した。
- 実務的な制御は分散していた。ICANN と Public Technical Identifiers はルート KSK セレモニーのプロセス、公開文書、文書化、アウトリーチ、最終的なロール決定を制御し、Verisign はルートゾーン維持者の役割を運用し、リゾルバ事業者はトラストアンカー設定とソフトウェア動作を制御し、ベンダーは RFC 5011実装品質を制御し、公的機関や企業は自社ネットワークのフォールバック計画を制御した。
- 説明責任の教訓は、グローバルなインターネット基盤の変更には、観測可能な準備状況、公開された意思決定基準、コミュニティレビュー、安全なロールバック思考、そしてテレメトリが信頼を損なう場合に延期する十分な謙虚さが必要である。ロールオーバーが成功したのは、それが公的な運用リスクとして扱われたからであり、リスクが架空のものだったからではない。
ルートキーは小さかったが、依存関係はグローバルだった
DNSSEC ルートキー署名鍵ロールオーバーは、単に一つの暗号鍵の交換に縮小すれば、微細なイベントのように聞こえる。運用上の用語では、それはグローバルな依存関係テストだった。DNS ルートは、公開ドメインネームシステム委任階層の頂点に位置する。DNSSEC 検証リゾルバは、署名付き DNS データを検証するためにトラストアンカーを使用する。ルート KSK が変更された後、検証リゾルバ内のルートトラストアンカーが古くなると、リゾルバは正しい回答を偽造とみなしてエンドユーザーの名前解決に失敗する可能性がある。
ICANN の専用ルートゾーン KSK ロールオーバーページが主要な情報源である。それは、ICANN が2018年10月11日にロールオーバーを実施したこと、KSK のロールとは新しい公開鍵と秘密鍵のペアを生成し、公開鍵部分を検証リゾルバの事業者に配布することを意味すること、そして最新のルートゾーン KSK を持っていないと DNSSEC 検証リゾルバが DNS クエリを解決できなくなるため、最新の KSK を維持することが不可欠であることを説明している。これが、平易な言葉で表現された説明責任の問題の全容である。中央のトラストオブジェクトの変更は、分散した事業者がローカルの検証状態を更新していない場合、ユーザー障害となる。
KSK は単独で存在していたわけではない。ICANN のロールオーバーページでは、当初の計画はルートゾーン管理パートナー（IANA 機能オペレータとしての ICANN、ルートゾーン維持者としての Verisign、そして2016年10月1日に役割が終了する前の NTIA をルートゾーン管理者として含む米国商務省）の作業として説明されている。IANA ルートゾーン管理ページは現在のルートゾーン管理への公開エントリーポイントを提供し、IANA DNSSEC ルートゾーン KSK ページはトラストアンカーと KSK セレモニー情報を提供している。したがって、運用記録は ICANN ガバナンス、PTI/IANA 機能、Verisign のルートゾーン運用、そしてルートトラストアンカーを消費する多数の独立したリゾルバ事業者の交差点に位置する。
DNSSEC 自体の技術アーキテクチャは、なぜこの出来事が重要だったかを説明している。RFC 4033は DNSSEC 導入と要件を定義し、RFC 4034は DNSSEC で使用されるリソースレコードを定義し、RFC 4035はプロトコル修正を定義している。これらの標準は ICANN 固有のインシデント証拠ではなく、ルートキーを結果的に重要にした検証チェーンを説明している。検証リゾルバは、自身が受け入れる信頼のパスを持つか、持たないかのいずれかだ。一つの事業者がある一つのサービスのために交換できるウェブサイト証明書とは異なり、ルートトラストアンカーは共有インフラである。
そのため、公共の継続性の利害は広範だった。ISP、企業、大学、公的機関、再帰 DNS プロバイダー、レジストリ、レジストラ、クラウドネットワーク、ソフトウェア配布者、アプライアンスベンダー、一般ユーザーは、すべてが直接の ICANN 顧客ではなかった。しかし、彼らの DNS 解決は自身の再帰リゾルバが準備できているかどうかに依存し得た。だからこそ、ICANN が2017年の延期を発表した際、グローバルインターネットユーザーの約4分の1、つまり約7億5,000万人が DNSSEC 検証リゾルバに依存しており、不十分に実施されたロールオーバーによって影響を受ける可能性があると推定したのだ。その数字は、それらすべてのユーザーが失敗するという予測ではなかった。それは依存する母集団の測定値だった。
この区別は重要である。ロールオーバーは停止ではなかった。それは起こりうる停止の前に行われた説明責任テストだった。公共インフラガバナンスは、しばしば失敗後にのみ判断される。今回、ガバナンスの記録が有意義なのは、ICANN が失敗する前に延期し、計画を再打開し、より多くの証拠を収集し、アウトリーチを拡大し、後に明示的なリスク受容をもって実施決定を行ったからである。
延期が説明責任の転換点となった
記録の中で最も重要な出来事は、ロールオーバーが成功する前に起こった。ICANN の2017年9月27日の延期告知は、DNS 保護に貢献する暗号鍵を変更する計画が延期されることを伝えた。ICANN は、最近取得したデータにより、ISP やネットワーク事業者が使用するかなりの数のリゾルバがまだ準備できていないことが示されたと説明した。それは、リゾルバがどの鍵を設定しているかをルートサーバーに報告することを可能にする最近の DNS プロトコル機能と、この新たな可視性を結びつけた。
その機能はRFC 8145であり、検証リゾルバが設定されたトラストアンカーを通知する方法を定義している。このプロトコルは ICANN に完全な知識を与えなかった。それは、ノイズが多く、部分的で、運用上機微な準備状況の可視性を生み出した。一部の信号は、設定ミスのシステム、テスト環境、フォワーダー、旧式ソフトウェア、古い設定、または大きなユーザー母集団にサービスを提供していないリゾルバから来る可能性があった。しかし、不完全なテレメトリの存在は依然としてガバナンス上の出来事だった。ICANN は、一部のリゾルバが古い状態であるという信号にもかかわらず予定通り進めるか、またはコミュニティがデータを解釈しアウトリーチを強化する間延期するかを決定しなければならなかった。
ICANN は延期を選択した。後のロールオーバーが成功したため、今となっては称賛しやすい決定だ。当時は、それ自体にコストが伴った。延期は計画への信頼を損ない、2つの鍵が公開されている期間を延長し、ICANN の DNSSEC 実践規定が必要とする運用演習を遅らせ、2017年の日付に既に準備していた事業者に不確実性を知らせる可能性があった。しかし、予定通り進めれば、名前解決が停止したときに初めてリゾルバ事業者とそのユーザーが準備の問題を発見するリスクを負うことになっただろう。
延期の告知は、インフラガバナンスとしては異例なほど率直だった。そこでは、リゾルバソフトウェアが適切に設定されていないことや、広く使用されているあるリゾルバプログラムにおいて、予想どおりに鍵を自動更新していないように見える問題が最近発見されたことなど、事業者が新しい鍵をインストールしていない複数の理由がある可能性が述べられていた。また、ICANN は SSAC、地域インターネットレジストリ、ネットワーク運用者グループなどを含むコミュニティに働きかけていると述べた。ICANN の CEO が、成功とエンドユーザーの接続性に悪影響を与えうる新たな問題を特定した後に進めることは無責任であると発言したと引用している。
その言葉は公開基準を作り出した。ICANN は、すべての検証リゾルバが動作するという約束をしたわけではない。新たに発見された準備状況の証拠が決定を変更するという約束をしたのだ。インフラ運用においては、それがカレンダー主導の変更と証拠主導の変更との違いである。
延期はまた、リゾルバ事業者に対する説明責任を維持した。ICANN はすべての再帰リゾルバにログインしてトラストアンカーをインストールすることはできなかった。ISP、企業、政府ネットワーク、DNS サービスの事業者は、自身のリゾルバソフトウェアと設定を制御していた。延期することで、ICANN は準備の問題を公にし、それらの事業者に追加の時間を与えた。それはすべての責任を彼らに移したわけではないが、共有制御モデルを可視化した。
RFC 5011の自動化は有用だが、魔法ではない
このロールオーバーは、トラストアンカーの自動更新動作に大きく依存していた。RFC 5011は、DNSSEC トラストアンカーの自動更新を定義している。RFC 5011の利点は明白だ。検証リゾルバは、追加保留期間中に新しい鍵を観測し、それを自動的にトラストアンカーとして受け入れることができる。このような仕組みがなければ、すべての検証リゾルバ事業者はインターネット規模で鍵を手動でインストールする必要がある。
しかし、自動化それ自体は説明責任には決してならない。それは、現実の多様性の下でコードと設定が行う約束である。リゾルバは、アルゴリズムを正しく実装し、状態を永続化し、保留プロセスと互換性のあるクロックとアップタイムパターンを持ち、関連する DNSKEY 素材を受信・検証し、自動更新を妨げるようなローカル設定の選択を回避しなければならない。また、事業者は自身のリゾルバが実際に検証を行っているかどうか、別のリゾルバに転送しているかどうか、そのパッケージバージョンが正しく動作するかどうか、設定管理システムがトラストアンカーの状態を上書きするかどうかを把握する必要がある。
Verisign のKSK ロールオーバーページは、ルートゾーン維持者およびルートサーバーの視点からこの区別を捉えている。そこでは、すべての DNSSEC バリデーターがトラストアンカーを必要とし、RFC 5011がルート KSK ロールオーバーにおいて本番環境でテストされたことがないと述べている。また、Verisign はルートネームサーバー事業者として、一部の RFC 8145データを受信し、古いトラストアンカー設定を持っていると思われる送信元を特定するために分析したと述べている。これは重要である。なぜなら、テレメトリは中央の ICANN ダッシュボードだけではなく、ルートサーバー事業者も準備状況の信号を見て対応できたことを示しているからだ。
自動化はロールオーバーを可能にしたが、公開説明責任には自動化が機能したという独立した証拠が必要だった。その証拠には、トラストアンカー通知、リゾルバソフトウェアテスト、古い状態に見える事業者へのアウトリーチ、パブリックコメント、メーリングリストでの議論、イベント後のモニタリングが含まれる。また、障害が十分に広範囲だった場合のロールバックの閾値を定義する意欲も含まれていた。
ルートゾーン KSK ロールオーバー設計チームの最終報告書は有用な背景である。これは、2017年の延期前に最初のルート KSK ロールオーバーの設計プロセスを概説している。そこでは、インターネットがこれまで運用上のルートトラストアンカーロールオーバーを経験したことがないからこそ、慎重な段階分け、コミュニケーション、測定が推奨されていた。後の延期は設計チームの失敗を意味するのではなく、設計の前提が正しかったことを示している。つまり、最初のロールオーバーには観測と段階的な意思決定が必要だったのだ。
教訓は RFC 5011が信頼できないということではない。教訓は、分散した自動更新メカニズムは、共有インフラを保護する場合、テレメトリと社会的調整を必要とするということだ。標準は状態機械を定義できるが、すべての事業者にその状態機械が自社ネットワークで正しく動作しているかどうかを理解させることはできない。
パブリックコメントが技術変更をガバナンス記録へと変えた
延期の後、ICANN は単にプライベートに新しい日付を選んだわけではない。そのルートキー署名鍵ロールオーバープロセスの再開計画に関するパブリックコメントページは、改訂された計画をコミュニティのレビューに開いた。このパブリックコメントページでは、計画には準備状況に関するより多くの周知、準備状況データのさらなる分析、そして2018年10月11日の実際のロールオーバーが含まれると述べられている。関連するルート KSK ロールオーバー継続計画 PDFは、以前の延期後の再開案を説明している。
このステップが重要である理由は、技術的正当性と制度的正当性が異なる問題だからだ。ICANN は技術的に鍵を変更する能力があっても、準備状況に関するコミュニティの証拠を無視すれば、政治的に無責任だった可能性がある。逆に、コミュニティは無期限の延期を要求する可能性もあったが、無期限の延期もまた運用上の負債を生む。パブリックコメントは、その不一致を記録に残すことを強制した。つまり、どのデータが信頼されるべきか、どのようなアウトリーチが十分か、どのような障害閾値を使用すべきか、誰が最終決定を下すのか、といったことだ。
計画草案コメントに関するスタッフ報告書は、その翻訳ステップの証拠である。それはすべてのリスクを消し去ったわけではない。それは、ICANN が理事会に計画を提示する前にコメントを収集し回答したことを示している。インフラの説明責任は、しばしば全員の合意よりも、権限者が行動する前に証拠と異議を可視化することにある。
ICANN の理事会承認発表では、理事会が DNS ルートを保護する暗号鍵の初めての変更計画を承認し、2018年10月11日に実施するよう組織に指示したと述べている。その発表は、すべてのネットワーク事業者がリゾルバを適切に設定していることを完全に保証する方法はないと認めつつ、ICANN は大多数がルートゾーンにアクセスできると期待していると述べた。また、事業者にとって最悪の場合の修正は、DNSSEC 検証をオフにし、新しい鍵をインストールし、検証を再度有効にすることだと述べた。
その根拠となる2018年9月16日の ICANN 理事会決議は正式なガバナンスの成果物である。それらが重要なのは、実施決定が技術スタッフの単独行動ではなかったからだ。それは、DNS のセキュリティ、安定性、回復力を使命に含む公益法人による制度的決定だった。理事会はすべてのリゾルバを運用したわけではないが、改訂された計画と協議を経て中心的な変更を承認した。
公正な説明は、パブリックコメントがリスクを排除したと偽るべきではない。それは立証責任を変えたのだ。ICANN は、なぜ2018年10月の実施がさらなる延期よりも優れているかを説明しなければならなかった。事業者は追加の1年を使って自らの準備状況を検証しなければならなかった。コミュニティは、不確実性がゼロでない限り共有トラストアンカーをロールできないことを受け入れなければならなかった。なぜなら、ゼロ不確実性は決して訪れないからだ。
コミュニケーションは制御の一部であり、広報ではない
ICANN のアウトリーチ資料は運用上の制御だった。ロールオーバーページは、DNS 検証リゾルバの現在のトラストアンカーを確認する方法や、検証リゾルバを最新のトラストアンカーで更新する方法に関するリソースをリンクしていた。これらの文書はマーケティングではない。それらは、準備の最終段階を制御する事業者向けの実践的な指示だった。
ルート KSK ロールオーバー中に予想されることに関する包括的ガイドは、別の形の制御、すなわち期待値管理を提供した。事業者は、何が変わり、いつ変わるのか、症状がどのように現れるのか、検証が失敗した場合にどうすべきかを知る必要があった。サイレントな中央変更は、あらゆる停止調査を最初からやり直すことになる。公開ガイドは、ヘルプデスク、ネットワークチーム、セキュリティスタッフに共有の枠組みを与えた。
DNS-OARC の KSK ロールオーバー資料および関連事業者コミュニティの場も同じ理由で重要だった。DNS-OARC は ICANN ではなく、その役割を中央のガバナンス機関に誇張すべきではない。これは、リゾルバ事業者や DNS 専門家がテストや観測を共有できる公開技術コミュニティチャネルとして有用である。インターネットインフラの変更は、しばしばこのような半公式な調整の網目を通じて成功する。すなわち、標準化団体がメカニズムを定義し、ICANN がルート機能を管理し、ルート事業者がトラフィックを観測し、事業者コミュニティがリスクを展開可能な行動に変換するのだ。
コミュニケーションは公共セクターのネットワークにも届く必要があった。マニフェストラベルの「公共セクターの継続性」が当てはまるのは、政府サービス、学校、病院、緊急管理局、公共機関が、多くの場合中央の IT 組織やベンダーによって設定された再帰 DNS に依存しているからだ。そのような環境で検証リゾルバが古いままであることは、DNSSEC 教育の演習としてではなく、サービスに到達できないこととして経験されるだろう。
公共セクターの継続性に関する教訓は、トラストアンカーの更新がサービス所有者から隠されている場合、セキュリティ改善が可用性リスクを生む可能性があることだ。市の機関は、自身の上流リゾルバが検証を行っているかどうかを知らないかもしれない。病院のネットワークチームは管理 DNS アプライアンスに依存しているかもしれない。学区は ISP のリゾルバの動作を継承しているかもしれない。ICANN の公開資料は、それらの組織にテストを強制することはできなかったが、適切な質問をする手段を与えた。
コミュニケーションはパニックを避ける必要もあった。ICANN は、準備ができていない検証リゾルバが障害を起こす可能性があると警告しつつ、インターネット全体が停止すると示唆しないようにしなければならなかった。DNSSEC の採用を阻害することなく、検証を行わないリゾルバのほとんどは直接影響を受けないことを説明する必要があった。緊急回復策として検証を無効にすることを、デフォルトの選択肢にしないように説明する必要もあった。このバランスは運用上難しい。警告が少なすぎれば行動が起こらず、多すぎればセキュリティメカニズムそのものへの不信を招く。
実施決定は残余リスクを受け入れた
2018年9月の承認は、ICANN がすべてのリゾルバの安全を証明したことを意味しない。それは、アウトリーチの追加、分析、コミュニティ協議を経て残余リスクを受け入れたことを意味する。この区別は説明責任の核心である。
ICANN の承認発表では、調査により、多数のネットワーク事業者が DNSSEC 検証を有効にしており、約4分の1のインターネットユーザーがそれに依存していることが示されたと述べている。また、少なくともいくつかの事業者はほぼ間違いなく準備ができていないとも述べている。これは異例なほど正直なリスク言語だ。完璧なロールを約束したわけではない。なぜ実施が依然として正当化されるのかを説明している。すなわち、予想される障害は小さく、回復可能であり、鍵ロールオーバープロセスを実行する必要性によって相殺されるというものだ。
公開記録にはロールバックの概念も含まれていた。ICANN の最初のロールオーバーが成功裏に完了したという発表では、後日、発生したいくつかの問題は迅速に軽減され、コミュニティが定義したロールバックを開始する閾値に近づくシステム障害を示唆するものはなかったと述べている。この文章が重要なのは、成功が事後的な楽観主義だけでなく、明示的な運用閾値に照らして評価されたことを示しているからだ。
DNSSEC におけるロールバックは簡単ではない。バリデーターが状態を変更した後にルート KSK をロールバックすると、それ自体の複雑さが生じる。それでも、ロールバック閾値を持つことは、どの程度の被害が決定を変えるかを定義することをリーダーに強いる。そのような閾値がなければ、チームは変更の勢いに捕らわれる可能性がある。閾値があれば、組織は少なくとも、安定性が完了よりも優先される場合の公開基準を持つことになる。
したがって、実施決定は ICANN のリーダーシップと理事会ガバナンスに属していたが、分散した証拠に基づいていた。トラストアンカーを更新したリゾルバ事業者は準備状況を作り出した。実装が正しく動作したソフトウェアベンダーは準備状況を作り出した。信号を分析したルート事業者は準備状況を作り出した。前提を疑問視したコミュニティレビューアは準備状況を作り出した。ICANN は調整し決定したが、分散システムを単独で準備完了にしたわけではない。
これが核心の説明責任マップである。ICANN は中央ルート KSK 運用に対する権限と、アウトリーチと意思決定のガバナンスに対する責任を有していた。リゾルバ事業者は自身の検証設定に対する責任を負っていた。ベンダーは実装に対する責任を負っていた。公共セクターとエンタープライズネットワークの所有者は自身の継続性計画に対する責任を負っていた。システム全体を保持する当事者はいなかったため、説明責任は仮定されるのではなく明示的でなければならなかった。
イベント自体は静かだった。なぜなら準備が静かではなかったからだ
2018年10月11日、ICANN はロールオーバーを実施した。ICANN の10月15日のイベント後発表では、利用可能なデータの評価後、持続的に悪影響を受けたかなりの数のインターネットエンドユーザーは見られないようだと述べた。発生したいくつかの問題は迅速に軽減され、ロールバックを必要とするシステム障害を示すものではなかった。また、ICANN は2019年第1四半期の次の鍵セレモニーで、古い KSK（KSK-2010）の失効処理に進むと述べた。
その後の2018年 DNSSEC KSK ロールオーバーのレビューは、最も強力な事後情報源である。そこでは、KSK-2010 は2018年ロールオーバーまで使用されたトラストアンカー、KSK-2017 は2018年10月11日にルートゾーンの署名に最初に使用された鍵と定義されている。また、最初の本番ロールオーバーからの教訓も文書化している。レビュー報告書は、ICANN を自らの作業のニュートラルな観察者にするわけではないが、次のロールオーバーのための永続的な記録を作成するため、勝利発表よりも価値がある。
イベントが静かだったことを、リスクが誇張されていた証拠と誤解してはならない。多くのインフラ変更が静かになるのは、まさに事業者が延期し、テストし、コミュニケーションし、監視したからだ。崩壊前に弱点を発見した橋梁負荷テストは、誤警報ではない。それはテストの要点である。したがって、2017年の延期は2018年の成功の一部であり、それとは別個の傷ではない。
イベント後の記録は、請求の範囲も抑制していた。誰も影響を受けなかったとは言っていない。持続的な悪影響を受けたかなりの数のエンドユーザーはおらず、システム障害もなかったと述べている。これはグローバルインフラの変更として正しいレベルだ。個々の事業者がローカルな問題を抱えた可能性もある。関連する問いは、ルートトラストアンカーの変更が広範で持続的な DNS 解決障害を引き起こしたかどうかだった。
古い鍵の失効ステップも重要である。ロールオーバーは新しい鍵が使用されたからといって単に終了するわけではない。古いトラストアンカーは、バリデーターが新しい状態を受け入れたことを確認する形で退役させなければならない。ICANN のレビューとその後のセレモニー資料は、ロールオーバーが単一のタイムスタンプではなく一連の流れであったことを示している。
DNS 委任の権力は、ドメインが再委任されない場合でも現実である
マニフェストラベルの「DNS 委任の権力」は通常、ルートゾーンエントリ、TLD 委任、レジストラ関係、名前所有権の制御を思い起こさせる。KSK ロールオーバーは、別の形の委任権力を示している。それは、ルートゾーン検証トラストチェーンの制御である。ICANN は TLD を再委任したり、登録者のドメインを変更したりしたわけではない。ICANN は、検証リゾルバが署名付きルートデータを信頼できるかどうかを判断するために使用する暗号鍵を変更したのだ。
この権力は制約されている。ICANN は技術実践規定、コミュニティレビュー、理事会ガバナンス、IANA 機能の期待、ルートゾーンパートナーの調整、グローバルな監視の下で運営されている。しかしそれでも権力である。下手な中央鍵運用は、正しく署名されたデータをバリデーターにとって無効に見せたり、事業者に検証の緊急無効化を強いたりする可能性がある。鍵が暗号であるという事実は、決定を純粋に技術的にするわけではない。
ルートゾーン KSK オペレーターDNSSEC 実践規定は、ルート KSK オペレーターが鍵管理をどのように行うかについての期待を設定するため、関連性がある。実践規定は無味乾燥な文書だが、説明責任の手段である。それらは、セレモニー、役割、制御、期待を定義し、コミュニティがオペレーターが公開された手続き内で行動しているかどうかを評価できるようにする。ICANN が鍵をロールしたとき、それは単に裁量を行使したのではなく、文書化された運用責任を行使していたのだ。
IANA トラストアンカーXMLと関連するルートアンカー公開場所も、この権力の一部である。それらは、トラストアンカー素材を機械可読かつ人間が確認可能な形で公開している。公開だけでは採用を保証するのに十分ではないが、公開と安定した配布なしには、リゾルバ事業者は確実に準備ができない。
DNS 委任の権力は、決定から成果物、事業者の行動に至るまでの公開された連鎖があるときに説明責任を果たせるようになる。ロールの決定は文書化されている。公開鍵は公開されている。期待される事業者の行動は説明されている。テレメトリは議論されている。理事会承認は記録されている。イベント後のレビューは公開されている。この連鎖は害を排除するわけではないが、権力の行使を検証可能にする。
プライベートなプラットフォームの停止との対比は有用である。プライベートな SaaS プロバイダーは、時には顧客のみに通信し、ほとんど公開しないことが可能である。ICANN には同じような選択肢はなかった。ルート KSK は公的なインターネット依存関係にある。依存する母集団が公的であったため、説明責任のチャネルも公的でなければならなかった。
リゾルバ事業者にも説明責任があった
ICANN だけを責めたり称賛したりする中央の分析は、システムの半分を見逃している。リゾルバ事業者は、自社のネットワークにおいてロールオーバーを安全にもリスクにもした。ある ISP が数百万ユーザーに対して DNSSEC 検証を有効にしている場合、そのリゾルバが更新され、監視され、テストされたかどうかを制御する。ある企業が内部および外部の解決に検証リゾルバを使用している場合、変更管理にルートトラストアンカーの準備状況が含まれているかどうかを制御する。ある公共機関が DNS をベンダーにアウトソーシングしている場合、ベンダーの質問と継続性の期待を制御する。
ICANN の現在のトラストアンカーを確認する文書と検証リゾルバを更新する文書は実践的な手順を提供したが、事業者がそれらを使用しなければならなかった。中央組織は、ローカルの怠慢を永遠に補うことはできない。検証が有効であるが DNSSEC 障害の監視がないリゾルバは、潜在的な継続性リスクである。トラストアンカーファイルが設定管理によって上書きされるリゾルバは、潜在的な継続性リスクである。RFC 5011を誤って実装したベンダーアプライアンスは、潜在的な継続性リスクである。
公共セクターの側面はこれを具体的にする。政府機関や重要な公共サービスは、しばしば共有サービス、クラウドプロバイダー、管理セキュリティベンダー、ネットワークインテグレーター、通信契約から DNS の選択を引き継ぐ。これらの機関は DNS の専門家ではないかもしれないが、それでもプロバイダーに証拠を要求できる。DNSSEC 検証が有効かどうか、どのリゾルバソフトウェアが使用されているか、ルートトラストアンカーがどのように更新されるか、検証障害がどのように監視されるか、緊急変更がどのように承認されるか、などである。
事業者は回復経路も制御していた。ICANN の理事会承認発表では、DNSSEC 検証をオフにし、新しい鍵をインストールし、検証を再有効化することを、準備ができていない事業者にとっての最悪の場合の修正策として説明していた。この緊急経路は、一時的であっても検証を無効にするとセキュリティ制御が取り除かれるため理想的ではない。しかし、ユーザーが名前を解決できないままになるよりはましだ。説明責任の問いは、事業者がこの経路を変更前に文書化していたかどうかであり、危機の最中に発見したかどうかではない。
これが、このロールオーバーが単なる DNSSEC の歴史ではなく、リスクと説明責任のシリーズに属する理由である。このイベントは、分散した事業者が自らのローカルな慣行を中央のセキュリティ変更と整合させられるかどうかをテストした。グローバルなセキュリティ制御は、継続性のためにそれに依存する準備が最も不十分な組織と同じだけの回復力しかない。
テレメトリは解釈する責任を生み出したが、確実性は生まなかった
RFC 8145トラストアンカー通知は、可視性と不確実性を同時に生み出したため、ストーリーの中で最も興味深い要素の一つである。その信号は、リゾルバがどのトラストアンカーを設定していると信じているかを示すことができる。しかしルートサーバーは DNS トラフィックを見ており、組織の意図を見ているわけではない。一つの可視の送信元アドレスが多くのユーザーを代表するかもしれないし、単なるラボかもしれない。一部の信号は古い可能性がある。一部のリゾルバは通知しないかもしれない。一部のネットワークは、実際の検証リゾルバを隠すような層を通じて転送しているかもしれない。
2017年の延期は、ICANN が不完全であってもテレメトリを決定に関連するものとして扱ったことを示している。これは優れたガバナンスだが、解釈を説明する責任も生む。テレメトリがリスクを示唆している場合、リーダーはそのリスクが延期するほど現実的かどうかを判断しなければならない。後にテレメトリが依然としていくつかの古い信号を示している場合、リーダーはそれらの信号が重大なユーザー影響を表しているのか、管理可能な残余ノイズなのかを判断しなければならない。
ロールオーバーレビューと技術アップデートは、この分析負担を示している。ICANN ロールオーバーリソースページは、技術アップデート、レビュー資料、事業者ガイダンスを一箇所にまとめている。2017年12月18日のルート KSK ロールオーバープロジェクトのアップデートは、延期後の分析状況を文書化している。このような文書の要点は完全な自信を生むことではなく、決定が噂に基づくことを防ぐことである。
テレメトリの説明責任には二つの側面がある。ICANN とルート事業者は、信号を過大に主張することを避ける必要があった。リゾルバ事業者はそれを無視することを避ける必要があった。あるネットワークのリゾルバが古いトラストアンカーを通知している場合、事業者は中央コミュニティが協力なしにローカル設定を特定して修正することを期待するのは妥当ではない。逆に、ICANN は、観測された古い信号が許容できないグローバルな障害を意味しない理由を示さずに進めることは妥当ではなかった。
このバランスは DNS を超えてますます関連性が高まっている。現代のインフラ変更は、しばしば分散したクライアント、エージェント、リゾルバ、証明書、パッケージマネージャ、エンドポイントからのノイズの多いテレメトリを伴う。KSK ロールオーバーからの教訓は、不完全な証拠は無力化されるべきでも、無視されるべきでもないということだ。それは透明な解釈と説明責任ある意思決定基準を引き起こすべきだ。
ICANN が制御したものとしなかったもの
ICANN は、IANA 機能と Public Technical Identifiers の役割を通じて、鍵セレモニー、公開、計画文書、コミュニティ協議、アウトリーチ、技術ガイダンス、理事会エスカレーション、実施/中止勧告、監視、イベント後レビューを含む中央 KSK プロセスを制御した。ICANN は、すべての検証リゾルバ、すべてのソフトウェアパッケージ、すべての ISP 変更ウィンドウ、すべてのエンタープライズ設定、すべての公共セクターDNS 契約を制御したわけではない。
Verisign はルートゾーン維持者機能を制御し、観測と調整に関連するルートサーバーインフラを運用したが、各ネットワーク内部のローカルなバリデーター状態は制御しなかった。リゾルバソフトウェアプロジェクトは RFC 5011動作と DNSSEC 検証の実装品質を制御した。アプライアンスベンダーとオペレーティングシステム配布者は、パッケージングとデフォルト動作を制御した。ネットワーク事業者は配備を制御した。公共機関や企業は調達、監視、フォールバック計画を制御した。
エンドユーザーはこれらのほとんどを制御しなかった。ISP のリゾルバが検証に失敗した場合、一般市民は原因が古いトラストアンカーなのか、DNSSEC 障害なのか、ルーティング問題なのか、アプリケーションの問題なのか、ウェブサイト停止なのかを知ることはできない。管理ルーターを使用する小規模企業は、自身の DNS アプライアンスが KSK-2017 を受け入れたかどうかを知ることはできない。この非対称性こそが、説明責任がユーザーではなくインフラ事業者に課せられるべき理由である。
したがって、説明責任の問いは「誰がインターネットを所有していたか？」ではない。誰も所有していなかった。問いは、ロールオーバーの結果として重要な各部分を誰が制御していたかである。ICANN は中央権限と公開調整を制御した。事業者は準備状況を制御した。ベンダーはコードを制御した。公共機関は継続性の期待を制御した。それぞれに異なる義務があった。
この階層化されたマップは、浅い成功物語も防ぐ。ICANN は証拠に基づいて延期し実施することでうまくやった。しかし将来のロールオーバーは、毎回英雄的なアウトリーチに依存するべきではない。リゾルバ事業者はトラストアンカーのインベントリを制度化すべきだ。ベンダーは検証状態を可視化すべきだ。公共機関はプロバイダーに DNSSEC 継続性の証拠を要求すべきだ。ルートゾーンガバナンスは計画とレビューを引き続き公開すべきだ。成功は、使い捨ての記憶ではなく、繰り返し可能なプラクティスになるべきだ。
次のロールオーバーは運ではなく証拠を継承すべきだ
ICANN の現在のルートゾーン KSK アルゴリズムロールオーバーページは、ルートゾーンの暗号保守が続いていることを示している。将来のアルゴリズムロールオーバーは、単に RSA 鍵を別の RSA 鍵に置き換えるのではなく、暗号アルゴリズムを変更するため、2018年の鍵ロールオーバーとは異なる。その将来の作業により、2018年の説明責任記録はより価値が高くなり、低くなることはない。最初のロールオーバーは、公開計画、アウトリーチ、テレメトリ、理事会承認、事業者ガイダンス、事後レビューのテンプレートを生み出した。
このテンプレートは改善されるべきである。第一に、テレメトリは事業者が自身のインフラストラクチャに結びつけやすくする必要がある。中央の信号は、事業者がどのデバイスがそれを生成したか分からない場合、あまり有用ではない。第二に、リゾルバソフトウェアは、通常のネットワークチームが監視できるような方法でトラストアンカーの状態を露出すべきである。第三に、公共セクターとエンタープライズの調達は、再帰 DNS を継続性インフラストラクチャとして扱うべきだ。第四に、検証の緊急無効化は、最後の手段として訓練され、復旧が続けられるべきであり、長期的な回避策として常態化してはならない。第五に、ICANN は、将来の延期や実施決定が既知の標準に照らして評価できるように、事前に決定基準を公表し続けるべきだ。
2018年のロールオーバーは、境界付けられた自信の価値も示している。ICANN は、一部の事業者が準備できていないことを認めた上で実施した。これは正直である。重要なインフラは、すべての参加者による完全なコンプライアンスを待つことはできない。しかし、正直な残余リスクは回復の証拠と組み合わせるべきである。つまり、誰が監視しているのか、問題がどのように検出されるのか、どの閾値がロールバックを引き起こすのか、事業者がどのように支援を受けるのか、事後の教訓がどのように公開されるのか、である。
同じ基準は公共セクターネットワークにも適用されるべきだ。機関は、誰が再帰 DNS を提供しているのか、検証が有効かどうか、ルートトラストアンカーが自動的に更新されるかどうか、DNSSEC 障害アラームが存在するかどうか、ルートゾーン暗号変更中にプロバイダーにどのように連絡するかを把握すべきだ。もし公共機関がこれらの質問に答えられないならば、説明責任を保持せずに継続性を委任したことになる。
永続的な教訓
ICANN の2016～2018年ルート KSK ロールオーバー記録は、運用説明責任の強力な例である。なぜなら、それには計画、警告信号、延期、パブリックコメント、改訂計画、理事会承認、実行、監視、レビューという居心地の悪い中間部分が含まれているからだ。物語は「ICANN が鍵を変え、何も起こらなかった」ではない。物語は、ICANN と DNS コミュニティが鍵の変更をグローバルな運用リスクとして扱い、リスクを管理できるほど可視化したということである。
ICANN の公開イベント後声明によれば、ロールオーバーは重大な持続的エンドユーザー影響なく成功した。その成功は、中央の調整と同じくらい、分散した準備に帰せられるべきだ。ICANN はルート KSK プロセスと決定を制御した。Verisign やその他のルート事業者は運用観測に貢献した。リゾルバベンダーと事業者は現場で検証を機能させた。公共および民間のネットワーク所有者は自身の継続性に対する責任を負った。
説明責任の教訓は永続的である。中央のトラストアンカーは公的な約束であり、プライベートな設定項目ではない。それが変更される場合、中央の権限を持つ組織は計画を公表し、テレメトリに耳を傾け、証拠がそれを正当化する場合には延期し、障害閾値を定義し、実践的な事業者の手順を伝達し、結果をレビューしなければならない。トラストアンカーに依存する事業者は、自身のシステムを理解し、準備状況をテストし、障害を監視し、回復を準備しなければならない。
最初の DNSSEC ルート KSK ロールオーバーは、将来のルート暗号変更がリスクフリーであることを証明したわけではない。権限が証拠と組み合わされ、技術的な自信がカレンダーを止めるのに十分なほど謙虚なままであった場合、共有インフラの変更は責任を持って実行できることを証明した。これこそが、次のロールオーバーが満たすべき説明責任の基準である。