DYN がマネージド DNS を収益継続性の説明責任の境界とした

概要

• 確認:2016年10月21日、DYN はマネージド DNS インフラに対する DDoS 攻撃を報告した。同社の公開声明によると、第一波は東部標準時午前7時頃に始まり、米国東海岸の DYN サーバーへ誘導されるユーザーに影響を与え、約2時間後に緩和された。第二波は正午直前に始まり、よりグローバルな影響を及ぼし、1時間強で緩和された。DYN によると第三波の試みは顧客影響なしに緩和された。
• 観測:ThousandEyes はグローバルな観測点から DNS クエリの高い失敗率を測定し、攻撃のピーク時には約75%の観測点から送信されたクエリが DYN のサーバーで応答されなかったと報告した。また、監視対象のうち約1,200のサイトとサービスに影響が出ており、脆弱な顧客の多くが複数の DNS プロバイダーではなく DYN のネームサーバーのみを使用していたことも判明した。
• 限定された帰属:DYN は Flashpoint と Akamai の分析により、トラフィックの一部が Mirai に感染したデバイスに由来することが確認されたと述べた。後に米司法省は Mirai の作成者による有罪答弁と、2016年10月21日に Mirai 亜種ボットネットによる攻撃が DYN に影響を与え、Sony、Twitter、Amazon、PayPal、Tumblr、Netflix、Southern New Hampshire University などのサイトを数時間にわたりアクセス不能または断続的にした個人の有罪答弁を発表した。公開記録は、単一の攻撃者、単一のボットネット、または単一の攻撃ベクトルがその日 DYN が観測した全トラフィックを説明することを証明していない。
• 評価:このインシデントは共通モード依存性障害であった。DYN はマネージド DNS プラットフォーム、緩和パートナー、コミュニケーション、インフラアーキテクチャを管理していた。顧客は、権威 DNS がプロバイダー間で多様化されているか、TTL、フェイルオーバー、監視慣行が自らの可用性主張と一致しているかを管理していた。IoT ベンダー、所有者、ISP、規制当局、攻撃者はボットネット問題の異なる部分を管理していた。

証拠記録とその使用方法

本記事では、DYN の公開声明、独立した DNS 測定、司法省の記録、DNS 標準、セキュリティ研究、DDoS ガイダンス、市場コンテキストを層状の証拠として使用している。以下の表は、引用された各情報源が影響を受けたすべての顧客の損失を証明すると主張するものではなく、どの公開記録が説明責任分析を裏付けているかを説明するものである。

DNS はウェブアプリケーションよりも先に障害を起こした

ユーザーが DNS を意識するのは通常、それが壊れた時だけである。サイト名は正常に見える。ブラウザは動いている。ユーザーの接続は健全かもしれない。対象アプリケーションはまだ稼働しているかもしれない。しかし、権威 DNS 経路が応答できなければ、サーバー自体が消えたかのようにサービスは見えなくなる。それが DYN インシデントを混乱させた理由である。多くのサービスは、必ずしも自身のアプリケーション層で壊れていたわけではない。ユーザーが到達できるほど信頼性高く名前が解決できなかったのだ。

2016年10月のインシデントは、2種類のアウトソーシングの交差点に位置する。第一に、多くのデジタルビジネスは、グローバルなエニーキャスト到達性、トラフィックステアリング、運用専門知識、DDoS 準備を単独で経済的に構築できないため、権威 DNS をマネージドプロバイダーにアウトソースしていた。第二に、数百万の家庭や組織が、脆弱なデフォルト認証情報や貧弱な更新経路を持つ安全でない接続デバイスを公共インターネット上に配置していた。Mirai はこの第二のアウトソーシング選択を、第一のアウトソーシングに対する攻撃トラフィックに変換した。

公開された PDF コピー2016年10月21日の DDoS 攻撃に関する DYN の声明で保存されている DYN 自身の声明は、同社がマネージド DNS インフラに対する DDoS 攻撃を受けたと述べている。第一波は東部時間午前7時頃に始まり、約2時間後に復旧、第二波は正午直前に始まりよりグローバルで、午後1時頃に復旧、第三波の試みは顧客影響なしに緩和されたと説明している。DYN はまた、どの時点でもシステム全体の停止は発生しておらず、第一波の間に米国西海岸から影響を受けたサイトにアクセスしたユーザーなどは成功したであろうと述べた。

