Akamai 2021 Edge DNS 障害：設定ロールアウトと説明責任

要約

Akamai は、2021年7月22日15:45 UTC にソフトウェア設定の更新が同社の Secure Edge コンテンツデリバリネットワークの DNS コンポーネントのバグを引き起こしたと発表した。一部の顧客ウェブサイトは最大1時間利用できなくなった。Akamai は更新をロールバックし、サービスは正常に戻り、このインシデントはサイバー攻撃ではないと述べた。[1]
Akamai は翌日、当初の表現の範囲を訂正した。同社は最初に DNS サービスへの影響と説明していたが、さらなる調査により影響を受けたシステムは Secure Edge CDN の DNS コンポーネントに限定された。この訂正は重要である：公的証拠は、すべての Akamai 権威 DNS サービス、ゾーン、顧客が障害を起こしたことを立証していない。[1]
ThousandEyes は約15:38 UTC から DNS およびアプリケーション障害を観測し、16:45 UTC 頃に広範な復旧を確認した。同社のテストでは、影響を受けたドメインに対してタイムアウトと SERVFAIL 応答が見られた。観測開始時刻と Akamai の発表した更新時刻の7分の差は、異なる証拠境界を反映しており、一方の記述に黙って合わせるべきではない。[2][3]
このインシデントは、ネットワーク到達可能性が機能するリンクと到達可能なサーバーだけに依存しない理由を示した。命名制御プレーンが使用可能なアドレスを返せなければ、パケットが CDN エッジまで到達できても、ユーザーは意図したアプリケーション接続を確立できない。[2][10][11]
Akamai の現在の Edge DNS ドキュメントは、グローバルエニーキャスト、プライマリおよびセカンダリゾーン、変更リスト、バージョン差分、伝搬状況、以前のバージョンの再有効化について説明している。これらの管理策は、成熟したプラットフォームが生成できる証拠を特定するが、現在の製品ドキュメントは2021年の更新がどの内部パスで処理されたかを証明していない。[5][6][7][8]
Akamai のインシデント前のシステムペーパーは、24のエニーキャストクラウドと入力遅延ネームサーバーについて説明しており、一部の入力起因障害の際に古いデータを保持することを目的としている。これはアーキテクチャコンテキストであり、インシデントポストモーテムではない。公的パケットは、影響を受けたコンポーネントがその設計を使用していたか、なぜこのイベントを封じ込められなかったかを立証していない。[9]
説明責任は実践的な管理に従う。Akamai は共有コンポーネント、更新パイプライン、検証、ロールアウト、監視、ロールバック、修復証拠を管理していた。顧客は DNS および CDN の多様性、証明書、オリジン、継続性テストの一部を管理していた。再帰リゾルバはキャッシュと stale-serve ポリシーを管理していた。これらの責任は階層化されているが、互換性はない。

障害はアプリケーション接続の前に発生した

インターネット障害は、ネットワークがアップかダウンの2状態のスイッチであるかのように説明されることが多い。Akamai のインシデントは、そのような見方を覆す点で有用である。

通常のウェブリクエストでは、ユーザーは IP アドレスではなく名前から始める。再帰リゾルバは、キャッシュ情報と参照をたどり、ドメインの権威応答を得る。返されたアドレスは、CDN エッジ、ロードバランサー、オリジンへの接続を導く。権威ステップが失敗すると、ユーザーはアプリケーション接続を試みることすらできない。ルーターはパケットを転送できる。サーバーは稼働できる。ファイバーは無傷である。それでもサービスに到達できないのは、命名制御プレーンが次の使用可能な宛先を生成しなかったためである。[10][11][17]

ThousandEyes は2021年7月のインシデント中にこの分離を観測した。Akamai の CDN エッジインフラへの接続は利用可能なままで、影響を受けたドメインの DNS 解決が失敗することを報告した。テストでは権威サーバーから SERVFAIL 応答または応答なしを受信した。ブラウザとアプリケーションは、測定された断絶が依存関係チェーンの早い段階で発生したにもかかわらず、一般的なウェブサイト障害のように見える障害を表面化した。[2]

この区別は単なる技術用語以上のものである。これは制御表面を特定する。

ファイバーカットが地域を隔離する場合、責任ある管理策には物理的多様性、復旧、再ルーティングが含まれる。BGP が安全でない経路をエクスポートする場合、管理策には経路ポリシー、検証、封じ込めが含まれる。権威 DNS が共有設定更新によってバグが引き起こされ応答できない場合、管理策には設定表現、テスト範囲、ロールアウト範囲、障害ドメイン分離、ロールバック権限、リゾルバ相互作用、顧客依存関係設計が含まれる。

すべてのケースを「インターネットがダウンした」と呼ぶことは、これらの違いを隠す。また、ユーザーのエラーページに表示される企業に責任を漂流させる。より良い問いは、次のネットワークステップに必要な情報を提供できなかったシステムはどれか、その障害を防止、制限、検出、逆転させる実践的能力を持っていたのは誰か、である。

このインシデントについて、Akamai 自身の声明が高レベルのトリガーを提供している。同社はソフトウェア設定の更新がバグを引き起こしたと述べた。正確な設定、コードパス、影響を受けた人口、内部トポロジーは公開していない。つまり、この記事は設定権限と到達可能性証拠を分析できる。プライベート実装詳細を特定したり、個人のエンジニアを非難したり、名前付きの現在の Edge DNS 機能が2021年に失敗したと主張することはできない。[1]

