Dyn は DNS 依存を収益継続のアカウンタビリティ問題とした

概要

• Dyn インシデントは従来のアプリケーション障害ではなかった。影響を受けた多くのオンラインサービスではサーバー、スタッフ、ソフトウェアは稼働していたが、攻撃者がインターネットにサービスがどこにあるかを伝える権威 DNS 層を標的にしたため、ユーザーは確実に到達できなかった。
• Dyn は自社の権威 DNS インフラ、DDoS 対応、ステータス通信、顧客支援を管理していた。顧客はプロバイダー集中、セカンダリ DNS、TTL 選択、レジストラ準備、監視、事業継続前提を管理していた。IoT メーカーとアクセスネットワークは攻撃規模を可能にしたボットネットリスクの一部を管理していた。
• アカウンタビリティ問題は収益継続である。小売業者、メディアサイト、SaaS プロバイダー、公共サービスは、原本アプリケーションが健全でも、名前解決が攻撃されたプロバイダーに過度に依存している場合、注文、広告、サポートチャネル、ユーザーの信頼を失う可能性がある。
• 耐久性のある修復は、DNS が重要な依存関係として設計されている証拠である：複数プロバイダー権威、テスト済みゾーン転送または自動化、独立した監視、実践されたレジストラ変更、現実的な TTL、DDoS 容量、ステータス通知、到達可能性は収益管理の一部であるという取締役会レベルの認識。

DNS 障害は健全なサービスを到達不能にする

DNS は、障害が発生するまで目に見えないことが多い。ユーザーは、背後にある権威ネームサービスの連鎖ではなく、到達しようとしたブランドを覚えている。2016年10月21日、インターネットの大部分が断続的な到達不能問題を経験した。これは、当時大手マネージド DNS プロバイダーであった Dyn が、持続的な分散型サービス拒否攻撃を受けたためである。Dyn の攻撃の分析概要は、複数の攻撃波と Mirai ボットネットに関連する多数の悪意のある送信元アドレスを説明している。Dyn の初期の公開声明は、この出来事を顧客アプリケーションの侵害ではなく、マネージド DNS インフラへの攻撃として位置づけた。

その違いは重要である。サービスの Web サーバーがダウンした場合、サービス提供者はアプリケーションの復旧に集中できる。DNS 解決が失敗すれば、ユーザーはサーバーに到達できず、サーバーが健全であることを知ることもできない。マネージド DNS は収益、サポート、公開通信、認証、コンテンツ配信の前に位置する。すべてのトランザクションを処理するわけではないが、多くのトランザクションを開始できるかどうかを決定する。これにより DNS は、単なる技術的なアドレス帳ではなく、収益継続の依存関係となる。

2016年の攻撃は集中問題も明らかにした。多くの著名なサービスが DNS に Dyn を使用していた。Dyn が攻撃されたとき、それらの顧客は障害領域を共有した。一部はセカンダリ DNS やその他の緩和策を持っていた。他は Dyn の可用性に大きく依存していた。ユーザーの体験は地理、リゾルバキャッシュ、タイミング、顧客設定によって異なった。一般の目には一つのインターネット障害として映ったが、実際のアカウンタビリティマップには Dyn のインフラ、顧客の DNS アーキテクチャ、レジストラ制御、再帰リゾルバ、トランジットネットワーク、ボットネットを動かした脆弱な IoT デバイスが含まれていた。

アメリカ合衆国コンピュータ緊急対応チームは、2016年10月の Mirai およびその他のボットネットによる DDoS リスク増大に関する注意喚起で、Mirai 型の脅威についてすでに警告していた。この警告は Dyn 事件よりも前であり、侵害された IoT デバイスが DDoS 攻撃に使用されていることを説明していた。そのタイミングは重要である。Dyn 攻撃は IoT ボットネット問題を生み出したのではなく、ボットネットの規模が共有 DNS プロバイダーを公開到達不能のチョークポイントに変えることを示した。

Dyn の制御は現実的だったが、完全ではなかった

Dyn はマネージド DNS インフラと対応を直接制御していた。顧客が購入したサービスを運営し、DDoS 防御を維持し、上流プロバイダーと調整し、顧客に最新情報を提供し、サービスを復旧した。顧客は Dyn が大規模な攻撃からプラットフォームを防御することを合理的に期待できた。同時に、大手プロバイダーの防御でも、多くのネットワークからの分散トラフィックによって圧倒されたり、劣化したりする可能性がある。アカウンタビリティの問いは Dyn が無敵であるべきかどうかではない。Dyn、顧客、そして広範なエコシステムが、攻撃された一つのプロバイダーが作り得る爆発範囲を縮小したかどうかである。