この詳細は重要である。このインシデントは、すべての DYN 顧客がどこでも消えるような単純な二値的停止ではなかった。それは地理、エニーキャスト、リゾルバの挙動、TTL、顧客のドメイン設定、DDoS トラフィックの強度変化によって形作られた可用性障害であった。これによりコミュニケーションは困難になった。顧客はあるネットワークからテストして成功しても、他の場所では失敗を見ることがあった。プラットフォーム所有者は健全なアプリケーションサーバーを持っていても、サービスがダウンしているとの苦情を受けることがあった。ユーザーはキャッシュされた DNS 回答が期限切れになるまで待ち、その後突然アクセスを失うことがあった。

共有依存性は測定結果に現れた

ThousandEyes の分析「DYN の DNS インフラに対する DDoS 攻撃」は、顧客側の依存性に関する最も明確な公開説明を提供している。その監視では、3つのフェーズが観測された：米国東海岸に集中した初期影響、より広範なグローバル影響、その後の緩和と残存攻撃またはブラックホール化。攻撃のピーク時には、グローバル観測点の約4分の3が DYN のサーバーに応答されない DNS クエリを送信した。また、監視対象ドメインのうち約1,200の影響を受けたサイトとサービスが報告された。

技術的要点は単純だが深刻だった。DYN は顧客ドメインの権威サーバーを運用していた。リゾルバが既に新鮮なキャッシュ回答を持っておらず、DYN の権威サーバーに到達できなければ、接続に必要なアドレスを取得できなかった。短い TTL 値は通常運用ではトラフィック管理をより俊敏にするが、同時にユーザーは権威解決の成功により頻繁に依存することになる。低 TTL 自体が悪いわけではなく、トレードオフである。DNS プロバイダーの DDoS イベント中は、「キャッシュがまだ行き先を知っている」状態から「リゾルバが再び利用不能な権威に問い合わせなければならない」状態への移行時間を短縮しうる。

ThousandEyes はまた、トラフィックステアリングにおける DYN の人気についても言及した。マネージド DNS は単なる静的な電話帳ではなかった。大規模サービスがユーザーを近くのデータセンターにルーティングし、トラフィックをシフトし、パフォーマンスを最適化するのに役立っていた。つまり、通常条件下で回復力と速度を向上させる製品が、同時に、その劣化が多数の顧客に同時に影響を及ぼしうる依存性にもなったのである。プロバイダーの価値提案が強いほど、共有制御プレーンとしての魅力が増す。

説明責任に関する ThousandEyes の最も重要な発見は、顧客アーキテクチャに関するものだった。影響を受けた多くの DYN 顧客は、複数の DNS プロバイダーに分散させるのではなく、DYN のネームサーバーのみを使用していた。分析では、単一のマネージド DNS プロバイダーの顧客と、複数のプロバイダーを使用していたため多くの他社で見られた完全な利用不能パターンではなく読み込み時間の遅延にとどまった Amazon.com を対比している。これは、すべての顧客が一夜にしてマルチプロバイダーDNS を導入できたことを意味するものではない。リスクがアーキテクチャ上のものであり、可視的であり、部分的に顧客によって制御されていたことを意味する。

シカゴ・サンタイムズが転載した AP 通信の記事は、一般の体験を捉えている：米国および欧州で人気ウェブサイトにアクセスしようとするユーザーへの波及効果があり、Twitter、Netflix、Sony の PlayStation Network が影響を受けたとされるサービスの一部であった。ガーディアンの同時代の報道は、Netflix、Twitter、Spotify、Reddit、CNN、PayPal、Pinterest、Fox News、主要新聞がオフラインまたは障害と報じられたと列挙した。これらの報道は範囲と公的認識の把握に有用であるが、各指名サービスが同じ技術的障害モードや同じ期間を経験したことを証明するものではない。

「冗長」な DNS 内に潜む共通モード障害

DNS は設計上冗長性が組み込まれている。ドメインは複数のネームサーバーをリストする。リゾルバは代替を試みることができる。権威サーバーは地理的に分散できる。問題は、冗長性が形式的であっても障害独立性がないことである。

RFC 2182は1997年以来、複数の DNS サーバーが存在する主な理由は、一つのサーバーが到達不能でもゾーン情報を利用可能に保つことであり、セカンダリサーバーは地理的およびトポロジ的に分散すべきだと述べている。全てのサーバーが同一の局所的障害モードを共有する設定に対して警告している。平易な言葉で言えば、複数のネームサーバーは、それらが同時に障害を起こすなら十分ではない。

DYN のケースは、この原則を物理的な場所からプロバイダー依存性へと変換した。顧客は複数の DYN ネームサーバーをリストしても、依然として一つのプロバイダー、一つの商業関係、一つの運用サポート経路、一つの DNS 管理認証情報、そしてそのプロバイダーへの大規模攻撃に対する一つの露出を持つ可能性がある。ドメインの観点からは、それらのネームサーバーは多様に見える。説明責任の観点からは、それらは依然として共通のプロバイダー依存性の一部である。

