Azure の2021年 DNS キャッシュ欠陥と再試行増幅の説明責任

要約

2021年4月1日21:21 UTC から22:00 UTC にかけて、Azure DNS でサービス可用性の問題が発生しました。Microsoft は、依存サービスの大半が22:30 UTC までに復旧したと述べています。当時のコミュニティ通知では影響時間帯を約21:30～22:30 UTC としていましたが、独立した監視では21:20頃にアラームが報告されています。これらは異なる観測であり、必ずしも矛盾する時計ではありません。[1][2]
Microsoft は、Azure でホストされる一連のドメインを標的とした世界中からの異常な DNS クエリの急増を説明しました。攻撃者、意図、ボットネット、確認された分散型サービス拒否キャンペーンは公に特定していません。最初の急増は、Microsoft の説明を超えて未解明のままです。[2][4][5]
Microsoft は、特定のイベントシーケンスによってコード欠陥が露呈し、Azure DNS Edge キャッシュの効率が低下したと述べました。公開記録には、コードパス、キャッシュキー、ヒット率、影響を受けたエッジ数、キャッシュミスごとのバックエンド負荷は開示されていません。[2][4][5]
DNS サービスが過負荷になると、クライアントはより頻繁に要求を再試行しました。Microsoft は、ボリューム急増緩和システムがそれらの再試行を正当なものとみなし、破棄しなかったと述べています。これは再試行増幅フィードバックループを裏付けますが、パケットレベルの正確な再構築を示すものではありません。[2][4]
Microsoft は、監視が可用性の低下を検知し、エンジニアが対応し、DNS サービスは22:00 UTC までに自動復旧したと述べています。復旧時間が設計目標を超えたことを認めました。その後、過剰な再試行から保護するために緩和ロジックを変更し、キャッシュ欠陥の修正と異常トラフィック検出の改善を次のステップとして挙げました。[2][4][5]
この障害は1つのアプリケーションではなく、ネットワークコントロールプレーンに影響を及ぼしました。ユーザーは Azure、Dynamics、Xbox Live などの Microsoft サービスで名前解決が断続的に困難になりました。正しいサービスレコードが存在しても、稼働中の権威パスが信頼できる応答を返さない場合は十分ではありませんでした。[1][3][6]
現在の Azure ドキュメントには、グローバルエニーキャスト DNS ネットワーク、信頼性機能、顧客向け制御が記載されています。これらの資料はアーキテクチャと責任を説明しますが、2021年の正確な実装や修復完了の証拠として使用することはできません。[7]-[13]
DNS 標準は、権威サービスと再帰解決を分離し、キャッシュ、無応答、再試行が負荷をどのように形成するかを文書化しています。RFC 4697は、リゾルバーの再試行挙動が権威サーバーに過剰な作業を課す可能性があるため、特に関連性があります。これらの標準は、この障害の際にどのクライアントやリゾルバーがどの程度寄与したかを示すものではありません。[14]-[22]
責任は管理権限に従います。Azure DNS エンジニアリングはキャッシュコード、エッジ容量、トラフィック整形、緩和分類、復旧自動化を管理していました。Microsoft のサービスチームは共有 DNS 依存関係を管理していました。リゾルバーとクライアントの運用者は再試行とキャッシュ動作を管理していました。顧客は一部の監視と委任の選択を管理していましたが、Azure の内部欠陥を検査または修復することはできませんでした。
信頼できる修復には、期間を限定した証拠が必要です。クエリクラス別キャッシュヒット率、再試行率、エッジ飽和、エニーキャスト集水域の変化、緩和ルールの挙動、既知の正常解決プローブ、サービス別復旧、再発テストなどです。これらはいずれもステータスラベルだけから推測すべきではありません。

タイムラインには複数の時計が存在する

インシデント報告は時間が経つほど整理されがちです。Azure DNS の記録は、有用な区別を消してしまう整理には抵抗すべきです。

Microsoft の後日のインシデント報告は、Azure DNS のサービス可用性問題を2021年4月1日21:21 UTC から22:00 UTC までの間としました。同社は、サービスの大半が22:30 UTC までに復旧したと述べています。Exoprise はその説明を再掲し、自社の DNS およびサーバー監視が21:20頃にアラームを上げたと報告しました。[2] Microsoft 社員による当時のコミュニティ通知は、対応がまだ進行中だった時点で、顧客への影響をおよそ21:30 UTC から22:30 UTC としていました。同じページでの後日の Microsoft 社員の更新では、Microsoft DNS サーバーでトラフィック急増が見られ、回復力のある DNS 機能が有効化されたと述べています。[1]

これらのタイムスタンプは異なるものを測定しています。

外部監視による最初の障害観測。
事業者側が後から定めた DNS サービス状態の開始時刻。
事業者が DNS の自動復旧とみなした時刻。
顧客が断続的なアクセスを経験した期間。
依存サービスの大半が復旧した時刻。

The Register の当時の報道は、およそ21:30 UTC の開始時刻を引用し、Microsoft が調査中にトラフィックを回復力のある DNS 機能へ迂回させたと述べました。主要な地理的地域への影響を説明する一方で、Microsoft の政府向けクラウドと中国サービスを報告範囲から除外しました。[3] TechCrunch は別途、複数の Microsoft 製品に及ぶ障害を報じ、Azure Portal と Azure サービスの問題を認める Microsoft のコメントを引用しました。[6]