顧客は異なる一連の事実を制御していた。単一プロバイダーの権威 DNS を使用するか、複数プロバイダー構成にするかを選択した。キャッシュとフェイルオーバーの動作に影響する TTL を設定した。レジストラアクセスとゾーン管理手順を維持した。アプリケーションの健全性とは別に DNS を監視した。ストレス下で権威を移すことを実践したか、しなかった。DNS の復元力を取締役会レベルの収益問題とするか、インフラチームに任せる技術的詳細とするかを決定した。これらの選択が Dyn の停止を短時間の劣化、大きな収益中断、または公開信頼事件にするかを決めた。

DNS 設計にはトレードオフが伴うため、普遍的な答えはない。複数プロバイダーDNS は復元力を向上させるが、運用の複雑さが増す。ゾーン変更は同期されなければならない。DNSSEC、ヘルスチェック、地理ルーティング、トラフィックステアリング、プロバイダー固有の機能はフェイルオーバーを難しくする。低 TTL は変更の伝播を早めるが、クエリ負荷を増やし、すべてのキャッシュを上書きするわけではない。レジストラ変更は、資格情報、ロック、承認が準備できていない場合、遅くなったりリスクが生じたりする。アカウンタビリティのあるアーキテクチャはそれらのトレードオフを認識し、"セカンダリ DNS"を魔法の言葉と見なさずにテストする。

広範なエコシステムも制御を持っていた。IoT メーカーはデフォルトの脆弱な資格情報、不十分な更新プラクティス、外部性の悪用に対する説明責任の低いデバイスを出荷した。アクセスネットワークは侵害されたデバイスからのトラフィックの一部を検出し、制限できた。消費者や中小企業は、DVR、カメラ、ルーターを保護する実用的な能力に乏しいことが多かった。法執行機関は後に Mirai を指名された被告に関連付け、司法省の2017年の有罪答弁発表は Mirai とクリック詐欺ボットネットの作成と運用を説明した。その法的記録は悪意のある責任を示すため重要だが、到達可能性の復元力に関する供給者と顧客の義務を排除するものではない。

収益継続は到達可能性から始まる

収益継続は、支払い処理、在庫、チェックアウト、サポート、配達を中心に語られることが多い。DNS も同じリストに属する。顧客がドメインを解決できない場合、販売ページ、ログインページ、API、サポートポータル、広告在庫、ステータスページがすべて到達不能になる可能性がある。オリジンサーバーは健全なままでも、収益は正面玄関で停止する。メディア企業にとって、到達可能性は広告と視聴者に影響する。小売業者にとってはコンバージョンに影響する。SaaS プロバイダーにとってはアップタイムコミットメントに影響する。公共サービスにとっては情報へのアクセスと危機コミュニケーションに影響する。

Dyn インシデントは、DNS の集中がサプライヤーリスクを顧客の収益損失に変換することを示した。顧客は DDoS の標的になる必要はなかった。攻撃されたプロバイダーに依存していたために被害を受けた。これはコスト移転である：攻撃者は Dyn を標的にし、Dyn は攻撃を吸収し、顧客は到達不能の損失を吸収し、ユーザーはアクセス不能を受け入れ、ボットネットに参加した IoT 所有者やメーカーは同等のコストを負担することは稀だった。アカウンタビリティは、最終的な目に見えるブランドにすべての非難を置くのではなく、その移転を見ることを必要とする。

監視は依存関係に一致する必要がある。ある地域からのアプリケーション合成チェックがウェブサイトダウンを報告しても、オリジン障害と権威 DNS 障害、再帰リゾルバキャッシング、BGP 到達可能性、CDN ルーティング、地域 ISP 問題を区別できないかもしれない。成熟した組織は、複数のネットワークから権威 DNS 応答を監視し、ネームサーバーが応答するかどうかをチェックし、使用されている場合は DNSSEC の有効性を観察し、アプリケーションの健全性と名前解決の健全性を分離する。Dyn 攻撃中、その区別が対応を形作った。アプリケーションが健全な顧客は、アプリケーションのロールバックではなく、DNS とプロバイダーの対応を必要とした。

収益記録には顧客向けステータスも含まれるべきである。サービスのメインステータスページが、影響を受けたサービスと同じ DNS プロバイダーに依存している場合、ユーザーは説明に到達できないかもしれない。独立したステータスドメイン、代替通信チャネル、キャッシュされたサービス通知が重要になり得る。このインシデントは、ネームサービスプロバイダーが障害の原因である場合、企業は顧客に何が起きているかを伝えられるかという基本的な設計上の質問を明らかにした。