論文「主要ウェブサイトとサービスによる DNS 解決における冗長性の欠如」は、DYN インシデント後の DNS における集中と多様化を調査した。少数の DNS プロバイダーへの集中が増加し、ドメインが複数の DNS 管理プロバイダーを使用しない強い傾向が見られた。そのサンプルでは、攻撃前に単一プロバイダーを使用するドメインの割合は約91%から93%であり、2016年10月から2016年11月の間に92.2%から89.4%に低下した。DYN 顧客のうち、多様化していないドメインの割合はインシデント後に急減し、2017年5月まで減少し続けた。

これらの数値は、特定のデータセット内の研究結果として扱うべきであり、インターネット全体の正確な国勢調査ではない。それでも、実践的な教訓を裏付けている。DNS はプロバイダー多様化を可能にしたが、多くの顧客は障害独立性よりも運用の単純さを選択していた。それは不合理ではない。マルチプロバイダー権威 DNS は複雑さをもたらす：一貫したゾーンデータ、DNSSEC 署名と鍵管理、ヘルスチェック動作、トラフィックステアリングの違い、伝播遅延、スプリットブレインリスク、監視、契約上の説明責任。多様性のコストは実在する。DYN 攻撃は、多様化しないコストもまた実在し、顧客自身のインフラではなくサプライヤーを通じて到来しうることを示した。

エニーキャストは強力だが魔法ではない

DYN のインフラは、多くのグローバル DNS プラットフォームと同様にエニーキャストを使用していた。エニーキャストは、複数のロケーションが同一の IP アドレスをアナウンスし、インターネットルーティングがリゾルバを近くのまたは優先インスタンスに送ることができるようにする。レイテンシを改善し、トラフィックがネットワーク内を移動できるため多くの局所的障害を吸収する。これがマネージド DNS プロバイダーが広範な到達性と高速応答を提供できる理由の一つである。

エニーキャストは容量を無限にはしない。トラフィックを分散できるが、攻撃圧力も分散しうる。攻撃が十分に大規模、広範囲、または上流リンクやピアリング、共有プレフィックスを輻輳させるような方法で標的化された場合、エニーキャストロケーションは共倒れしたり、複雑に変動したりする。ThousandEyes は、多くのクエリが DYN のインターネットサービスプロバイダーや DYN のネットワークエッジを通過できず、同じコンステレーションとグループ内のネームサーバーが相関したパフォーマンスを示したことを観測した。この観測は DYN の内部設計が過失であったと証明するものではない。これは、「複数のプレゼンスポイントがある」ことが「あらゆる妥当な DDoS 条件下で独立した可用性がある」ことと同じではない理由を示している。

DYN の声明は、シナリオを練習し、プレイブックを持ち、緩和パートナーを利用し、インシデント管理と顧客コミュニケーションを開始したと述べた。また、攻撃は高度に分散しており、Mirai に関連する数千万の個別 IP アドレスが関与し、複数のベクトルとインターネットロケーションを使用したとも述べている。プロバイダーは、DDoS 緩和が単に十分な帯域を購入する問題であるかのように判断されるべきではない。非常に大規模な分散攻撃は、測定エラー、再試行ストーム、副次的トラフィック、経路不安定性、攻撃トラフィックのフィルタリングと正当なクエリの維持との間の困難なトレードオフを生み出す。

それでも、顧客はまさにこの運用領域における専門知識をプロバイダーが主張するからこそマネージド DNS を購入する。したがって、DYN はプロバイダー側の回復力の責任を負っていた：容量計画、上流調整、エニーキャストアーキテクチャ、ネームサーバーコンステレーション設計、ステータス通信、顧客サポート、緩和パートナーの準備、インシデント後の証拠。公正な説明責任の説明は、両方の考えを同時に保持できる。攻撃は悪意があり大規模だった。DYN のビジネスは、敵対的条件下で権威 DNS を到達可能に保つことだった。

Mirai は消費者デバイスリスクをインフラに持ち込んだ

Mirai がこの攻撃を文化的に記憶に残るものにしたのは、ボットネットが主に通常のインターネット接続デバイス—カメラ、ルーター、デジタルビデオレコーダー、同様の組み込みシステム—から構築されたからである。USENIX の論文「Mirai ボットネットの理解」は、Mirai が主に組み込みおよび IoT デバイスで構成され、最大約60万の感染に達したと説明している。論文は、感染方法の単純さと急速な成長が、比較的洗練されていない技術で十分な低価格デバイスを侵害し、十分に防御された標的を脅かす可能性があることを示したと論じている。

