2002年のルート DNS 攻撃：分散サービス耐性が説明責任の試金石に

概要

2002年10月21日、分散型サービス拒否（DDoS）攻撃により DNS ルートサーバーシステムへの重要な経路が著しく劣化した。CAIDA は指定された監視地点から往復遅延の急激な変化を観測し、論理ルート識別子によって継続時間が異なっていた。[1]
ICANN は後に、13個の論理ルートサーバーアドレスのうち9個が「圧倒された」と説明した。この帰属付きの表現は攻撃の広がりの証拠であり、9つの完全なサービスが世界中で消滅したことや、すべてのリゾルバと利用者が失敗したことを証明するものではない。[5]
CAIDA は、グローバルなネットワーク運用への目に見える影響は軽微だったと結論付けた。再帰キャッシュ、再試行動作、複数の論理ルート識別子が、深刻なサーバーと経路のストレスを全面的なトランザクション失敗から切り離す助けとなった。[1][20][21]
CAIDA のパケット分析は、イベント直後から10分間隔で E、I、K、M ルートのリンクを対象とした。これらの観測は監視対象リンクの直接的な証拠であり、全ルートインスタンス、リゾルバ、経路、アプリケーションの全数調査ではない。[2][3]
RFC 2870と RFC 3258は、容量、多様な接続性、ログ、協力、分散型権威サービスが攻撃前から認識されていた制御であることを示す。ただし、攻撃日にすべての運用者がすべての制御を展開していたことを証明するものではない。[8][9]
後の anycast、RSSAC、SSAC、大規模権威サービスに関するガイダンスは、是正と測定の基準を提供する。これらは後の比較資料であり、遡及的な法的義務や2002年当時の正確なトポロジーの証明ではない。[6][10]-[16]
責任はルートサーバー運用者、トランジットおよびアクセスネットワーク、リゾルバ運用者、調整機関に分散していた。単一の機関がすべてのサーバー、経路、キャッシュ、フィルタ、利用者トランザクションを制御していたわけではない。
説明責任の基準は運用上のものである。記録は権限を特定し、到達可能な経路、正しい応答、リゾルバの継続性、境界のある緩和、複数視点での復旧の証拠がサービスの継続性を証明する。

権限の記録はサービスの保証ではない

ルートヒントのエントリは再帰リゾルバに DNS ルートサーバーがどこにあるべきかを伝える。ルートゾーンの記録は委任に責任を持つ権限を特定できる。しかし、どちらの記録もパケットを輻輳した経路に通過させたり、権威インスタンスに応答を強制したり、フラッド下で容量を維持したり、利用者のトランザクションが完了したことを証明したりはできない。

この区別は2002年10月21日に運用上重要になった。この日、分散型サービス拒否攻撃が DNS ルートサーバーシステムの論理アドレスに向けて大量のトラフィックを送り込んだ。このイベントはしばしば劇的なサーバー数に圧縮される。ICANN は後に、13個の論理ルートサーバーアドレスのうち9個が「圧倒された」と説明した。この表現は重要だが、サービス可用性の完全な説明ではない。9つの完全なサービスがすべての場所で消滅したこと、すべての再帰リゾルバが同時にルートに問い合わせる必要があったこと、利用者が全面的な障害を経験したことを確立するものではない。[5]

したがって、説明責任の問いは、アドレスが攻撃を受けていたかどうかよりも厳しい。容易に混同される複数の層を分離する必要がある。サーバーリンクに到着するトラフィック、特定のネットワーク経路から見える応答、異なるキャッシュ状態を持つ再帰リゾルバの動作、完了した利用者トランザクションの成功または失敗である。各層には独自の運用者、証拠、障害境界がある。

権威記録が重要なのは、リゾルバが使用すべきサービス識別子を確立するからである。それらは委任と権限の不可欠な台帳である。しかし、台帳は稼働中のシステムではない。運用上の継続性は、正しく応答できる権威インスタンス、到達可能な経路、十分な容量、障害ドメイン間の分散、キャッシュ情報を効果的に使用するリゾルバ、可能な範囲で有害なトラフィックを制約するネットワーク、緩和と復旧を調整できる運用者に依存する。

ルート DNS 到達可能性をイベントから取り除けば、サービス継続性の問題はなくなる。リゾルバキャッシュを取り除けば、サーバーのストレスが同等の利用者被害と誤って見なされやすくなる。権威サービスの分散を取り除けば、耐性設計を評価できない。経路多様性を取り除けば、需要が健全な容量に到達する方法を分析できない。送信元アドレスフィルタリングを取り除けば、トラフィック発生源エッジでの責任が消える。計測視点を取り除けば、局所的な観測が根拠のないグローバルな主張になる。運用者の連携を取り除けば、分散サービスがどのように検知し、緩和し、復旧を宣言するかの信頼できる説明はない。

2002年の攻撃はこれらの依存関係を可視化した。それは単一の機関が排他的な制御を持っていたことを示したのではなく、利用者が体験するサービスが記録、実行コード、ルーティング、キャッシュ、自律的な運用判断から組み立てられていることを示した。説明責任はこれらの実際的な制御と各管理者が提示できる証拠に従わなければならない。

2002年10月21日に観測されたこと

CAIDA の当時の計測報告は、UTC のおよそ22:00に往復遅延の急激な劣化を報告した。UCSD の視点からは、I と M を除く監視対象の全ルートで性能変化が見られたが、継続時間は一様ではなかった。CAIDA は F、G、L で約1時間、A と B で約5〜10分、J で10分強の影響が続いたと報告した。[1]

これらの観測は深刻なイベントの証拠を提供するが、すべてのネットワークからのルートサービスの普遍的な地図を提供するものではない。測定はサンディエゴとサンノゼのモニターに依存しており、特定の地点から特定の経路を通じて見えるサービスを記述していた。あるモニターから応答が悪かったルートアドレスは、別の上流、経路、地理的経路を使うリゾルバには異なる状態を示す可能性がある。逆に、測定サイトから応答が良く見えたルートでも、別のネットワークからは到達しにくい場合がある。

この制限は CAIDA に特有の弱点ではなく、分散サービス計測の基本的な性質である。モニターは自分の経路が見える範囲を記録する。その結果が広く意味を持つのは、地点、指標、時間間隔、対象が結論とともに明示された場合だけである。

CAIDA はまた、グローバルなネットワーク運用への目に見える影響は軽微だったと結論付けた。[1] この知見は攻撃のどのような再話にも制約を課す。深刻なトラフィックとルートサーバーの性能変化を、普遍的な利用者障害の自動的な証明として扱うことを排除する。さらに説明が必要である。DNS アーキテクチャは、権威ルートアドレスと個々のトランザクションの間にバッファを持つ。特に再帰キャッシュと複数のルートサービス識別子の利用可能性である。