セカンダリ DNS は規律であって、チェックボックスではない

Dyn 攻撃への一般的な事後対応は「セカンダリ DNS を使用する」だった。それは方向としては正しく、運用としては不完全である。セカンダリ DNS には機能する設計が必要である。ゾーンは同期されなければならない。プロバイダーの違いは理解されなければならない。ヘルスチェックの動作は矛盾してはならない。DNSSEC 署名は慎重に管理されなければならない。レジストラ委任には独立したネームサーバーを含める必要がある。インシデント対応者は、どのプロバイダーがどのゾーンで権威であるか、どの自動化がレコードを更新するか、緊急時に本番環境を壊さないようにするかを知っている必要がある。

Internet Systems Consortium のBIND のゾーン転送に関するドキュメントと IETF のDNS NOTIFY に関する RFC 1996は、マルチサーバーDNS にゾーン変更を配布するための長年のメカニズムがあることを示している。現代のマネージド DNS は API、トラフィック管理、プロバイダー固有の機能を追加するが、中核の問題は同期と権威である。企業は、テストされた更新プロセスなしにセカンドベンダーを追加しても、停止中に機能するとは想定できない。

TTL 戦略も別の規律である。低 TTL は通常の状況下でレコード変更の伝播を早めるが、負荷が増加し、キャッシュとクライアントの動作が異なるため、即時変更を保証しない。高 TTL はプロバイダー停止中にキャッシュされた回答でユーザーを保護できるが、意図的なフェイルオーバーを遅くする。正しい答えは、サービス種別、トラフィックパターン、プロバイダー設計、インシデントモデルに依存する。アカウンタビリティとは、組織がデフォルトを継承するのではなく、意図的な選択を行い、テストしたことを意味する。

レジストラの準備は見落とされがちな部分である。組織が圧力下で権威ネームサーバーを変更する必要がある場合、レジストラアクセス、複数人承認、資格情報保護、レジストリロックや変更遅延の理解が必要である。完全なセカンダリ DNS 設定も、組織が安全に委任を更新できなければほとんど役に立たない。逆に、性急なレジストラ変更は、ネームサーバーが誤入力されたり、DNSSEC DS レコードが間違っていたり、承認が停滞したりすると、新たな停止を生み出す可能性がある。収益継続計画は、プロバイダーコンソールだけでなく、全体のパスを練習する必要がある。

DDoS 容量はエコシステムの問題である

Mirai ボットネットは、DDoS リスクが被害者から遠く離れて生み出されることを示した。カメラ、DVR、ルーターなどのデバイスは、セキュリティが不十分で広く展開されていたため、攻撃トラフィックに勧誘された。KrebsOnSecurity の2016年の Dyn 停止の分析は、公開妨害を侵害された消費者デバイスに関連付け、Cloudflare の後のMirai の回顧分析は、デフォルト資格情報とデバイスの露出がなぜ重要かを説明した。これらの情報源は Dyn 自身の説明の代わりにはならないが、攻撃規模が共有インフラ問題であった理由を理解するのに役立つ。

これはアカウンタビリティにとって重要である。経済的インセンティブが一致していないからだ。低コストのデバイスメーカーは、弱いセキュリティによってコストを節約できる。所有者は、デバイスが機能し続けるため、侵害に気づかないかもしれない。アクセスプロバイダーはトラフィックを見るが、デバイスを所有していない。DNS プロバイダーとその顧客は攻撃コストを吸収する。一般市民はサービスを失う。これは典型的な予防インセンティブ問題である：ボットネット勧誘を防ぐ最善の立場にある当事者が、最大の目に見える損失を負わないかもしれない。

政府と標準化団体は、時間の経過とともに IoT セキュリティガイダンスで対応してきた。NIST のNISTIR 8259：IoT デバイスメーカーのための基礎的なサイバーセキュリティ活動と NIST の後の消費者 IoT サイバーセキュリティ基準は、広く早期に実装されていれば Mirai 型の露出を低減したであろうデバイスセキュリティのベースラインを表現している。FCC のスマートデバイスのサイバーセキュリティラベリングプログラムは同じ政策方向を反映している：安全でないデバイスプラクティスを購入者により可視化する。これらの対策は DNS プロバイダーの集中を解決しないが、プロバイダーの防御を失敗させる可能性のあるトラフィックソースに対処する。