司法省の2017年 Mirai 発表「司法省が重大な DDoS 攻撃に関与した3件のコンピューター犯罪事件で起訴と有罪答弁を発表」は、Paras Jha、Josiah White、Dalton Norman が Mirai ボットネットを運営し、ワイヤレスカメラ、ルーター、デジタルビデオレコーダーなどの IoT デバイスを標的としたと述べた。司法省によると、Mirai はピーク時に数十万台の侵害デバイスで構成され、Jha が2016年秋に犯罪フォーラムでソースコードを投稿した時点でオリジナルの Mirai 亜種への関与は終了した。その後、他の行為者が他の攻撃で Mirai 亜種を使用したと司法省は述べている。

司法省の2020年発表「個人が2016年のモノのインターネットサイバー攻撃への関与で有罪答弁」は、Mirai 亜種ボットネットを DYN の日により直接的に結びつけた。元少年とされる個人が、2016年10月のサイバー攻撃に関連して有罪答弁したと発表した。司法省によると、この個人と他の者は、Sony PlayStation Network をオフラインにする目的で2016年10月21日に複数の DDoS 攻撃を開始するためにボットネットを使用し、その攻撃は DYN に影響を与え、Sony、Twitter、Amazon、PayPal、Tumblr、Netflix、Southern New Hampshire University などのウェブサイトを数時間にわたりアクセス不能または断続的にした。

この帰属記録は慎重に使用されるべきである。これは、少年行為者がすべての DYN 影響の唯一の原因であったとも、DYN のトラフィック全体が一つのボットネットから来たとも述べていない。DYN 自身は、攻撃トラフィックの一つの源が Mirai 感染デバイスであると述べた。プロバイダーはまた、複数のベクトルとインターネットロケーションを説明している。最も安全な結論は、Mirai と Mirai 亜種が実質的に関与し、犯罪行為の層は回復力アーキテクチャの層から分離されているということである。

Mirai の脅威に関する CISA アラートは、Mirai マルウェアが脆弱な IoT デバイスをスキャンし、Mirai ソースコードの公開が更なるボットネットのリスクを高めたと警告した。後に NIST がホストした商務省と国土安全保障省の報告書「ボットネットおよびその他の自動化された分散脅威に対するインターネットと通信エコシステムの回復力強化」は、問題をエコシステム全体として位置付けた：自動化分散攻撃はグローバルであり、効果的なツールは広く使用されておらず、製品はライフサイクル全体で保護されるべきであり、インセンティブはずれており、単一の利害関係者コミュニティでは問題を解決できない。

このエコシステムの枠組みは、狭い非難の物語よりも DYN インシデントにより適合する。攻撃者は所有していないデバイスを悪用した。デバイスメーカーは、強力なアップデート、アイデンティティ、ライフサイクル管理のない低コスト製品を出荷することが多かった。デバイス所有者は、クローゼットの中のカメラやレコーダーが DNS インフラへの攻撃に参加しうることをほとんど理解していなかった。ISP は感染デバイストラフィックに対する部分的な可視性を持っていたが、インセンティブと実際の制限が混在していた。DNS プロバイダーは、攻撃がエッジに達した時にそれを認識した。顧客は、名前が解決しなくなった時にそれを認識した。ユーザーは、サイトが読み込まれないという形でのみそれを認識した。

後のNISTIR 8259A IoT デバイスサイバーセキュリティ能力コアベースラインは2016年には存在せず、DYN に対する遡及的な法的義務として扱うべきではない。それでも、エコシステムが何を重視するようになったかの証拠として有用である：デバイス識別、セキュア設定、データ保護、論理的アクセス、ソフトウェアアップデート能力、サイバーセキュリティ状態認識、文書化。Mirai が成功したのは、多くのデバイスが責任あるインターネット参加者として管理できなかったからである。

顧客の制御は実在したが不均等だった

マネージド DNS の顧客は受動的な傍観者ではなかった。ドメイン所有者は、委任の選択、プロバイダー選択、監視、TTL ポリシー、フェイルオーバー設計、そして重要なサービスが一つの DNS プロバイダーの喪失を生き残れるかどうかを管理する。しかし、その制御は顧客間で平等ではなかった。深いインフラチームを持つ大規模プラットフォームは、複数の権威プロバイダーを運用し、スタックの一部を自己ホストし、一貫性自動化を維持し、多くのネットワークから解決をテストすることができた。小規模な出版社、小売業者、ソフトウェアベンダー、非営利団体、自治体サービスは、まさにそのスキルを回避するためにマネージド DNS を購入したかもしれない。