D-Root の運用者履歴は、2002年10月21日を大規模攻撃の日として独立に特定し、運用者が後にイベントの分析を準備したと記している。[4] この記録は日付とインシデントの運用上の認識を裏付けるが、それだけではすべてのルート識別子やすべての物理インスタンスで同一の状態があったことを確立しない。

CAIDA の後のパケット分析は別の限定された視点を提供する。攻撃開始直後から E、I、K、M ルートにサービスするリンクで収集されたトラフィックを調べ、観測を10分間隔にグループ化した。リクエストと観測されたクライアントの分布は、これらのリンクからの直接測定である。[2] より広範な CAIDA ルートトラフィック研究は、それらの観測が位置するデータセットと方法論を説明している。[3]

E、I、K、M のリンクデータを、すべてのルート識別子、物理インスタンス、リゾルバ、アクセスネットワーク、アプリケーションの全数調査として扱ってはならない。それは攻撃進行中に開始され、指定されたリンクを対象とし、定義された観測間隔を使用した。その境界が分かるからこそ価値がある。この証拠の正しい使い方は、監視対象リンクにいつ何が現れたかを述べ、それらのサンプルをシステム全体の裏付けのない合計に変えることに抵抗することである。

したがって、3つのソース固有の記述は矛盾なく共存できる。

CAIDA は監視地点から、継続時間がルート識別子ごとに異なる経路性能変化を観測した。[1]
CAIDA は後に、選択された E、I、K、M リンクで10分間隔のパケットと見かけのクライアントを分析した。[2]
ICANN の2007年の比較では、2002年の攻撃中に13個の論理ルートサーバーアドレスのうち9個が「圧倒された」と記述された。[5]

それぞれ異なる対象を観測している。1つは測定された経路性能、もう1つは選択されたリンクのパケット、3つ目は論理アドレスを中心とした後の組織的要約である。責任ある分析はこれらの区別を保持する。

「13のうち9」がなぜ調査の出発点なのか

13という数字は論理ルートサーバー識別子を指す。論理識別子は必ずしも1台のマシン、1つのサイト、1つの経路と等価ではない。その運用上の実現は、責任を負う運用者が権威容量をどのように展開し、サービスアドレスをどのように広告するかに依存する。

この点は、2002年の物理的およびトポロジー的な分散がルートシステムの後の展開ほど広範ではなかったとしても重要である。公開された凍結証拠は、攻撃当日のすべての物理インスタンス、アクティブな経路、局所的な緩和策を列挙していない。したがって、インターネットのあらゆる部分から同時に到達可能だったハードウェアやサイトの正確な再構築を支持できない。

ICANN の表現は帰属付きの形で保持されるべきである。13個の論理ルートサーバーアドレスのうち9個が「圧倒された」と説明された。[5] 「圧倒された」は、攻撃が重要なサービス経路または容量を圧倒したことを伝える。それは普遍的な停止境界を定義しない。各アドレスに関連するすべての権威容量がどこでも失敗したとは言わない。すべてのリゾルバの再試行判断やキャッシュ状態を明らかにしない。完了したトランザクションを数えない。

サーバーアドレスの数は少なくとも4つの次元を省略する。

第一に、視点を省略する。到達可能性は関係的なものである。リゾルバは特定のネットワークから特定の経路を通じてアドレスに到達する。カリフォルニアで観測された応答失敗は、その経路と時刻についての証拠であり、ヨーロッパ、アフリカ、アジア、または別の北米ネットワークからの直接観測ではない。

第二に、時間を省略する。CAIDA が報告した性能変化はすべて同じ長さ続いたわけではない。[1] 時間間隔のない数は、あるアドレスでの短時間の劣化と別のアドレスでのより長い状態を組み合わせ、それらを運用上同一に見せることができる。

第三に、サービス分散を省略する。分散アドレッシング設計が展開されている場合、1つの論理識別子が複数のサービス地点で表現されることがある。そのような分散の存在、範囲、動作は、議論されている日付と識別子について実証されなければならない。後のトポロジーから推測することはできない。

第四に、リゾルバ層を省略する。再帰リゾルバは、各利用者リクエストに対してルートクエリを送信せずに、有効なキャッシュされた参照を使って応答できる。別のリゾルバは新しい情報を必要とし、別のルート識別子に再試行するか、別の経路に遭遇するかもしれない。サーバーアドレスの見出しはこれらの違いを解決できない。

したがって、この数は攻撃の深刻度の証拠であり、利用者被害の自己完結的な尺度ではない。正しい問いは、その数を最小化すべきかどうかではない。その数が何を測定し、何を省略し、それをサービス結論に変換するためにどのような追加証拠が必要かである。

この区別は説明責任を薄めるのではなく保護する。過負荷の各アドレスを普遍的なサービス消滅と安易に同一視すれば、運用者はどの制御が実際に被害を封じ込めたかを判別できない。キャッシュ、代替権威容量、経路多様性、連携が見えなくなる。一方、多くのトランザクションが依然成功したためとして数を無視すれば、攻撃が重要インフラに与えた圧力が過小評価される。防御可能な説明は両方の事実を同時に保持しなければならない。攻撃は重要なルートサービス経路を著しく劣化させたが、入手可能な証拠は普遍的な失敗を確立していない。

リゾルバキャッシュがインフラストレスと利用者被害を分離する

DNS 解決プロセスは、すべての利用者クエリがルートサーバーに移動することを要求しない。再帰リゾルバは許可されたキャッシュ生存期間の間 DNS 情報を保持する。リゾルバが解決を続行するために必要な参照をすでに保持している場合、そのトランザクションではルートサーバーに問い合わせずに、期限切れでないその情報を使用できる。[20], [21]

したがって、キャッシュは権威インフラへの攻撃と利用者に見える体験との関係を変える。一時的なサービスバッファを生み出す。バッファは無制限でも均一でもない。

2つのリゾルバが同じ攻撃に直面しても、キャッシュに異なるレコードと異なる残存生存期間があるため、異なる結果を経験する可能性がある。一方は人気ドメインに必要な参照をすでに持っているかもしれない。他方はキャッシュしていないか、キャッシュコピーが期限切れになった情報をルートに問い合わせる必要があるかもしれない。上流経路も異なる可能性がある。同じ論理ルートアドレスに問い合わせても、同じ応答状態を観測しないかもしれない。

これが、ルートサーバーアドレスへの深刻な攻撃が、アプリケーション全体で同等に深刻かつ同時的な失敗を引き起こす必要がない理由を説明する。また、サーバーテレメトリだけでは利用者影響の問題を解決できない理由も説明する。ルート運用者はトラフィックが急増したか、インスタンスでの応答が劣化したかを示せる。その証拠は不可欠だが、どの再帰リゾルバが影響を受けたサービスをその期間に必要としたか、どの利用者トランザクションが失敗したかは示さない。