ネットワークオペレーターのプラクティスも重要である。BCP 38、RFC 2827や更新されたBCP 84、RFC 8704などのスプーフィング防止ガイダンスは、送信元アドレス検証に対処し、これは一部の悪意のあるトラフィックのクラスを減らすのに役立つ制御である。Mirai はスプーフィングだけに依存していたわけではないが、広範な教訓は DDoS 復元力がエコシステムの規律であるということだ。DNS プロバイダーは容量を購入し、スクラビングを構築できるが、アクセスネットワーク、デバイスメーカー、クラウドプロバイダー、顧客はすべて攻撃の規模と影響に影響を与える。

公共サービスの継続性は別の義務を追加する

Dyn の顧客基盤には、多くのユーザーが日常生活の一部として扱う商業プラットフォームやサービスが含まれていた。直接の顧客が民間企業であっても、オンラインサービスの到達可能性はコミュニケーション、メディア、支払い、仕事、公共の認識に影響を与えた。したがって、DNS の停止は政府システムの停止ではなくても、公共サービスの継続性の問題になり得る。共有プロバイダーが多くの広く使用されるサービスを支える場合、その復元力は市民インフラの一部となる。

これが DNS ガバナンスが重要である理由の一つである。権威 DNS 委任は公開インターネットの制御ポイントである。レジストリ、レジストラ、権威プロバイダー、再帰リゾルバ、CDN プロバイダー、ネットワークオペレーターはすべて、ユーザーがサービスに到達できるかどうかを形作る。Dyn インシデントは DNS プロトコルの失敗ではなかったが、そのガバナンスシステム内での集中した運用依存の結果を暴露した。多くの顧客が複雑性を外部委託するため、少数のプロバイダーが非常に重要になり得る。

公共部門の組織は同じ出来事から学ぶべきである。単一の DNS プロバイダーに依存する政府機関、保健機関、裁判所システム、選挙管理機関、緊急サービスは、プロバイダー攻撃中に市民が重要な情報に到達できるかどうかを問うべきである。独立したステータスチャネル、複数プロバイダーDNS、レジストラ手順、DNSSEC ロールオーバー、緊急コミュニケーションをテストすべきである。公共サービスは、民間プロバイダーの復元力が自動的に公的義務を満たすと想定できない。

公共の利益基準は、すべての組織が独自のグローバル DNS ネットワークを運営しなければならないというものではない。マネージドプロバイダーが存在する正当な理由がある：専門知識、規模、セキュリティ、自動化、サポート。基準は、高依存の顧客が購入した障害領域を理解することである。プロバイダーは優れていても、顧客にテスト済みの代替手段がなければ、単一の依存ポイントになり得る。運用の外部委託は、公開到達可能性に対するアカウンタビリティを外部委託するものではない。

アドレス帳が壊れたとき、通知の質が重要になる

DNS 障害の間、コミュニケーションは通常よりも困難である。サービスの通常の通信経路が同じ名前の連鎖に依存している可能性があるからだ。影響を受けるドメイン下のステータスページは到達不能になるかもしれない。電子メールは遅延したり信頼されなかったりする。ソーシャルメディアが実用的なチャネルになるかもしれないが、すべての顧客がアカウントをフォローしているわけではない。重要なオンラインサービスを販売する企業は、DNS プロバイダーの障害に耐えるコミュニケーション計画を必要とする。

その計画には、独立したステータスインフラ、代替ドメイン、事前に取り決めたソーシャルチャネル、顧客連絡先リスト、サポート手順が含まれるべきである。また、顧客メッセージとプロバイダーメッセージを区別すべきである。Dyn はプラットフォームの攻撃ステータスを報告できた。各顧客は、自社のサービスが影響を受けたか、データは安全か、トランザクションは失われたか、通常のサービスがいつ期待されるかを自社のユーザーに伝えなければならなかった。プロバイダーのステータスは必要だが十分ではない。なぜなら、ユーザーは目に見えない DNS ベンダーではなく、ブランドとの関係を持っているからである。

通知の質は収益回復にも影響する。小売業者がユーザーに何も伝えなければ、一部のユーザーはブランドのアプリケーションが失敗したと想定して永久に去るかもしれない。SaaS プロバイダーが DNS 解決は影響を受けているがデータは安全だと説明できなければ、顧客は侵害やデータ損失を心配するかもしれない。公共サービスが市民に代替情報への到達方法を伝えなければ、信頼は損なわれる。技術的なステータス更新は顧客維持の証拠の一部となる。

Dyn 攻撃は、インシデントコミュニケーションがユーザーを過負荷にせずに依存関係を名前を挙げるべきである理由を示した。明確な通知は、サービスが DNS プロバイダー攻撃のために到達不能問題を経験していること、ユーザーデータとオリジンシステムは侵害されていないことが知られていないこと、代替チャネルが利用可能であること、更新が特定の場所に表示されることを伝えることができる。そのメッセージは不確実性を減らす。また、企業がその時点で知っていたことの記録を保存する。