ここでクラウドサービス依存性が説明責任の問題となる。サプライヤーは専門知識を販売できるが、顧客はどのレベルのサプライヤー障害を許容できるかを決定する必要がある。問題は「すべてのウェブサイトが特注のグローバル DNS ネットワークを運営すべきか」ではなく、それは経済的に不合理である。問題は、顧客の可用性の約束が依存関係マップと一致しているかどうかである。オンライン到達性をミッションクリティカルと見なすビジネスは、単一のマネージド DNS プロバイダーが単一障害点であるかどうかを知るべきである。レジストラでの委任変更の速さ、キャッシュされた NS レコードの存続期間、セカンダリプロバイダーが最新のゾーンを持っているかどうか、DNSSEC が検証を継続するかどうか、パブリックインシデントを発生させずにフェイルオーバーをテストできるかどうかを知るべきである。

小規模組織にとって、現実的な回答は完璧なマルチプロバイダーアーキテクチャではないかもしれない。それはより狭い復旧計画かもしれない：最も重要なレコードのために構成された第二のプロバイダー、安定した資産に適切な長い TTL、レジストラ認証情報を複数の信頼できる人物に利用可能にすること、帯域外ステータスページ、キャッシュされた緊急連絡先情報、DNS 解決障害をアプリケーション障害と区別する監視。それは完全に自動化された多様性ほど洗練されていないが、グローバルなサプライヤーインシデントの最中に依存性を発見するよりはまだ良い。

このリスクは下流のユーザーにも及ぶ。到達不能になるマーケットプレイス、出版社、SaaS プロバイダー、支払いサービスは、広告主、販売者、サポートチーム、契約業者、顧客にコストを転嫁する。ユーザーは根本原因が DNS、DDoS、クラウドホスティング、ISP ルーティング、またはアプリケーションのバグであるかを見ることができない。単に取引できない。マネージド DNS は経路の非常に早い段階に位置するため、その障害は名前解決が戻るまで以降のすべての冗長性を無意味にしうる。

コミュニケーションは二つの聴衆にサービスしなければならなかった

DYN には二つのコミュニケーション問題があった。直接の顧客に何が起こっていて、何を期待できるかを伝えなければならなかった。また、停止が DYN の契約顧客ベースをはるかに超えて可視的であったため、より広範なインターネットコミュニティにも伝えなければならなかった。一般ユーザー、ジャーナリスト、規制当局、インフラピア、競合他社は、このイベントが標的型プラットフォーム停止なのか、より広範なインターネット不安定性なのか、ボットネット緊急事態なのか、DNS 集中問題なのかを理解することに利害があった。

DYN の声明は、慎重なプロバイダー物語を提供した：システム全体ではなく、地域的に可変、二つの顧客影響波、緩和された第三波の試み、インシデント管理の起動、緩和パートナーの関与、トラフィック源の一つとして Mirai の確認、そして将来の防御を保持するために更なる詳細は控える。このバランスは防御可能である。DDoS プロバイダーは、進行中または再現可能な攻撃中に完全な緩和設計図を公開すべきではない。

しかし、顧客は安心感以上のものを必要としていた。意思決定支援が必要だった。直ちに DNS プロバイダーを変更すべきか？TTL を変更すべきか？顧客向け停止通知を発行すべきか？ゾーン伝播は遅延しているか？すべての地域が影響を受けているか？顧客の DNS レコードは無事か？どのネームサーバーグループが劣化しているか？問題の再発が予想されるか？プロバイダーが自らをインターネットインフラとして売り込むほど、そのステータスコミュニケーションはサービスの一部となる。

このインシデントはまた、顧客が独立した監視を必要とする理由を示した。プロバイダーのステータスページは遅延または簡略化される可能性がある。顧客自身のアプリケーションチェックは、ウォームキャッシュを持つネットワークから実行されると DNS 障害を見逃すかもしれない。監視は、権威ルックアップ、複数地域からの再帰的解決、アプリケーション到達性、依存性固有の障害をテストすべきである。ThousandEyes の公開分析が強力だったのは、DNS クエリ障害を「インターネットがダウンしている」という漠然としたユーザー感覚から分離したからである。

キャッシュ、再試行、準備が被害の形状を変えた

DNS 障害は、再帰層がユーザーと権威プロバイダーの間に位置するため、均等に経験されない。再帰リゾルバが既に有効なキャッシュ回答を持っていれば、権威サーバーが障害を起こしている間もユーザーはサービスに到達し続けることができる。キャッシュ回答が期限切れになったり、リゾルバが回答を持っていなければ、同じサービスがそのネットワークから突然到達不能になることがある。同じ都市の二人のユーザーが、リゾルバ、キャッシュ、クエリタイミングが異なるために異なる結果を報告しうる。