逆の推論も安全ではない。即時の利用者に見える被害が限定的でも、インフライベントが重要でなかったことを意味しない。キャッシュデータは経年劣化する。到達可能な権威サービスの長期的な喪失は、ローカルで利用できなくなった情報を必要とするリゾルバを徐々に露出させる。アーキテクチャは衝撃を吸収できるが、その衝撃が無関係になるわけではない。

キャッシュは、再帰リゾルバ運用者がこのバッファの重要な側面を制御するため、説明責任マップに属する。彼らはキャッシュ動作、再試行、ルートヒント、利用者向け監視を管理する。彼らの証拠は、リゾルバが応答を続けたか、ルート識別子間でクエリを移したか、タイムアウトに遭遇したか、有用なキャッシュ情報を使い果たしたかを示すことができる。リゾルバ側のデータがなければ、評価はサーバーの苦境と逸話的な利用者体験の間に閉じ込められたままである。

ルートサーバーシステムと再帰リゾルバ集団も異なる時計で動作する。ルートインスタンスは即時のトラフィックスパイクを経験する。モニターは数秒から数分後に増加した往復遅延を観測できる。リゾルバへの影響はキャッシュ状態と再試行動作に依存する。利用者トランザクションはアプリケーション固有のタイミングと許容度を加える。これらの時計を「DNS がダウンした」というような1つの文に結合することは因果連鎖を消し去る。

CAIDA が報告した限定された結論、つまりグローバルなネットワーク運用への目に見える影響は軽微だったという結論は、この階層モデルに適合する。[1] 利用者レベルの正確な失敗率が入手できないため、影響を受けた利用者がいなかったという主張に一般化すべきではない。また、劇的なアドレス数のために捨て去るべきでもない。それは、キャッシュと残存する権威到達可能性を含む広範なシステムが、激しい圧力にもかかわらず相当なサービスを提供し続けたという証拠である。

したがって、説明責任にはストレス証拠と継続性証拠の両方が必要である。前者はインフラがどこで負荷を受けたかを示す。後者はリゾルバとトランザクションがタイムリーで正しい回答を得続けたかどうかを示す。一方が他方の代わりにはならない。

分散運用が耐性の所有権を変える

DNS ルートサーバーシステムはトポロジーだけでなく運用権限においても分散している。個々のルートサーバー運用者は、自らのインスタンス、容量計画、上流接続、ローカルフィルタリング、監視、インシデント対応を管理する。トランジットおよびアクセスネットワークは経路の他の部分を管理する。再帰リゾルバ運用者はキャッシュと再試行を管理する。調整・助言機関はこれらのドメインをつなぐが、自律性を消すものではない。

これは、責任をルートゾーンに関連する組織や後にファクトシートを公開した機関に還元できないことを意味する。ICANN、IANA 機能、RSSAC 関連構造はルートゾーン、調整、助言の役割を持つ。それらは2002年の攻撃中にすべてのルートインスタンスを運用する単一の指令系統を構成してはいなかった。

記録管理者と運用者の区別は中心的である。ルートゾーンとルートヒントの記録は、どの論理サービスが権限を持つかを特定する。これらの記録の正確性は不可欠である。誤った権限情報はリゾルバを誤ったサービスに向ける。しかし、正しい記録は経路が利用可能であること、インスタンスに容量があること、上流ネットワークが有害なトラフィックをフィルタリングすることを保証できない。

運用上の継続性は、それらの層を制御する当事者によって生み出される。ルート運用者は容量を追加し、サービスを分散し、上流を多様化し、インスタンステレメトリを収集できる。トランジットプロバイダーは経路を提供し、輻輳を管理し、自身のドメイン内で送信元妥当性制御を実施できる。アクセスネットワークは顧客ネットワークから出る不自然な送信元トラフィックを制約できる。リゾルバ運用者は信頼できるキャッシュと再試行動作を維持できる。調整機関は共通の期待と証拠形式を確立できる。どの役割も他のすべてを置き換えることはできない。

この分散は単純な排他的非難の割り当てを妨げるが、説明責任を排除しない。説明責任をより精密にする。各運用者は、実際に保有していた制御、当時利用可能だった証拠、他者の権限を奪わずに合理的に取れた行動に対して評価されるべきである。

ルート運用者にとって関連する問いは、正当なクエリが使用可能な権威容量に到達できたか、接続性が単一経路のボトルネックを回避するのに十分多様だったか、監視がインスタンス問題をより広範な経路問題から区別したか、復旧が運用者自身のネットワーク外から実証できたかを含む。

トランジットおよびアクセスネットワークにとって、問いは経路容量、ルーティング動作、ネットワークエッジでの制御に関する。ルート運用者はすべての発信元アクセスネットワークで送信元アドレスを直接検証できない。アクセスプロバイダーはすべてのルートサービスが容量をどのように分散するかを指示できない。彼らの義務は制御が異なるため異なる。

リゾルバ運用者にとって、問いは利用者への継続的サービス、キャッシュ動作、再試行結果、上流ルートの苦境とローカルリゾルバまたはアクセス障害を区別する能力に関する。

調整機関にとって、説明責任は共通の期待、情報交換、インシデント分析、比較可能な指標の質に関するものであり、独立に運用される各サービスに即時命令を発する架空の権力に関するものではない。

利用者は最も弱い立場にある。低速または失敗したトランザクションを観測できるが、通常はルートリンクの負荷、ルーティング変更、キャッシュ内容、運用者間の連携を検査できない。証明責任を利用者に負わせるシステムは制御構造を逆転させる。証拠は関連するテレメトリを保有する運用者から来るべきである。

したがって、分散責任は中央集権的主権でも運用上の曖昧さでもない。制御マップである。マップは、誰が状態を観測できたか、誰がそれを変更できたか、誰が他者に依存したか、後のレビューのためにどのような証拠が残るべきかを問うことを可能にする。

容量と多様性は攻撃前から認識されていた制御だった

2002年のイベントは概念的な空白の中で起きたのではない。攻撃前に公開された RFC 2870は、ルートネームサーバーの運用要件を定めていた。標準準拠サービス、測定されたピーク需要を上回る容量、多様な接続性、権威専用運用、ログ、セキュリティ分析における協力を扱っていた。[8]

これらの期待は、権威インフラをより耐性にする制御の種類を特定するため、攻撃に直接関連する。容量の余裕は異常な需要をある程度吸収できる。多様な接続性は1つのプロバイダーまたは経路への依存を減らす。権威専用運用はサービス役割を狭める。ログと協力的分析は検出と再構築を支援する。