取締役会レベルの教訓は「もっと DNS を買う」ではない

取締役会レベルの教訓は、公開到達可能性をビジネス資産として扱うことである。DNS、BGP、CDN、DDoS 防御、TLS 証明書、レジストラ制御、ステータス通信はすべて収益の前に位置する。これらは技術チームが所有するかもしれないが、その失敗は商業的および公共的な害を生み出す。取締役会はすべてのレコードタイプを知る必要はない。組織にテスト済みの代替手段のない重要な依存関係があるかどうかを知る必要がある。

Dyn 後の有用な取締役会報告書は6つの質問に答えるだろう。どのドメインが収益上重要または公共サービス上重要か？どのプロバイダーがそれらの権威 DNS を制御しているか？どのドメインにセカンダリ DNS または独立したフェイルオーバーがあるか？フェイルオーバーは最後にいつテストされたか？メインドメインが解決できない場合、組織はどのようにコミュニケーションするか？DNS が1時間、6時間、または1日劣化した場合、どの収益、サポート、または安全プロセスが停止するか？

同じ報告書には所有者名と演習結果を含めるべきである。誰も所有していない複数プロバイダー設計はリスクが高い。実際のレジストラと DNSSEC の制約に対してテストされていないフェイルオーバー計画は不確実である。同じ依存関係を共有するステータスページは脆弱である。アプリケーション応答のみをチェックする監視ツールはネームサービスの障害を見逃す。取締役会レベルのアカウンタビリティは技術的な芝居ではなく、財務的および公的責任を負う人々が依存関係を明確に見ることを確実にする方法である。

保険と契約も DNS がこのように扱われると変化する。サイバー保険の質問には、権威 DNS の集中とフェイルオーバーテストを含めるべきである。エンタープライズ契約は、アップタイムの依存関係とプロバイダーレベルの攻撃中の顧客通知を明確にすべきである。ベンダー管理は、DNS プロバイダーがログ、攻撃概要、顧客影響データ、インシデント後の支援を提供できるかどうかを検討すべきである。目標は攻撃された一つのプロバイダーを罰することではない。収益が危険にさらされる前に顧客とプロバイダーが証拠を共有することである。

耐久性のある修復は共有障害領域を減らすことを意味する

Dyn 後の耐久性のある修復記録は、単に大きな DDoS 容量ではない。容量は役立つ。Anycast は役立つ。スクラビングは役立つ。プロバイダーの多様性は役立つ。顧客アーキテクチャは役立つ。IoT デバイスセキュリティは役立つ。ネットワークフィルタリングは役立つ。コミュニケーションは役立つ。重要な問いは、共有障害領域が縮小したかどうかである。多くの重要なサービスが依然として一つのプロバイダー、一つのレジストラアカウント、一つのステータスドメイン、一つのテストされていない緊急手順に依存している場合、教訓は不完全なままである。

Dyn や他のマネージド DNS プロバイダーにとって、修復の証拠には DDoS 容量、上流調整、Anycast フットプリント、顧客固有の影響の可視性、ステータスの透明性、攻撃波中のサポートが含まれるべきである。顧客にとっては、テスト済みのセカンダリ DNS、独立した監視、レジストラ準備、DNSSEC プロセス保証、代替コミュニケーションが含まれるべきである。デバイスとネットワークエコシステムにとっては、ボットネット勧誘と悪用トラフィックの低減が含まれるべきである。公共部門ユーザーにとっては、DNS プロバイダーの障害を前提とした継続訓練が含まれるべきである。

攻撃はまた、組織に冗長性と独立性を混同しないように思い出させる。同じプロバイダーからの2つのネームサーバーは技術的な冗長性を提供するかもしれないが、プロバイダーの独立性は提供しない。同じ侵害された自動化アカウントを通じて制御されるセカンドプロバイダーは、運用の独立性を提供しない可能性がある。同じ DNS 依存関係の下でホストされるステータスページは、コミュニケーションの独立性を提供しないかもしれない。独立性は、プロバイダー、アカウント、資格情報、ネットワーク、人を通じて追跡されなければならない。

Dyn インシデントは、公然と見える静かな依存関係を暴露したため、有用なアカウンタビリティケースであり続ける。インターネットは消えなかった。共有アドレス機能が使いにくくなった。それだけで、主要なサービスを到達不能にし、コストを顧客とユーザーに移し、企業に DNS を収益インフラとして扱っていたかどうかを問わせるのに十分だった。次の停止に対する答えは、攻撃前に実証可能であるべきであり、最初の波が当たった後に即興で作られるべきではない。