したがって、ターゲットは狭い：ネットワークインフラ上のリスクと説明責任。このインシデントは単にソフトウェアバグが存在したから重要ではない。バグが、共有 DNS コンポーネントに影響を与える力を持つ設定チャネルの背後にあり、そのコンポーネントを通じて多くの顧客サイトの到達可能性に影響を与えたから重要である。

年表には2つの時計と1つの範囲訂正が必要

ThousandEyes は、外部から観測された問題の開始を7月22日約15:38 UTC に置く。Akamai は15:45 UTC にソフトウェア設定の更新がバグを引き起こしたと述べている。これらの時刻は異なる知識の形態を指している。

外部測定プラットフォームは、テストがその視点から失敗し始める時刻を記録する。オペレーターは変更が発生した時刻、内部しきい値が作動した時刻、またはインシデントが宣言された時刻を記録する。最初の失敗したユーザークエリは、公開ステータス更新よりも前になる可能性がある。設定は時間とともに伝搬する。時計は異なる可能性がある。責任ある方法は、両方のタイムスタンプとその出所を述べることであり、最もクリーンなナラティブを作るものを選択しないことである。[1][2][3]

ThousandEyes は、Akamai を使用するサービスの間でウェブおよびアプリケーション障害の増加を観測した。同社の DNS テストでは、CDN 環境でホストされているドメインの解決障害が見つかった。一部のユーザーは SERVFAIL を受信し、他のユーザーはタイムアウトした。影響は顧客と地域によって異なった。測定会社は16:45 UTC 頃に広範な復旧を置いている。Akamai は混乱が最大1時間続き、ロールバック後にサービスが再開したと述べている。これらの説明は、公的証拠が支持するレベルで互換性がある。[1][2]

Akamai の声明には別の本質的な年表が含まれている：声明自体が変更された。

同社は7月23日に訂正を追加した。最初の投稿は「Akamai の DNS サービス」への影響を説明していた。さらなる調査により、影響は Secure Edge コンテンツデリバリネットワークの DNS コンポーネントに限定されたことが示された。[1]

これは編集上の些事ではない。範囲は根本原因証拠の一部である。「Akamai DNS が失敗した」は、すべての権威 DNS 製品、ゾーン、サービスパス、顧客が1つの障害を共有したことを示唆する。Akamai の訂正はその示唆を拒否する。独立した観測者は依然として「Akamai Edge DNS 障害」などのフレーズを合理的に使用してテストで見たものを説明するが、責任ある再構築は観測者のサービスラベルとオペレーターの後のコンポーネント境界を区別しなければならない。

範囲訂正は、初期のインシデント言語が永続的な事実に硬化すべきではない理由も示している。オペレーターは完全なコンポーネントマップがわかる前にコミュニケーションする。ジャーナリストと顧客は最初の説明を繰り返す。検索エンジンはそれを保持する。後の訂正は元の見出しよりも可視性が低くなることがある。良い説明責任の実践にはバージョン管理された記録が必要である：何が言われたか、いつ変更されたか、なぜ変更されたか、変更がどの結論に影響するか。

この場合、訂正は影響を受けたプラットフォームを狭めるが、到達可能性への影響を消去しない。コンポーネントは製品よりも狭くても、多くの顧客が使用するパス上に存在できる。関連する質問はより正確になる：

どの Secure Edge CDN DNS コンポーネントが更新を受けたか？
どの顧客プロパティまたは命名パスがそれに依存していたか？
コンポーネントは独立したサービス拠点間で設定状態を共有していたか？
どの障害ドメインが利用可能なままであったか？
ロールバックはどのように伝搬したか？
正常な応答が戻ったことをどの証拠が立証したか？

公開ソースセットは6つすべてに答えない。ロールバックが正常サービスを復旧するのに十分迅速に機能したこと、および同社が更新プロセスを見直す計画を立てたことを立証する。残りの質問は証拠ギャップを定義するものであり、仮定で埋める許可ではない。[1]

DNS 多様性は設定多様性と同じではない

DNS アーキテクチャは、ゾーンに対して複数の権威サーバーを期待する。RFC 2182はその理由を直接説明している：ゾーン情報は、1つのサーバーが利用不可または到達不能の場合でも利用可能であるべきである。セカンダリサーバーは、ネットワーク障害や電源障害を含む可能性のある障害モードを考慮して配置されるべきである。[12]

大規模商用サービスは別の形態の分散を追加する。Akamai の Edge DNS ドキュメントは IP エニーキャストを説明しており、論理サービスアドレスが複数の物理ロケーションからアナウンスされる。リゾルバのクエリは、ネットワークトポロジーとポリシーに従って利用可能なインスタンスにルーティングされる。Akamai は複数のネットワークと大陸にわたる数千のネームサーバーを説明している。[5]

RFC 4786は、エニーキャストが権威 DNS にとって魅力的な理由を説明している。サービスを分散し、アクセシビリティを向上させ、物理ロケーションごとに DNS 参照が増えるのを回避する。また、監視がより複雑になることも警告している：可用性はクライアントの位置に依存し、特定のノードに到達するクライアント集団はルーティングとともに変化する。[13]

物理的およびルーティングの多様性は価値がある。それらは自動的に設定多様性を提供しない。

多くのロケーションが同じ安全でない入力を消費する場合、すべてのロケーションが物理的に健全でありながら、使用不能な応答を返したり、同じ方法で失敗したりする可能性がある。エニーキャストサイトを追加することは、1つの制御プレーン依存関係を維持しながらサービング多様性を高めることができる。プラットフォームはデータセンターの損失を生き残れるが、グローバルな設定バグに対して脆弱なままである可能性がある。2つの障害クラスは異なる管理策を必要とする。