しかし、この文書は2002年10月21日のすべての運用者の展開状態を証明できない。RFC の運用要件は、すべてのルート識別子が同じアーキテクチャを実装し、同等の容量を持ち、同じテレメトリを記録したという証拠ではない。また、法的義務、過失、違反を確立するものでもない。それらの結論にはここで提供される技術記録を超えた証拠が必要である。

RFC 2870はイベント前の文脈として最適に使用される。容量、接続多様性、ログ、協力がすでに重要な運用制御として理解されていたことを示す。[8] 後のアーキテクチャがすでに普遍的だったと偽ることなく、これらの領域への説明責任調査を可能にする。それ自体で調査に答えるものではない。

2002年4月に公開された RFC 3258は、共有ユニキャストアドレスを使用して権威ネームサービスを分散することを説明した。[9] この設計は、サービスアドレスを複数の地点から発信し、ルーティングがどの地点がクエリを受信するかを決定することを可能にする。また、独自の運用境界も導入する。配置が重要であり、ルーティング動作が重要であり、権威データは分散サービス全体で一貫していなければならない。

タイミングは重要だが慎重に扱わなければならない。RFC 3258は、ルーティングを通じた分散権威サービスが10月の攻撃前に文書化されていたことを示す。しかし、すべてのルート識別子がそれを展開していたこと、すべての展開が同等だったこと、ルートシステムがすでに後の anycast フットプリントを持っていたことを確立しない。

容量と分散は異なる問題を解決する。1つの地点での容量増加はより大きな局所的フラッドに耐えるかもしれないが、その地点にサービスする経路と上流リンクに依存し続ける。より多くの地点は需要を分散し共有故障を減らすが、分散は経路が正当なクエリを到達可能な容量に向け、インスタンスが一貫した回答を提供する場合にのみ有用である。十分なサービス容量のない経路多様性は、より多くの過負荷経路を露出させるだけである。経路多様性のないサービス容量は到達不能のままである。

したがって、攻撃は単一の制御ではなく連鎖をテストする。

権限記録が正しい論理サービスを特定しなければならない。
ルーティングがクエリを運用中のインスタンスに届けなければならない。
経路とインスタンスに十分な使用可能容量がなければならない。
分散インスタンスが一貫した権威回答を返さなければならない。
リゾルバ動作が利用可能なサービスを効果的に使用しなければならない。
監視が連鎖のどのリンクが損なわれているかを明らかにしなければならない。
損なわれたリンクが組織境界を越える場合、運用者が連携しなければならない。

すべてのリンクに証拠要件がある。設定ファイルは意図された権限を証明できる。経路観測は広告された到達可能性を示せる。インスタンステレメトリは負荷と応答動作を示せる。リゾルバ測定は実際の解決を示せる。トランザクションテストは利用者向けの完了を示せる。信頼できるインシデント後説明は、1つのカテゴリを他のすべての代替として使用すべきではない。

共有ユニキャストと攻撃当日のトポロジーを書き換える危険

後の耐性改善は、以前のシステムを実際より単純に見せることがある。ルートサーバーシステムのその後の anycast による拡大は特にこの歪みを生みやすい。

RFC 4786は後に、同じサービスアドレスが複数の離散的な地点から広告される anycast 運用モデルを定義した。[10] RFC 7094は、トポロジー、ルーティング、サービス動作の関係を含む、anycast 分散のさらなるアーキテクチャ上の考慮事項を展開した。[11] RFC 7720は後に、ルートネームサービスのプロトコルおよび展開要件を説明した。[12]

これらの出版物は有用な比較基準を提供する。論理サービスアドレスが自動的に1台の物理マシンと解釈されるべきではない理由と、ルーティングがサービス提供の一部である理由を説明する。また、運用上のリスクを特定するのにも役立つ。配置が不均一になる可能性、経路が需要を移動させる可能性、サイトごとに容量が異なる可能性、分散インスタンスが一貫したサービス動作を必要とする可能性である。

それらは後の展開を過去に投影する許可証ではない。証拠は、2002年10月21日に普遍的なルート anycast があったという主張も、攻撃当日の分散の完全な識別子別地図も支持しない。RFC 3258のイベント前公開は、共有ユニキャスト分散が文書化された技術だったことを確立する。[9] 普遍的な実装を確立しない。

ICANN の2007年のファクトシートは、後のルート攻撃を2002年のイベントと比較し、後の攻撃の利用者影響が低かった理由の一部を、2002年以降に開発された anycast 展開と改善された運用者連携に帰した。[5] この比較は、分散と連携がより重要な耐性制御になったという結論を支持する。後の制御を遡及的な義務に変換したり、1つの是正策がイベント間のすべての違いを説明したと証明したりはしない。

責任ある比較は因果的かつ限定的である。分散サービスは、1つの論理アドレスに向けられたフラッドが関連するすべての容量を消費するのを難しくする。ルーティングがトラフィックを複数の地点に届ける可能性があるからである。経路と上流の多様性は一部の障害を隔離できる。より多くの観測点は地域差を明らかにできる。連携は運用者が攻撃指標を交換し、正当なトラフィックを保護するのを助ける。

しかし、anycast は呪文ではない。複数サイトで同じアドレスがあっても、同等の到達可能性、バランスの取れた負荷、独立した上流、十分な容量を保証しない。ルーティングポリシーがトラフィックの行き先を決める。配置が悪いまたは供給不足のサイトは依然として苦しむ。経路変更は需要をリダイレクトできる。すべてのインスタンスを1つの論理ラベルの下に集約する監視は、局所的な苦境を隠す可能性がある。

したがって、分散の説明責任上の価値は実証可能な結果にある。運用者は、どのインスタンスがアドレスにサービスしたか、どの経路がそれらを露出したか、トラフィックがどのように移動したか、正当な応答がタイムリーで正しいままであったか、障害が封じ込められたかを示せるべきである。anycast ラベルの存在だけでは十分ではない。

これは分析を稼働中のサービスに戻す。ルートヒントにリストされた論理アドレスは、サービスが利用可能であるべき場所を特定する。分散展開はその識別子を実現するより多くの方法を生み出す。攻撃中に多様なネットワークからその実現が機能したかどうかを示せるのは測定だけである。

測定は時計、層、視点を特定しなければならない

2002年の証拠は、インフラ説明責任に規律ある測定言語が必要な理由を示している。「ルート」に関する記述は少なくとも5つの異なる対象を指し得る。

測定層	確立できること	単独では確立できないこと
リンクとパケット負荷	定義された間隔中に監視対象リンクで見えるトラフィック量と見かけのクライアント	すべてのルートリンクの状態または利用者トランザクションの成功
経路性能	指定されたモニターから論理アドレスへの到達可能性または応答劣化	すべてのリゾルバまたは地域からの到達可能性
権威サービス	観測されたインスタンスがタイムリーで正しい DNS 回答を返したか	下流リゾルバのキャッシュ状態と動作
再帰リゾルバ	キャッシュ、再試行、利用可能なルートを通じて解決が継続したか	すべてのアプリケーションまたは利用者が経験した状態
完了したトランザクション	定義されたネットワークから特定の利用者向け操作が成功したか	すべての基盤 DNS コンポーネントのグローバルな健全性