実際の DNS 演習はフェイルオーバー図よりも難しい

多くの組織は復元力のある DNS アーキテクチャを描ける。しかし、それが悪い日に機能することを証明できる組織は少ない。実際の演習は、プライマリ権威プロバイダーが攻撃トラフィックによって劣化し、プロバイダーコンソールが遅く、再帰リゾルバが地域間で不均一な動作を示し、公開ステータスページが部分的に影響を受け、ビジネスリーダーが収益予測を求めているという前提で開始されるべきである。演習はチームに、待つか、権威を移すか、セカンダリプロバイダーを使用するか、レコードを変更するか、TTL を変更するか、問題を悪化させずに劣化を伝えるかを決定させるべきである。

演習にはレジストラの手順を含めるべきである。誰がログインできるか？レジストリロックは有効か？変更は複数人承認で保護されているか？セキュリティ制御を無効にせずに緊急変更を行えるか？DNSSEC DS レコードは理解されているか？RFC 6781の DNSSEC 運用プラクティスガイダンスは、署名されたゾーンが運用上の考慮事項を追加する理由を示している。DNSSEC は信頼性を強化できるが、不注意な緊急変更は検証を破壊する可能性がある。ゾーンに署名する企業は、障害発生前にフェイルオーバーが署名、鍵管理、委任とどのように相互作用するかを知っているべきである。

演習には監視の違いを含めるべきである。アプリケーションモニターは何を報告するか？権威 DNS モニターは何を報告するか？異なる地域からの再帰リゾルバテストは何を報告するか？カスタマーサポートは何を聞いているか？CDN は何を見ているか？広告、チェックアウト、ログイン、API システムは何を報告するか？これらの信号が分離されていなければ、インシデントコマンダーは間違った障害を追跡するかもしれない。Dyn のケースは、アプリケーションが健全でもユーザーが名前を解決できない可能性があることを示した。監視がこれらの信号を一つの「サイトダウン」アラームにまとめることは対応を遅らせる。

演習にはビジネス上の選択を含めるべきである。DNS 権威を移すと、一部のユーザーは回復するが、ゾーンが古かったりプロバイダー機能が異なる場合、他のユーザーにリスクが生じるかもしれない。待つことはエラーを回避できるが、収益損失を長引かせる。代替チャネルを通じてコミュニケーションすることは顧客を助けるが、事前に承認された言語が必要かもしれない。取締役会レベルの復元力プログラムは、誰がそれらのトレードオフを決定でき、どの証拠が必要かを定義すべきである。技術チームは、攻撃下で商業的リスクの決定を即興で行うことを強いられるべきではない。

最終的な出力は測定可能であるべきである。権威 DNS 障害を診断するのにどのくらいかかったか？プロバイダーに連絡するのに？セカンダリプロバイダーの準備を確認するのに？必要なら委任を更新するのに？顧客通知が独立したチャネルに現れるまでに？収益に重要なフローが複数の地域から到達可能になるまでに？これらの時計は DNS 復元力をアーキテクチャの話からアカウンタビリティのある継続性に変える。

契約はアップタイム数値だけでなく、インシデント証拠を要求すべきである

マネージド DNS 契約は、サービスレベル、サポート階層、クエリボリューム、機能、価格を強調することが多い。Dyn 後、高依存の顧客は証拠義務も要求すべきである。プロバイダーが攻撃された場合、タイムライン、影響を受けた地域、攻撃特性、緩和手順、利用可能な場合は顧客固有の影響、インシデント後の教訓を提供できるか？セカンダリ DNS を使用する顧客をサポートできるか？顧客の CDN、レジストラ、インシデント対応チームと調整できるか？どの情報を公開しても安全かを顧客に伝えられるか？

顧客もプロバイダーに明確さを提供する義務がある。どのドメインが最も重要か？どのレコードがデプロイメントシステムによって自動化されているか？どのプロバイダー機能が使用されているか？どの連絡先が緊急変更を承認できるか？どの公共サービスまたは規制上の義務が適用されるか？顧客自身の重要度マップが不明であれば、プロバイダーはすべての顧客に等しく良いサポートを提供できない。契約は重要なドメインと緊急連絡先を明示すべきである。

