要約
- Dyn の2016年10月の DDoS インシデントは、権威 DNS を顧客フェイルオーバーの説明責任問題にしました。多くのサービスが、自社のアプリケーションスタックが直接の標的でなくても到達不能になったからです。
- Dyn は管理 DNS インフラ、緩和パートナーシップ、顧客コミュニケーション、インシデント後の声明を管理しました。顧客はドメインアーキテクチャ、セカンダリ DNS 計画、監視、レジストラの準備、インシデント判断ルールを管理しました。
- ThousandEyes やその後の DNS 冗長性研究を含む独立した測定と研究は、単一プロバイダーへの DNS 集中が多くのドメインに実質的なエクスポージャーを生み出すことを示しました。
- Mirai や IoT ボットネットの記録は重要ですが、プロバイダーと顧客の義務を消し去るものではありません。ボットネットの説明責任、プロバイダーの復元力、顧客フェイルオーバーは、同じ公開可用性問題の異なる層です。
- 永続的な教訓は、DNS フェイルオーバーは訓練された運用規律であり、調達のチェックボックスではないということです。セカンダリプロバイダー、TTL の選択、ゾーン同期、DNSSEC、監視、公開通知は、攻撃前に連携しなければなりません。
DNS 障害は正常なアプリケーションの背後に隠れる可能性がある
Dyn インシデントは、多くのユーザーが見落としがちな依存関係の明確な例です。ウェブサイト、ストリーミングサービス、ソーシャルプラットフォーム、決済ツール、メディアプロパティは、アプリケーションサーバーが機能していても、ユーザーが名前を解決できないと到達不能になります。アドレス帳がアプリケーションの応答よりも先に機能しなくなります。ユーザーにとっては、その区別は重要ではないかもしれません。サービスがダウンしているのです。説明責任のレビューにとっては、責任のある管理が異なるため、その区別は重要です。
Dyn が保存している2016年10月21日の DDoS 攻撃に関する声明では、管理 DNS インフラへの攻撃、複数の波、緩和パートナー、地域や時間によって異なる顧客への影響が説明されています。この声明は Dyn の説明として一次資料ですが、顧客ごとの完全な損失マップではありません。プロバイダーが攻撃され、管理 DNS が運用面であったことが示されています。
ThousandEyes の分析、Dyn の DNS インフラへの DDoS 攻撃は、顧客フェイルオーバーの問題を示すのに役立ちます。モニタリングされた視点からの深刻なクエリ障害、影響を受けた多数のサイト、Dyn に大きく依存するドメインとより多様な DNS 構成を持つドメインとの違いが報告されました。正確な数値は測定データセットを反映しており、インターネット全体ではありませんが、教訓は確かです。名前解決のアーキテクチャが、プロバイダーへの攻撃を顧客の障害にするかどうかを決定することができるのです。
説明責任のテストは、層を分離することから始まります。Dyn にはインフラの復元力、DDoS 緩和、ステータスコミュニケーション、顧客ガイダンスに関する義務がありました。顧客にはドメインアーキテクチャ、プロバイダーの多様性、フェイルオーバーテスト、ユーザーコミュニケーションに関する義務がありました。ボットネットの運営者は敵対的なトラフィックに対する責任がありました。いずれか一つの層のみを全体像として扱うと、他の層が隠れてしまいます。
セカンダリ DNS は魔法のスイッチではない
RFC 2182、セカンダリ DNS サーバーの選択と運用は古いですが、基本的な復元力の原則を述べているため今でも有用です。権威 DNS サーバーは同じローカル障害モードを共有すべきではありません。現代の管理 DNS では、この原則はより複雑になります。顧客は複数のプロバイダー、エニーキャストネットワーク、DNSSEC、レジストラ管理、自動ゾーン管理、API 連携、CDN リンクレコードを使用することがあります。多様性は、運用上現実的である場合にのみ価値があります。
セカンダリ DNS は、ゾーンが古い、DNSSEC の管理が不適切、プロバイダーが同じ上流に依存している、監視が部分的な障害を検出しない、レジストラの変更が遅い、スタッフが変更を承認できる人物を知らない、レコードが安全に同期するには動的すぎるなどの場合、制御として失敗する可能性があります。セカンダリプロバイダーを追加してもフェイルオーバーをテストしない顧客は、問題を解決していません。仮説を購入しただけです。
主要なウェブサイトやサービスにおける DNS 解決の冗長性の欠如に関する研究（論文）は、DNS 集中を測定可能なアーキテクチャとして扱うため価値があります。この論文のデータセットは普遍的な国勢調査ではありませんが、プロバイダーの多様性とテストされた冗長性が自動的ではないという広い点を支持しています。多くの組織は、シンプルで統合されており、通常は信頼性が高いという理由で、1つの管理 DNS プロバイダーに依存しています。そのシンプルさの代償は、プロバイダーレベルのインシデント時に現れます。
したがって、取締役会レベルの質問は「セカンダリ DNS はあるか」ではなく、「攻撃条件下でプライマリ DNS プロバイダーが故障した場合に名前解決が生き残ることを証明できるか」です。その証明には、ゾーン同期、監視、運用権限、ランブック、DNSSEC 処理、連絡先リスト、テスト証拠が必要です。これらがなければ、セカンダリ DNS は回復経路ではなく図面にすぎない可能性があります。
顧客フェイルオーバーは攻撃前に始まる
顧客フェイルオーバーは、しばしば危機的な行動として想像されます。プロバイダーがダウンしたらバックアップに切り替える。実際には、DNS フェイルオーバーは通常のアーキテクチャから始まります。権威ゾーンをホストしているのはどのプロバイダーか？複数のプロバイダーのネームサーバーがレジストリに委任されているか？レコードは同期されているか？ダイナミックレコードは1つのシステムまたは複数のシステムで制御されているか？TTL は想定される変更率に適切か？DNSSEC 署名はプロバイダー間で互換性があるか？レジストラ設定を変更できるのは誰か？DNS 緊急事態を宣言できるのは誰か？顧客に伝えるのは誰か？
これらの決定は華やかではありませんが、DDoS イベント中に顧客が行動できるかどうかを決定します。セカンダリプロバイダーがまだ委任されていない場合、レジストラの変更には時間がかかり、伝搬の不確実性が生じます。ゾーンデータが古い場合、フェイルオーバーはユーザーを間違ったエンドポイントに誘導する可能性があります。DNSSEC キーが調整されていない場合、ユーザーは検証エラーを経験する可能性があります。監視がプロバイダー障害とアプリケーション障害を区別しない場合、チームは間違った層のトラブルシューティングを行う可能性があります。
CISA の分散型サービス拒否攻撃の理解と対応に関するガイダンス（リンク）は、準備、ベースライン、プロバイダー連携、対応手順を強調しています。NCSC のサービス拒否ガイダンス集（リンク）も同様の一般的なポイントを述べています。サービスを理解し、防御を理解し、計画を作成し、テストする。DNS 顧客はこれをドメイン固有の訓練に変換する必要があります。
訓練は具体的でなければなりません。プライマリ権威 DNS プロバイダーが攻撃を受けており、主要地域から部分的に到達できないと仮定します。組織は障害を認識できますか？アプリケーションが正常であることを確認できますか？プロバイダーと通信できますか？DNSSEC を壊さずにセカンダリ DNS に移動または依存できますか？ステータスページが同じ DNS に依存している場合、公開ステータスページを更新できますか？インシデントをユーザーに説明できますか？答えが不確かな場合、フェイルオーバープランはまだ制御ではありません。
プロバイダーの透明性には顧客の行動詳細が必要
DNS プロバイダー攻撃中、顧客は緩和が進行中であるという保証以上のものを必要とします。彼らは実行可能な不確実性を必要とします。どの地域が影響を受けているか？どのサービスが劣化しているか？権威応答が失敗しているか遅延しているか？特定のレコードタイプが影響を受けているか？顧客は TTL を下げるべきか、トラフィックを移動するべきか、セカンダリプロバイダーを有効にするべきか、待つべきか？API は利用可能か？ステータス更新は影響を受けた DNS から独立したインフラにあるか？次の更新はいつか？
Dyn の公開声明は攻撃の波と緩和作業を挙げました。それは有用です。しかし、顧客フェイルオーバーのレンズは、攻撃がアクティブな間に顧客がその情報で何ができるかを問います。テストされたフェイルオーバーを持たない顧客は見守るしかないかもしれません。委任されたセカンダリ DNS、独立したステータスコミュニケーション、準備された判断ルールを持つ顧客は、インシデントを乗り切るか、特定のレコードを移行するか、ユーザーに警告するかを決定できます。プロバイダーの透明性と顧客の準備は互いを増幅させます。
ステータスの問題は微妙です。DNS プロバイダー自身のステータスページ、メール更新、ソーシャルチャネル、サポートポータル、API ドキュメントは、DNS が攻撃下にある間も到達可能でなければなりません。顧客が情報源に到達できない場合、ソーシャルメディア、噂、サードパーティの監視に依存する可能性があります。プロバイダーはステータス通信を帯域外の継続サービスとして設計する必要があります。
顧客コミュニケーションも重要です。主要なオンラインサービスが DNS 障害のために到達不能な場合、ユーザーはサービス、ISP、ローカルデバイス、アカウント、または決済システムのどれが壊れているのか理解できないかもしれません。準備された顧客は、同じ障害モードを共有しない公開ステータスチャネルを持ち、依存関係を平易に説明する必要があります。「アプリケーションは動作していますが、DNS プロバイダーが攻撃を受けているため、一部のユーザーはドメインを解決できません」というのは、一般的なダウンタイムの表現よりも有用です。
Mirai はボットネットの説明責任を不可避にした
Dyn 攻撃は Mirai と IoT ボットネット問題と切り離せませんが、Mirai を使用して分析を平坦化すべきではありません。CISA の Dyn 以前の警告、Mirai およびその他のボットネットによる DDoS 脅威の高まりは、Mirai と公開されたソースコードが DDoS リスクを高めたと警告しました。査読済みの研究、Mirai ボットネットの理解は、安全でないデバイスがどのように大規模に採用されるかを説明しました。
DOJ の記録は後に刑事説明責任の文脈を提供しました。同省は重要な DDoS 攻撃に関連する3件のコンピュータ犯罪事件での起訴と有罪答弁を発表し、後にDyn に影響を与えた IoT 攻撃に関与した個人の有罪答弁を発表しました。これらの記録は重要です。敵対的なトラフィックが自然現象ではなかったことを示しています。
しかし、ボットネットの説明責任はプロバイダーと顧客の管理の代わりにはなりません。犯罪的なボットネットが洪水を引き起こす可能性がありますが、プロバイダーは依然として緩和能力とコミュニケーションを必要とし、顧客は依然としてフェイルオーバープランを必要とします。ボットネット層はトラフィックがなぜ可能であったかを説明します。DNS アーキテクチャ層はなぜ無関係なサービスが到達不能になったかを説明します。顧客アーキテクチャ層はなぜ一部の顧客が他よりも露出していたかを説明します。
NIST のボットネットに対する復元力強化に関する報告書（リンク）や後の IoT ガイダンス（NISTIR 8259A）は、政策の議論がデバイスのライフサイクル、製造業者の責任、エコシステムのインセンティブに向かう様子を示しています。それは必要ですが、遅いです。DNS 顧客はフェイルオーバーをテストする前に IoT エコシステムが修正されるのを待つことはできません。
測定は逸話をアーキテクチャに変える
障害の物語はすぐに逸話になる可能性があります。あるユーザーは Twitter がダウンしていると言います。別のユーザーは Spotify が動作していると言います。3人目は問題が地域的だと言います。プロバイダーは緩和が進行中だと言います。測定はこれらの観察をアーキテクチャに変えるのに役立ちます。ThousandEyes は複数の視点から DNS 障害を測定しました。RIPE Labs はDyn 攻撃の簡単な考察を RIPE Atlas の観測を用いて公開しました。RIPE Labs はまた、DNS DDoS の複雑さについて議論し、再帰的リトライ動作や攻撃トラフィックと正当な DNS クエリの区別の困難さを含めました。
測定は説明責任にとって重要です。障害がどこで見え、どこで見えなかったかを示すからです。プロバイダーは攻撃量を見るかもしれません。顧客はクエリ障害を見るかもしれません。ユーザーは到達不能なサービスを見るかもしれません。再帰リゾルバはリトライするかもしれません。キャッシュはタイミングに応じて影響を隠したり増幅したりするかもしれません。異なる地域は異なる結果を経験するかもしれません。測定がなければ、当事者は部分的な視点から議論します。
学術研究、例えば堤防が壊れるとき：DDoS 中の DNS 防御の解剖は、DNS 防御動作、キャッシング、層固有の復元力を調査することで別の層を追加します。重要なのは、一つの論文がすべての Dyn 顧客への影響を判断できるということではありません。DNS 復元力は研究、測定、改善が可能であるということです。それは大惨事の後にのみ説明できる謎ではありません。
顧客は独立した DNS 監視を自身の証拠の一部として使用すべきです。監視は、複数の地域とネットワークからの権威応答をテストし、プロバイダーを比較し、解決失敗を警告し、アプリケーション層と名前解決層のどちらが失敗しているかを特定する必要があります。組織がプロバイダーから独立して DNS 障害を確認できない場合、重要なイベントの最中に盲目的になる可能性があります。
公共サービスの継続性も名前解決に依存する
Dyn イベントは、同時代の報道（Chicago Sun-Times/AP の主要企業へのサイバー攻撃がインターネットを混乱させる、The Guardian の大規模 DDoS が主要サイトへのアクセスを妨害）によると、多くの人気オンラインサービスに影響を与えました。それらの名前の付いたサービスはほとんどが民間でしたが、継続性の教訓は公共サービスにも当てはまります。政府ポータル、緊急情報ページ、公衆衛生予約ツール、裁判所提出システム、税務サービスも、DNS が復元力を持たない場合に消滅する可能性があります。
公共部門の継続性は義務を引き上げます。民間のメディアやエンターテイメントサービスは収益と信頼を失う可能性があります。公共サービスは権利、期限、給付、健康、法的アクセス、緊急情報に影響を与える可能性があります。したがって、公共の買い手は DNS 復元力を調達と保証に含めるべきです。彼らは権威 DNS がどこでホストされているか、セカンダリ DNS が委任されているか、DNSSEC が運用上テストされているか、レジストラの資格情報が保護されているか、ステータスコミュニケーションが独立しているかを尋ねるべきです。
これは技術的なチェックリストだけではありません。公的なアドレス帳のガバナンスです。DNS 委任権限は、人々が名前を入力したり、リンクをクリックしたり、アプリを使用するときにどこに行くかを決定します。その権限がテストされた回復経路なしに集中している場合、公共のアクセスは単一のプロバイダーが攻撃を吸収する能力に依存する可能性があります。それは一部のサービスでは許容されるかもしれませんが、他のサービスでは許容されません。その区別は明確にされるべきです。
公共機関はユーザー側のテストも実行するべきです。主要ドメインが損なわれた場合、市民は依然として緊急情報を見つけることができますか？代替ドメインは事前に伝達されていますか？公式のソーシャルチャネルは確認されていますか？コールセンターはウェブサイトが到達不能な場合に何を言うべきか知っていますか？システムが利用できない場合、期限は延長されますか？名前解決は公共継続性の第一歩に過ぎませんが、他のステップを開始させるステップです。
契約は稼働時間だけでなく証拠を要求すべき
管理 DNS 契約はしばしばサービスレベル、サポート、セキュリティ、可用性を強調します。Dyn の後、顧客は証拠の権利を求めるべきです。プロバイダーはどのインシデントデータを共有するか？どのステータス頻度が約束されているか？顧客固有の影響情報は利用可能か？どのエクスポートおよびゾーン転送メカニズムが存在するか？セカンダリプロバイダーはどのようにサポートされるか？プロバイダーの DDoS 緩和パートナーとエスカレーションルートは何か？緊急時に変更はどのように認証されるか？
稼働時間のパーセンテージは共通モードリスクを隠すことができます。プロバイダーは歴史的な可用性目標を達成していても、顧客の最も重要な名前にとって集中した障害ドメインを表す可能性があります。したがって、契約レビューにはアーキテクチャ上の質問を含めるべきです。顧客はサポート条件に違反せずにマルチプロバイダーDNS を運用できるか？API とゾーン形式は移植可能か？プロバイダーはプロバイダー間での DNSSEC 構成をサポートしているか？部分的な障害の影響を再構築するために必要なログを顧客は取得できるか？
Oracle がDyn を買収したという発表は、Dyn の市場での役割とエンタープライズ顧客基盤を説明しました。買収は攻撃のみが原因として扱われるべきではありません。しかし、管理 DNS とインターネットパフォーマンスサービスが重要な商業インフラであったことを示しています。そのようなサービスを購入する顧客は、それらをコモディティのアドオンではなく、重要な依存関係として扱うべきです。
証拠の権利はプロバイダーも保護します。プロバイダーが攻撃のタイムライン、緩和手順、顧客通知、回復マイルストーンを示すことができれば、自身の管理を顧客アーキテクチャやボットネットの状況と区別できます。弱い証拠記録は、正確さのない非難を招きます。強力な記録は公正な配分をサポートします。
説明責任の質問は誰がフェイルオーバーを証明できるか
公開記録には多くの未知の点が残されています。完全な攻撃トラフィックの構成、影響を受けたすべてのドメイン、すべての顧客構成、Dyn の内部能力決定、個々の顧客の損失、正確な契約上の義務。これらの未知の点は重要です。これらは、単一の当事者が全損害を所有していたという簡単な主張を防ぎます。また、説明責任の基準をより実用的にします。誰がフェイルオーバーを証明できるか？
Dyn は公開声明と顧客コミュニケーションを通じて対応の一部を証明できました。独立したモニターは特定の視点からの観測された DNS 障害を証明できました。顧客は、原則として、セカンダリ DNS があったかどうか、委任されていたかどうか、ゾーンが最新だったかどうか、DNSSEC が機能したかどうか、アプリケーションが正常だったかどうか、ユーザーが明確な通知を受け取ったかどうかを証明できました。ボットネットの訴追は犯罪層の一部を証明できました。それぞれの証明は異なる説明責任の質問に答えます。
顧客にとって、鍵となる証明はインシデント前のものです。プロバイダー障害後に文書化されたフェイルオーバープランは弱いです。障害前にテストされたプランは制御です。テストには、プライマリプロバイダーの障害、セカンダリプロバイダーの動作、レジストラアクセス、DNSSEC 検証、監視、ステータスページの独立性、顧客コミュニケーション、ロールバックを含めるべきです。定期的に実行するのに十分退屈で、誤った前提を暴露するのに十分真剣であるべきです。
プロバイダーにとって、信頼できる修復には、緩和能力、透明なステータス、顧客ガイダンス、マルチプロバイダーアーキテクチャのサポート、明確なインシデント証拠が含まれます。公共機関や重要なサービスにとって、信頼できる修復にはサービスランキングと代替コミュニケーションが含まれます。IoT エコシステムにとって、信頼できる修復にはボットネット燃料を減らすデバイスセキュリティの改善が含まれます。Dyn のケースはこれらすべての層の交差点に位置しています。
本当の DNS 演習は図面よりも難しい
最後の教訓は運用です。DNS 図面は2つのプロバイダーと多数のネームサーバーを示すことができます。実際の演習は、組織がそれらを使用できるかどうかを示します。演習は、1つ以上の地域での部分的な権威 DNS 障害から始めるべきです。監視はそれを検出するべきです。インシデントチームは行動するかどうかを決定するべきです。DNS チームはゾーンの最新性を確認するべきです。セキュリティチームは資格情報を確認するべきです。コミュニケーションチームは独立したステータスチャネルを更新するべきです。ビジネスオーナーはどのサービスが影響を受けているかを理解するべきです。法務またはコンプライアンスチームは期限とユーザー影響の影響を記録するべきです。
次に、チームは変更をテストするべきです。セカンダリプロバイダーからレコードは正しく提供されますか？再帰リゾルバは期待通りに動作しますか？DNSSEC は検証されますか？モバイルアプリ、API、CDN 統合、メール、アイデンティティフローはまだ機能しますか？ログは保存されていますか？影響を受けた地域のユーザーは復旧しますか？組織は DNS とアプリケーションの正常性の違いを説明できますか？別の障害を引き起こさずに通常に戻れますか？
結果は、合格または不合格としてだけでなく、証拠として文書化されるべきです。どの前提が間違っていたか？どの連絡先が古かったか？どのプロバイダーインターフェースが混乱を招いたか？どの名前がセカンダリカバレッジを欠いていたか？どのステータスページが障害モードを共有していたか？どのレコードが手動処理には動的すぎたか？これらの発見が演習の真の価値です。
Dyn の2016年の DDoS インシデントは、静かな真実を暴露したため今も関連性があります。公開インターネットは、その背後にあるサービスよりも復元力がテストされていない名前に依存することがよくあります。権威 DNS は単なる配管ではありません。それはユーザーがそもそもサービスを見つける経路です。顧客フェイルオーバーの説明責任は、その経路が誰かによって攻撃される前に設計、テスト、ガバナンスされるときに始まります。
DNSSEC と自動化はフェイルオーバーを難しくする可能性がある
DNSSEC は真正性を向上させますが、キー管理、署名、委任、運用役割が理解されていない場合、マルチプロバイダーフェイルオーバーを複雑にする可能性があります。あるプロバイダーを通じてゾーンに署名し、ストレス下で移動しようとする顧客は、検証エラーが2番目の障害になることを発見するかもしれません。正しい教訓は DNSSEC を避けることではなく、真正性と可用性が一緒にテストされるように DNSSEC をフェイルオーバードリルに含めることです。
自動化にも同様の二重の刃があります。API 駆動の DNS 変更、インフラストラクチャ・アズ・コード、動的レコード、トラフィックステアリング、CDN 統合は、通常の運用を効率的にすることができます。また、1つのプロバイダー統合のみが維持されている場合、または自動化パイプラインが影響を受けたプロバイダーに依存している場合、緊急フェイルオーバーをより脆弱にすることもあります。手動コンソールへのフォールバックは遅すぎるかもしれません。自動フォールバックはテストされていないかもしれません。責任ある設計は、プロバイダー障害時にどの自動化が信頼され、どの人間の承認が必要かを指定します。
したがって、ドリルには暗号化と自動化のチェックを含めるべきです。チームはキーを再生成または事前配置できますか？レコードを安全に同期できますか？スプリットブレイン DNS 応答を防げますか？無効になったパイプラインからの古いレコードを避けられますか？ネガティブキャッシングと TTL 動作をテストできますか？複数の再帰リゾルバから検証できますか？これらの詳細は狭く聞こえるかもしれませんが、フェイルオーバーが実際のユーザーにとって機能するかどうかを決定します。
ステータスページには独立した名前が必要
厄介な障害モードの1つは、ステータスページが説明するサービスと同じ DNS 経路に依存していることです。ユーザーがメインドメインを解決できない場合、ステータスドメインも解決できない可能性があります。真剣な顧客フェイルオーバープランは、ステータス通信を独立した名前、プロバイダー、チャネルに配置する必要があります。また、すべてが失敗した依存関係を共有しないソーシャルチャネル、メールリスト、顧客ポータル、サポートスクリプトを含めるべきです。
これは単なるコミュニケーションの好みではありません。DNS インシデント中、一般市民はサービスが壊れているのか、ユーザーの ISP が壊れているのか、デバイスが壊れているのか、アカウントが侵害されているのかを知らないかもしれません。独立したステータスチャネルは不確実性とサポート負荷を減らします。また、アプリケーションが正常かどうか、DNS が損なわれているかどうか、フェイルオーバーが進行中かどうか、ユーザーが何を期待すべきかを会社が説明する場所を提供します。
公共部門のサービスにとって、独立したステータスはさらに重要です。フォームを提出しようとしている市民、給付金を確認しようとしている市民、緊急アドバイスを探している市民、法的期限に間に合わせようとしている市民は、信頼できる代替情報源を必要とします。ステータスチャネルは政府ネットワークの外部および異なる地域からテストされるべきです。障害の一部がアイデンティティである場合、同じアイデンティティプロバイダーを必要とするべきではありません。専門家でない人にも理解可能であるべきです。
調達は DNS を重要な依存関係として扱うべき
組織はしばしば、クラウドホスティング、アイデンティティ、決済処理、メール、データストレージを重要なサービスとしてレビューする一方、DNS を小さな項目として扱います。Dyn イベントはその階層を変更することを主張します。DNS が失敗すると、他の多くの投資が到達不能になります。調達レビューでは、プロバイダーが信頼できる DDoS 容量、透明なインシデントコミュニケーション、独立したステータス、セカンダリ DNS のサポート、エクスポート可能なゾーン、DNSSEC ガイダンス、顧客固有のレポート、緊急連絡先を持っているかどうかを尋ねるべきです。
レビューはまた、顧客が何をすることを約束しているかを尋ねるべきです。プロバイダー単独では顧客の完全なフェイルオーバーアーキテクチャを実装できません。顧客は正確なゾーンを維持し、適切な場合にセカンダリネームサーバーを委任し、レジストラアカウントを保護し、変更をテストし、決定権限を割り当て、独立した場所から解決を監視する必要があります。プロバイダーの復元力を購入しても顧客の準備がなければ不完全です。
重要度はサービスごとに階層化されるべきです。マーケティングマイクロサイトはより長い DNS 中断を許容するかもしれません。決済ゲートウェイ、緊急ポータル、アイデンティティエンドポイント、顧客が使用する API、公衆衛生サービスは許容しないかもしれません。階層化は過剰エンジニアリングと危険な怠慢の両方を防ぎます。チームがユーザーへの害が最も高い場所に復元力の努力を費やすことを可能にします。
再帰リゾルバとキャッシュはユーザー体験を複雑にする
権威 DNS は解決経路の一部に過ぎません。再帰リゾルバ、キャッシュ、TTL、ネガティブキャッシング、リトライ動作、ユーザーネットワーク条件はすべて、人々が経験することを形作ります。Dyn イベント中、一部のユーザーはサービスに到達でき、他はできませんでした。一部のキャッシュされたレコードは一時的に権威障害を隠したかもしれません。他のリゾルバ動作は圧力を増加させたかもしれません。この複雑さは、独立した測定が非常に重要である理由です。
顧客は、本社からの正常なクエリがグローバルな可用性を証明すると想定すべきではありません。彼らは地域、ネットワーク、リゾルバタイプを横断する視点を必要とします。企業 DNS、公開リゾルバ、ISP リゾルバ、モバイルネットワーク、クラウド監視場所をテストすべきです。また、DNS 解決とアプリケーション応答の違いを監視すべきです。DNS が最初に失敗した場合、アプリケーション監視は決して実行されないかもしれません。
ユーザーサポートスクリプトは、ユーザーを専門用語で溺れさせることなくこの複雑さを反映するべきです。「名前解決が損なわれているため、一部のユーザーがサービスに到達できません。アプリケーション自体は監視されており、チームは DNS プロバイダーと協力しています。利用可能な場合は代替チャネルを提供します。」というように言うことができます。明確な言語は、権威 DNS 障害を自分のラップトップから解決できないユーザーによる繰り返しのトラブルシューティングを減らします。
ボットネット防止は遅い、したがって顧客の準備は迅速でなければならない
Mirai は、安全でない IoT デバイスがリソースの豊富なターゲットを圧倒するトラフィックを生み出す可能性があることを示しました。IoT セキュリティ、デバイスラベリング、ベースライン機能、デフォルト資格情報、更新サポートに関する政策作業は必要です。また遅いです。デバイスは何年も展開されたままになり、所有者はパッチを当てないかもしれず、製造業者は消えるかもしれず、ソースコードは再利用されるかもしれません。DNS に依存する顧客は、ボットネットエコシステムが最初に改善されるのを待ってから継続性を条件付けることはできません。
それはボットネット防止が無関係であるという意味ではありません。それは層が正直であるべきという意味です。政府、製造業者、ISP、セキュリティコミュニティはボットネット燃料を減らすべきです。DNS プロバイダーは緩和能力を構築し購入すべきです。顧客はフェイルオーバーを設計すべきです。ユーザーは明確なコミュニケーションを受けるべきです。単一の層が全負担を担うことはできず、一つの層での失敗が別の層での怠慢を許すべきではありません。
この層状の見解は取締役会にとって有用です。取締役会は DDoS 問題が「プロバイダーの仕事」かどうか尋ねるかもしれません。答えは部分的にはイエス、部分的にはノーです。プロバイダーは自身のインフラを防御しなければなりません。顧客は、問題のビジネスプロセスにとって1つのプロバイダーで十分かどうかを決定しなければなりません。取締役会はそのリスク受容を所有します。重要な収益または公共サービスの経路が単一の権威 DNS プロバイダーに依存している場合、それは取締役会レベルの依存関係です。
公開記録は障害と依存関係を区別すべき
DNS インシデント後、公開報道はしばしば影響を受けたブランドをリストします。それは規模を示すのに有用ですが、因果関係を曖昧にする可能性があります。名前の付いたサービスは、DNS プロバイダーが攻撃を受けているため一部のユーザーにとって到達不能であるかもしれませんが、サービス自身のアプリケーションは正常です。別のサービスは自身の構成のために異なる影響を受けるかもしれません。3つ目はマルチプロバイダーDNS またはキャッシュされたレコードによって保護されているかもしれません。報告がプロバイダー障害、顧客依存関係、ユーザー影響を区別するとき、説明責任は向上します。
同じ区別は企業のポストモーテムにも現れるべきです。顧客は、アプリケーションが失敗したかどうか、DNS 解決が失敗したかどうか、フェイルオーバーが機能したかどうか、何を変更するかを述べるべきです。顧客が単に「サードパーティの障害が影響した」とだけ言う場合、読者は顧客が合理的なアーキテクチャを持っていたかどうかを判断できません。「サービスが利用できなかった」とだけ言う場合、読者は依存関係を特定できません。適切な言葉は、機密の詳細を共有しすぎずに具体的です。
プロバイダーのポストモーテムも同様に、顧客を単一のカテゴリーとして扱うことを避けるべきです。一部の顧客はより良いアーキテクチャを必要とするかもしれません。一部はより良いガイダンスを必要とするかもしれません。一部は、攻撃条件が前提を超えたため、強力な設計にもかかわらず影響を受けたかもしれません。顧客固有の詳細は機密かもしれませんが、集約された教訓は依然として共有できます。市場は、プロバイダーと顧客のポストモーテムが互換性のあるカテゴリーで語るとき、より速く学習します。
説明責任テストは意図的に退屈である
最高の DNS 復元力プログラムは意図的に退屈です。ゾーンを同期し続けます。定期的にフェイルオーバーをテストします。レジストラアクセスを保護します。DNSSEC を文書化します。多くの場所から監視します。独立したステータスチャネルを維持します。複数の人を訓練します。決定を記録します。プロバイダーの証拠をレビューします。ユーザーへの害によってサービスをランク付けします。有名なボットネットが教訓をトップページに戻す前に、これらのことを行います。
退屈な制御は、DNS が通常機能するため延期されやすいです。Dyn の攻撃はその自己満足の代償を示しました。権威層が失敗するとき、インシデントはユーザーに突然感じられますが、アーキテクチャの決定は古いものでした。説明責任は、それらを変更する時間がある間に、それらの古い決定を可視化することを意味します。
公開インターネットは、ほとんどのユーザーが見ることのない信頼と到達可能性の連鎖に依存しています。Dyn は一つのリンクを可視化しました。責任ある対応は、パニック、非難、またはすべてのサービスが同じ高価なアーキテクチャを必要とするという普遍的なルールではありません。それは規律ある質問です。このサービスについて、この公共または商業的な結果において、プライマリ DNS 経路が攻撃下にあるときにユーザーがまだ私たちを見つけることを証明できますか？
フェイルオーバーの所有者は曖昧であってはならない
DNS はチームの間に位置します。インフラがゾーンを所有するかもしれません。セキュリティが DDoS リスクを所有するかもしれません。アプリケーションチームがエンドポイントを所有するかもしれません。マーケティングがドメインを所有するかもしれません。法務がレジストラ契約を所有するかもしれません。カスタマーサポートがステータスコミュニケーションを所有するかもしれません。プロバイダー攻撃中、曖昧さは遅延になります。組織は、誰が DNS フェイルオーバーを宣言できるか、誰が委任を変更できるか、誰が DNSSEC アクションを承認できるか、誰がステータスメッセージを更新できるか、誰が顧客向けのリスクを受け入れられるかを知っているべきです。
所有者はインシデント前に権限を持つべきです。フェイルオーバーに、一緒に練習したことのない人々の緊急会議が必要な場合、計画は脆弱です。決定は依然としてチェックを含むことができますが、チェックは訓練されるべきです。指名されたフェイルオーバー所有者は、一人が単独で行動することを意味しません。それは組織がどの役割が決定を調整するかを知っていることを意味します。
レジストラ管理は同じ依存関係の一部である
多くの DNS 計画はレジストラアクセスを軽視しています。組織がネームサーバーの委任や DS レコードを変更する必要がある場合、レジストラの資格情報、多要素認証、ロックステータス、承認ワークフローが重要です。プロバイダーレベルの DNS インシデントは、レジストラアカウントにアクセスできない、緊急手順なしに過保護にされている、または退職した従業員によって保持されている場合に悪化する可能性があります。レジストラの準備は、DNS プロバイダーの準備と同じ真剣さでテストされるべきです。
テストは無謀なライブ変更を避けるべきですが、誰がアクセス権を持っているか、どの承認が必要か、ロックがどのように処理されるか、緊急連絡先がどのように機能するか、変更がどのようにロールバックされるかを検証できます。また、レジストラのコミュニケーションが影響を受けたドメインから独立していることを検証する必要があります。変更を承認できる唯一の人々が、同じ DNS 経路に依存するメールアドレスを通じてメッセージを受信する場合、プロセスは最悪の時に失敗する可能性があります。
顧客の証拠は後の配分のために保存されるべき
DNS 障害後、顧客はプロバイダー障害、自身のアーキテクチャ、上流のリゾルバ動作、アプリケーション問題の間で害を配分する必要があるかもしれません。その配分には証拠が必要です。監視ログ、プロバイダーのステータスメッセージ、リゾルバテスト、顧客影響レポート、サポートチケット、内部決定は保存されるべきです。それらがなければ、ポストモーテムは記憶と非難になります。
証拠の保存は、アーキテクチャを変更すべきかどうかを決定するのにも役立ちます。障害が特定の地域のユーザーにのみ影響した場合、対応はグローバルな障害とは異なるかもしれません。セカンダリ DNS が正しく応答したがアプリケーションがまだ失敗した場合、DNS 計画が主な問題ではないかもしれません。顧客がステータスページに到達できなかった場合、コミュニケーションアーキテクチャの作業が必要です。DNSSEC 検証がフェイルオーバー中に失敗した場合、セキュリティと DNS チームは共同修復計画を必要とします。
証拠はインシデントがまだ新しいうちにレビューされるべきです。数ヶ月待つと、技術的事実が民間伝承に変わります。短く規律のあるレビューは、保持する記録、再検討する決定、再実行するテストを特定できます。Dyn のインシデントは、次のプロバイダーレベルの攻撃の前にその習慣を奨励するため、今も価値があります。
サービスオーナーは DNS 障害のユーザーへの影響を知るべき
DNS リスクは各サービスオーナーに翻訳されるべきです。公開 API、決済ページ、アイデンティティエンドポイント、緊急情報サイト、顧客ポータルを実行するチームは、名前が解決できない場合にユーザーが何を失うかを知っているべきです。キャッシュされたレコードが短いクッションを提供するかどうか、モバイルユーザーが企業ユーザーと異なる影響を受けるかどうか、サポートスタッフが使用可能な代替手段を提供できるかどうかを知っているべきです。その翻訳がなければ、DNS は障害が顧客に到達するまでインフラの抽象概念のままです。
サービスオーナーはまた、どのレベルの残留リスクが許容可能かを事前に決定すべきです。一部のサービスは、ユーザーへの影響が低い場合、単一プロバイダーを許容できます。他は、公共または商業的な害が高いため、セカンダリ DNS、独立したステータス、頻繁な訓練を必要とします。その決定は、技術的なデフォルト設定内に隠されるのではなく、リスク受容として文書化されるべきです。
DNS ドリルにはビジネスクロックを含めるべき
技術的な DNS ドリルは成功しても、ビジネスが時間内に行動できない場合があります。演習にはビジネスクロックを含めるべきです。いつ顧客への害が始まるか、いつサポート量が増加するか、いつ法務または規制の通知が必要になるか、いつ収益または公共サービスの期限が影響を受けるか、いつ経営陣がセカンダリ構成を有効にするかを決定しなければならないか。これらのしきい値はサービスによって異なるため、インフラおよびセキュリティチームとともにサービスオーナーが設定する必要があります。
ドリルはロールバックもテストすべきです。緊急 DNS 変更は、古いレコード、DNSSEC 設定、レジストラロック、またはアプリケーション依存関係が慎重に復元されない場合、一つの問題を解決し別の問題を生み出す可能性があります。したがって、責任あるフェイルオーバープランには、通常サービスへの復帰経路、通常サービスが安全であるという証拠、問題が終了したことをユーザーに伝えるコミュニケーションが含まれます。Dyn の教訓は、攻撃された経路から離れる方法だけでなく、組織がプレッシャーの下で依存関係のライフサイクル全体を管理できることを証明する方法です。
この記事は以上です。