この挙動は非難と対応の両方を複雑にする。サービス所有者はオリジンサーバーを見て正常な状態を確認するかもしれない。マネージド DNS プロバイダーは、攻撃トラフィック、正当なリゾルバ再試行、古いキャッシュ効果、経路変更の混在を観測するかもしれない。再帰オペレーターは、応答がタイムアウトしたときに再試行することでクエリ圧力を増加させる可能性がある。ユーザーは断続的な到達性を認識し、アプリケーションが壊れていると想定するかもしれない。公の物語は「主要ウェブサイトがダウンしている」となるが、技術的な現実は「一部のリゾルバが一部の時間枠で一部のドメインの権威回答を取得または更新できない」に近い。

RIPE Labs のDYN 攻撃の概要は、RIPE Atlas 測定を使用してイベントを分散プローブから観測した。関連する RIPE Labs ノート「DNS DDoS に関する考察」は、再帰的再試行トラフィックが影響を悪化させうること、DNS プロトコル DDoS 中に正当な DNS トラフィックと攻撃トラフィックを区別することが困難であることを強調した。これらは DYN に対する法的判断ではない。DNS DDoS 緩和が、単一の敵対的ソースをブロックしたり単一のバックアップサーバーを追加するよりも厄介である理由を説明している。

インシデント後の研究は、別の角度から同じ点を指摘した。論文「堤防が決壊するとき：DDoS 中の DNS 防御の解剖」は、キャッシングが DNS 回復力の重要な要素であり、異なる DNS レイヤーが DDoS を非常に異なって経験しうると論じている。この論文は DYN インシデントを、DNS プロバイダーとして DYN を使用しているドメインに影響を与えた可視的停止の例として使用し、一方でルートサーバーのような他の DNS 標的は可視的なサービス停止なしに攻撃を吸収したと指摘している。教訓は、ある DNS レイヤーが安全で別のレイヤーが弱いということではない。アーキテクチャ、キャッシング、多様性、トラフィック量、オペレーターの実践が組み合わさって公的影響を決定するということである。

マネージド DNS 顧客にとって、これは準備がリスク登録簿上のベンダー名以上のものを含むべきことを意味する。顧客は、どのレコードが長いキャッシュ寿命に十分安定しているか、どのレコードが動的ステアリングを必要とするか、どの再帰リゾルバがユーザーにとって重要か、古い回答がフェイルオーバーにどのように影響しうるかを知る必要がある。また、緊急 TTL 変更がインシデント前に有用か、それともキャッシュが既に古い値を保持している後ではほとんど象徴的かを決定する必要がある。DNS 変更は時間依存性であり、即時のグローバル伝播を前提とする復旧計画は復旧計画ではない。

一般的な DDoS ガイダンスは同じ運用規律を強化する。英国国家サイバーセキュリティセンターのサービス拒否ガイダンスコレクションは、準備を4つの実践に枠付けている：サービスを理解する、防御を理解する、対応計画を作成する、対応をテストする。CISA のサービス拒否攻撃の理解は、基本的な可用性問題を説明する：正規のユーザーが情報システム、デバイス、ネットワークリソースにアクセスできない。CISA、FBI、MS-ISAC による後の分散型サービス拒否攻撃の理解と対応は DNS よりも広範だが、原則は適合する：組織は事前準備、サービスプロバイダーとの調整、トラフィックベースライン、対応手順、コミュニケーション計画を必要とする。

これらの実践は、クラウド依存性に関する不快な真実を露呈する。顧客は DNS 運用をアウトソースできるが、DNS 障害が自社のビジネスにどのように影響するかの知識をアウトソースすることはできない。DYN は自社のインフラに対する攻撃を緩和できたが、すべての顧客の許容可能な劣化状態を知ることはできなかった。銀行、マーケットプレイス、出版社、大学、ゲームネットワーク、病院予約ポータルは、遅い解決、古い回答、地域的到達性喪失に対する許容度が異なる。顧客の継続性計画は、プロバイダーのステータスをビジネス上の意思決定に変換しなければならない：ユーザーに通知するか、チャネルをシフトするか、取引を中断するか、フェイルオープンかフェイルクローズか、DNS が安定するまで部分的な到達性を受け入れるか。

DYN にとって、同じ準備原則は逆方向に走る。マネージド DNS プロバイダーは、自社のインフラに対する DDoS イベントが単にネットワーク内部の技術的インシデントではないことを理解しなければならない。それは同時多発的な顧客危機である。顧客は、委任変更を即興で行ったり、TTL を短縮したり、ゾーンを一貫性なく移動させたり、サポートを殺到させたりしてイベントを悪化させることを避けるために十分な情報を必要とする。プロバイダーのプレイブックは、したがって、緩和、顧客セグメンテーション、ステータス精度、および異なるレベルの DNS 洗練度を持つ顧客向けのガイダンスを含まなければならない。