CAIDA のイベント記述は主に経路性能層に位置する。UTC のおよそ22:00に往復遅延の変化と、監視対象ルート間で異なる見かけの継続時間を報告した。[1] これらの測定は、指定されたサイトからの観測として表現される場合、強力な証拠である。グローバルな可用性主張に変換されると弱くなる。

後の E、I、K、M 分析はリンクとパケット層に位置する。10分間のグループ化が時計を提供し、監視対象リンクが範囲を提供する。[2] データセットコンテキストは、そのようなルートトラフィック観測がどのように組み立てられたかを説明する。[3] 分析はそれらのリンクが見たものを特徴づけられるが、すべての物理的発信元、すべての経路、すべてのリゾルバの結果を確立できない。

ICANN の「13のうち9」の説明は論理アドレスの要約である。[5] 指定されたサービス全体への圧力の広がりを捉えるが、経路、インスタンス、リゾルバ、トランザクションの証拠を置き換えない。

したがって、信頼できるインシデント再構築は、主要な記述ごとに4つの修飾子を付けるべきである。

対象：観測は論理アドレス、物理的またはトポロジー的インスタンス、リンク、経路、リゾルバ、トランザクションのどれに関するものか。
視点：どのネットワークまたは監視位置から観測されたか。
指標：証拠はトラフィック量、往復遅延、応答率、正確性、タイムアウト動作、完了した解決のどれか。
間隔：状態がいつ始まり、継続時間がどのように測定され、復旧がいつ確認されたか。

これらの修飾子がなければ、異なる測定が実際には異なる層を記述しているのに矛盾しているように見せられることがある。ルートリンクが高負荷でも、リゾルバはキャッシュから応答し続けることができる。モニターは1つの経路から劣化応答を見ても、別の経路は使用可能なままである。1つの権威クエリがタイムアウトし、再試行が別のサービス識別子に到達しても、トランザクションは成功し得る。

後の RSSAC 出版物は、ルートサービスの期待と測定をより一貫させるための比較基準を提供する。RSSAC のサービス期待に関する作業は、提供されるサービスの観点からルートサーバーシステムを捉え、共通測定フレームワークは運用者間で比較可能な証拠を求める。[13], [14] RFC 9199も同様に、大規模権威 DNS サーバーシステムのための後の運用上の考慮事項を提供する。[16]

これらの後の文書は、2002年にすべての運用者を統制した義務として提示すべきではない。その価値は遡及的かつ前向きである。将来のイベントを宣言、比較、終了しやすくするために証拠をどのように構造化できるかを示す。

測定の説明責任は復旧にも適用される。運用者の内部グラフが正常に戻ることは有用だが、外部リゾルバが依然として回答を得られない場合は十分ではない。モニターの回復はすべての場所での回復を証明しない。リゾルバが1回成功したことは持続的な安定性を確立しない。復旧は、インスタンスの健全性、経路到達可能性、権威の正確性、リゾルバの成功、地理的またはトポロジー的に多様な外部観測の複数層によって支持されるべきである。

目的は不可能なグローバル全数調査ではない。分散システムがそれを提供することはまれである。目的は、意思決定者が何が分かっているか、何が推測されているか、何が未知のままかを判別できるほど範囲が明示的な、境界のある証拠である。

実際の制御が実際の説明責任を決定する

分散サービスには、実際の制御に従う責任モデルが必要である。そのモデルは過失を主張せずに述べることができる。

主体	主な制御	期待される証拠
ルートサーバー運用者	インスタンス配置、権威容量、上流多様性、ローカルフィルタリング、監視、インシデント対応	インスタンス別およびリンク別の健全性、応答動作、経路コンテキスト、緩和タイミング、復旧証拠
トランジットおよびピアリングネットワーク	経路容量、経路伝播、輻輳管理、ネットワークドメインフィルタリング	経路とトラフィックの変化、影響を受けた経路、フィルタリング措置、関連ネットワークからの到達可能性
アクセスネットワーク	顧客エッジ制御とドメイン内の送信元アドレス妥当性	展開範囲、例外、検証結果、利用可能な場合は攻撃関連の観測
再帰リゾルバ運用者	キャッシュ動作、再試行、ルートヒント、利用者向け解決監視	キャッシュ依存の成功、タイムアウトと再試行パターン、ルート選択結果、リゾルバ復旧
調整および助言機関	共通の期待、情報交換、証拠形式、インシデント後分析	タイムリーな通知、共通用語、比較可能な測定、記録された決定、境界のある知見
エンドユーザー	アプリケーション要求とローカル観測	トランザクション症状、利用者が隠れたインフラ状態を再構築する期待なし

ルート運用者は権威サービスに対して最も直接的な制御を持つが、すべてのパケット経路に対してではない。容量を分散し、上流を選択し、インスタンスを監視し、ローカル緩和を適用できる。すべての発信元ネットワークが有害なトラフィックを発するのを単独で防ぐことはできない。

トランジットおよびピアリングネットワークは、トラフィックが特定の経路を通じて権威容量に到達できるかを制御する。輻輳、経路可用性、サイト間の需要移動に影響を与えられる。提供された証拠は2002年の攻撃中のすべての経路またはピアリング決定を再構築しないため、特定の経路介入を推測すべきではない。完全な経路記録の欠如自体が説明責任の教訓である。サービス主張には、インスタンス枯渇と経路障害を区別するのに十分なルーティング証拠を添付すべきである。

アクセスネットワークは異なる制御を持つ。自ドメインから出るトラフィックがそのドメインにとって妥当な送信元アドレスを使用しているかを評価する立場にある。それは彼らをルートシステムの管理者にするわけではない。攻撃されたサーバーが宛先で完全に実施できないリスク境界に責任を持つようにする。

再帰リゾルバ運用者は、通常の DNS 使用に最も近いコンポーネントを制御する。キャッシュは継続性を維持でき、再試行は残存サービスを見つけられ、監視はルートストレスが解決失敗に変換されているかを明らかにできる。リゾルバ運用者はルート容量を制御しないが、利用者影響の伝播に関する決定的な証拠を提供できる。

ICANN と関連調整構造は別の層を占める。ルートゾーンと制度的役割は、ICANN をサービスエコシステムと後の分析に関連させるが、独立に運営されるルートサービスに対する排他的な運用制御には相当しない。助言構造も同様である。期待を定義し、連携を促進し、証拠を改善できるが、すべてのインスタンスを直接運用するわけではない。

