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、規制当局、攻撃者がボットネット問題のそれぞれ異なる部分を管理していた。

DNS 障害は Web アプリケーションよりも先に発生した

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

2016 年 10 月のインシデントは、2 つの形態のアウトソーシングが交差する地点にある。第一に、多くのデジタル企業は権威 DNS をマネージドプロバイダーに委託した。なぜなら、そのプロバイダーがグローバルなエニーキャスト到達範囲、トラフィックステアリング、運用ノウハウ、DDoS 対策を提供でき、多くの顧客が単独で経済的に構築できるものではなかったからだ。第二に、数百万の家庭や組織が、安全でない接続デバイスを公共のインターネットに設置し、しばしば弱いデフォルトの認証情報や貧弱な更新経路のまま放置していた。Mirai は、その 2 つ目のアウトソーシングの選択を、1 つ目に対する攻撃トラフィックに変換した。

Dyn 自身の声明は、Dyn の 2016 年 10 月 21 日 DDoS 攻撃に関する声明の公開 PDF に保存されており、同社がマネージド 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 サーバーを設置する主な理由は、1 つのサーバーが到達不能でもゾーン情報を利用可能に保つことであり、セカンダリサーバーは地理的およびトポロジー的に分散されるべきだと述べている。すべてのサーバーが同じ局所的な障害モードを共有する設定に対して警告している。平易な言葉で言えば、複数のネームサーバーがあっても、それらが同時に故障するなら十分ではない。

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

論文主要ウェブサイト・サービスによる DNS 解決の冗長性の欠如は、Dyn インシデント後の DNS における集中と多様化を調査した。少数の DNS プロバイダーへの集中が進み、ドメインが複数の DNS 管理プロバイダーを使用しない強い傾向があることを発見した。そのサンプルでは、攻撃前に単一のプロバイダーのみを使用していたドメインの割合は約 91%から 93%であり、2016 年 10 月から 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 がこの攻撃を文化的に記憶に残るものにしたのは、ボットネットが主にカメラ、ルーター、デジタルビデオレコーダーなどの一般的なインターネット接続デバイスから構築されたためである。Mirai ボットネットの理解（USENIX 論文）は、Mirai が主に組み込みおよび IoT デバイスで構成され、約 60 万の感染のピークに達したと説明している。この論文は、感染方法の単純さと急速な成長が、比較的洗練されていない技術でも、十分な低スペックデバイスを侵害し、十分に防御された標的を脅かすことができたことを示したと論じている。

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

司法省の 2020 年の発表、2016 年の IoT サイバー攻撃への関与について個人が有罪答弁は、Mirai 変種ボットネットと Dyn の日をより直接的に結びつけた。それによると、元未成年の個人が 2016 年 10 月のサイバー攻撃に関連して有罪答弁した。司法省によれば、この個人と他の者たちは、2016 年 10 月 21 日に Sony PlayStation Network をオフラインにする目的でボットネットを使用していくつかの DDoS 攻撃を仕掛け、その攻撃が Dyn に影響を及ぼし、Sony、Twitter、Amazon、PayPal、Tumblr、Netflix、Southern New Hampshire University などのウェブサイトを数時間にわたってアクセス不能または断続的にした。

この原因特定の記録は注意深く使用されるべきである。これは、その未成年のアクターが Dyn へのすべての影響の唯一の原因であるとは言っておらず、また Dyn のトラフィック全体が単一のボットネットから来たことも意味していない。Dyn 自身は、攻撃トラフィックの一因が Mirai 感染デバイスであると述べた。プロバイダーはまた、複数のベクトルとインターネットロケーションについても述べている。最も安全な結論は、Mirai とその変種が実質的に関与しており、犯罪行為の層は回復力アーキテクチャの層とは別であるということだ。

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

このエコシステムの枠組みは、狭い非難の物語よりも Dyn のインシデントに適合する。攻撃者は自分が所有しないデバイスを悪用した。デバイスメーカーは、しばしば強固な更新、識別、ライフサイクル管理なしに低コスト製品を出荷していた。デバイス所有者は、クローゼットの中のカメラやレコーダーが DNS インフラへの攻撃に参加し得ることをほとんど理解していなかった。ISP は感染デバイスのトラフィックを部分的に可視化できたが、インセンティブは混在し、実用上の限界があった。DNS プロバイダーは攻撃が自社のエッジに達した時にそれを認識した。顧客は名前の解決が停止した時にそれを認識した。ユーザーは単にサイトが読み込まれないこととしてのみ認識した。

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

顧客制御は現実だが不平等だった

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

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

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

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

コミュニケーションは 2 つのオーディエンスに対応する必要があった

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

Dyn の声明は注意深いプロバイダーの物語を提供した：システム全体ではなく、地域によって異なり、2 つの顧客影響波、緩和された第 3 の試行波、インシデント管理の起動、緩和パートナーの関与、Mirai がトラフィック源の一つとして確認、将来の防御を維持するために詳細は控える。このバランスは弁護可能である。DDoS プロバイダーは、進行中または再現可能な攻撃の最中に完全な緩和の青写真を公開すべきではない。

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

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

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

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

この動作は、非難と対応の両方を複雑にする。サービス所有者はオリジンサーバーを見て正常な健全性を確認するかもしれない。マネージド 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 ガイダンスも同じ運用規律を強化する。英国国家サイバーセキュリティセンターのサービス拒否（DoS）ガイダンスコレクションは、準備を 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 メーカーが法的義務に違反したこと、またはすべての損失が 1 人の被告に帰属できることを立証しているわけではない。個々の 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 依存性：各クリティカルドメインとサブドメインに対してどのプロバイダーが応答するか？リストされたすべてのネームサーバーは同じプロバイダーまたは同じルーティングおよび管理制御プレーンを通じて運用されているか？そのプロバイダーが主要地域から到達不能になった場合、どのサービスが機能しなくなるか？

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

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

DNSSEC と変更管理：DNSSEC が有効な場合、署名、鍵、DS レコードはマルチプロバイダー運用や緊急プロバイダー変更に耐えられるか？耐えられない場合、フォールバックは安全に失敗する可能性があり、それは依然としてユーザーがサービスに到達できないことを意味する。

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

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

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

ボットネット露出：接続デバイスを製造、展開、または管理する組織にとって、デフォルト認証情報、安全な更新、デバイス識別、脆弱性報告、サポート終了は、デバイス群が他者の DDoS 能力にならないように設計されているか？

これらのテストは抽象的な工学の純粋性ではない。これらは、ドメイン所有者が「冗長なネームサーバーがある」という言葉が、真の障害独立性を意味するのか、それとも 1 つのプロバイダー依存関係内のいくつかのホスト名に過ぎないのかを学ぶ方法である。

永続的な教訓

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

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

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

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