これが、サーバー数を数えることが弱い回復力の主張である理由である。オペレーターはどの要素が独立しているかを特定する必要がある：

電源と施設；
物理ネットワークパス；
ルーティングアナウンス；
ソフトウェアバイナリ；
設定入力；
検証システム；
展開コントローラー；
管理資格情報；
監視；
ロールバックチャネル；
組織的承認。

異なる国の2つのネームサーバーは、同じ設定ソースを共有できる。2つの DNS プロバイダーは、同じレジストラや隠れプライマリを共有できる。2つの CDN パスは、同じ証明書自動化やオリジンに依存できる。2つの承認ステップは、同じパーサーを使用し、したがって同じ安全でない意味を受け入れることができる。

インシデントの公開原因声明は、この共有制御問題を指している。Akamai は個々のサービングサイトが失敗したとは述べていない。ソフトウェア設定の更新が共有コンポーネントのバグを引き起こしたと述べている。サービスはロールバック後に復旧した。このシーケンスは、サーバー数ではなく、更新チャネルを中央の説明責任オブジェクトにする。[1]

適切な制御モデルは、設定配布を独自のネットワークプロトコルとして扱う。プロデューサー、バリデーター、バージョン、受信者、伝搬時間、確認応答、ロールバックがある。部分的な障害、古い状態、互換性のないバージョン、安全でないグローバル値に対してテストされるべきである。成熟したプラットフォームは、どの受信者が変更を受け入れ、どの受信者が拒否し、どのバージョンを提供し、各障害ドメインからユーザーが何を観測するかを知るべきである。

したがって、冗長性の主張は、目録ではなく障害仮説として表現されるべきである。「数千のネームサーバーがあります」は容量とロケーションの質問に答える。「新しい入力は、独立したカナリアが安全であることを証明する前に、すべてのサービング障害ドメインに影響を与えることはできません」は設定爆発半径の質問に答える。2021年7月のイベントは、証拠を必要とする2番目の主張を浮き彫りにする。

設定更新はネットワーク権限の委任された行使である

「ソフトウェア設定更新」というフレーズは、ソフトウェアリリースよりも重要でないように聞こえる。設定はしばしばデータとして扱われる：変更が容易で、コードよりリスクが低く、迅速な展開に適している。分散ネットワークでは、その区別は誤解を招く可能性がある。

設定は動作を選択する。コードパスをアクティブにし、ルーティングを変更し、レコードデータを変更し、マッチを広げ、安全制限を削除し、トラフィックを異なるサービスに向けることができる。グローバルスコープの設定は、1つのカナリアサーバーに限定されたコード変更よりも多くの運用権限を行使できる。

したがって、正しいリスク単位はファイルタイプではない。それは実効権限である。

変更パイプラインは、配布前に4つの質問に答えるべきである。

第一に、解析および正規化後の更新の意味は何か？構文の有効性は意味の安全性ではない。値は整形式でありながら、不可能、安全でない、またはグローバルに矛盾した状態を選択できる。

第二に、どのユーザー、ゾーン、サービス、ロケーションに影響を与えることができるか？スコープはコンパイルされた結果から計算されるべきであり、変更リクエストの名前から推測されるべきではない。

第三に、それを停止できる独立した条件は何か？バリデーターは保護対象のコンポーネントとは異なる方法で失敗するべきである。両方が同じスキーマ、パーサー、生成モデルを使用する場合、共有欠陥が両方を打ち負かす可能性がある。

第四に、通常の制御パスが損なわれた場合、以前の状態をどのように復元できるか？ロールバックには、既知の正常バージョン、配布権限、到達可能な管理プレーン、受信者が実際に以前の状態に戻った証拠が必要である。

Akamai の現在の Edge DNS ドキュメントは、有用な制御アーティファクトの例を提供している。プライマリゾーンの変更は変更リストに蓄積される。オペレーターは追加と削除を確認し、ゾーンをアクティブにするか、変更を破棄できる。API はゾーンバージョンをリストし、差分を表示し、伝搬状況を報告し、以前のバージョンを再有効化できる。[7][8]

これらのドキュメントは現在の製品リファレンスである。公開インシデント声明は、2021年の Secure Edge CDN コンポーネントがこの正確なワークフローを使用したとは述べていない。文書化された変更リスト管理が失敗したと主張することは不正確である。それでもドキュメントは、管理された DNS プラットフォームにどのような証拠が存在できるかを示す点で価値がある：バージョン、差分、レビュー担当者の決定、アクティベーションイベント、伝搬記録、再有効化アクション。

公開説明責任にとって、最も有用なインシデント後の証拠は、実際の2021年の更新を同等のアーティファクトにマッピングするものである：

意図された目的と承認されたスコープ；
正規化された設定；
アクティベーション前に行われたテスト；
最初のカナリア集団；
受信者のシーケンスと割合；
作動したアラート；
伝搬を停止する決定と権限；
選択された既知の正常バージョン；
ロールバック後の受信者からの確認応答；
DNS 応答とアプリケーション到達可能性を確認する外部テスト。

すべてのプライベート設定値を公開することは、セキュリティや顧客リスクを生み出す可能性がある。説明責任にそれは必要ない。必要なのは、企業が障害クラスを理解し、修復がそれに対処し、同じ入力が再び同じ制御されないリーチを得ることができないことを立証するのに十分な構造化証拠である。