SSAC の DDoS リスクと協調 DNS 制御に関する助言、およびその作業に対応する制度的記録は、この調整層の後の発展を示す。[6], [7] ルートサーバー運用者の脅威緩和フレームワークも同様に、耐性が単一の指令点ではなく運用者の制御と協力から生まれる分散モデルを反映している。[15]

制御の所有権は3つの問いで評価されるべきである。

第一に、誰が状態を観測できたか？ルート運用者はインスタンスとリンクのテレメトリを見る。トランジットネットワークは自ドメイン内のトラフィックと経路を見る。リゾルバ運用者はタイムアウト、キャッシュ使用、再試行を見る。利用者はトランザクション症状を見る。

第二に、誰が状態を変更できたか？ルート運用者はサービス容量を追加または再配分できる。上流はルーティングまたは緩和を変更できる。アクセスネットワークは不自然な送信元トラフィックを制約できる。リゾルバ運用者は堅牢な再試行とキャッシュ動作を維持できる。調整機関は通信を整列できるが、それらの運用行動を代替できない。

第三に、誰が復旧を証明できるか？単一の主体がすべてのピースを持つわけではない。ルート運用者はサービス回復を示せ、ネットワークは経路とトラフィックの正常化を示せ、リゾルバ運用者は新たな解決成功を示せ、外部モニターは到達可能性をテストできる。信頼できる終了報告は、1つの管理者から来たと偽らずにこれらの記録を結合する。

このモデルは説明責任を工学分野に変える。システムを排他的に運用していなかった1つの機関を非難する極端と、分散運用を誰も結果を説明しなくてよい理由として扱う極端の両方を避ける。

入口フィルタリングは上流の責任であり、万能薬ではない

送信元アドレスフィルタリングは、サービス拒否トラフィックが攻撃対象サービスから遠く離れた弱点を悪用できるため、分析に属する。RFC 2827は、偽造送信元アドレスを持つトラフィックを減らすことを意図した入口フィルタリングを説明している。[17] RFC 3704は、マルチホームネットワークと非対称ルーティングによって生じる複雑さを含むフィルタリングの考慮事項を展開している。[18] RFC 4732は、サービス拒否をネットワークの複数部分にわたる注意を必要とするインターネット全体の工学的問題として扱っている。[19]

これらの文書は制御境界を特定する。自社の顧客または下流から正当に発信されるべき送信元アドレスを知るネットワークは、複数のネットワークを経由した後にパケットを受信するルートサーバーよりも、不自然なトラフィックを拒否する立場にある。

この原則は、2002年の攻撃が特定のスプーフィング手法に依存していたことを確立しない。提供された公開証拠は、完全な送信元集団、攻撃者、動機、パケット生成方法を特定しない。スプーフィング対策標準の存在からこれらの事実を推測するのは不適切である。

入口フィルタリングも分散フラッドに対する単一ネットワークの治療法ではない。1つのアクセスネットワークで偽造送信元をフィルタリングしても、他のネットワークからの有害なトラフィックを防げないし、有効な送信元アドレスを使うトラフィックを止めない。その有効性は、関連する発信エッジ全体での展開、正確なポリシー、正当なルーティング複雑性への対応に依存する。

この制御は依然として重要である。宛先側防御は発信エッジのすべての弱点を修復できない。偽造送信元トラフィックがアクセスネットワークから出ることを許されると、攻撃されたサービスは、より識別力のある実施点を通過した後に症状を見る。逆に、過度に広範なフィルタリングは正当なマルチホームトラフィックを害し得る。説明責任には、制御が不自然な送信元に対して効果的であり、正当な接続を維持するのに十分精密であるという証拠が必要である。

したがって、適切な問いは境界付けられている。

ネットワークは実際に統治できるドメイン内で送信元妥当性制御を展開したか？
マルチホーミングと非対称経路の例外は理解されテストされたか？
運用者は制御が何を受け入れ拒否したかを示す証拠を収集したか？
フィルタリング変更は正当なサービスの改善と相関付けられるか？
緩和は有害なトラフィックを他へ移動させたか、新たな到達可能性障害を生んだか？

これらの問いのいずれも2002年の攻撃者を特定しない。アクセスネットワークに排他的責任を割り当てない。関連する制御の一部が上流に存在する場合に、分析がすべての負担を権威サーバーに負わせないことを保証する。

経路多様性、ピアリング、トランジット容量はフィルタリングと並んで属する。ルートインスタンスは十分な計算容量を持っていても、上流経路が飽和していれば到達不能のままである。別のインスタンスは健全でも、ルーティングが影響を受けたリゾルバをそこに向けないためほとんどトラフィックを受けない。フィルタリングは特定のトラフィックリスクを減らし、多様性は代替配信経路を維持し、サービス分散は追加の容量エンドポイントを生み出す。制御は互いに補完するが交換可能ではない。

連携は運用上の制御であり、中央指令の主張ではない

分散運用者モデルは、単一の当事者がシステム全体を制御しないからこそ連携に依存する。急速に進行する攻撃の間、運用者は観測しているものの共通用語、境界のある証拠を交換するチャネル、局所的緩和とシステム全体の復旧を区別する方法を必要とする。

連携を許可と混同してはならない。ルート運用者は、中央機関がすべての技術的行動を指示するのを待たずに自らのサービスを保護できなければならない。トランジットネットワークは自ドメイン内で行動しなければならない。リゾルバ運用者はローカルサービスを維持しなければならない。連携は、それらの自律的行動が共有結果に影響するときに価値を持つ。

2002年の記録は共通証拠がなぜ重要かを示す。CAIDA は指定されたモニターからの経路性能を説明した。[1] 後の分析は選択されたルートリンクでのパケットを説明した。[2] ICANN は論理アドレスを要約した。[5] D-Root はイベントを運用者履歴に記録した。[4] 各説明は有用だが、異なる対象を慎重に調整しなければならない。

後の SSAC、RSSAC、運用者出版物はその証拠問題への応答として読める。協調制御、サービス期待、共有測定、脅威緩和を強調する。[6], [13]-[15] その関連性は将来の可観測性と対応の改善にある。2002年10月にそのようなメカニズムがすべて必須または展開されていたと宣言するために使用すべきではない。

効果的な連携は測定可能な成果を持つ。運用者は、共有イベントを認識した時刻を記録し、どのサービス識別子またはインスタンスが影響を受けたかを述べ、ルーティングとフィルタリングの変更を記録し、復旧を宣言するために使用した証拠を特定し、範囲に関する意見の相違を保持できる。グローバルラベル、つまり「アップ」か「ダウン」しか生み出さない連携プロセスは、分散システムを捉えない。