公開証拠は、すべての名前、リゾルバー、地域、サービスに共通する単一の復旧時点を確立するものではありません。DNS キャッシュにより、障害と復旧が異なる時刻に現れることがあります。ウォームな回答を持つリゾルバーは、権威サービスの可用性が低下した後も名前を提供し続けることができます。コールドキャッシュの別のリゾルバーは即座に失敗するかもしれません。権威サービスが改善しても、クライアントや中間リゾルバーに残る否定応答や失敗状態が、目に見える復旧を遅らせることがあります。Microsoft 自身も、DNS の自動復旧22:00と主要サービス復旧22:30を区別しています。[2]

この区別は説明責任にとって重要です。事業者は、ユーザーが依然として重要な名前を解決できない場合に、内部サーバー指標だけで復旧を定義すべきではありません。また、外部アラームを自動的に根本原因の開始として扱うべきでもありません。整合性のあるタイムラインには少なくとも4つのトラックが必要です。権威サービスの健全性、再帰リゾルバーの結果、依存サービスの復旧、ユーザーから見た到達可能性です。

異常な急増は証明された攻撃ではない

Microsoft は、Azure DNS が Azure でホストされる一連のドメインを標的とした世界中からの異常なクエリ急増を受けたと述べました。[2][4] これは量と対象分布の説明です。それ自体では、誰がトラフィックを生成したか、意図が悪意だったか、送信元アドレスが偽装されていたか、またはその事象が特定のサービス拒否分類に該当するかを確立するものではありません。

一部の報道は攻撃という言葉を使いました。ここで引用する技術記録は、パケットサンプル、帰属報告、DDoS キャンペーンを名指しする Microsoft の声明を提供していません。したがって、将来の証拠基準は狭くなります。

Microsoft の説明で確認：世界的なクエリ急増が一連の Azure ホストドメインを標的とした。
Microsoft の説明で確認：サービスの通常のキャッシュとトラフィック整形がそのような急増を緩和することが期待されていた。
Microsoft の説明で確認：特定のシーケンスの下でコード欠陥がエッジキャッシュ効率を低下させた。
不明：急増を引き起こしたもの。
不明：協調的行為者がサービス拒否を意図したか。
不明：トラフィックが偽装、反射、侵害デバイスによる生成、ソフトウェア動作によるものか、複数の発生源が組み合わさったか。
不明：関係した名前、クエリタイプ、レート、地理的分布。

この境界は単なる意味論的な注意ではありません。修復はメカニズムに依存します。送信元アドレス検証は偽装トラフィックを抑制できますが、正当なクライアントの再試行を止めることはできません。レート制限は高ボリュームを抑えられますが、有効な解決を拒否する可能性があります。キャッシュ容量の追加は繰り返しの質問には役立ちますが、一意な名前やキャッシュを迂回するクエリの組み合わせが支配的なワークロードには役立たないかもしれません。より良いエニーキャスト分散は作業を分散できますが、エッジ間で過負荷を移動させることもあります。

証拠なしに急増を攻撃と呼ぶことは、1つの説明を確定したように見せ、責任を外部に向ける可能性があります。Microsoft 自身の説明は、発生源にかかわらず内部欠陥と緩和分類のギャップを特定しています。最初のトラフィックが悪意だったとしても、サービスはサポートされるべき障害モード、つまりキャッシュ効率の低下と、ボリューム制御が除去しなかった正当な再試行を処理しなければなりませんでした。

キャッシュ欠陥が各クエリのコストを変えた

キャッシュは権威 DNS において単なる性能最適化ではありません。繰り返しの質問に対してエッジがどれだけ作業を行い、どれだけの負荷がより深いサービスコンポーネントに到達するかを決めることができます。

Microsoft は、1つの特定のイベントシーケンスによってコード欠陥が露呈したため、DNS Edge キャッシュ効率が低下したと述べました。[2][4][5] この表現は情報に富んでいますが不完全です。影響を受けたクエリが回答キャッシュを外れたのか、否定キャッシュを迂回したのか、バックエンド参照を繰り返したのか、共有状態で競合したのか、エントリを無効化したのか、別の希少資源を消費したのかは述べていません。すべてのエッジが脆弱だったのか、特定のエニーキャスト経路を通じて到達した一部だけだったのかも特定していません。

説明責任のある再構築は、これらの詳細を埋めることを避けるべきです。それでも効率がなぜ重要かを示すことはできます。

単純化したエッジが繰り返し質問を受けると仮定します。キャッシュヒット率が高ければ、回答の多くは既に利用可能な状態から提供されます。クエリあたりの限界作業は比較的低く保たれます。欠陥がより多くのクエリを低速な経路に押し下げると、各要求はより多くの CPU 時間、メモリ、同期、ネットワーク作業、またはバックエンド容量を消費する可能性があります。遅延が上昇します。クライアントはより長く待つか、応答を受け取れません。そして再試行します。再試行の集合は、元の急増が成長を止めても受信レートを引き上げます。

これは Microsoft の説明が裏付ける核となるフィードバックループです。

異常なクエリ急増が Azure DNS に到達する。
特定のシーケンスがキャッシュ効率の欠陥を露呈させる。
より多くの要求が高コストの処理を必要とするか、より長く待たされる。
DNS サービスの可用性が低下する。
クライアントが未応答の要求を再試行する。
ボリュームシステムがそれらの再試行を正当とみなす。
再試行トラフィックが既に損なわれたサービスに作業負荷を追加する。