サービス水準合意は有用だが不完全である。停止後のクレジットは手数料のごく一部を返すかもしれないが、顧客の収益損失ははるかに大きい。より良い予防ツールは、停止前の運用上の協力である。顧客はプロバイダーとアーキテクチャをレビューし、フェイルオーバーをテストし、ステータスチャネルを定義すべきである。プロバイダーは現実的な限界を説明すべきであり、単に高可用性を約束するのではない。プロバイダーがセキュリティ上の懸念から十分な情報を共有できない場合、危機時に共有できる抽象度のレベルを定義すべきである。

契約は変更管理にも対処すべきである。多くの停止は、圧力下での緊急変更によって悪化する。2つの DNS プロバイダーを使用する顧客は、ゾーン変更がどのように同期されるか、一方がプライマリか、API 資格情報がどのように保護されるか、変更がどのようにレビューされるか、ロールバックがどのように機能するかを知っている必要がある。自動化がデプロイメントのために DNS レコードを更新する場合、組織はその自動化が両方のプロバイダーに安全に書き込めるかどうかを知る必要がある。複雑なゾーンを手動でコピーすることに依存する緊急 DNS 計画は、チームが疲れてビジネスがパニックになっているときに失敗する可能性がある。

DNS の経済性は、これへの過小投資を容易にする。マネージド DNS は、クラウドホスティング、支払い処理、ソフトウェアエンジニアリングと比較して小さな項目かもしれない。しかし、停止はアプリケーション層がリクエストを見る前に収益を止めることができる。契約価値と依存関係価値は大きく異なる可能性がある。アカウンタビリティは、依存関係の価値を復元力投資の基礎として扱うことを必要とする。

公共当局は同じテストをコピーできる

公共当局は、自らのサービスが製品を販売しないため、収益継続の教訓はあまり関連性がないと想定することがある。Dyn のケースはそうではないと言う。収益を公共アクセスに置き換えれば、依存関係は同じである。給付金ポータル、緊急警報ページ、裁判所サービス、健康情報サイト、選挙情報ページ、都市サービスは、DNS が上流で失敗すると到達不能になる可能性がある。市民は、原因がアプリケーションコード、DNS、DDoS トラフィック、レジストラ設定のいずれであるかを気にしない。市民はサービスを必要としている。

したがって、公共団体は権威 DNS 依存関係登録を維持すべきである。どのドメインが緊急コミュニケーションに重要か？支払い、予約、法的期限、健康サービス、本人確認に使用されるものは？どの DNS プロバイダーがそれらをホストしているか？どのレジストラが委任を制御しているか？週末に変更を行えるチームは？ドメインが解決できない場合、どの代替チャネルが存在するか？異なるプロバイダーとドメインを使用するステータスチャネルは？これらは簡単な質問だが、インシデントがそれらを視界に強制するまで欠けていることが多い。

英国 NCSC のDNS リスクの理解と管理に関するガイダンスは、DNS を重要な依存関係として説明し、組織に所有権、設定、レジストラセキュリティを理解することを奨励している。そのガイダンスは Dyn の教訓を強化する：DNS リスクはプロバイダーの問題だけではない。公開デジタルサービスを持つすべての組織にとって、所有権、設定、監視、継続性の問題である。

公共部門の演習には市民コミュニケーションを含めるべきである。プライマリドメインが失敗した場合、市民はどこで更新情報を見るか？コールセンターは同じ情報を受け取れるか？地域事務所は通知を表示できるか？ソーシャルメディアアカウントは信頼でき、更新できるか？パートナーは代替ドメインにリンクできるか？緊急サービスは事前に取り決めたチャネルを通じてコミュニケーションできるか？これらの質問は運用的に感じられるかもしれないが、それがポイントである。DNS 障害は、一般市民が情報を必要とし、通常のアドレスが機能しないときに公共サービスの問題になる。

同じ登録は調達を支援できる。新しいデジタルサービスを購入する公共団体は、サービスの DNS がどのようにホストされているか、委任がどのように制御されているか、どのようなセカンダリ配置があるか、DNSSEC がどのように処理されているか、プロバイダー障害がどのようにテストされているかを尋ねるべきである。サプライヤーがすべてを扱うという答えであっても、公共団体は証拠を受け取るべきである。外部委託された DNS は、公共サービスがそれに依存している限り、公共の責任であり続ける。

アカウンタビリティはボットネット予防にまで及ぶべきである

Dyn 攻撃はデバイス政策への教訓も残した。DDoS 防御者と DNS 顧客は単独でボットネット規模を解決できない。Mirai に参加したデバイスは、Dyn やその顧客の直接制御外にあることが多かった。これにより予防は困難になるが、政策も必要になる。デバイスメーカーはデフォルト資格情報を避け、更新メカニズムを提供し、サポート期間を文書化し、一般ユーザーにとって現実的な安全な設定を可能にすべきである。ネットワークオペレーターは悪意のあるトラフィックパターンを検出し、顧客が侵害されたデバイスを修復するのを支援すべきである。小売業者と調達団体はデバイスセキュリティを購入基準として扱うべきである。

