要約
- GoDaddyによれば、障害は2025年12月12日21時20分GMTに始まり、誤実行したコマンドを検知して取り消した後、21時28分GMTに復旧した [1]。
- 同社は全てのGoDaddy権威DNSサービスが影響を受け、新規の権威問い合わせが必要な利用者では一時的に失敗したと説明した。キャッシュ済み回答が影響を緩和した場合もあった [1]。
- 公開説明には、コマンド文字列、承認経路、対象プレフィックス、Anycastノード数、失敗問い合わせ数、設定ハッシュは示されていない。これらを推測で補うべきではない。
- IETF文書はAnycast、権威DNS、TTL、複数地点からの監視を説明するが、本件で非公開の制御機構を特定する証拠ではない [2][3][4][5]。
- 重要な統制は、操作対象と除外範囲を固定し、独立審査と限定的なcanaryを通し、外部の経路・DNS観測で効果を確認し、別途審査された手順で元の状態を復元することである。
事実の境界を固定する
本稿が扱うのは2025年12月12日のGoDaddy権威DNS Anycast障害であり、2012年に発生した別のGoDaddy DNS障害ではない。日付も公開記録も運用上の境界も異なるため、一方の原因や対策を他方に当てはめてはならない。
GoDaddyは12月15日に技術説明を公開した。同社が明示した事実は、コマンドが誤って実行されたこと、Anycastアクセスが8分間途絶えたこと、全権威DNSサービスが影響を受けたこと、コマンドを検知して取り消したこと、ネットワーク復旧後にルーティングテーブルが更新され、リゾルバが再び権威サーバーへ到達できたことである [1]。
一方、説明は操作対象を特定していない。BGPポリシー、オーケストレーション状態、サービスヘルスとの連動、共有プレフィックス、その他の制御のどれを変更したのかは公開されていない。対象プレフィックス、ノード、AS、地域、ドメイン数、問い合わせ失敗率、承認記録、変更前後のハッシュも示されていない。
この不足は、特定の統制が存在しなかったことや個人の過失を証明しない。公開分析が責任を持って述べられる範囲を定める。事故固有の記述はGoDaddyの発表に帰属させ、標準文書は検証すべき一般的な問いを組み立てるためだけに使うべきである。
権威DNSとAnycastは別の状態である
権威DNSは、委任された名前について決定的なレコードを提供する。再帰リゾルバが有効なキャッシュを持たない場合、権威サーバーへの問い合わせが必要になる。RFC 1034はTTLがキャッシュ保持時間を制限することを説明している [4]。したがって同じ8分間でも、既存回答を持つ利用者と新規回答を必要とする利用者では体験が異なる。
Anycastはサービスへの経路を分散する仕組みである。RFC 4786では、同じサービスアドレスへの到達性を複数の離れたノードから広告し、ルーティングシステムがそのうち一つへ要求を運ぶモデルを示す [2]。DNSデータの正しさ、サーバーの健全性、サービスアドレスの広告状態は、関連していても同一ではない。
ゾーンデータが正しくても経路が消えることがある。ノードが回答可能でも広告が失われることがある。広告が残っていてもサービスが応答できないことがある。操作の影響を説明するには、記録された変更と稼働中の経路、そして実際の権威問い合わせを同じ時間軸で結ぶ必要がある。
GoDaddyは「権威ドメイン名サービスへのAnycastアクセス」が中断し、復旧時にルーティングテーブルが更新されたと述べた [1]。到達性が中心だったことは確認できるが、全てのBGP広告が撤回されたことや、具体的な制御対象までは確認できない。
グローバル操作には厳密な対象IDが要る
高リスク操作の対象を単に「DNSネットワーク」と記録するのは不十分である。申請時の人間向けセレクタは、サービスアドレス、プレフィックス、ノード群、経路ポリシー、設定リビジョンへ展開し、機械的に比較できる集合として固定すべきである。その集合が審査後に変われば、承認は失効しなければならない。
範囲の証明には除外も含まれる。試験ノード一台が対象なら、本番ノードとグローバル用プレフィックスが含まれないことを示す。地域限定操作なら、他のcatchmentが広告を維持し、正しい権威応答を返し続けることを確認する。
コマンド文字列だけでは十分ではない。別名、タグ、動的グループ、生成設定は実行時に予想以上へ展開し得る。審査すべきものは、展開済み対象、現在状態、変更差分、期待される経路効果であり、後から意味が変わる名称ではない。
グローバル操作自体が常に不適切というわけではない。重大事故では複数広告を同時に制御する必要がある。しかし範囲が広いほど、独立承認、事前計算したロールバック、明確な停止条件、複数地点の外部プローブ、限定ノードから始める可逆canaryが必要になる。
ノードの多さは独立性を保証しない
Anycastは地理的分散を可能にするが、共有制御が本当の障害ドメインになり得る。同じセレクタ、ポリシー生成器、資格情報、オーケストレーション操作が全ノードを同時に変更できるなら、拠点数はその共通操作への耐性を生まない。
RFC 4786はサービス可用性と経路広告の連動、共有するカバープレフィックスの危険、観測地点によって可用性が異なる難しさを扱う [2]。独立性は構成図の箱の数ではなく、現実の障害遷移で証明される。
安全な試験では、一つのノードまたは経路群を外し、他の地点から正しい権威応答が継続することを確認する。自動復旧が局所障害を全体へ拡大しないこと、複数サービスが同一プレフィックスを共有する場合に一サービスの不具合で全体が撤回されないことも検証する。
セレクタの展開は隔離環境で事前に再現できる。本番では限定したcanaryに可逆変更を行い、複数ネットワークから合成DNS問い合わせを続ける。他のcatchmentが安定している場合だけ、次の範囲へ進むべきである。
キャッシュは見え方を変えるが、権威サービスを置き換えない
GoDaddyは、キャッシュによって影響が主に新規検索を必要とする利用者に限られたと説明した [1]。TTL、過去の問い合わせ、再帰リゾルバ、OS、ブラウザの状態が異なるため、権威障害が全サイトの一斉停止として見えないことはあり得る。
ただしキャッシュは可用性保証ではない。新しい名前は未キャッシュであり、レコードは障害中に失効し得る。RFC 8767は一定条件で期限切れデータを返す再帰側の仕組みを定義するが、導入と方針はリゾルバごとに異なる [5]。本件のどの利用者がその恩恵を受けたかは、このRFCからは分からない。
指標は、権威問い合わせ成功率、サービスアドレス到達性、キャッシュ回答、最終的なアプリケーション到達性を分けるべきである。キャッシュが症状を緩和しても、権威プラットフォームが稼働していた証拠にはならない。
復旧にも複数の時計がある。設定が戻り、経路が収束し、リゾルバが再試行し、アプリケーションが回復する。GoDaddyの21時28分という時刻に加え、各地点の実問い合わせがいつ安定したかを分布として保存する必要がある。
台帳と稼働ネットワークを突き合わせる
インベントリ、ポリシーリポジトリ、配備システムは、承認済み対象や所有者、意図した状態を保つ重要な台帳である。しかし台帳は稼働ネットワークそのものではない。承認済みセレクタが実行時に誤展開する場合も、APIが成功しても経路効果が誤る場合もある。
一つの変更IDに、申請、対象集合ハッシュ、差分、審査者、実行結果、ノード別経路状態、外部DNS問い合わせ、ロールバック状態を結び付けるべきである。共通時刻を使えば、コマンド、経路変化、問い合わせ失敗の順序を再構成できる。
実行証拠は何を試みたかを示し、効果証拠は何が起きたかを示す。クライアントが応答を失った場合、操作が部分的に実行済みかもしれない。冪等キーと稼働状態で照合する前に再送してはならない。
ロールバックも二つ目のコマンドだけでは終わらない。以前の設定、期待した広告、正しい権威応答、外部プローブの安定を確認し、残差を明記する。設定と公開サービスの双方が戻って初めて完了といえる。
実行可能な証拠パッケージ
実行前には、サービスへの影響、対象アドレスとノード、地域・グローバル分類、共有プレフィックス、現在状態、変更差分、独立審査、canary、停止条件、検証済みロールバックを凍結する。対象集合が変われば再審査する。
実行中には、認証済み主体、API要求の正確なバイト列、冪等キー、各対象の応答、設定リビジョンを追記専用で保存する。同時に外部から経路、応答コード、内容、遅延、catchment変化を観測する。変更資格情報に監査記録を書き換える権限を与えない。
実行後には、複数地域・複数ネットワークから権威アドレスへ直接問い合わせる。管理された未キャッシュ名または短TTL名を使い、キャッシュが権威障害を隠さないようにする。内部ヘルスが正常でも外部到達性が不一致なら、障害を閉じない。
再発防止試験は少なくとも、単一ノードを外しても他ノードが継続すること、意図的に広すぎるセレクタが実行前に拒否されること、実行応答を失っても重複操作せず状態を確定できることを扱う。対象ハッシュ、経路観測、DNS結果、警報、復元結果を一つの記録に残す。
公開説明は機密を守りながら具体化できる
GoDaddyの発表は、日付、時間、対象サービス、操作の種類、利用者影響の仕組み、復旧、改善の分類を示した [1]。一般的な「問題は解決した」という通知より有用である。さらに、コマンド構文や資格情報を公開せずに統制の改善を説明できる。
例えば、操作が共有グローバル対象に届いたか、canaryと上限があったか、検知が内部警報か外部問い合わせか、ロールバックが事前承認済みだったか、再発試験が一つの操作で全ノードを失わないことを証明したかを示せる。「改善予定」と「試験済みの統制」は分けるべきである。
権威DNSは多数の独立したドメインに共通する基盤であり、利用者は内部の経路制御を直接監査できない。範囲を限定した公開記録は、機密トポロジーを漏らさずに障害種別と改善の実効性を評価できる材料となる。
責任の境界
GoDaddyは発表対象の権威プラットフォームと、誤実行したとするコマンドを管理した。再帰リゾルバ、アクセス網、ブラウザ、OSは下流のキャッシュと再試行を管理した。グローバル経路が両者を接続した。この境界は影響のばらつきを説明するが、起点となる制御の所有を消さない。
運用者の責任は、操作を意図した対象に限定し、想定外の到達性喪失を検知し、検証済み状態へ戻すことである。リゾルバはキャッシュやserve-staleで耐性を高められるが、到達可能な権威サーバーを無期限に代替できない。
結論は非難ではなく証拠にある。Anycastは独立した到達可能ノードを制御が維持するときだけ分散となる。キャッシュは有効な回答が残る間だけ症状を緩和する。グローバル操作は、対象、差分、承認、効果、復元を一つの監査記録に固定し、稼働ネットワークで試験して初めて信頼できる。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加