このループは、いずれかのクライアントが非合理的に振る舞うことを必要としません。再試行は個別には合理的であり得ます。システム的な障害は、集約的な挙動と、その作業を安全に分類または整形できない運用者の能力から生じます。

RFC 1034と RFC 1035は、キャッシュを DNS 運用の基本的な部分として確立しています。[17][18] RFC 2308は、リゾルバーが同じ不存在の質問を無制限に繰り返さないように否定キャッシュを定義しています。[19] RFC 8020や RFC 8198などの後続標準は、特定の条件下で不要な否定クエリトラフィックを減らす方法を説明しています。[21][22] これらの文書は、Azure の欠陥が否定応答に関係したことを証明するものではありません。クエリの再利用、キャッシュ状態、繰り返しのミスが認識された運用変数であることを示すだけです。

正当な再試行でも集約的には安全でないことがある

Microsoft の最も重大な認めは、クライアントの再試行が正当な DNS トラフィックとみなされ、ボリューム急増緩和システムによって破棄されなかったことです。[2][4]

「正当」は複数の意味を持ち得ます。パケットはもっともらしい送信元を持つかもしれません。クエリはプロトコルに適合しているかもしれません。クライアントは再帰リゾルバーの使用を許可されているかもしれません。要求されたドメインは存在するかもしれません。しかし、いずれも無制限の集約的再試行ストリームが障害のある権威サービスにとって安全であることを保証しません。

RFC 4697は、権威サーバーに過剰なクエリ負荷を課し得るリゾルバー挙動を文書化しています。リゾルバーが過度に積極的に再試行したり、複数のサーバーにクエリを送ったり、より規律ある応答なら負荷を減らせる状況で作業を続けるパターンを説明しています。[20] この文書は Azure インシデントより何年も前から存在します。その関連性は、Azure が必ずしも特定の規定アルゴリズムに違反したことではありません。リゾルバーと権威の境界における再試行増幅が既知の運用障害クラスであることを確立します。

Azure の記録はいくつかの疑問に答えていません。

どのクライアントまたは再帰実装が再試行したか。
再試行は Microsoft 運用のサービスコンポーネント、公開リゾルバー、企業リゾルバー、エンドユーザーデバイスのいずれかに集中していたか。
次の試行を引き起こした応答またはタイムアウトは何か。
再試行間隔はランダムだったか同期していたか。
クライアントはエニーキャストアドレス間を移動したか、同じ到達エッジへ繰り返したか。
キャッシュ欠陥出現後、どのクエリクラスが最も高いコストを生んだか。
正当な再試行は、名前、タイミング、送信元ネットワーク、または先行応答によって最初の急増と区別可能になったか。

これらの測定がなければ、「過剰な再試行」は有用なカテゴリですが完全な診断ではありません。

緩和の課題も現実です。すべての再試行を破棄すると、障害を長引かせ、最初のパケットが単に失われたクライアントを拒否する可能性があります。すべての再試行を許可すると、過負荷を持続させます。運用者は、回復を保つために十分な既知の正常な作業を保護しつつ、不釣り合いな資源を消費するパターンを制限する、境界付きの受け入れが必要です。

Microsoft は、インシデント直後にボリューム緩和ロジックを更新し、DNS サービスを過剰な再試行から保護したと述べました。[2][4] 検証可能な説明は、何の信号が変わったか、新しいルールが無害な再試行と有害な集約挙動をどう区別するか、どのような偽陽性テストが実行されたか、正当な名前をブロックした場合に運用者がどのように制御を無効化または調整できるかを示すはずです。

権威サービスと再帰解決は異なる制御領域である

ユーザーの DNS ルックアップは、異なる当事者が運用するシステムを横断します。

デバイス上のスタブリゾルバーは通常、再帰リゾルバーに問い合わせます。再帰リゾルバーはキャッシュから回答するかもしれません。使用可能な回答がない場合、委任をたどり、関連ゾーンの権威サーバーに問い合わせます。RFC 1034と RFC 1035は、これらの役割とそれらの間のメッセージ交換を定義しています。[17][18]

Azure DNS は、影響を受けた Azure ホストドメインの権威層を運用していました。サービスのエッジ実装、キャッシュ動作、容量、トラフィック整形、権威応答を管理していました。再帰リゾルバーはキャッシュ状態、サーバー選択、タイムアウト解釈、再試行動作を管理していました。アプリケーションは、名前解決失敗後に自分の呼び出しを再試行するかどうか、どのようにするかを管理していました。アクセスネットワークとインターネットルーティングは、エニーキャストクエリがどの Azure エッジに到達するかに影響しました。

したがって、同じ症状でも原因が異なることがあります。

到達した権威エッジが過負荷のため、リゾルバーがタイムアウトすることがある。
エッジが健全でも、経路がパケットを破棄することがある。
権威サービスが改善した後も、リゾルバーが否定結果や使い果たした再試行状態を保持することがある。
アプリケーションが1つのリゾルバー失敗を多数の並行再試行に変えることがある。
ステータスページ自体が、そのホスト名が損なわれた層に依存しているため到達しにくくなることがある。