公開結論は内部の確信より狭くあるべきである。運用者が不完全な可視性を持つ場合、正しい宣言は境界のあるものである。指定されたインスタンスと外部視点でサービスが復旧し、他の地域は未検証のままである。明示的な不確実性は、裏付けのない普遍性より説明責任がある。

測定可能な耐性と復旧のテスト

この攻撃の中心的教訓は、後の1つの技術がルート DNS リスクを解決したということではない。耐性主張はサービス経路全体にわたる証拠に変換されなければならないということである。

防御可能な説明責任テストは7つの接続された段階に整理できる。

1. 権限の完全性

最初の問いは、リゾルバが期待されるルートサービス識別子を特定する正確な記録を持っているかである。ルートゾーンとルートヒント情報がこの台帳機能を果たす。これらの記録が誤っていれば、正しい宛先の稼働容量に決して到達しないかもしれない。

権限の完全性は必要だが十分ではない。この段階を通過することは、システムが意図されたサービスを指していることを証明する。それらのサービスが到達可能であることを証明しない。

2. 多様なネットワークからの到達可能性

第二段階は、論理アドレスが複数の独立したネットワーク地点から到達可能かをテストする。測定は、可能な場合は視点、経路、指標、間隔を示すべきである。

CAIDA の観測は、この規律がなぜ重要かを示す。報告された往復遅延の変化は、特定のモニターからの実際の測定だった。[1] 現代の耐性評価はそのような視点の数と多様性を拡大すべきだが、モニターがカバーする以上の地理を主張することに抵抗しなければならない。

この段階での合格は、すべてのプローブが同一の性能を報告することを要求しない。運用者がサービスが健全、劣化、未検証の場所を理解し、地域的障害をグローバル平均の内に隠すことを避けることを要求する。

3. 使用可能な権威サービス

到達可能性は、タイムリーで正しい権威回答につながらなければならない。使用可能な応答を返さないアドレスへの経路は継続性を提供しない。運用者は、リンク飽和、インスタンス枯渇、誤った回答、正当なトラフィックを落とすローカル緩和を区別すべきである。

分散は、開示が運用上安全な場合はインスタンスレベルで説明されるべきである。関連する証拠には、どのサービス地点が利用可能だったか、容量が共通ボトルネックを避けるのに十分独立していたか、同じ権威データがそれら全体で提供されたかが含まれる。

RFC 2870は容量、多様な接続性、ログ、協力に関するイベント前の文脈を提供する。[8] RFC 3258は初期の分散サービスモデルとそのルーティングおよび一貫性の懸念を提供する。[9] 後の anycast およびルートサービス文書は比較を洗練する。[10]-[12] いずれも攻撃固有のテレメトリの代わりにならない。

4. リゾルバの継続性

第四段階は、再帰リゾルバがキャッシュ、再試行、到達可能なルート識別子を通じて回答を得続けられるかをテストする。この段階は、評価がサーバーの苦境をトランザクション失敗と同一視するのを防ぐ。

リゾルバの結果は可能な場合キャッシュ状態別に分離すべきである。暖かいキャッシュはアーキテクチャのバッファが機能したことを示す。未キャッシュまたは期限切れ情報を必要とするクエリは、現在の権威到達可能性をより直接的にテストする。どちらも重要だが、異なる問いに答える。

RFC 1034と RFC 1035は、この境界を生み出すリゾルバとキャッシュ動作の基礎を提供する。[20], [21] 2002年イベント中のグローバルリゾルバ集団の正確なキャッシュ状態は未知のままであり、サーバーデータだけから再構築できない。

5. 正当なトランザクション完了

第五段階は、実際のまたは代表的な利用者向け解決が完了するかを測定する。トランザクション証拠は、少数の成功したテストをグローバルな証明として提示するのではなく、アクセスネットワークと時間枠を示すべきである。

この段階は、インフラ性能が利用者影響になる場所である。それでも慎重に解釈すべきである。トランザクションはローカルリゾルバ、アクセス経路、ルートより下の権威依存、アプリケーションタイムアウトのために失敗する可能性がある。ルート関連の帰属には、失敗を関連するルートサービス状態に結び付ける証拠が必要である。

CAIDA の目に見えるグローバル運用影響は軽微だったという結論は、重要なイベント固有の境界である。[1] すべての利用者体験を定量化しないが、普遍的な崩壊の主張を防ぐ。

6. トラフィック発生源と経路制御

第六段階は、権威サービスの外側の制御をテストする。ネットワークは、送信元アドレス検証の姿勢、経路容量、関連するルーティングまたはフィルタリングの変更を説明できるべきである。

RFC 2827と RFC 3704は入口フィルタリングの原則とその運用上の限界を特定する。[17], [18] RFC 4732はサービス拒否緩和を分散工学的文脈に置く。[19] この段階の証拠は、すべての攻撃トラフィックが偽造送信元を使用したと仮定すべきではない。どの制御が利用可能だったか、どこに適用されたか、変更が正当なトラフィックを維持したかを示すべきである。

経路多様性も主張ではなくテストされるべきである。複数の上流名は独立した障害ドメインを証明しない。複数の経路は影響を受けたリゾルバが健全な容量に到達することを保証しない。有用な評価は経路観測をサービス結果に結び付ける。

7. 調整された宣言と復旧

最終段階は、運用者がイベントがいつ宣言され、どのサービス境界が影響を受け、何が変わり、回復がどのように検証されたかを述べられるかを問う。

後の RSSAC 測定作業は比較可能なルートシステム証拠のフレームワークを提供し、運用者の脅威緩和と大規模権威サービスガイダンスは追加の比較点を提供する。[13]-[16] これらの後の資料は、遡及的な攻撃当日の義務と誤って表現されることなく、現在の期待を導くべきである。

復旧は複数の指標間の合意を必要とするべきである。

影響を受けたインスタンスのトラフィックと応答状態が安定した。
経路が多様な外部ネットワークから健全なサービスを到達可能にする。
権威回答が正しくタイムリーなままである。
リゾルバテストが関連するキャッシュ条件で成功する。
正当なトランザクションテストが回復する。
緩和が同等のアクセシビリティ障害を生まない。
残る未知の地域またはサービス識別子が明示的に記録される。

単一の指標が連鎖全体を証明できない。一緒に、境界のある再現可能な宣言を支持できる。

このフレームワークは是正を測定可能にする。「anycast を追加する」「容量を増やす」「連携を改善する」は不完全な約束である。是正策は、どの障害境界に対処するか、それが機能したことを示す証拠を述べるべきである。追加インスタンスは到達可能性または障害隔離を改善すべきである。容量増加は定義された経路での使用可能余裕を増やすべきである。フィルタリングは正当な送信元を排除せずに有害なトラフィックを減らすべきである。連携は検出を短縮し、範囲を整列させ、比較可能な復旧証拠を生み出すべきである。