Akamai のアーキテクチャペーパーは質問に情報を与えるが、評決にはならない

インシデントの前に、Akamai の研究者は同社の DNS システムがどのように大量の権威クエリに応答するかを説明するペーパーを発表した。このペーパーは24のエニーキャストクラウド、システム監視、古いまたは危険な入力を処理するメカニズムについて議論している。1つの設計は、各クラウドに入力遅延ネームサーバーを配置した。これらのサーバーは人為的な遅延で入力を受け取り、オペレーターが入力起因の障害に対応している間、古いデータで応答を続けることができた。[9]

そのアーキテクチャは、新鮮な入力と継続サービスとの間の意図的な分離を説明するため、設定説明責任に直接関連する。これは Akamai のエンジニアが入力起因障害をクラスとして考慮していたことを示している。また、2021年に何が起こったかを問う具体的な用語も提供する。

それは答えを提供しない。

オペレーターのインシデントポストは、Secure Edge CDN の DNS コンポーネントを特定する。ペーパーはシステムレベルで Akamai DNS アーキテクチャを説明する。このパケットの公開ソースは、影響を受けたコンポーネントがペーパーの入力遅延設計を使用したこと、トリガーとなる更新が遅延入力の1つであったこと、設計が影響を受けた顧客パスに対して有効であったこと、またはそれが失敗したことを証明していない。

ペーパーを非難に変えることは、一般的な分析エラーを犯すことになる：公開されたアーキテクチャをすべてのプロダクションパスの完全な目録として扱うこと。大規模ネットワークには、システムの世代、製品固有のコンポーネント、移行、例外、制御境界が含まれる。ペーパーは1つのメカニズムを正確に説明できても、すべてのサービスがそれを使用することを保証しない。

防御可能な使用方法は、反事實的かつ証拠的である。

影響を受けたコンポーネントに独立した遅延パスが存在した場合、インシデント中にどの入力を提供したか？存在しなかった場合、どの特性がコンポーネントを不適切にしたか？更新が応答データではなくコード動作に影響を与えた場合、古い設定でも同じバグを呼び出せたか？フォールバックがオペレーターのアクティベーションを必要とした場合、監視は時間内に条件を特定したか？ユーザーが異なるエニーキャストクラウドに到達した場合、フォールバック状態は一貫していたか？

これらの質問が重要な理由は、ロールバックだけでは1つの証明しか与えないからである：新しい設定が削除されたときに即時サービスが回復した。それは、独立したパスが障害の一部を封じ込めたか、なぜ元の検証がバグを見逃したか、または別の安全でない設定が同じ共有障害を生み出すかどうかを明らかにしない。

ペーパーはまた、なぜ証拠が障害クラスにリンクされるべきかを示している。オペレーターは冗長ネームサーバー、エニーキャスト、遅延入力を持っていると言える。顧客は各メカニズムがどの障害をカバーするかを知る必要がある。施設喪失、BGP 分離、古いデータ、破損データ、ソフトウェアバグ、制御プレーン侵害は異なる。1つのために設計されたメカニズムは、別のものには無関係であり得る。

したがって、2021年7月の説明責任記録は両方の極端を避けるべきである。Akamai の公開されたレジリエンスエンジニアリングを無視すべきではなく、そのエンジニアリングがこのコンポーネントを保証したと仮定すべきでもない。文書化された安全策と未公開のイベントパスとの間のギャップは、それ自体が正確な証拠への要求である。

ロールバック速度は重要だが、ロールバック証拠はもっと重要である

Akamai のロールバックは約1時間でサービスを復旧した。これは運用上重要である。共有コンポーネントが顧客の到達可能性に影響を与える場合、既知の正常状態への迅速な復帰は害を制限し、プロダクションで無限にデバッグする誘惑を減らす。[1]

ロールバックは1つのアクションではない。それは一連の主張である。

最初の主張は、オペレーターが新しい更新を原因として特定したことである。2番目は、以前のバージョンが利用可能で安全であったことである。3番目は、ロールバックコマンドが影響を受けた受信者に到達したことである。4番目は、それらの受信者がそれを受け入れたことである。5番目は、権威応答が回復したことである。6番目は、アプリケーションが外部ネットワークから到達可能になったことである。各主張には独自の証拠がある。

バージョン管理インターフェースは、どのオブジェクトが選択されたかを証明できる。配布テレメトリーは、どのインスタンスが確認応答したかを証明できる。DNS プローブは、選択された視点から応答が戻ったことを証明できる。アプリケーションテストは、応答が動作する接続につながったことを証明できる。顧客レポートは、内部監視が見逃した残存パスを特定できる。

この階層化された証明は、エニーキャストシステムで重要である。1つのロケーションからの成功したテストは1つのエニーキャストインスタンスに到達するが、他の場所のユーザーは別のインスタンスに到達する可能性がある。RFC 4786の監視警告が適用される：サービスは、観測者のルーティングパスに応じて健全または不健全に見える可能性がある。[13]

したがって、オペレーターはインシデント前にロールバック完了を定義すべきである：

制御状態が戻された；
設定受信者が収束した；
障害ドメイン全体で権威応答成功が回復した；
エラーコードとタイムアウトがベースラインに戻った；
代表的な顧客パスでアプリケーション到達可能性が回復した；
ステータス通信が残存不確実性で更新された。