RFC 8906は、応答しない権威サーバーがリゾルバーの視点からパケット損失と区別できないことがあると説明しています。[16] この曖昧さは自動化された挙動とインシデントコミュニケーションの両方に影響します。リゾルバーは合理的に別の権威アドレスを試すかもしれませんが、多くのリゾルバーが同じ決定をすると負荷を移動または増加させることができます。

説明責任はこれらの役割を平坦化すべきではありません。Azure はすべてのクライアントアルゴリズムを制御できません。リゾルバー運用者は Azure のキャッシュコードを修正できません。顧客は内部エッジテレメトリを検査できません。しかし Azure はクエリを受け付けるサービス境界と再試行トラフィックを分類する緩和ロジックを管理していました。それは、権威サービスが劣化しても、有効な復旧挙動を持続的な過負荷に変えないことを証明する一次責任を Azure に与えます。

エニーキャストはクエリを分散するが、すべてのエッジを同等にするわけではない

現在の Microsoft 文書は、Azure DNS がグローバルなネームサーバーネットワークとエニーキャストを使用して、各クエリを近くの利用可能な DNS サーバーに転送すると述べています。[7] Microsoft の Windows Server エニーキャストガイダンスは、複数の場所が同じサービスアドレスを広告し、ルーティングが経路を選択するという一般的なパターンを説明しています。[9]

これらの文書は現在のアーキテクチャと一般的な実践を説明しています。2021年の正確なトポロジー、経路ポリシー、撤退挙動を証明するものではありません。この時間的境界は明示的に保つべきです。

RFC 9199は、大規模な権威サービスが複数のサーバー、エニーキャスト、負荷分散を一般的に使用する理由を説明しています。また、1つの普遍的な展開モデルを仮定しないよう警告しています。リゾルバーの配置、ルーティング、ピアリング、集水域の形状が、どのインスタンスがトラフィックを受けるかに影響します。[14]

クエリ急増中、エニーキャストは負荷を分散できます。しかし不均一な体験を生むこともあります。

1つの集水域が標的ワークロードのより大きな割合を受け取る場合がある。
経路変更が敵対的クエリと正当なクエリの両方を別のエッジへ移動させる場合がある。
ノードはアプリケーション層が過負荷でも到達可能であり続ける場合がある。
撤退が1つのサイトを保護する一方で、トラフィックを他へ集中させる場合がある。
異なるネットワークの再帰リゾルバーが異なるエッジに到達し、異なる可用性を報告する場合がある。

Microsoft の公開 RCA は、キャッシュ欠陥がすべてのエッジに影響したか、経路が変わったか、回復力のある DNS 機能が集水域移動を意味したか、一部のサーバーが他よりキャッシュ効率が良かったかを開示していません。[1][2]

「トラフィックを当社の回復力のある DNS 機能へ迂回させた」という表現は、当時のステータス報告に現れました。[3] 何が変わったかを確立するには広すぎます。信頼できる技術的説明は、その表現を証拠に結びつけるはずです。

どの経路またはサービスエンドポイントが変わったか。
どの集水域が移動したか。
キャッシュ状態が移動またはウォームアップしたか。
各段階で応答率とタイムアウト率がどう変わったか。
その変更が再試行量を減らしたか。
どの外部プローブが復旧を確認したか。

エニーキャストは基盤であって赦免ではありません。その価値は、実際のワークロードの下で観測された継続性によって測られます。

古いデータの提供は選択肢であり、想定される治療法ではない

権威サーバーが応答できないとき、再帰リゾルバーは以前有効だった応答の期限切れコピーを持っている場合があります。RFC 8767は、指定された条件下で回復力を向上させるために古いデータを提供する境界付きの方法を定義しています。[15]

このメカニズムは継続性に関連しますが、欠けていた制御としてインシデントに持ち込むべきではありません。公開情報源は、どのリゾルバーが古い回答を保持していたか、どのレコードが提供できるほど安定していたか、応答が期限切れだったか、古いデータの提供が有効だったかを示していません。

古いデータの提供にはトレードオフがあります。

短い権威障害の間、安定したサービス名を到達可能に保つことができる。
運用者が緊急に変更する必要があるアドレスを保持してしまう可能性がある。
一部のユーザーから継続する権威障害を隠す可能性がある。
キャッシュされた回答がない初回クエリには役立たない。
権威エッジを修復せず、すべてのクエリクラスを減らすわけでもない。
その有用性は事前のキャッシュ状態と設定された制限に依存する。

否定キャッシュにも同様の境界があります。RFC 2308は既知の否定回答に対する繰り返しクエリを減らします。RFC 8020は、検証済み NXDOMAIN ブランチより下でリゾルバーが停止することを許可します。RFC 8198は、DNSSEC 認証済み否認レコードの積極的な使用により追加の否定回答を合成することを可能にします。[19][21][22]

これらのメカニズムは不要な上流作業を減らすことができます。Azure の急増がランダムな不存在名で構成されていたことや、露呈した欠陥が否定キャッシュに関係したことを証明するものではありません。クエリ分布と DNSSEC 状態を知らずに安全に推奨することもできません。

証拠に基づく問いは「なぜすべてのリゾルバーが古いデータを提供できなかったのか」ではありません。むしろ次の通りです。