連邦取引委員会の D-Link に対する措置は、2017年の苦情発表に要約されており、特に Dyn ケースから生じたわけではないが、安全でないネットワークデバイスに対するアカウンタビリティの方向性を示している。消費者デバイスのセキュリティは、デバイス所有者のプライバシー問題だけではない。規模が大きくなると、脆弱なデバイスは無関係な被害者に対するインフラ攻撃能力となる。その外部性が、デバイスセキュリティが DNS 継続性の記事に属する理由である。

成熟した公開記録は、ボットネット予防とサービス継続性を結びつけるだろう。安全でないデバイスが公共サービスを到達不能にする攻撃を助長するならば、デバイス基準、ラベリング、脆弱性開示、ネットワーク悪用対応は復元力の一部である。DNS サービスを運営する側は依然として強力な防御を必要とする。顧客は依然としてフェイルオーバーを必要とする。しかし、社会全体の攻撃表面も縮小する必要がある。そうでなければ、各プロバイダーは増え続ける脆弱なエンドポイントのプールに対して単により多くの容量を購入するだけである。

Mirai の起訴は一種のアカウンタビリティを提供した：ボットネットの作成者が特定され罰せられた。それは必要だが不十分である。事後の刑事責任は、停止中に失われた売上や、サービスが到達不能だったために逃した予約を回復しない。予防的アカウンタビリティは、なぜこれほど多くのデバイスがそもそも勧誘され得たのか、そして安全でない展開から誰が利益を得るのかを問う。これらの質問は、分析を一つの攻撃から市場とガバナンスの問題に移す。

次の Dyn 類似イベントはより断片的になるかもしれない

次の大規模な DNS 到達不能イベントは、一つのプロバイダーが一つの明白な攻撃下にあるようには見えないかもしれない。レジストラ侵害、DNS インフラに影響するルートリーク、DNSSEC ミス、クラウドプロバイダー制御問題、CDN 相互作用、再帰リゾルバ動作、地域フィルタリングが関与するかもしれない。アカウンタビリティのパターンは変わらない：顧客は名前解決がビジネス依存関係であることを、それが失敗したときにのみ発見する。プロバイダーの独立性、レジストラ制御、代替コミュニケーションを実践してきた組織は、証拠をもって対応できる。DNS をデフォルト設定として扱ってきた組織は、より困難な時間を過ごすだろう。

断片化したイベントは公に説明するのがより難しい。一部のユーザーがサービスに到達でき、他のユーザーができない場合、カスタマーサポートは報告を地域の問題として却下するかもしれない。キャッシュが一部のユーザーに対して問題を隠す場合、経営幹部は影響を過小評価するかもしれない。監視が間違ったネットワークから来ている場合、対応者は影響を受けた地域を見逃すかもしれない。ステータスページがスタッフには機能しても顧客には機能しない場合、コミュニケーションは誤解を招く。成熟した DNS 継続性計画は、一貫性のない可視性を想定し、それを捉えるための監視を設計すべきである。

断片化のビジネス影響は深刻であり得る。グローバル小売業者は特定の市場でのみチェックアウトを失うかもしれない。SaaS プロバイダーは特定のリゾルバの背後にある顧客に対して失敗するかもしれない。政府サイトは国内では到達可能でも国外では到達不能になるかもしれない。広告、分析、サポートツールは部分的なデータを報告するかもしれない。組織が DNS 到達可能性とアプリケーションパフォーマンスを分離できなければ、害を正確に計算したり、顧客に正直に通知したりできない。

だからこそ、Dyn の記録は取締役会の記憶に残るべきである。インターネットの制御面は、ブランド所有者が考えている場所にあるとは限らないという思い出である。企業は復元力のあるサーバーに多額の投資をしても、名前の層で脆弱なままである。公共団体はアプリケーションを強化しても、レジストラや DNS プロバイダーの障害を通じて到達不能になる可能性がある。プロバイダーは強力なネットワークを構築しても、数百万の脆弱なデバイスからのトラフィックに直面する。アカウンタビリティは、一般市民がそれらを見る前に依存関係を見る規律である。

実用的な基準は単純である：ドメインが収益、ケア、公開情報、顧客信頼を運ぶほど重要であれば、その失敗経路は、攻撃者が全員のためにテストする前にテストされるべきである。