インシデントポストは、ロールバック後サービスが通常の運用を再開したと述べている。それは基礎となる測定を公開していない。最初の声明としては許容できるが、成熟した説明責任記録は後の監査と顧客保証のためにそれらを保持すべきである。

ロールバックには独立性も必要である。展開に使用された同じコントローラー、資格情報、ネットワークパス、ソフトウェアが復元に必要である場合、障害は自らの修復を無効にする可能性がある。高い爆発半径のインフラは、不健全なコンポーネントに依存せずに既知の正常状態をアクティブにできる最小限の復旧チャネルを保持すべきである。

公開パケットは、そのリスクが Akamai で現実化したかどうかを示していない。それは制御質問を特定する。1時間以内の復旧は、実行可能な復元パスが存在したことを示唆している。耐久性のある保証は、そのパスが通常の管理またはサービスプレーンの喪失に対してテストされていることを示すものであり、制御アクセスを無傷のままにするバグに対してのみではない。

リゾルバの動作はユーザー体験を変えたが根本原因は変えなかった

再帰リゾルバはユーザーと権威サーバーの間に位置する。それらのキャッシュは、有効期限が切れるまで応答を保持できる。それらのリトライアルゴリズムは権威サーバー間で選択する。SERVFAIL、タイムアウト、古いデータの処理方法は、障害がどの程度早く可視化され、どの程度持続するかに影響する。

RFC 2308はネガティブキャッシュ動作を定義する。RFC 4697は、権威サーバーに到達できないかサーバー障害を返す場合に発生する可能性のある有害なリトライパターンと負荷を文書化する。RFC 8767は、リゾルバが応答を更新できない場合に制限付き条件下で古いデータを提供することを許可する。Akamai インシデントの後に公開された RFC 9520は、SERVFAIL を含む解決失敗のネガティブキャッシュを洗練する。[14][18][19][20]

これらのメカニズムは、ユーザーが同じ権威障害を異なる体験をする理由を説明する。

まだ有効なキャッシュ応答を持つリゾルバはトラフィックを誘導し続けることができる。応答の有効期限が切れたリゾルバは新しい権威応答を必要とし、即座に失敗する。古いデータを提供するように設定されたリゾルバは、古い応答が安全でポリシー条件が満たされていれば到達可能性を維持できる。別のリゾルバは SERVFAIL を返す。アプリケーションも異なる方法でキャッシュし、一部は別のリゾルバを通じてリトライする。

この変動は根本原因を Akamai からリゾルバに移さない。Akamai の声明は、更新が DNS コンポーネントのバグを引き起こしたと述べている。リゾルバポリシーはユーザー可視の害を軽減または増幅できるが、基礎となるコンポーネントがそれを提供できない場合に有効な権威データを作成することはない。

Stale-serve にも限界がある。古いアドレスは、サービスが移動した場合、セキュリティ応答がレコードを変更した場合、証明書とオリジンがもはや一致しない場合に危険である。リゾルバは応答をまったくキャッシュしていない可能性がある。TTL は短い可能性がある。ネガティブとポジティブのキャッシュ状態は異なる。オペレーターは継続性と鮮度・正確性のバランスを取らなければならない。RFC 8767はそのバランスを説明しており、透過的なフェイルオーバーを保証するものではない。[14]

これは階層化された説明責任モデルを生み出す。

Akamai は共有権威コンポーネントと更新パイプラインに対して責任を負う。リゾルバオペレーターは標準準拠の観測可能な障害処理と、継続性/鮮度トレードオフのコミュニケーションに対して責任を負う。顧客は自分たちが管理できる TTL とアーキテクチャ選択に対して責任を負う。ユーザーは、主要サービスが機能することを期待する前に、どのリゾルバまたは権威コンポーネントが失敗したかを診断する実践的義務を持たない。

したがって、証拠はレイヤーを分離すべきである。権威クエリ成功、再帰応答コード、キャッシュ状態、アプリケーション接続成功は異なる測定である。その分離なしに、ステータスレポートは、1つのリゾルバがキャッシュから応答するが新鮮な権威クエリが失敗するため DNS は健全であると主張したり、1つの再帰キャッシュが失敗を保持しているため権威サービスはまだダウンしていると主張したりする可能性がある。

顧客の冗長性はオリジンまで独立していなければならない

ThousandEyes は影響が Akamai 顧客間で異なることを報告した。影響を受けた DNS および CDN パスに依存する組織は利用不可のままであったが、一部のマルチ CDN 設計はより多くのサービスを維持した。同社の後のレビューは、マルチ CDN アプローチによってほとんど影響を免れた例として Amazon を挙げている。[2][4]

教訓は単に「2つの CDN を買う」ではない。

2番目のプロバイダーは、ユーザーがそれを発見し到達できる場合にのみ有用である。権威 DNS 委任は代替を返せなければならない。DNSSEC 署名と鍵配布は有効であり続けなければならない。証明書は同じ名前をカバーしなければならない。代替 CDN は利用可能なオリジンに到達し、十分な容量を持たなければならない。アプリケーション状態、認証、詐欺防止、データ一貫性は両方のパスで機能しなければならない。オペレーターはいつどのようにトラフィックをシフトするかを知らなければならない。

RFC 8901はマルチプロバイダーDNSSEC モデルと、検証リゾルバが異なるプロバイダーからの応答を認証できるようにするために必要な調整を説明している。それは多様性が独自の制御プレーンを導入することを示している。鍵、DNSKEY レコード、DS レコード、署名アルゴリズム、タイミングは一貫していなければならない。不正確なマルチプロバイダー展開は、単一プロバイダーでは発生しない障害を生み出す可能性がある。[16]