影響を受けた名前のうち、使用可能なキャッシュ回答を持っていたものはどれか。
再試行トラフィックのうち、コールド、肯定、否定、期限切れの各キャッシュ状態から来た量はどれだけか。
安全でない古い状態を保持せずに権威作業を減らした回復力挙動はどれか。
リゾルバーが古い、失敗した、または遅延した回答を返したとき、アプリケーションはどう振る舞ったか。

これらの測定は、一般的な標準の議論をインシデント固有の制御決定に変えます。

依存関係の集中が1つの DNS 障害を多くのサービス障害のように見せた

インシデントは Azure、Dynamics、Xbox Live などの Microsoft サービスを通じて可視化されました。名前解決が複数のサービス経路の下にあったためです。Microsoft の Q&A 通知は Azure、Dynamics、Xbox Live を挙げました。[1] Exoprise は Microsoft 365のコミュニケーションを再掲し、Teams とより広範な依存製品を挙げました。[2] The Register と TechCrunch は独立して、Microsoft の各プロパティにわたる広範なアクセス苦情を説明しました。[3][6]

証拠は、すべての基盤アプリケーションが失敗したことを示していません。サービス名を解決できないユーザーは、コンピュート、ストレージ、アプリケーションプロセスが健全でもサービスを利用できないと感じます。この区別は診断と復旧の両方で重要です。

DNS はネットワークアイデンティティの一部です。ユーザーとソフトウェアが使用する名前を到達可能なエンドポイントにマップします。レコードは正しく保存されたままでありながら、それに回答するサービスが利用不能になることがあります。応答が到着しなければ、正しいレコードからユーザーが実際に得る利益はありません。

共有依存関係はいくつかの説明責任の問いを生みます。

公開ステータス、サポート、管理、認証の経路は同じ権威 DNS 層に依存していたか。
内部対応者は診断とコミュニケーションに必要なツールに到達できたか。
どのサービスチームが Microsoft のネットワーク外部から独立して DNS を監視していたか。
どのサービス所有者が、自分の名前が1つのエッジキャッシュ実装を共有していると知っていたか。
影響を受けた名前空間の外に静的な緊急通信経路はあったか。
サービス復旧は、権威復旧後にリゾルバーキャッシュの失効または更新に依存したか。

Exoprise はイベント中の Azure ステータスページへのアクセス困難を報告し、Microsoft がユーザーを代替ステータス画面に誘導したと説明しました。[2] その報告は独立した観測として扱うべきであり、すべてのステータスエンドポイントが同じ理由で失敗した証拠ではありません。それでもガバナンス上の問題を露呈します。インシデント通信チャネルは、それが報告するサービスと未検証の依存関係を共有すべきではありません。

修復は必ずしもすべての名前に対する第2の DNS プロバイダーではありません。正確な依存関係グラフと独立した観測から始まります。Microsoft のサービス所有者は、どの名前、権威経路、再帰リゾルバー、コントロールプレーンアクションが共通のままかを知る必要があります。

監視は劣化を検出したが、検出は封じ込めではない

Microsoft は、サービスの可用性低下が監視システムをトリガーし、エンジニアを動員したと述べました。[2] Exoprise は、外部監視が21:20頃にアラートし、事業者の DNS ウィンドウの後日設定された21:21開始に近いと述べました。[2]

このタイミングは、検出だけが問題ではなかったことを示唆します。サービスは22:00までに自動復旧しましたが、Microsoft はその継続時間が設計目標を超えたと認めました。関連する問いは、検出後に運用者が何をできたかになります。

有用な検出システムは、少なくとも以下の信号を分離すべきです。

受信クエリレート。
クエリクラス別のキャッシュヒット率とミス率。
応答または失敗した要求あたりのコスト。
キュー深度とサーバー飽和。
有効回答率。
外部リゾルバーからのタイムアウト率とエラー率。
再試行量と再試行の送信元分布。
エニーキャスト集水域の移動。
サービス別の名前解決成功率。

集約的なトラフィックアラームは、クエリあたりの作業量の変化を見逃す可能性があります。キャッシュ欠陥は、慣れ親しんだクエリレートを容量問題に変えることがあります。可用性アラームは、ユーザーが既に失敗している後でしか発火しないことがあります。ボリューム検出器は、再試行を有効と分類しながら、その集約効果が復旧を妨げることがあります。

公開説明は、エンジニアが追加の配信容量と、さらなる対応が必要な場合にボリューム緩和システムから DNS クエリに応答する能力を準備したと述べています。[2] どちらのステップも自動復旧前に実際に適用されたか、どの閾値でトリガーされたか、容量がフィードバックループを断ち切ったかは述べていません。

これは制御の区別です。

検出は何かが間違っているかに答える。
診断はメカニズムを特定する。
封じ込めは有害なフィードバックを制限する。
復旧は有効な解決を回復する。
検証は外部ユーザーと依存サービスが復旧したことを示す。

高速なアラームは弱い封じ込めを正当化しません。自動復旧は、サービスがより長いまたは繰り返される急増から確実に復旧できることを証明しません。

復旧は設計目標を超えた

Microsoft が復旧が設計目標を超えたと述べたことは、数値目標を開示せずに内部基準を明らかにするため、異例に有用です。[2][5]

この声明は4つの疑問を提起します。

第一に、設計目標は何を測定していたのか。権威回答の可用性、自動復旧までの時間、運用者介入までの時間、またはエンドツーエンドのサービス復元を指す可能性があります。これらは互換ではありません。