2016年10月のインシデントは、共有準備層の薄さを明らかにしたために部分的に損害が大きかった。DNS エンジニアはキャッシング、エニーキャスト、権威解決を理解していた。多くのビジネスリーダーとユーザーは理解していなかった。一部の顧客はプロバイダー多様性を理解していた。多くの顧客はそれを実装していなかった。IoT セキュリティ専門家はデフォルト認証情報と管理されていないデバイスフリートのリスクを理解していた。数百万のデバイスが既に露出していた。共通モード障害は、専門知識が別々のコミュニティに存在するが、共有された運用上のコミットメントに変換されていない場合にしばしば発生するものである。

法的境界は運用上の教訓よりも狭い

公開記録は、悪意のある DDoS 活動、DYN サービス障害、顧客到達性問題、Mirai の関与、その後の刑事答弁を確立している。DYN が特定の契約に違反したこと、すべての影響を受けた顧客が合理的なアーキテクチャを欠いていたこと、すべての IoT メーカーが法的義務に違反したこと、またはすべての損失が一人の被告に帰属できることを確立していない。個々の DYN 契約、顧客のサービスレベル契約、保険契約、第三者依存性の条件は、広範な法的結論を支持する形では公開されていない。

その境界は運用上の教訓を弱めるべきではなく、むしろ明確にする。法的過失はフォーラム固有である。運用管理は設計選択に可視的である。DYN はプロバイダーレベルの回復力とコミュニケーションを管理していた。顧客は DNS プロバイダー多様化と継続性計画を管理していた。IoT ベンダーはデフォルト認証情報、アップデート経路、ライフサイクルサポートを管理していた。デバイス所有者は、展開と基本的強化を製品が実用的にした範囲でのみ管理していた。ISP とセキュリティ企業は検出、通知、緩和の選択を管理していた。政府はインセンティブ、基準、法執行対応、官民調整を管理していた。

このインシデントが説明責任分析に属するのは、単一の層では全体の障害を修復できなかったからである。完璧なマルチプロバイダーDNS 顧客でも、スタックの他の場所にある大規模ボットネットに苦しむ可能性がある。よく構築された IoT 製品ラインは、顧客の権威 DNS を多様化しない。優れた DNS プロバイダーでも、販売していないデバイスからの前例のない敵対的トラフィックに直面する可能性がある。政府報告書はライフサイクルセキュリティを推奨できるが、数百万の露出デバイスを即座に置き換えることはできない。共通モード障害は、これらの層の間の適合から出現した。

インシデント後の市場シグナル

攻撃の1ヶ月後、Oracle は DYN を買収することで合意したと発表した。Oracle のプレスリリースは、DYN を大手クラウドベースのインターネットパフォーマンスおよび DNS プロバイダーと説明し、3,500以上のエンタープライズ顧客のために毎日400億のトラフィック最適化決定を推進し、Netflix、Twitter、Pfizer、CNBC などの顧客を挙げた。この買収は、攻撃の結果として解釈されるべきではない（リリースはそう述べていない）。それでも、DYN の市場役割の文脈として有用である。これはニッチな趣味のサービスではなかった。高プロファイルのデジタルビジネス向けの主要なマネージド DNS プラットフォームであった。

その市場地位こそが、このインシデントが依然として重要な理由である。クラウド集中はしばしば真の利益を生み出す：より良い専門知識、よりグローバルな到達性、より速い緩和、専門スタッフ、規模の経済。それはまた、障害モードを変える。多くの顧客が同じプロバイダーに収束するとき、彼らの独立した事業継続性の主張は相関するようになる。プラットフォームは機能をアウトソースしても、アウトソーシングアーキテクチャの結果を依然として所有する。

2018年の商務省と国土安全保障省の報告書は、ボットネット回復力に対して市場インセンティブがずれていると論じた。同様のインセンティブ問題がマネージド DNS の顧客側にも存在した。単一プロバイダーDNS は購入、設定、監視、サポートが容易である。マルチプロバイダーDNS は共通モードリスクを低減するが、エンジニアリングの複雑さと設定ミスの可能性を増加させる。その複雑さを回避する顧客は、平時には決して罰せられないかもしれない。ペナルティは、サプライヤーがストレス下で故障した時にのみ現れ、その時には多くの顧客が同じイベントを同時に経験するかもしれない。

実践的説明責任テスト

DYN のケースはリーダーに、依然として有用な複数のテストを提供する。