その複雑さは多様性を無効にしない。それは、回復力がラベルとして購入されるのではなく、設計およびテストされなければならないことを意味する。

顧客はいくつかの次元にわたって独立性を評価できる：

異なる権威プロバイダーとサービングネットワーク；
障害プロバイダーに依存しないレジストラと委任ワークフロー；
互換性のある DNSSEC と鍵管理プロセス；
制御された比較可能なソースデータから生成された CDN 設定；
両方のパスで利用可能な証明書とセキュリティポリシー；
同じ単一依存関係を共有しないオリジン接続；
十分な容量と商業的承認；
複数のリゾルバとネットワークを通じた外部監視；
フェイルオーバーとフェイルバックのためのリハーサルされた決定プロセス。

組織は何が共有されているままかを知るべきである。両方のプロバイダーが1つの自動化パイプラインからレコードを受信する可能性がある。両方が同じオリジンからプルする可能性がある。両方がオペレーターアクセスに1つのアイデンティティプロバイダーを使用する可能性がある。単一の誤ったソース更新が2つのベンダーに伝搬し、見かけの多様性を打ち負かす可能性がある。

顧客は、プライマリ DNS または CDN が利用不可の場合に代替パスが機能するというテスト証拠を保持すべきであり、両方が健全な場合だけではない。それには、障害注入、DNS 委任テスト、キャッシュ動作観測、証明書チェック、アプリケーショントランザクションが含まれる。

それでも、顧客のアーキテクチャは Akamai を免責しない。共有 DNS コンポーネントに対して責任を受け入れるプラットフォームプロバイダーは、顧客が検査または修復できないリスクを管理する。階層化された責任は、顧客が回避可能な集中を避けるべきであり、プロバイダーは共有変更の権限を制約すべきであることを意味する。すべての顧客が未公開のプロバイダーバグを補償するために2番目のグローバルプラットフォームを構築することを期待するものではない。

観測可能性は設定、DNS、アプリケーション状態を接続しなければならない

ThousandEyes はアプリケーション障害が DNS 解決問題と一致することを示すことができた。Akamai は設定更新を特定し、それを逆転させることができた。完全なインシデント記録はそれらのビューを接続する必要がある。

少なくとも5つの証拠レイヤーが重要である。

変更レイヤーは、要求された設定、正規化表現、差分、レビュー担当者、アクティベーション時間、配布範囲、以前のバージョンを記録する。

サービングレイヤーは、どのネームサーバーインスタンスまたはコンポーネントノードが更新を受け入れ、それぞれがどのバージョンを提供し、それらの健全性と応答コードを記録する。

DNS レイヤーは、権威クエリ成功、レイテンシ、SERVFAIL、タイムアウト、名前、レコードタイプ、エニーキャストパス、ネットワーク全体の応答一貫性を記録する。

リゾルバレイヤーは、キャッシュ状態、stale-answer 動作、リトライ、ネガティブキャッシュ効果を記録する。

アプリケーションレイヤーは、返された応答が成功した TLS およびアプリケーショントランザクションにつながったかどうかを記録する。

これらのレイヤーが無関係の識別子と時計を使用する場合、根本原因分析は遅くなり、説明責任は弱くなる。変更 ID はコンポーネントバージョン、サービング集団、プローブ結果、インシデントタイムラインにトレース可能であるべきである。システムは、ライブ状態がもはや障害を再現しないロールバック後でも、この相関を保持すべきである。

外部測定は依然として不可欠である。エニーキャストは内部プローブをユーザーとは異なる方法でルーティングする可能性がある。顧客ドメインは、汎用ヘルス名が実行しないコードパスを実行する可能性がある。再帰動作は異なる。オペレーターの監視には、代表的なリゾルバ、ネットワーク、名前、アプリケーショントランザクションを使用した外部からのテストを含めるべきである。

公開記録はその利点を示している。Akamai の15:45更新時刻と ThousandEyes の15:38観測障害は同一ではないが、一緒に調査に値する境界を露出している。一部の伝搬は記録されたトリガーの前に開始したか？測定タイムスタンプはより初期の症状を反映したか？時計または出版精度が異なったか？ソースパケットは答えない。相関された内部記録はできる。

コミュニケーションは同じレイヤー区別を保持すべきである。「ネットワーク健全」は広すぎる。有用なステータスメッセージは、権威応答が回復しつつある、ロールバックが伝搬している、アプリケーション到達可能性が改善している、残存リゾルバキャッシュがまだ失敗を示す可能性があると言える。顧客はその後、自分たちの証拠をオペレーターの証拠と比較できる。

Akamai の声明は簡潔で、トリガー、ロールバック、期間、非サイバー攻撃境界、後の範囲訂正を含んでいた。これらは強力な初期事実である。説明責任ギャップは、会社が何も言わなかったことではない。公開記録が検証、ロールアウト封じ込め、耐久性のある修復を評価するために必要な技術的証拠を含んでいないことである。

説明責任は管理、能力、証拠に従う

説明責任は時々過失に還元される：Akamai が設定を変更したので、Akamai が責任がある。それは方向的に真実だが、分析的に不完全である。有用な配分は、どの当事者がどのリスクを制御し、各当事者がどの証拠を保持すべきかを特定する。

Akamai プラットフォームおよびネットワークエンジニアリング