第二に、どのメカニズムがそれを達成すると期待されていたのか。キャッシュは負荷低下とともに回復するかもしれません。エニーキャストサイトは撤退するかもしれません。容量が追加されるかもしれません。緩和ルールが変わるかもしれません。制御所有者とトリガーがなければ、「設計目標」は願望のままです。

第三に、目標は複合障害に対してテストされたのか。通常の負荷テストは健全なキャッシュ効率でクエリ容量を測るかもしれません。キャッシュテストは同期した再試行を含まないかもしれません。ボリューム緩和テストは敵対的パケットをモデル化しても、有効な再試行を無制限に許可するかもしれません。2021年のイベントはそれらの条件を結びつけました。

第四に、修復はどう検証されたのか。Microsoft は、要求をキャッシュ内で効率的に処理できるようにするコード欠陥の修復と、異常トラフィックの自動検出と緩和の改善を挙げました。[2][4] 作業項目のリストは完了の証拠ではありません。

適切なクローズアウトは、各対策をテストに結びつけるはずです。

対策	必要な証拠
キャッシュ欠陥の修復	トリガーシーケンスの再現テスト、修復前後のキャッシュ効率、コードおよびデプロイ識別子
再試行保護	制御された再試行ワークロード、正当な回答の保持、偽陽性率、ロールバック閾値
異常検出	クエリクラス別の検出遅延、感度、誤警報の証拠
エッジ容量	キャッシュ効率低下時のエッジ別飽和余裕
自動復旧	繰り返しの障害注入実行と復旧時間分布
サービス復旧	リゾルバーネットワークをまたぐ代表的な Microsoft および顧客名の外部プローブ

この証拠がなければ、読者は Microsoft が何を改善しようとしたかは知ることができますが、どれだけのリスクが除去されたかは知ることができません。

SLA はインシデント証拠の代替ではない

Azure は DNS ゾーンに関する SLA を公開しています。現行文書は、指定された契約条件下でのサービス可用性と潜在的なサービスクレジットを定義しています。[13] 今日の法的および商業的境界を特定するのに有用です。

2021年のどの契約が適用されたか、特定の顧客が請求条件を満たしたか、測定されたダウンタイムが閾値を超えたか、Microsoft に法的責任があったかを確立するものではありません。このパケットの公開情報源には、顧客固有の請求、規制当局の決定、裁判所の認定は含まれていません。

SLA は顧客被害よりも狭い対象を測定することもあります。DNS 可用性の計算は、遅延したアプリケーション復旧、ステータスページへのアクセス、運用人件費、リゾルバーが回答を得られなかったために失われたトランザクションを捉えないかもしれません。逆に、顧客のサービス困難の報告が自動的に SLA 違反を証明するわけでもありません。

したがって説明責任の記録は3つの台帳を分離すべきです。

技術的可用性：権威および再帰システムが何を返したか。
顧客影響：どの機能が、誰に対して、どれだけの時間失敗したか。
契約上の救済：どの条件、測定、請求手続きが適用されたか。

これらを混同すると、責任を誇張するか被害を過小評価します。したがって、1つの指標をインシデント全体として選ぶよりも、限界の方が重要です。

顧客はアーキテクチャを管理していたが、Azure の欠陥は管理していなかった

現在の Azure 信頼性ガイダンスは、プロバイダーと顧客の責任を説明しています。Azure は DNS プラットフォームを運用し、顧客はゾーン、レコード、委任、一部の回復力の選択を構成します。[8][12]

顧客は有用な措置を取ることができます。

Azure 外部のリゾルバーとネットワークから重要な名前を監視する。
どの制御経路とユーザー経路が Azure ホストゾーンに依存しているかを棚卸しする。
TTL を意図的に選択する。
解決失敗時のアプリケーション挙動をテストする。
緊急アクセスと通信経路を保持する。
その複雑さを正当化するシステムについて権威プロバイダーの多様化を評価する。
使用する場合は DNSSEC と委任操作を理解する。

これらの制御は、Azure のキャッシュ欠陥の責任を顧客に移すものではありません。顧客はエッジ実装を検査できず、ボリューム分類を変更できず、プロバイダー容量を追加できません。また、1つのアーキテクチャが普遍的に正しいと言われるべきでもありません。

マルチプロバイダー権威 DNS は1つの共通モードを減らせますが、ゾーン同期、委任、DNSSEC、アクセス制御、フェイルオーバーのリスクを追加します。RFC 9199は、1つの必須設計ではなく文脈を強調します。[14] ルーティング、レジストラアクセス、自動化、運用スタッフを共有する第2のプロバイダーは、重要な点で独立していないかもしれません。

関連する顧客決定は、文書化されたリスク受容です。

サービスが生き残らなければならない名前解決失敗はどれか。
実際に独立している故障ドメインはどれか。
委任またはプロバイダー状態はどれだけ速く変更できるか。
フェイルオーバーが作り出す可能性のある古いまたは矛盾した状態は何か。
変更を実行し元に戻す権限を誰が持つか。
実際のユーザーネットワークから経路が機能することを証明するテストは何か。

顧客の回復力は防御の一層です。基盤運用者が自らの欠陥と緩和挙動を未測定のままにしておく言い訳ではありません。

責任は管理権限と証拠アクセスに従う

公開記録は管理に基づく割り当てを裏付けます。