権威 DNS 依存性:各クリティカルドメインとサブドメインに対してどのプロバイダーが応答するか？リストされたすべてのネームサーバーは同じプロバイダーによって、または同じルーティングと管理制御プレーンを通じて運用されているか？そのプロバイダーが主要地域から到達不能な場合にどのサービスが故障するか？

プロバイダー独立性:最新のゾーンデータを持つ第二の権威 DNS プロバイダーはあるか？もしあるなら、ネットワーク、制御プレーン、認証情報、サポート経路、DDoS 緩和において真に独立しているか？もしなければ、組織は単一プロバイダーリスクを意識的に受け入れているか？

TTL とキャッシュ戦略:DNS TTL は、俊敏性の必要性と停止許容度に対する組織の実際の要件を反映しているか？最も安定したレコードは、一時的なプロバイダー障害時の頻繁な権威ルックアップへの回避可能な依存を減らすのに十分なキャッシュ寿命を与えられているか？

DNSSEC と変更管理:DNSSEC が有効な場合、署名、鍵、DS レコードはマルチプロバイダー運用や緊急プロバイダー変更に耐えられるか？もしくは、フォールバックは安全に失敗するかもしれず、その場合でもユーザーはサービスに到達できない。

監視:組織は権威 DNS 障害、再帰リゾルバ問題、CDN の問題、オリジン障害、アプリケーション障害を区別できるか？エニーキャストや地域的な DNS 問題を検出するために十分な数のネットワークと地域からテストが実行されているか？

レジストラ復旧:レジストラ認証情報、レジストリロック、緊急連絡先、委任変更手順は文書化され、保護され、インシデント中に利用可能か？安全に委任を変更できなければ、バックアップ DNS プロバイダーは役に立たない。

サプライヤーコミュニケーション:マネージド DNS プロバイダーは、防御方法を露出せずに、顧客が選択を行うために必要なレベルのステータス詳細を提供しているか？顧客サポート経路は、多くの顧客が同時に支援を求める同時影響イベント向けに設計されているか？

ボットネット露出:接続デバイスを製造、展開、管理する組織にとって、デフォルト認証情報、セキュアアップデート、デバイスアイデンティティ、脆弱性報告、サポート終了サポートは、デバイスフリートが他者の DDoS 能力にならないように設計されているか？

これらのテストは、抽象的なエンジニアリングの純粋さではない。ドメイン所有者が「冗長なネームサーバーがある」ということが、真の障害独立性を意味するのか、単に一つのプロバイダー依存性内の複数のホスト名を意味するのかを学ぶ方法である。

永続的な教訓

DYN はマネージド DNS が悪いことを証明しなかった。真実に近いのはその逆である：マネージド DNS が存在するのは、DNS 可用性が困難で専門的であり、グローバルに露出しているからである。多くの顧客は、専門知識なしに独自の権威インフラを運用することを強いられれば、回復力が低下するだろう。このインシデントは、アウトソーシングがアーキテクチャを消去しないことを証明した。アーキテクチャの一部をサプライヤーに移動させ、その後顧客はそのサプライヤーがコンポーネントなのか共通モード依存性なのかを決定することを要求する。

また、Mirai は消費者 IoT だけがすべてのインフラ停止の責任を負わされうることを証明しなかった。安全でないエッジデバイスが、中核サービスを脅かすのに十分な力に集約されうることを証明した。それらのデバイスを所有する家庭や企業は DYN を攻撃する意図はなかった。デバイスベンダーは自社製品をインターネットインフラの一部として想像しなかったかもしれない。しかし、公共インターネットはそれにもかかわらず彼らを参加者にした。

したがって、DYN インシデントの説明責任ある記憶は層状であるべきだ。犯罪行為者が攻撃を開始した。DYN は極度の敵対的トラフィック下で高価値 DNS プラットフォームを防御し、それでも顧客影響のある障害を経験した。多くの顧客は権威 DNS を一つのプロバイダーに依存し、複数のネームサーバーが常にプロバイダー多様性を意味するわけではないことを発見した。IoT ベンダーと所有者は、弱いデバイスが攻撃リソースになることを許していた。政府と標準化団体は後に、ボットネット回復力を単に一人の攻撃者を罰する問題ではなく、市場とエコシステムの問題として枠付けた。

実践的な教訓は厳しい：到達可能性は退屈な制御プレーンに依存する。企業は冗長なアプリケーションサーバー、複数のクラウド、アクティブ-アクティブリージョン、洗練されたインシデント対応を構築しても、権威 DNS 依存性が単一プロバイダーで到達不能であれば、ユーザーのブラウザから消えうる。DNS 委任は力である。それを低リスクの調達項目として扱うことが、マネージドサービスが共通モード障害になる方法である。