Akamai は更新を受けたコンポーネント、ソフトウェアと設定インターフェース、検証、展開トポロジー、監視、ロールバック、インシデント後の修復を管理していた。その義務はコンポーネントのリーチに比例していた。1つの変更が多くの顧客サイトに影響を与える可能性がある場合、パイプラインはその共有爆発半径のために設計された管理策を必要としていた。

関連する証拠には、正規化された差分、テスト、カナリア結果、展開確認応答、健全性メトリクス、ロールバックログ、回帰結果が含まれる。公開声明は高レベルの原因と回復を立証するが、それらのアーティファクトは立証しない。[1]

Akamai 製品および変更責任者

製品責任者は、更新の緊急性、顧客影響、承認がどのように表現されるかを管理していた。彼らは変更がルーチンであるかどうか、例外がステージングをバイパスできるかどうか、どのサービスレベルコミットメントが適用されるかを決定した。彼らはまた、顧客が自分たちの継続性計画を評価するのに十分なアーキテクチャおよび是正情報を受け取るかどうかを管理していた。

この役割はマネージャーを非難することと同じではない。爆発半径の制限と証拠要件は、ソフトウェア決定と同様に製品決定であることを認識する。

Akamai 顧客

顧客はプロバイダー多様性、DNS 委任、TTL、証明書、オリジン接続、アプリケーションポータビリティ、フェイルオーバーテストの一部を管理していた。彼らの義務はサービスの重要性と実践的リソースに依存していた。銀行、航空会社、公共サービスは、低影響サイトよりも強力な独立パスを合理的に要求する可能性がある。

顧客は Akamai の内部更新を管理していなかった。2番目のプロバイダーを購入しないことは根本原因を移さない。それは顧客のエクスポージャーと復旧オプションを変更する。

再帰リゾルバオペレーター

リゾルバオペレーターはリトライ、障害キャッシュ、stale-answer ポリシー、監視を管理していた。それらの実装は期間と可視症状を変更する可能性がある。彼らは現在の標準に従い、有害なリトライ増幅を避け、権威障害とローカルキャッシュ状態を区別するのに十分なテレメトリーを露出すべきである。[14][18][19][20]

彼らは安全に現在の権威データを発明することはできなかった。Stale-serve は制限された緩和策であり、健全な権威の代替ではない。

レジストラおよびセカンダリ DNS プロバイダー

顧客が使用する場合、レジストラとセカンダリプロバイダーは委任と代替サービングパスを管理していた。マルチプロバイダー運用には、一貫したレコード、DNSSEC 調整、変更権限、テスト済みフェイルオーバーが必要であった。[12][16]

標準化および測定機関

IETF はプロトコル動作と運用ガイダンスを定義した。ThousandEyes は独立した測定を提供した。どちらも Akamai のコンポーネントを運用していなかった。彼らの役割は、障害メカニズムと公開証拠をより読みやすくすることであった。

このマップは2つのエラーを防ぐ。1つ目は、変更をアクティブにした最後の人物への非難の完全集中。2つ目は、どの当事者も具体的な義務を持たないほど責任が拡散することである。実践的管理は各義務に境界を与える。

修復の主張には再現可能な障害テストが必要である

Akamai は将来の混乱を防ぐためにソフトウェア更新プロセスを見直していると述べた。[1]

そのコミットメントは賢明だが、「プロセスを見直した」は技術的成果ではない。耐久性のある問いは、組織が障害クラスを再現し、独立した管理策が今それを封じ込めていることを示せるかどうかである。

強力な修復プログラムは正確なインシデントモデルから始まる：

バグをトリガーする最小の設定；
それを解釈するコンポーネントとバージョン；
露出したサービング集団；
観測可能な DNS 障害；
ロールバック状態；
それを特定する監視信号。

次のステップはネガティブテストである。トリガークラスをプリプロダクションに供給し、新しい検証がそれを拒否するか、カナリアがより広いフリートに到達せずに失敗することを確認する。テストは特定の入力がブロックされることだけでなく、意味的に同等の入力や変形が制御をバイパスできないことを主張すべきである。

3番目のステップは独立性である。修復が別のバリデーターを追加する場合、それが故障したコンポーネントとは異なる表現、パーサー、または真実のソースを使用することを示す。カナリアを追加する場合、カナリアがプロダクションと同じコンパイル設定を受信し、DNS またはアプリケーション障害で昇格が自動的に停止することを証明する。

4番目のステップは障害ドメイン封じ込めである。安全でない更新が証拠が評価される前にすべての権威サービングドメインに到達できないことを示す。ドメインはエニーキャストクラウド、ソフトウェアコホート、地域、顧客グループ、サービスコンポーネントによって定義できるが、運用上意味があるものでなければならない。

5番目のステップは劣化条件下でのロールバックである。通常の制御パスの一部を無効化または分離し、オペレーターが既知の正常状態を再有効化できることを示す。複数の外部ネットワークからの収束を確認する。

6番目のステップは顧客可視の成果である。顧客が修復を自分たちの依存関係にマッピングできるのに十分な情報を公開する。これには、悪用可能な詳細を開示せずに、障害クラス、封じ込めメカニズム、テスト範囲、日付を含めることができる。

7番目のステップは再発監視である。拒否された設定、カナリアアボート、ロールバックテスト、設定関連 DNS エラーを時間の経過とともに追跡する。一度合格して静かに劣化する修復は耐久性がない。