Azure DNS エンジニアリング

Azure DNS エンジニアリングは、権威サービス、キャッシュ実装、エッジ展開、トラフィック整形、ボリューム緩和ロジック、復旧自動化を管理していました。クエリ分布、キャッシュ指標、サーバー状態への最良のアクセスを持っていました。その義務はすべてのクエリ急増を防ぐことではありませんでした。1つのキャッシュ欠陥が正当な再試行に過負荷を持続させないように劣化挙動を設計・テストし、何が起きたかを示す証拠を保持することでした。

Microsoft インシデント管理

インシデント管理はエスカレーション、調整、公開コミュニケーションを管理しました。予備的な「急増」更新と後日のキャッシュ欠陥説明の違いは、記録が何が変わったかを示していれば調査中は合理的です。最終報告を最初から判明していたかのように提示するのではなく、仮説、証拠、是正措置のタイムスタンプ付きシーケンスを保持すべきです。

Microsoft サービス所有者

Azure、Dynamics、Xbox Live、Microsoft 365、関連する制御面を運営するチームは、依存関係設計と外部監視を管理しました。DNS 欠陥を管理していませんでしたが、重要な名前、ステータスページ、復旧ツールが同じ権威経路を共有しているかどうかを特定できました。

再帰リゾルバーとクライアント運用者

リゾルバーとクライアント開発者は、再試行間隔、キャッシュ挙動、失敗処理を管理しました。RFC 4697は、再試行の規律が長年認識されてきた共有責任である理由を示しています。[20] 記録はどの実装が最も多くのトラフィックを生成したかを特定していないため、特定の運用者を非難すべきではありません。完全な事後分析は、エコシステムが有害なパターンを修復できるように集約分布を提供します。

顧客

顧客は一部のゾーン、TTL、監視、プロバイダー多様化の選択を管理しました。その責任は、サービスの重要度、利用可能な契約オプション、独立 DNS の実現可能性に依存します。Azure のエッジキャッシュや緩和分類器を修正するために必要な情報や権限を持っていませんでした。

この割り当ては非対称です。管理と証拠が非対称だったからです。Azure は中心的な運用証拠と、失敗しているサービスを変更する手段を握っていました。

反事実はどの制御が重要かを示す

反事実分析は、トリガー、寄与条件、修復を分離するのに役立ちます。

異常な急増がキャッシュ欠陥なしに発生していたら

Microsoft は通常のキャッシュとトラフィック整形が急増を緩和するだろうと述べました。[2][4] その声明が正しければ、サービスはより高いキャッシュ効率とより低いクエリあたり作業を維持できたはずです。これにより欠陥は背景のバグではなく寄与条件または根本原因候補になります。

キャッシュ欠陥が急増なしに現れていたら

サービスには低下した効率を吸収する十分な余剰容量があったかもしれません。その場合、急増がトリガー条件になります。公開記録は余裕を明らかにしていないため、1つの要因を全体の根本原因とするよりも相互作用の方が防御可能です。

再試行が直ちに境界付けられていたら

フィードバックループは弱まったかもしれません。しかし広すぎる再試行フィルターは正当な復旧トラフィックを拒否した可能性があります。正しい制御は、代表的な有効要求を保持し、低い偽陽性率を示す必要があります。

すべてのリゾルバーが古い回答を提供していたら

一部の安定した名前は到達可能を保てたかもしれませんが、コールドキャッシュのユーザーと変更されたレコードは依然として失敗します。普遍的な古いデータ提供は安全でない状態を保持する可能性もあります。これは完全な反事実的修復ではありません。

顧客が2つの権威プロバイダーを使用していたら

委任、ゾーンデータ、DNSSEC、ヘルスポリシーが調整されていれば、一部の名前は独立した経路を保持できたかもしれません。他の共有依存関係やリゾルバー挙動は依然として失敗する可能性があります。多様化は検証可能なアーキテクチャであり、スローガンではありません。

より多くのエッジ容量が利用可能だったら

容量は飽和を遅らせることができたかもしれません。必ずしもキャッシュ欠陥を除去したり再試行を分類したりはしません。同じフィードバックループを持つより大きなシステムは、後でより大きな規模で失敗するかもしれません。

これらの反事実は層状の結論を裏付けます。最初の急増が事象をトリガーし、キャッシュ欠陥がクエリあたり作業を増やし、再試行挙動が負荷を増幅し、緩和分類がループを断ち切れず、依存関係の集中が影響を伝播し、復旧制御は事業者の設計目標より長くかかりました。

公開証拠が依然として証明できないこと

情報源は有用な輪郭を確立しますが、決定的な内部記録は利用できません。

それらは以下を確立しません。

最初のクエリ急増の発生源、意図、所有。
急増が協調的な攻撃だったか。
クエリ量、パケットレート、クエリタイプ分布。
標的となったドメインとレコード。
故障したキャッシュ実装またはコードパス。
インシデント前、中、後のキャッシュヒット率。
影響を受けた DNS エッジの数または場所。
経路またはエニーキャスト集水域の変化。
どの再帰リゾルバーまたはクライアントが再試行を生成したか。
再試行間隔、同期、増幅係数。
修復前後の正確なボリューム緩和ルール。
サービス別および地域別の影響。
顧客損失、SLA クレジット、法的責任。
修復の完了日と独立した検証。
同じトリガーシーケンスがその後テストされたか。

