概要
- 2018 年 10 月、ICANN による 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 キー署名鍵ロールオーバーは、1 つの暗号鍵の置き換えに縮小してしまえば、微視的なイベントのように聞こえる。運用上の観点からは、グローバルな依存関係のテストであった。DNS ルートは、公開ドメインネームシステムの委任階層の頂点である。DNSSEC 検証リゾルバは、署名された DNS データを検証するためにトラストアンカーを使用する。ルート KSK 変更後に、検証リゾルバ内のルートトラストアンカーが古いままだと、有効な回答を不正なものとみなし、そのユーザーに対する通常の名前解決に失敗する可能性がある。
ICANN の専用ルートゾーン KSK ロールオーバーページが基盤となる情報源である。同ページでは、ICANN が 2018 年 10 月 11 日にロールオーバーを実施したこと、KSK のロールとは新しい公開鍵と秘密鍵のペアを生成し、公開鍵部分を検証リゾルバの運用者に配布することであり、最新の KSK を維持することが不可欠であること、現在のルートゾーン KSK がないと DNSSEC 検証リゾルバが DNS クエリを解決できなくなることを説明している。これが説明責任の問題の全てを平易な言葉で表している。中央のトラストオブジェクトの変更が、分散した事業者がローカルの検証状態を更新していない場合に、ユーザー障害となるのである。
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 千万人が DNSSEC 検証リゾルバに依存しており、不手際なロールオーバーの影響を受ける可能性があると見積もった理由である。この数字は、それらのユーザー全員が失敗するという予測ではなかった。依存する人口の測定値であった。
この区別は重要である。ロールオーバーは障害ではなかった。それは、起こりうる障害の前に実施された説明責任のテストだった。公共インフラのガバナンスは、しばしば失敗の後に判断される。ここでは、ICANN が失敗の前に延期し、計画を再開し、さらなる証拠を集め、アウトリーチを拡大し、後に明示的なリスク受容を伴ってゴーの決定を下したため、ガバナンスの記録が意味を持つのである。
延期こそが説明責任の導火線だった
記録の中で最も重要なイベントは、成功したロールオーバーの前に起こった。ICANN の2017 年 9 月 27 日の延期発表は、DNS の保護に役立つ暗号鍵を変更する計画が延期されると述べた。ICANN は、最近得られたデータが、ISP やネットワーク事業者が使用する多数のリゾルバがまだ準備できていないことを示していると説明した。そして、この新たな可視性を、リゾルバがルートサーバーにどの鍵を設定しているかを報告できるようにした最近の DNS プロトコル機能に結びつけた。
その機能とは、検証リゾルバが設定されたトラストアンカーを通知する方法を定義したRFC 8145である。このプロトコルは ICANN に完全な知識を与えるものではなかった。それは、準備状況について、ノイズが多く、部分的で、運用上微妙な見解を生み出した。一部の信号は、設定ミスのあるシステム、テスト環境、フォワーダ、旧式のソフトウェア、古い設定、あるいは大規模ユーザーを抱えていないリゾルバからのものである可能性があった。しかし、不完全なテレメトリの存在そのものがガバナンス上のイベントであった。ICANN は、一部のリゾルバが古いままであるシグナルがあるにもかかわらず、スケジュール通りに進めるか、それともコミュニティがデータを解釈しアウトリーチを強化する間、延期するかを決定しなければならなかった。
ICANN は延期を選択した。この決定は、後のロールオーバーが成功したため、後知恵で賞賛するのは簡単である。当時は、それ自体のコストを伴っていた。延期は計画への信頼を損ね、2 つの鍵が公開されている期間を長引かせ、ICANN の DNSSEC 実施基準書で要求される運用演習を遅らせ、既に 2017 年の日付に向けて準備していた事業者に不確実性のシグナルを送る可能性があった。しかし、予定通りに進めていれば、リゾルバ事業者とそのユーザーは、名前が解決しなくなるまで準備問題を発見することになったかもしれない。
この延期発表は、インフラガバナンスとしては異例なほど率直である。事業者が新しい鍵をインストールしていない理由は複数ある可能性があり、リゾルバソフトウェアの設定が適切でない場合や、広く使われているあるリゾルバプログラムで、鍵を期待通りに自動更新していないように見える最近発見された問題を含む、と ICANN は述べた。また、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 ルートを保護する暗号鍵の初めての変更計画を理事会が承認し、ICANN に対し 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 が、追加のアウトリーチ、分析、コミュニティ協議の後に残存リスクを受け入れたことを意味した。この区別は説明責任の中心である。
ICANN の承認発表は、何千ものネットワーク事業者が DNSSEC 検証を有効にしており、インターネットユーザーの約 4 分の 1 がそれに依存しているという調査結果があると述べた。また、少なくともどこかの一部の事業者はほぼ確実に準備できていないだろうとも述べた。これは異常なほど正直なリスク言語である。それは完璧なロールを約束しなかった。それでも進めることが正当化される理由を説明したのである。予想される失敗は十分に小さく、リカバリ可能であり、キーロールオーバープロセスを実施する必要性に勝るものであったからである。
公的な記録には、逆転の概念も含まれていた。ICANN の最初のロールオーバーが成功裏に完了したとの発表は、後日、発生したいくつかの問題は迅速に軽減され、コミュニティが定義した逆転の基準に近づくようなシステム的な障害を示唆するものはなかったと述べた。この一文は、成功が事後の楽観だけでなく、明示的な運用上の基準に対して評価されたことを示しているため重要である。
DNSSEC における逆転は簡単ではない。検証リゾルバが状態を変えた後でルート KSK をロールバックすると、それ自体の複雑さが生じる可能性がある。しかし、逆転の基準を持つことで、リーダーはどの程度の害が決定を変えるかを定義せざるを得なくなる。そのような基準がなければ、チームは変更の勢いに巻き込まれる可能性がある。基準があれば、組織は少なくとも、安定性が完了よりも優先される場合の公的な判断基準を持つことになる。
したがって、ゴーの決定は ICANN のリーダーシップと理事会のガバナンスに属していたが、分散した証拠に依拠していた。トラストアンカーを更新していたリゾルバ事業者が準備を創出した。実装が正しく動作するソフトウェアベンダーが準備を創出した。シグナルを分析したルート事業者が準備を創出した。前提に挑戦したコミュニティレビュアーが準備を創出した。ICANN は調整し決定したが、分散システムを単独で準備させたわけではなかった。
これが説明責任マップの核心である。ICANN は中央のルート KSK 運用に対する権限と、アウトリーチおよび意思決定ガバナンスに対する責任を有していた。リゾルバ事業者は、自身の検証設定に対する責任を有していた。ベンダーは実装に対する責任を有していた。公共セクターや企業のネットワーク所有者は、継続性計画に対する責任を有していた。単一の当事者がシステム全体を掌握していたわけではないため、説明責任は想定されるのではなく、明示される必要があった。
イベント自体は静かだった。準備がそうではなかったからだ
2018 年 10 月 11 日、ICANN はロールオーバーを実施した。ICANN の 10 月 15 日のイベント後発表は、利用可能なデータの評価後、持続的かつ否定的に影響を受けた相当数のインターネットエンドユーザーは見られなかったと述べた。発生したいくつかの問題は迅速に軽減され、逆転を必要とするシステム的な障害を示してはいなかったと述べた。また、ICANN は次のキーセレモニーで古い KSK、KSK-2010 を 2019 年第 1 四半期中に失効させる手続きに進むと述べた。
その後の2018 年 DNSSEC KSK ロールオーバーのレビューは、最も強力な事後分析の情報源である。これは、KSK-2010 を 2018 年のロールオーバーまで使用されたトラストアンカーと定義し、KSK-2017 を 2018 年 10 月 11 日にルートゾーンの署名に最初に使用された鍵と定義している。また、最初の本番ロールオーバーからの教訓を文書化している。レビュー報告書は ICANN を自身の作業の中立的な観察者にするものではないが、勝利発表よりも価値がある。なぜなら、次のロールオーバーのための耐久性のある記録を作り出すからである。
イベントの静けさを、リスクが誇張されていた証拠と誤解してはならない。多くのインフラ変更は、まさに事業者が延期し、テストし、コミュニケーションし、監視したからこそ静かになる。崩壊前に弱点を見つける橋の負荷テストは、誤警報ではない。それがテストの要点である。したがって、2017 年の延期は 2018 年の成功の一部であり、それとは別の傷ではない。
イベント後の記録も、主張の範囲を抑制している。誰も影響を受けなかったとは言っていない。持続的かつ否定的なエンドユーザーへの影響が相当数なく、システム的な障害もなかったと述べている。これは、グローバルなインフラ変更に対する適切なレベルである。一部の個々の事業者はローカルな問題を抱えていたかもしれない。関連する問いは、ルートトラストアンカーの変更が、広範で持続的な DNS 解決の失敗を引き起こしたかどうかである。
古い鍵の失効ステップも重要である。ロールオーバーは、新しい鍵が使われたからといって終わりではない。古いトラストアンカーは、検証リゾルバが新しい状態を受け入れたことを確認する方法で退役させなければならない。ICANN のレビューとそれに続くセレモニー資料は、ロールオーバーが単一のタイムスタンプではなく、一連の流れであったことを示している。
ドメインが再委任されなくても、DNS 委任の力は現実である
「DNS 委任権限」というマニフェストラベルは、通常、ルートゾーンのエントリ、TLD 委任、レジストラ関係、名前の所有権に対する管理を連想させる。KSK ロールオーバーは、別の形の委任権限を示している。すなわち、ルートゾーン検証の信頼チェーンに対する管理である。ICANN は、TLD を再委任したり、登録者のドメインを変更したりしたわけではない。検証リゾルバが署名されたルートデータが信頼できるかどうかを判断するために使用する暗号鍵を変更したのである。
この権限には制約がある。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 トラストアンカーシグナリングは、可視性と不確実性を同時に生み出したため、ストーリーの中で最も興味深い部分の 1 つである。このシグナルは、リゾルバがどのトラストアンカーを設定していると考えているかを示すことができる。しかし、ルートサーバーは DNS トラフィックを見るが、組織の意図は見ない。1 つの可視的な送信元アドレスが多数のユーザーを表すこともあれば、単なるラボであることもある。一部のシグナルは古い可能性がある。一部のリゾルバはシグナルを送らないかもしれない。一部のネットワークは、実際の検証リゾルバを覆い隠す層を通じて転送されるかもしれない。
2017 年の延期は、ICANN が不完全であってもテレメトリを意思決定に関連するものとして扱ったことを示している。それは良いガバナンスだが、解釈を説明する責任も生み出す。もしテレメトリがリスクを示唆するなら、リーダーはそのリスクが延期するほどリアルかどうかを決定しなければならない。もし後のテレメトリが依然としていくつかの古いシグナルを示すなら、リーダーはそれらのシグナルが重大なユーザー影響を示すのか、管理可能な残存ノイズなのかを決定しなければならない。
ロールオーバーレビューと技術アップデートは、この分析上の負荷を示している。ICANN ロールオーバーリソースページは、技術アップデート、レビュー資料、事業者ガイダンスを一箇所に集めた。2017 年 12 月 18 日のルート KSK ロールオーバープロジェクトに関するアップデートは、延期後の分析状況を文書化した。このような文書の要点は、完璧な確信を生み出すことではない。決定が噂に左右されるのを防ぐことである。
テレメトリの説明責任には 2 つの側面がある。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 ロールオーバーは、将来のルート暗号変更がリスクフリーであることを証明したのではない。権限が証拠と対にされ、技術的な自信がカレンダーを止めるほど謙虚に保たれる場合、共有インフラの変更は責任を持って行われ得ることを証明したのである。これこそが、次のロールオーバーが満たすべき説明責任の基準である。