攻撃は主権問題ではなく継続性問題を露呈した

2002年のイベントは、どの機関がルートを制御したかをめぐる争いと誤解される可能性がある。その枠組みは運用上の障害境界を見逃す。

ルート記録は、応答することが期待される論理サービスを特定した。攻撃は主にそれらの記録の存在に挑戦したのではなく、リゾルバが利用可能なネットワークを通じて稼働中の権威容量に到達できるかに挑戦した。

この区別が重要なのは、記録とサービスが異なる説明責任特性を持つからである。記録は正確性と許可された変更について監査できる。サービスは到達可能性、正確性、容量、継続性についてテストされなければならない。記録を維持または調整する機関は、それを実現するすべての経路とサーバーを自動的に制御するわけではない。

したがって、ルートサーバー運用者の実際の自律性は説明責任の障害ではない。説明責任設計が反映しなければならない事実である。各運用者は自らのインスタンスの証拠を提示し、システムレベルの見解で協力できるべきである。トランジットおよびアクセスネットワークは経路とエッジ制御について説明すべきである。リゾルバ運用者は利用者に提示された継続性について説明すべきである。調整機関はすべての運用行動を指揮すると偽らずに共通記録を保持すべきである。

この現実層アプローチはガバナンスのスローガンより厳格である。システムが稼働したか、どこで到達可能だったか、どの制御が攻撃を吸収したか、復旧がどのように実証されたかを問う。また、権限記録が魔法の保証として扱われるのを防ぐ。台帳の正しい名前はパケットを動かさない。

同じアプローチは予防に関する主張を制約する。提供された証拠は、1つの運用者または機関が単独で攻撃を防げたことを示さない。1つのルートでの容量増加は他のルートでのトラフィックを制御しない。1つのアクセスネットワークでのフィルタリングはすべての送信元を制約しない。リゾルバのキャッシュはデータを無期限に保持しない。連携はそれ自体で容量を生み出さない。耐性は複数の制御の複合効果から生まれた。

したがって、説明責任テストは複数的だが曖昧ではない。各管理者に運用する層での証拠を求め、システム全体にそれらの層にわたる継続性を示すことを求める。

公開証拠が確立できないもの

提供された記録からいくつかの重要な事実は未知のままである。

攻撃者の身元と動機は確立されていない。関与したシステムまたは送信元の完全な集団は分かっていない。証拠は攻撃を特定の人物、組織、行為者のクラスに帰属させることを正当化しない。

すべてのルート識別子と物理インスタンスでの正確なパケットレートは入手できない。CAIDA のパケット作業は、攻撃直後から E、I、K、M リンクをカバーし、観測を10分間隔に整理した。[2] これらのデータは監視されていないリンクに拡張すべきではない。

攻撃当日のすべての経路と緩和変更も未知である。公開証拠は、すべてのルート運用者について完全な BGP、ピアリング、トランジットの再構築を提供しない。独立に文書化されない限り、特定の経路決定がイベントを引き起こしたまたは終わらせたという主張を支持できない。

2002年10月21日にアクティブだった完全な物理トポロジーは列挙されていない。後の anycast 拡大はそのギャップを埋められない。後の分散モデルが攻撃中に普遍的に存在していたと説明するのは不正確である。

リゾルバのキャッシュ状態と正確な利用者に見える失敗率は入手できない。CAIDA の軽微な影響の結論は重要な境界だが、すべてのリゾルバまたは利用者の全数調査ではない。[1] 一部のトランザクションは失敗したかもしれない。記録はそれらを普遍的に定量化しない。

完全な内部運用者タイムライン、連携記録、コスト、法的配分も証拠の外にある。技術標準と後の助言文書は工学的制御を特定するが、過失、違法性、違反、法的責任を確立しない。それらの知見にはここに存在しない事実と法的分析が必要である。

すべてのイベント後是正策の有効性も同様に想定できない。ICANN の後の比較は、2007年の攻撃で利用者影響が低かったことを、2002年以降の anycast 展開と運用者連携に部分的に関連付けた。[5] それは限定的な比較を支持するのであって、すべての後の制御があらゆる条件下で同等に機能したという普遍的な主張ではない。

これらの未知は可視のままであるべきである。不確実性に関する正確さは、局所的な観測、組織的要約、後の設計改善が裏付けのない歴史的確信に変換されるのを防ぐため、インフラ説明責任の一部である。

本質的な説明責任の教訓

2002年のルート DNS 攻撃が深刻だったのは、再帰リゾルバが DNS 階層をナビゲートするために依存するインフラに協調的な圧力をかけたからである。その重要性は、インターネットがほぼ停止したとか、すべての利用者がサービスを失ったという主張を必要としない。

CAIDA は UTC のおよそ22:00に急激な性能劣化を観測し、視点から監視対象ルート識別子間で異なる継続時間を報告した。[1] 後のパケット分析は選択された E、I、K、M リンクでのトラフィックを文書化した。[2] D-Root の履歴はイベントの運用上の重要性を裏付けた。[4] ICANN は後に攻撃の広がりを13個の論理ルートサーバーアドレスのうち9個が圧倒されたと要約した。[5] それでも CAIDA は、目に見えるグローバル運用影響は軽微だったと結論付けた。[1]

システムを連鎖として調べると、これらの事実は整合する。論理アドレスはサービスを特定するが、完全な物理展開と同一ではない。経路はリゾルバがどの容量に到達できるかを決定する。分散権威インスタンスは代替を作るが、トポロジーと一貫性に依存する。再帰キャッシュはライブルートクエリへの即時依存を減らす。トランジットおよびアクセスネットワークはトラフィック経路と送信元妥当性境界の一部を制御する。測定は結論が局所的、地域的、システム全体かを決定する。連携は緩和と復旧中に自律的運用者をつなぐ。

したがって、攻撃は耐性を説明責任テストにした。記録が無傷のままだったとか、どこかのサーバーがどこかで応答したという以上の証拠が必要だった。正しい権威サービスが、十分な経路から、リゾルバとトランザクションの継続性が維持されるのに十分到達可能であり続けたという証明が必要だった。

後の anycast、RSSAC 測定、脅威緩和作業はそのテストへの応答として評価できる。[10]-[16] それらを攻撃当日の神話や遡及的な法的義務に変えるべきではない。その価値は、制御と証拠をより明示的にすることにある。

永続的な原則は単純である。記録は権限を特定し、稼働し到達可能なサービスが継続性を証明する。耐性のある分散サービスは両方を示せなければならない。その運用者は、何を制御したか、何を観測したか、どのように連携したか、復旧が本物だとどう知ったかを実証しなければならない。それ以下では、可用性を証明できないサービスを指す正確な台帳が残るだけである。

2002年のルート DNS 攻撃が分散サービス耐性を説明責任の試金石にした

概要