現在の Microsoft 文書はこれらの歴史的ギャップを埋めることができません。今日のサービスと推奨プラクティスを説明しています。[7]-[13] RFC はプロトコル挙動と運用オプションを定義しています。[14]-[22] 独立報道は声明と症状を保存しますが、Azure の内部テレメトリを持っていません。[2]-[6]

公開詳細の欠如は隠蔽や過失を証明するものではありません。因果的または法的な結論の確信度を制限します。最も強い発見は、Microsoft 自身の説明が内部キャッシュ欠陥、正当な再試行のフィードバックループ、緩和ギャップを特定していることです。Microsoft の管理するサービスを超えた責任の正確な分布は部分的に不明のままです。

修復はシーケンスとして監査可能であるべき

検証可能な修復プログラムは、バラバラの改善リストではなく、共通のインシデントテストを保持するはずです。

再現

関連するクエリとキャッシュ状態のシーケンスに一致する安全なワークロードを作成します。ソフトウェアバージョン、ゾーン形状、レコードタイプ、キャッシュ状態、エッジトポロジーを記録します。修正前のシステムが効率低下を示すことを証明します。

測定

キャッシュヒット率とミス率、クエリあたりコスト、応答遅延、タイムアウト率、キュー深度、エッジ飽和、再試行量を捕捉します。証拠が許す限り、最初のトラフィックと再試行を分離します。

封じ込め

境界付き再試行整形と異常トラフィック制御を適用します。既知の正常な名前、コールドおよびウォームキャッシュ状態、否定回答、DNSSEC 応答、複数のリゾルバー挙動をテストします。偽陽性を測定します。

復旧

外部トラフィックの低下だけを待たずに、設計目標内で権威可用性が回復することを示します。独立ネットワークをまたいでエニーキャストと経路挙動を確認します。

依存サービスの検証

複数の再帰リゾルバーとアクセスネットワークから、代表的な Azure、Microsoft コントロールプレーン、顧客名をプローブします。DNS 復旧とアプリケーション復旧を区別します。

ロールバック

緊急制御に所有者、失効条件、可逆的な構成があることを示します。無期限に残る緩和は新たなサービス拒否源になり得ます。

証拠の保持

テスト結果をコード、デプロイ、構成識別子に結びつけます。機密インフラ詳細を暴露せずに、特定のフィードバックループが除去されたことを示す十分な測定を含む境界付き要約を公開します。

このシーケンスは中心的な問いに答えます。Microsoft が「より多くの回復力」を追加したかではなく、同じキャッシュと再試行の相互作用が依然として障害閾値を越え得るかどうかです。

結論

2021年4月の Azure DNS 障害は、トラフィック量だけで説明されるものではありませんでした。

Microsoft は、異常なクエリ急増が DNS Edge キャッシュ効率を低下させるコード欠陥を露呈させたと述べました。サービスの劣化がクライアントの再試行を引き起こしました。それらの再試行は正当なトラフィックだったため、ボリューム緩和は当初それらを破棄しませんでした。サービスは自動復旧しましたが、設計目標内ではありませんでした。Microsoft はその後、再試行保護を変更し、キャッシュ欠陥を修復し、異常検出を改善すると述べました。[2][4][5]

このシーケンスは、複数の層を持つネットワーク基盤の説明責任問題を特定します。

急増は Microsoft が説明したトリガーであり、証明された攻撃帰属ではありません。
キャッシュ欠陥は作業を増やした内部寄与条件でした。
正当な再試行挙動がリゾルバーと権威の境界をまたいで負荷を増幅しました。
緩和ロジックは当初、その集約的な有効トラフィックを封じ込めませんでした。
共有 DNS 依存関係が1つの解決失敗を多数の見かけ上のサービス障害に変えました。
復旧指標はすべてのユーザーの体験にきれいに対応しませんでした。

責任ある結論は、DNS 再試行が悪い、エニーキャストが失敗した、顧客は常に第2のプロバイダーを使うべき、ということではありません。いずれの主張も証拠を超えます。

より強い基準は測定可能な劣化挙動です。権威 DNS 運用者は、異常なクエリシーケンスの下でキャッシュ効率がどう変わるか、正当な再試行が容量にどう影響するか、どの緩和が有効な回答を保護するか、エニーキャスト集水域がどう応答するか、どの外部プローブが復旧を証明するかを知るべきです。リゾルバーとクライアント運用者は再試行とキャッシュ挙動を境界付けるべきです。サービス所有者は重要な命名依存関係を特定し、独立したインシデント通信を保持すべきです。顧客は実際に制御できる継続性の決定をテストすべきです。

記録、サービス説明、ステータス通知は証拠の一部です。稼働中のサービスではありません。2021年4月1日、名前は正しく設定されたままでありながら、ユーザーはそれらを確実に解決できませんでした。説明責任は、その2つの状態が分かれるところから始まります。

最終的な証明は、実際の修復に結びついた再現可能なテストです。シーケンスを再現し、キャッシュ効率を測定し、境界付き再試行を誘発し、緩和を有効化し、既知の正常な回答を保持し、設計目標内で復旧し、独立したネットワークから結果を確認します。その証拠がなければ、一般にはもっともらしい説明があるだけです。それがあれば、運用者はフィードバックループが閉じられたことを示せます。

要約