現在の Akamai ドキュメントは変更リスト、差分、バージョン、伝搬状況、再有効化を説明している。これらは証拠のための有用なビルディングブロックである。この記事は、それらが2021年のインシデントのために追加されたとか、同じコンポーネントに適用されると主張することはできない。同等のアーティファクトが修復主張を評価すべき基準であると言える。[7][8]

公開記録が証明できないこと

ソースセットは実際のネットワークインフラ事例を立証するのに十分強力であり、抑制を要求するのに十分弱い。

それは正確な設定値を証明できない。バグを特定できない。更新がアクティベーション時にグローバルであったか、伝搬によって広くなったかを示せない。影響を受けた顧客数を述べられない。どのエニーキャストクラウドまたはネームサーバープロセスが失敗したかを立証できない。Akamai のシステムペーパーからの入力遅延ネームサーバーが関連していたかどうかを示せない。レビュー担当者、承認者、個々のオペレーターを特定できない。損失を定量化したり、契約上の損害を割り当てたりできない。

また、複数のプロバイダーを使用するすべての顧客が利用可能であったこと、または単一プロバイダーの顧客がすべて失敗したことを証明できない。ThousandEyes は測定視点からの例と集合観測を提供しており、普遍的な国勢調査ではない。[2][4]

RFC はプロトコルと運用コンテキストを確立する。それらは Akamai が標準に違反したという事実認定を作成しない。RFC 9199と RFC 9520はインシデントより後に発行されており、2021年の更新を支配した義務として提示されてはならない。[15][20]

これらの事実の欠如は説明責任を消去しない。それは支持された結論と推測の間の境界を定義する。支持された結論は、共有設定更新が DNS コンポーネントのバグを引き起こし、重大な到達可能性障害を引き起こし、ロールバックを必要としたことである。証拠義務は、設定権限が現在どのように制約されているか、回復がどのように検証されるかを示すことである。

再利用可能な到達可能性説明責任テスト

このインシデントは、権威 DNS、CDN ステアリング、トラフィック管理、または別の共有ネットワーク制御プレーンを運用するプロバイダー向けの実践的テストを支持する。

1. 不可欠な制御表面を名前付ける。
ユーザーが権威 DNS、BGP、エニーキャスト、ルーティングポリシー、証明書、オリジン選択、別のメカニズムに依存しているかを特定する。イベントを一般的な障害と呼んではならない。

2. 意図された変更と実効権限を分離する。
変更が何をすることを意図していたかを記録し、それが実際に影響を与える可能性のあるサービス、ユーザー、障害ドメインを計算する。

3. 意味を独立して検証する。
同じパーサー仮定の2つのコピーではなく、正規化された動作、承認されたスコープ、保護されたインフラを比較する制御を使用する。

4. 実際の障害ドメインにわたって段階的に実行する。
正確にコンパイルされた入力をカナリアし、DNS、ルーティング、またはアプリケーション証拠が劣化したときに自動的に伝搬を停止する。

5. 独立した既知の正常パスを保持する。
新しい入力を即座に消費せず、以前の状態を復元できるサービングまたは管理パスを維持する。

6. 外部から測定する。
複数のネットワークから権威応答、リゾルバ結果、アプリケーショントランザクションをプローブする。エニーキャストの健全性は1つのロケーションから推測できない。

7. ロールバック収束を証明する。
どの受信者が元に戻り、どの応答が戻り、どのアプリケーションが回復したかを示す。制御プレーンの成功メッセージだけでは不十分である。

8. 顧客の代替案をエンドツーエンドでテストする。
プロバイダー多様性には、委任、DNSSEC、証明書、オリジン、容量、状態、運用権限が含まれなければならない。

9. 訂正された範囲を公開する。
調査が最初の主張を狭めたり変更したりした場合、訂正を目立つように保持し、どの結論が変わったかを特定する。

10. 修復を再現された障害に結び付ける。
元のクラスと意味的バリアントが広範なユーザー影響なしに拒否、封じ込め、または回復されることを示す。

このテストは、すべてのアクターが平等な力を持つと偽ることなく責任を配分する。プロバイダーは共有プラットフォームの主要な負担を負う。顧客とリゾルバは、彼らが実際に所有する管理策に対して境界のある義務を負う。公開証拠はそれらの義務が評価されることを可能にする。

結論

Akamai は2021年7月22日に迅速にサービスを復旧した。公開声明は設定更新、トリガーされたバグ、ロールバック、最大1時間の期間、非サイバー攻撃境界を特定した。翌日の訂正は影響を受けたシステムを Secure Edge CDN の DNS コンポーネントに限定した。ThousandEyes は混乱が多くのサイトとユーザーにわたって DNS およびアプリケーション到達可能性障害として現れたという独立した証拠を提供した。[1][2]

より深い教訓は、分散 DNS が多くのサーバーを持っているにもかかわらず失敗したことではない。サービング分散と設定独立性が異なる特性であることである。エニーキャストはネットワークと大陸全体にサービスを分散できるが、共有制御入力は共通の障害モードを保持する。リゾルバキャッシュと顧客多様性は効果を和らげることができるが、安全な権威更新パイプラインの代わりにはならない。

リスクは変更が行使できる権限に従う。説明責任は誰がその権限を制約し、停止し、その結果を観測し、修復を証明できるかに従う。アプリケーション接続の前に位置するプラットフォームにとって、これらは単なるソフトウェアプロセスの好みではなく、ネットワークインフラの義務である。

Akamai の2021年エッジ DNS 障害：設定ロールアウトが到達可能性の説明責任テストとなった

要約