Cloudflare 1.1.1.1 停止と経路撤回の責任分析

要約

Cloudflare は 2025年7月14日 21:52 UTC から 22:54 UTC まで、1.1.1.1 のパブリック再帰 DNS サービスが世界規模で利用不可だったと報じている。影響を受けたのは大半のユーザーで、Gateway DNS でも断続的な劣化が発生した。直接の要因は、攻撃や DNS プロトコルの欠陥ではなく、内部トポロジー変更後に本番プレフィックスが撤回されたことだった [1]。
因果の発端は6月6日で始まっている。将来用に用意されていた Data Localization Suite の設定が、まだ本番稼働していないにもかかわらず、誤って 1.1.1.1 Resolver のサービスとそのプレフィックスを参照した。変化が即座にトラフィックに反映されなかったため、記録自体は表面上は静かなままだった [1][8]。7月14日、この未運用のサービスにテスト拠点を追加したことで、全世界リフレッシュが走り、本番拠点の大半ではなく 1 か所のオフライン拠点へトポロジーが縮退し、ルート撤回が起きた [1][8]。
Cloudflare は影響を受けた IPv4/IPv6 プレフィックスとして 1.1.1.0/24、1.0.0.0/24、2606:4700:4700::/48 と関連するリゾルバーアドレス帯域を列挙した。UDP、TCP、DNS over TLS のトラフィックは急落した。DNS over HTTPS は比較的安定したままである利用者が多く、これは cloudflare-dns.com が別のアドレス群を使っていたためである。エンドポイントと経路選択、つまりサービス名そのものではなく、到達経路の境界が停止範囲を決めた [1][16][17]。
アラートは発火し、22:01 にインシデントが宣言された。Cloudflare は 22:20 に設定をロールバックした。ルート再広告によりトラフィックは約77%まで回復したが、約23% のエッジサーバでは必要な IP バインディングがすでに削除済みだった。完全復旧にはバインディング復旧が必要であり、22:54 に回復を報告している [1]。
Cloudflare の撤回後、1.1.1.0/24 のための Tata Communications India の起点アナウンスが可視化された。Cloudflare はルーティング視点ではハイジャックのように見えたと説明したが、サービス停止の原因ではないと明言している [1][3][18][19]。起点正当性と経路監視は証拠として有用だが、権限を持つ事業者が必要な拠点からプレフィックスを広告し、DNS 問い合わせに回答していることをそれ自体で保証するものではない。
Anycast は 1 つのサービスアドレスを複数拠点から配信する。RFC 4786 はそのレジリエンス価値と監視の複雑さを説明する。7月の事象は Anycast 自体が本質的に不安全であることを示すものではなかった。むしろ、一つの誤ったサービス対プレフィックス記録が、システムにゼロ稼働拠点を許してしまうため、全世界のキャッチメントを消し去り得ることを示した [9][12][13]。
説明責任は、プレフィックス対サービス台帳、レンダリングされたトポロジー、全世界更新、ルートアナウンス、エッジバインディング、アラート設計、ロールバック権限、サービス復旧の証拠という実務制御に依存する。チケットや意図した設定は意図の証拠であり、実行中のルートと完了した DNS 応答が現実の証拠になる。
Heng.lu ドクトリンでは、IP プレフィックスとトポロジー記録は一意性、正確性、セキュリティメタデータ、運用継続性を保持すべきである。これらは台帳であってネットワーク運用を代替する主権的権限ではない。DNS、IP プレフィックス、Anycast、BGP、エッジバインディングの事実がなければ、ネットワークインフラ観点の主張は崩れるため、この論理は装飾ではなく中核である。

リゾルバーは DNS 質問を処理する前に失敗しうる

利用者が DNS 障害を説明するとき、自然に思い浮かぶのは「リゾルバーが名前を受け取ってアドレスを返せない」場面である。これは起こり得る失敗ではあるが、Cloudflare の 2025年7月障害の最初の失敗ではなかった。

クライアントはリゾルバーのサービスアドレスに到達したときだけクエリを送信できる。1.1.1.1 の場合、それらのアドレスは Anycast ネットワークを介して配信される。Cloudflare の複数拠点が同じプレフィックスの到達可能性を広告し、インターネットルーティングがそのいずれかへ経路を選ぶ。リゾルバーソフトウェアはその後、キャッシュエントリを用いるか権威 DNS サーバへ問い合わせて再帰処理を行う [5][6][12]。

7月の停止は、この前段階で発生した。Cloudflare の本番拠点が関連プレフィックスの広告を停止した。1.1.1.1 のアドレス宛てに送られたトラフィックは、回答を担うエッジに届かなかった。リゾルバーがまずドメイン名を誤解したわけではない。ネットワーク側が「そのリゾルバーはどこに存在するか」を誤ったのである [1]。

この区別が重要なのは、制御対象のシステムを特定できるからだ。

DNS 実装チームは再帰、キャッシュ、DNSSEC、リトライ、応答正確性を検証できる。しかし、それはサービスアドレスが経路上に残ることを保証しない。ネットワークチームは BGP のアナウンスやエッジインターフェースを観測できるが、リゾルバー処理が回答することは保証しない。サービス・トポロジーシステムはどの製品がどのプレフィックス・拠点を使うかを記録できる。記録はコンパイル後のルート状態やエッジバインディングが意図どおりかを保証しない。

サービスが成立するためには、次の層が一致しなければならない。

サービス ID が正しいプレフィックスに紐づいていること。
意図した本番拠点がサービスに紐づいていること。
ルート生成システムが、意図した拠点からこれらプレフィックスを広告すること。
エッジシステムが、トラフィック受け取りに必要な IP バインディングを保持すること。
リゾルバー処理が該当トランスポートを受け付け、問い合わせを完了すること。
監視が整合不一致を十分に早く検知し、制御可能な復旧に結びつくこと。

Cloudflare のポストモーテムでは、この不一致が最初の2層から始まり、次の2層へ拡大している。未公開のオブジェクトが本番リゾルバープレフィックスへの参照を取得した。後続のリフレッシュで、その関連付けがルート撤回へ変換された。複数のエッジサーバが必須バインディングを削除した [1]。

この結果を「DNS ダウン」と呼ぶのは理解しやすいが、制御分析としては粗すぎる。障害の種類は、ネットワークインフラにおけるアイデンティティと到達性の問題である。どのサービスがどのアドレスを所有し、どこから到達可能で、記録からどのルート状態が導かれ、どの実体/ソフトウェアでトラフィックを受けるか、という問いである。

そのためステータスダッシュボードだけが単独の証拠にならない。ダッシュボードは DNS 要素が稼働しているように見えても、重要なルーティングビューにプレフィックスが存在しない場合がある。ルートコレクタはプレフィックスを報告しても、その背後に健全なリゾルバーがいないことがある。プロセス監視でデーモンが正常でも、パケットが到達していないことはあり得る。説明責任は、これら単体指標のうちどれか一つの緑ランプではなく、状態間の照合にある。

未活性化のエラーはすでに本番リスクだった

Cloudflare は設定エラーの導入を 2025年6月6日と特定している。会社は将来用の Data Localization Suite サービスのサービス間トポロジーを準備中であった。新規サービスは本番運用ではなかったが、その設定に誤って 1.1.1.1 Resolver サービスと、そのプレフィックス参照が含まれていた [1]。

その時点では外部から見える事象はなかった。ルート変更なし、トラフィック移動なし、アラートなし。記録は本番設定環境に残るだけで、即時の影響を生じなかった。

この静かな期間は、記録が無害だったという証拠ではない。システムがまだその記録を行使していなかったことの証拠に過ぎない。

設定システムには未稼働、段階待ち、将来日付、無効、オフライン拠点付きのオブジェクトが存在しうる。運用上は必要な状態だ。計画中サービスは有効化前に表現される。問題は、眠っているオブジェクトが競合チェックなしに本番重要リソースを参照でき、後続の操作で全世界ネットワークをその基づいて再構成してしまうときに顕在化する。

したがって、考えるべきは「6月の変更がトラフィックを変えたか」だけではない。「6月の記録はどの程度の権限を獲得したか」である。

その記録が将来更新で本番プレフィックス所有を左右しうるなら、サービスがオフラインの間でも本番リスク境界を越えている。レビュー担当または自動バリデータは、その潜在的効果を理解する必要があった。即時のトラフィック変化がなかったため、通常のヘルスアラートは機能しにくい。事象は状態整合性の欠陥であり、まだサービスヘルス欠陥ではなかった。

適切な制御プレーンは次の問いに答えられるべきである。

どのサービスが各本番プレフィックスの権威ある所有者か。
同一プレフィックスを二つのサービスオブジェクトが参照してよいのか。
許可する場合、結果の拠点集合はどのルールで決まるのか。
非本番サービスが本番サービスのグローバルトポロジーを縮小できるか。
次にこのレコードをどの操作がコンパイルまたはリフレッシュするか。
その操作でレンダリングされるルート・エッジバインディング変更は何か。
世界的サービスがゼロの生存拠点に落ちることを防ぐ不変条件は何か。
公開の重要アドレスへの環境横断参照は誰が承認するか。

これらは装飾ではない。各問いは決定的なチェックとして実装可能だ。

プレフィックス所有テーブルは単一の権威あるサービス識別子を要求できる。トポロジコンパイラは展開前に有効拠点集合を算出できる。ポリシーはゼロ生存拠点出力を拒否できる。変更プレビューは非本番オブジェクトが影響する本番プレフィックスを一覧表示できる。独立監査者は意図された出力と現在の広告ルートを比較できる。

Cloudflare の現行 Data Localization ドキュメントは、トラフィック処理地点を制御する必要性を述べる。地理・コンプライアンス向け製品を説明しているが、2025年6月と7月の六月モデルの内部データ設計や制御の全容は直接証明しない [8]。ポストモーテムが機構説明の一次情報であり、現在のドキュメントは設計意図の背景を与えるに留まる。

この事実境界は重要である。公開記録から個別スキーマやデータベース、デプロイーツールを推定しやすいが、実務上の証拠はそうした推定を要件にしない。必要なのは、将来/未使用サービスが黙って本番リゾルバーのプレフィックス権限を取得しないという運用要件を明記し、それを検証可能にすることだ。

全世界リフレッシュが記録を実行ルート状態へ変換した

7月14日、Cloudflare は非本番サービスにテスト拠点を追加した。追加された拠点自体は生存していなかったが、この変更が全世界のネットワーク設定リフレッシュを引き起こした。6月の記録で 1.1.1.1 プレフィックスがそのサービスに紐づいていたため、リフレッシュ時に同プレフィックスが含まれた。結果として、リゾルバーの有効トポロジーは全本番拠点から 1 つのオフライン拠点へ縮退し、プレフィックスが撤回された [1]。

この連鎖は、変更の影響範囲を入力規模ではなくレンダリング結果で評価すべきことを示す。

入力は「非本番サービスへテスト拠点を1件追加する」と記述できる。出力は公開 DNS の主要サービスと複数の IPv4/IPv6 プレフィックスを変化させる。どちらも矛盾しないが、二つ目が運用リスクを示す。

インフラ自動化はしばしば短い宣言を多数のルータ、サーバ、拠点向けルールに拡大する。自動化の効率がある一方で、レビューはその拡大を可視化する必要がある。

この種の変更で必要な事前プレビューは少なくとも次を示すべきだ。

実際に有効トポロジーが変化するすべてのサービス。
追加、削除、再割当が起きるすべてのプレフィックス。
各プレフィックスごとに広告が開始・停止するすべての拠点。
追加または削除されるすべてのエッジバインディング。
影響を受けるすべてのプロトコルエンドポイント。
残存生存拠点数の最小値。
想定される BGP アナウンス差分。
想定される DNS 問い合わせ分布差分。

プレビューはデプロイと同じコード・データ経路から計算されるべきである。別ロジックでの要約は、実コンパイラの結果と食い違う可能性がある。運用上の優先は、レビュー対象は実行候補そのもの（レンダリング済み結果）であるべきで、人手説明の要約だけではない。

同じ原理はカナリアにも適用される。小さな第一段階は、失敗モードを実際に行使する場合のみ有効である。オフラインサービスへのテスト拠点追加は、顧客トラフィックが期待されないため安全に見え得る。しかしその操作が全世界更新とプレフィックス関連付けロジックを起動するなら、カナリアはその全域出力を観測すべきだ。オフライン拠点でのローカル接続テストでは決定的な効果を取りこぼす。

この7月の事例は、しばしば使われる「非本番変更」という短縮語を問い直す。

オブジェクトが顧客利用上は非本番でも、メタデータが本番コンパイラに参加し得る。拠点がオフラインでも追加されることで全域再計算が起きる。サービスが実ユーザーを持たなくても、プレフィックス関連が広く使われるリゾルバーを変更しうる。環境ラベルそのものが境界を定義しない。データ流とデプロイ権限が境界を決める。

これは全てを即座に顧客障害扱いすることを意味しない。組織は、変更が何を変える権限を持つかで分類すべきである。非本番オブジェクトが本番プレフィックス参照を持つなら、ローカルなテストだけのオブジェクトより高リスクカテゴリに分類される。

その分類の証拠は限定的で済む。変更チケットは影響を受けるコンパイラ名を示せる。機械生成プレビューは本番資源の一覧を提示できる。ポリシー結果は不変条件チェックを記録できる。カナリア報告はルートとサービス観測を示せる。広い「運用と本番分離」が効いているという抽象的安心より、維持されたファイルの方が有効である。

Anycast はサービスを分散し、制御誤りを集中させた

Anycast は一般にレジリエンス技術として説明される。同一アドレスが複数拠点から提供され、ルーティングが利用者をいずれかへ誘導する。RFC 4786 はこのモデルを示し、利用者位置とルーティングキャッチメントにより可観測性が複雑化することを示している [12]。

Cloudflare は 1.1.1.1 を含めて広く Anycast を使用している。現行ドキュメントと公開ネットワーク資料は、アドレス空間をネットワーク全体で発信する分散サービス構成を説明している [4][5][9][10][11]。

7月の停止は、Anycast の設計不備として読むべきではない。設計は複数の潜在拠点を提供するが、設定システムはそれらの到達可能性を同時に失わせた。

ここで分かれるのはデータプレーンの冗長性と制御プレーンの独立性である。

同一アドレスを多数拠点で提供できるが、誤った全域トポロジー記録をすべてが共有すれば、拠点数だけではその記録への独立防御は生まれない。拠点分散は地理的だが、制御上は共通障害モードとなる。

関連するレジリエンスの問いは以下のとおりである。

単一のサービス対プレフィックス対応が任意の Anycast ノードをすべて除去しうるか。
重要プレフィックスに対して不変な最小存在ルールを不変条件として持てるか。
グローバル変更は複数の独立監視点で成功検証を通過する必要があるか。
制御プレーン不確実時に一部拠点で最終的な広告状態を維持できるか。
緊急復旧が同一トポロジーコンパイラに依存せず可能か。
エッジバインディングは、ルートとサービス検証が一致するまで自動削除されないのか。

どれも単一の正解はない。古い経路の放置は壊れたサービスへ誘導し得る。逆に自動撤回の全面禁止はセキュリティや保守運用を阻害する。最小存在条件が残る拠点の健全性を伴わなければ、別の事故につながる。制御は到達性とサービスヘルスを対立なく両立させる必要がある。

このトレードオフゆえ、経路とサービス状態の双方を証拠として扱うべきである。

ルート広告は「インターネットが演算子側へパケットを送れる可能性」を示すが、意図されたアプリケーションが正常であることは示さない。リゾルバーのヘルスチェックはある一地点で処理可能であることを示すが、他地域のユーザーが到達できるかは示さない。トポロジー記録はシステム意図を示すが、ルータとエッジホストの実装結果は示さない。

グローバルリゾルバーの受理条件は、たとえば次の通り複合的である。

意図したサービスが、定義された健全な本番拠点集合を少なくとも一定数維持すること。
必要プレフィックスが独立したルートコレクタと主要顧客ネットワークから可視であること。
ルート終端する地点でエッジバインディングが存在すること。
UDP、TCP、DoT、DoH の各プローブが代表地域から完了すること。
クエリ量と応答コード分布が許容範囲内であること。

Cloudflare Radar は公開 DNS・ルーティング観測を提供するが、Cloudflare 運営の選択データと同社ネットワーク由来であり、全ユーザーパスを代表しない [2][3]。独立コレクタ、ISP のプローブ、顧客測定を組み合わせると記録は強くなる。重要なのは、同一の構成生成系で生成された外部グラフが障害を「証明」しなくとも、設定外で構成された構成を外部視点から観測できる設計が必要だという点である。

プロトコル経路が実際の影響範囲を示した

Cloudflare は、プレフィックス撤回時に UDP・TCP・DNS over TLS でのリゾルバー問い合わせ数が即座に大きく落ちたと報告した。多くの利用者は 1.1.1.1、1.0.0.1、または対応する IPv6 を直接設定しており、これら宛てパケットは Cloudflare の本番サービスへの経路を失った [1]。

DNS over HTTPS は比較的安定していた。多くの利用者は cloudflare-dns.com を用いており、こちらは別のアドレス群を使うためである。別アドレスを使う UDP トラフィックも比較的安定した例があった [1]。

この差分は説明責任上の教訓を含む。

第一に、単一製品は複数の配信経路を持ち、それぞれ依存条件が異なる。ドキュメントや会話ではすべて 1.1.1.1 と呼ばれることがあっても、運用境界は利用者側が使うエンドポイントとアドレス群で決まる。

第二に、多様性は実在し実用可能な場合のみ価値がある。DoH が常に UDP より堅牢であるわけではない。今回、比較的安定を示したのは、ユーザーの多くが異なるアドレス群に紐づくホスト名へ到達していたためである。将来別障害では、同アドレスまたは同ホスト解決経路が影響を受ける可能性がある。

第三に、影響報告は経路を特定して述べるべきだ。「1.1.1.1 がダウンした」は体感範囲を示すが、継続した要求の理由を隠す。「DNS 全体が停止」とは不正確である。ポストモーテムが示すトランスポートとエンドポイントの区別は、実務に有効な記述になる [1][16][17]。

第四に、利用者は障害時に必ずプロトコルを切り替えられるわけではない。文字通りのリゾルバーアドレスを設定した端末は、安全な自動経路で DoH ホスト名へ移行できないことがある。加入者クエリを転送するネットワーク運用者には、契約、プライバシー、性能、ポリシー上の理由で特定エンドポイントを使う必要がある。ドキュメントにフォールバックが書かれていても、ユーザー環境で実配備・許可・検証されていないことがある。

顧客側の説明責任は「なぜ全員が切り替えなかったか」ではなく、「重要顧客がどのリゾルバー依存を理解し、代替経路があり、かつ安全かつポリシー適合した検証がなされているか」という問いになる。

事業者側の問いは、障害前にこうした経路差を整理し、監視と広報に反映したかである。有用な障害告知は、どのアドレスとトランスポートが影響を受け、どれが利用可能か、安全に何ができるか、代替策のリスクは何かを明示する。

証拠として保持すべきは次のとおりである。

エンドポイント別・トランスポート別の問い合わせ率。
代表ネットワークからの到達性。
リゾルバーの成功率、タイムアウト、エラー率。
クライアント再送挙動。
フェイルオーバーや代替リゾルバーの有効化。
代替経路のセキュリティ・プライバシー特性。
経路別の復旧時刻。

これらの記録は、影響境界を検証可能にする。生き残った経路を都合よく使って別障害を矮小化することも防げる。

非関連の起点広告は原因ではなく証拠だった

Cloudflare のルートが減少し始めた後、21:54 に Tata Communications India AS4755 が 1.1.1.0/24 をアドバタイズした [1]。Cloudflare はルーティングシステム上はハイジャックのように見えたとしながら、停止原因そのものではないと明確に述べた。

この区別は維持されるべきである。

ルート撤回は、別の起点を可視化する前提条件を作った。観測上重要なのは、トラフィックがこれまでより低優先か非公開の経路へ移る可能性が生じたことであり、なぜその広告が存在したか、どのように伝播したか、どのルート制御が適用され、どれだけのトラフィックがそこに到達したかという別の問いである。これらは Cloudflare が公表した因果順序を反転しない。

両事象を混同するとドラマチックだが弱い記事になり、対処も誤った制御へ向かう。

RPKI 起点検証（RFC 6811）では、ルータが経路認可データに基づき、AS がそのプレフィックスの正当な発信元かを分類できる。[18] BGP の運用指針はフィルタリングと経路衛生を扱う。[19] これらの制御は一部の未承認起点リスクを低減する。

ただし可用性を保証するわけではない。

Cloudflare の承認済み AS でも経路撤回を行うことがある。正当な経路でも、意図したエッジで作動しないことがありうる。正しい起点でも提示地点が不足すれば機能しない。エッジにバインディングが残っていてもサービス自体が不健全な場合がある。逆に、異常に見えるルートが初期障害とは別の現象であることもある。

この7月事象は、セキュリティメタデータの役割が限定的であることを示す。

ルート起点記録は「この起点がこのプレフィックスを許可されるか」を答えるが、次を答えない。

今このプレフィックスを広告すべきか。
どの本番地点から何台広告されるべきか。
広告は意図したサービスへ到達するか。
エッジバインディングは維持されているか。
リゾルバーの応答は正しいか。
トポロジー変更により承認済み運用者のルートそのものが撤回されたか。

これは Heng.lu ドクトリンにおける台帳と記録の扱いと一致する。台帳は識別、認可、変更履歴を監査可能にするが、宣言でデータプレーンを強制しない。実行されるルートとサービスが最終的に成立する必要がある。

ポストモーテムの明確な非因果記述自体が、良い証拠実務である。インシデント報告は、同時観測と因果鎖を分離し、異常がなぜ見えたか、既知・未確定を明示するタイムラインを示すべきである。これにより、発端障害への対処を進めつつ、新たに露出した経路問題も見失わない。

検出は経路喪失後に始まった

Cloudflare によれば DNS トラフィックの低下は 21:52 に発生し、内部リゾルバーアラートは 22:01 に立ち上がり、その時点でインシデントが宣言された [1]。

9分という間隔は一部の運用では短いが、グローバルリゾルバーでは長く感じられることもある。重要なのは、信号を生んだ出来事である。

6月のエラーはトラフィック変化がないためアラートを発しなかった。7月14日には、ルート撤回後に受信クエリが減少し、リゾルバー・プロキシ・データセンター障害が発生してからアラートが出た。システムは、全域リフレッシュ後に生じた結果を検出した。

運用結果監視は不可欠だが、制御プレーンには事前デプロイ監視と変更相関の信号も必要である。

検出は3層で分離できる。

状態整合性検出

この層はデプロイ前に設定グラフの内部妥当性を確認する。重複プレフィックス所有、本番参照を持つ非本番サービス、ゼロ生存拠点出力、サービス重要度と変更範囲の不一致を検知できる。

変更影響検出

この層は実行されたレンダリング差分を観測する。カナリア時間帯で予想ルートと実際の BGP 広報、エッジバインディング、拠点集合を比較する。

サービス結果検出

この層はユーザー体験を測る。到達性、DNS クエリ完了、レイテンシ、タイムアウト、応答コード、トランスポート別ヘルスを測定する。

3層は異なる問いに答える。状態検証は影響前に既知の不正出力を停止できる。変更影響検出はコンパイラやデプロイ誤差を検知できる。サービス監視は設定モデルに反映されない障害を捉える。

どの層にも盲点はあるため、単独で信頼してはならない。

有効な設定モデルが実装されても、ルート実装は誤ることがある。ルート差分が正しくても、意図しないサービス状態に向かうことがある。合成問い合わせが成功しても、地域キャッチメントや顧客ネットワークを取りこぼす。公共ルートコレクタが私有経路を見逃す場合もある。制御目標は、乖離を迅速に検知することだ。

グローバルリゾルバーでは、実用的な変更ゲートは次のいずれかを満たす構成にすべきである。

重要プレフィックス所有の不正な変更がないこと。
本番プレフィックスが最小の健全拠点集合を下回らないこと。
独立 BGP ビューで未計画撤回がないこと。
許可外の範囲外でエッジバインディングが失われないこと。
期待値から説明できない実質的な問い合わせ量低下がないこと。
トランスポート別タイムアウト増加がないこと。
管理到達性やロールバック到達性を失っていないこと。

各要件には責任者が定義され、停止条件が必要である。停止命令だけで、停止・ロールバック権限がない監視は観測にすぎない。逆にデプロイ停止だけで十分な独立データがなければ、安全な作業が止まるか、破綻した状態を長引かせる。設計としては、証拠と意思決定権を接続することが必須である。

ルート再広告は部分復旧にすぎなかった

Cloudflare は 22:20 に原因設定をロールバックした。直ちに撤回プレフィックスの広告がほぼ復旧し、リゾルバートラフィックは概ね以前の約77%まで戻ったという。同時に、約23% のエッジフリートが必須 IP バインディングの自動再構成を終えていた [1]。

残る作業は運用上別のプロフィールを持つ。

通常のバインディング復旧は複数時間の段階ロールアウトで行われる。この速度は追加障害を避けるための設計である。インシデント時、Cloudflare はまず限定拠点で手動加速を試し、その後範囲拡大した。22:54 までにトラフィックはほぼ通常値へ戻った [1]。

この流れは三つの状態を示す有用な復旧モデルである。

サービストポロジー記録がロールバックされた。
BGP プレフィックスが再広告された。
エッジサーバがトラフィック受信と提供に必要な IP バインディングを取り戻した。

状態1でインシデントを閉じると意図した設定と実際の回復を混同する。状態2で閉じると到達性回復と完全回復を混同する。状態3では依然としてリゾルバーと顧客経路の検証が必要である。

復旧証拠はこのように層で整理されるべきである。

ロールバック対象記録そのものと承認情報。
ロールバック後のレンダリング済みルートセット。
独立観測で確認された再広告結果。
拠点別エッジバインディングの一覧。
リゾルバーのプロセスヘルス。
トランスポートと地域別の問い合わせ完了率。
ベースラインに対するトラフィック量比較。
残存エラーと顧客報告。
加速ロールアウトの判断とテスト根拠。

77% という数字は世界のユーザー復旧率ではない。Cloudflare 側のアカウントトラフィック基準に対する相対値である。利用者影響は設定されたリゾルバー、地理、再試行挙動、代替経路により異なる。この値の価値は、再広告後でもなおバインディングが未回復だった事実を示す点にある。

段階ロールアウトと緊急復旧の緊張関係は、明示されたガバナンスが必要である。

段階ロールアウトは通常変更時の影響を減らす。欠損バインディング由来の停止では、遅いロールアウトが停止を引き延ばす。復旧加速は早期復旧をもたらすが、未テストの全域変更リスクを上げる。Cloudflare は加速前にテスト拠点で検証を行ったと述べている [1]。

実務上の緊急対応は次を明示すべきだ。

通常速度を上書きできる者。
維持すべきテスト条件。
最初の復旧カナリアとなる拠点。
加速停止を決める測定指標。
独立観測で改善を確認する方法。
同時変更のロック方法。
通常デプロイ制御への復帰手順。

緊急処理は事前に実演しておくべきであり、障害時に初めて権限、ツール、依存関係を発見してはならない。

説明責任は統合された制御連鎖に従う

一人の設定作成者へ単独で帰責させるのは誘因として理解できるが、公開記録には個別過失の確証はなく、分散された制御連鎖を無視すると説明が不完全になる。

実務上の制御は複数層で成立する。

サービス所有

1.1.1.1 サービスの定義、重要性、プレフィックス、エンドポイント、到達要件を定めた主体があり、そこが不変条件と受け入れ可能な復旧条件を設計する。

番号資源・ネットワーク所有

本番プレフィックス、BGP 広報、ピアリング、ルーティング系を管理する主体があり、正しいアイデンティティとルート状態の記録、および独立観測を担保する。

トポロジーシステム所有

サービス・トポロジーと全世界更新機構を設計・運用する主体があり、環境境界、参照整合性、レンダリング差分レビュー、確実なロールバックを担保すべきである。

エッジ基盤所有

サービスアドレスをエッジサーバへ結びつけ・削除する主体があり、ルート状態とバインディング状態の変更条件および整合証明を定義する。

リゾルバー所有

再帰処理、トランスポート、ヘルスチェック、SLO を運用する主体があり、ルート存在だけでなく完了した問い合わせの結果で評価する。

インシデント指揮

検出、ロールバック、手動加速、対外連絡、事後対応を調整する主体があり、同時発生の変更競合回避と共通タイムラインの維持を行う。

顧客・ネットワーク運用者の依存関係責任

1.1.1.1 に依存するクライアント設定や加入者ネットワークを持つ組織は、独自の代替リゾルバー設計、検証、プライバシー・セキュリティのトレードオフを管理する。これは失敗したサービスへのコントロールから、提供者の責任を消し去るものではない。

責任を共有しても曖昧化はしない。各主体ごとに検証可能な義務と保持証拠があるべきだ。

プレフィックス所有者は権威的サービス紐付けの一意性を示せる。トポロジー所有者はゼロ生存拠点不変条件を示せる。ネットワーク所有者は想定広告を示せる。エッジ所有者はバインディングを示せる。リゾルバー所有者は応答を示せる。インシデント指揮は時系列を示せる。顧客はリスクが高い領域で継続性の検証を示せる。

ここには二つの極端な見方を避ける意義がある。

一つは、事業者がサービスを運用した以上、すべてを責任するという立場。これは顧客アーキテクチャと無料公開 DNS の制約を見逃す可能性がある。もう一つは、利用者側が代替リゾルバーを使えばよかったから事業者の説明責任はないという立場で、これは誤った経路制御と復旧設計への責任を除外する。

説明責任は、予防、検出、限定、開示、復旧を実現する制御への実務的コントロールに従う。ほかの主体が露出を下げても、失敗したサービス制御のコントロールは残る。

Heng.lu 現実層は、運用中のサービス同一性である

Heng.lu ドクトリンは、レジストリを宣言的主権者ではなく台帳と記録者と見なし、稼働コードとレジリエンスを優先し、番号資源を一意性・正確性・セキュリティメタデータ・継続性を持つオブジェクトとして扱う。

7月の事例は、ネットワーク上の直接例を与える。

1.1.1.1 プレフィックスにはアイデンティティがあり、サービス名もあった。トポロジー記録はサービス、プレフィックス、拠点を関連付ける。BGP と RPKI は追加でルートと認可の証拠を与える。これらは重要である。誤った関連付けが障害の起点だった。

しかし記録のみでリゾルバーの到達可否は変わらない。

到達可否は、最終的に記録がルート撤回とエッジバインディング変更へ変換されたときに変わり、復旧は再広告・バインディング復帰・問い合わせ完了で変わる。運用中のネットワークが「意図」と「実装」の対立を解消する。

これは記録反対論ではない。より強い記録を、運用証明と接続するための議論である。

本番サービスのプレフィックス台帳は次を保持すべきだ。

プレフィックスとアドレスファミリ。
権威サービス所有者。
意図された本番拠点。
ルーティング起点と認可メタデータ。
エッジバインディング要件。
プロトコルエンドポイント。
変更履歴。
重要度と最小存在ポリシー。
依存関係と復旧責任者。
最新のルートとサービス検証結果。

台帳は競合主張を可視化すべきであり、項目が埋まったから成功を宣言することはできない。

運用証明には次が含まれるべきだ。

レンダリング済みルート出力。
ルータ広告状態。
独立コレクタ視認性。
エッジインターフェース/バインディング状態。
リゾルバーヘルス。
代表経路で完了した DNS 問い合わせ。
復旧演習結果。

レジストリを台帳と見なすことは、受動的な文書化ではない。高品質な台帳は検証、認可、監査を駆動できる。不正や重複所有や欠損メタデータを拒否できる。だが宣言だけでパケット配送を代替することはできない。

同時に、この記事の論調にも制限がある。

これは特定の中央権限に全経路・全設定の承認を委ねるべきだという主張ではない。RPKI、RIR、規制当局、ベンダーが Cloudflare のネットワークを主権化すべきだという主張でもない。コミュニティや地域ラベルで正当性を決める論理でもない。

要点は現実層の原則である。記録が公開サービスプレフィックスを撤回できるなら、その権限・正確性・影響は、実際にルートとサービスが動作する状態と照合できる必要がある。

不変条件は、グローバルサービスが生存拠点0を下回らないことを止めるべきだ

Cloudflare のポストモーテムでは、リゾルバープレフィックスのトポロジーが全拠点から単一のオフライン拠点へ縮小したとされている [1]。これは直接の制御目標を示す。重要なグローバルサービスは、明示的に許可された緊急停止経路が使われる場合を除き、ゼロのオンライン本番拠点でデプロイされるべきでない。

不変条件は慎重に設計する必要がある。

単純な「1以上」という数だけでは弱い。1拠点では容量や地理的到達性が不足し得る。固定の最小値は、保守・地域制約・サービス設計の変動を考慮しないと過剰制約となる。全撤回禁止は、危険な故障に対し経路を残し続ける結果を生むこともある。

より強い不変条件は複数次元を含むべきである。

定義済み最小数の健全本番拠点を維持すること。
独立した障害ドメインをまたいだ拠点分散。
予想トラフィックを支える十分な測定容量。
グローバルからローカル範囲への無承認移行がないこと。
非本番オブジェクトが本番プレフィックスの唯一所有者とならないこと。
代替の健全拠点確認前に、エッジバインディング削除を許可しないこと。
全域撤回を行う際の明示的緊急承認。

不変条件はレンダリング候補と観測中状態の双方で評価されるべきだ。

たとえば設定上は10拠点維持になっていても、実際に5拠点が保守で停止していれば、静的候補検証は合格でも運用結果は不足する。逆にルートコレクタに多数広告が残っていても、対応するリゾルバー処理が不健全なら問題が残る。ゲート条件は、最新のヘルス・容量情報を含む設計が必要である。

結果は重要サービスに対してフェイルクローズとすべきだが、フェイルクローズは運用的に実装する必要がある。バリデータが利用不能なら変更は黙ってバイパスすべきでない。ネットワーク全体がすでに不調でも、インシデント指揮は制限付きオーバーライドを使う場合がある。その場合は実行者、期限、ログ、復旧後の整合が記録されるべきだ。

有用な不変条件レポートは次を含みうる。

項目	証拠
候補サービス対プレフィックス対応	レンダリング済み設定 SHA の厳密値
現在の本番割当	読み取り専用スナップショットと時刻
意図された拠点	環境・ヘルス状態を含む順序付き一覧
残存生存拠点	数、地域、容量、障害ドメイン
ルート差分	プレフィックス別の拠点ごとの広告/撤回
エッジバインディング差分	拠点ごとの追加・削除アドレス
外部観測	選定した BGP コレクタと顧客経路プローブ
サービス観測	トランスポート・地域別の DNS 応答
例外状態	担当者、理由、期限、承認

これは機密トポロジーを公開せよという主張ではない。完全レポートは保護されうる。公開の事後報告では、制御クラス、結果、限界、未対処領域を開示することで十分である。

対策の有効性は継続運用証拠で示される

Cloudflare のポストモーテムは、再発防止としての対策を列挙している。グローバルスコープのレガシー制御を縮小し、1.1.1.1 ルートの全域撤回に対する保護、検証・通知改善、レガシー基盤の見直しを進めると記載している [1]。

これらは対応すべき障害領域を狙っている。

グローバルスコープを縮小すれば影響範囲を抑えられる。保護対象プレフィックスを拘束すれば重大な出力を止められる。検証改善は参照・トポロジー誤りを早期検知しやすくする。通知改善は検知を速める。レガシー見直しは隠れた権限を可視化する。

公開記録は、提案対策の完了や有効性を全て保証していない。

これは Cloudflare 固有の欠点ではない。事後報告は通常、長期検証前に即時施策と計画を示す。説明責任は、少なくとも次の階層を分けて後続確認を要する。

提案された対策。
実装された制御。
テスト済みの制御。
演習される制御。
例外付きで稼働する制御。

7月型の失敗に対する継続的証拠の例は以下のとおりである。

プレフィックス紐付け衝突テスト

非本番の別サービスに本番リゾルバープレフィックスを結合しようとすると、システムが拒否し所有者競合を記録する。

ゼロ生存拠点テスト

候補トポロジーがリゾルバーをオンライン本番拠点ゼロに落とす場合、コンパイル前に拒否される。

レンダリング差分レビュー

テスト拠点追加が、影響を受ける本番プレフィックスと拠点を機械可読で列挙する。入力が局所的でもグローバル影響をレビュアが確認できる。

ルート撤回カナリア

制御された演習で、選定した公開 BGP ビューで想定外撤回が起きたとき、ロールアウト停止と回復経路確保が動作することを確認する。

エッジバインディング照合

システムが意図されたバインディング、実ホスト状態、ルート状態を変更前後で比較し、77% 到達・バインディング未完の状態を検知する。

プロトコル経路プローブ

UDP、TCP、DoT、DoH を実利用クライアントのエンドポイント想定で実行し、代替経路の独立性を記録する。

緊急加速演習

運用者が緊急経路でバインディングを復元し、カナリア成功を証明し、並行変更をロックして通常の段階ロールアウトへ戻す。

この一連の価値は、再発しないことを約束するものではない。既知の失敗クラスを境界付きで観測可能・回復可能にすることを示す。

実務的な証拠パック

取締役会、顧客、規制当局、技術審査者は、すべての内部コマンドを必要としない。必要なのは機構に即した証拠である。

制御	保持証拠	運用テスト	限界
プレフィックス所有	サービスプレフィックス台帳、所有者、履歴、認可情報	重複または環境横断の主張が拒否される	一意な記録でも内容は誤り得る
トポロジー整合	レンダリング済みサービス・拠点グラフ	重要サービスが承認された健全スコープを保持する	ヘルス情報は陳腐化し得る
全域影響プレビュー	正確なルートおよびバインディング差分	小さな入力が全ての本番出力を示す	コンパイラ欠陥はプレビューとデプロイの双方に影響
保護プレフィックス不変条件	重要プレフィックス方針の版管理	ゼロ生存拠点出力を阻止する	緊急撤回には代替経路が必要
変更カナリア	代表的コンパイラ、ルート、エッジバインディング結果	進行前に独立観測が一致する	1 か所カナリアは全領域を代表しない
BGP 観測	ルーターログと独立コレクタ	期待された広告が維持される	コレクタは全経路を観測しない
エッジバインディング在庫	拠点別のホストレベルバインディング状態	ルート状態とバインディング状態が一致する	バインディングはリゾルバーの健全性を保証しない
リゾルバーサービス証拠	エンドポイント・トランスポート・地域別の問い合わせ完了	実環境に近い問い合わせに対し評価可能な応答を示す	合成観測のカバレッジは限定的
ロールバック権限	インシデントロック、所有者、コマンド台帳	単独回復手順が上書きされない	手作業が自動化制御を抜ける余地
緊急展開	例外、カナリア、停止条件、期限	加速復旧が検証済みである	緊急性は運用リスクを高める
顧客継続性	依存関係マップと代替パス検証	重要サービスが制約下で継続する	代替経路が別依存を共有することがある
対策の持続性	再演習と例外記録	既知失敗クラスが時間を超えて制御される	テストでは将来の全振る舞いを証明できない

各項目は「記録」と「結果」を分けて扱う。

プレフィックス台帳は必要条件だが十分条件ではない。トポロジー図も必要条件であって十分条件ではない。BGP 可視性は必要条件だが十分条件ではない。DNS 応答も十分条件ではない。

証拠連鎖は、以下の状態で信頼性を得る。

承認済み記録に一人以上の責任者がいる。
レンダリング結果が重要不変条件を保持している。
実デプロイルートがレンダリング結果に一致する。
エッジバインディングがルート終端先と一致する。
リゾルバー処理が想定トランスポートで応答する。
代表ユーザーがサービスへ到達できる。
復旧証拠が影響の各層を閉じる。

機微情報は保護可能である。ルータ設定詳細、管理アドレス、内部サービス名、セキュリティ制御の細部は公開時にリスクとなりうる。独立審査者が適切な機密条件で検証する一方、公開資料では制御種別、タイムライン、試験結果、未解決限界を示すことができる。

運用者、顧客、審査者への問い

ネットワークおよびプラットフォーム運用者は次を問うべきである。

サービス対プレフィックス所有の権威主体はどこか。
非本番オブジェクトが本番プレフィックスを参照・縮小できるのか。
レンダリングされたグローバルルートとバインディング差分はレビューされるか。
ゼロ健康本番拠点を防ぐ不変条件は存在するか。
どの独立観測者がロールアウトを停止できるか。
ルート、バインディング、リゾルバーヘルスは照合されるか。
故障したトポロジーシステムに依存しない復旧経路はあるか。
インシデント変更ロックの所有者は誰か。
緊急ロールアウト加速はどのように行い、どのように通常状態へ戻すか。
この失敗クラスはいつ最後に演習されたか。

顧客および中継運用者は次を問うべきである。

重要業務で 1.1.1.1 アドレスを直接使用しているサービスはどれか。
cloudflare-dns.com や他経路を使っているか。
代替リゾルバーは設計・互換・検証が完了しているか。
フェイルオーバー時にプライバシー、フィルタ、セキュリティ要件を維持できるか。
ローカルキャッシュやサービス設計で依存を減らす際、古い回答や安全性の低下を生んでいないか。
供給障害ではなく実測インパクトを示すログを保有しているか。
選定済みリゾルバーが利用不可でも運用連絡を継続できるか。

審査者は次を問うべきである。

6月の記録には潜在的な本番権限が存在したか。
7月のプレビューがリゾルバープレフィックス撤回を明示したか。
カナリアは全世界リフレッシュを行使できたか。
保護プレフィックス方針は最新の拠点健全性を使用していたか。
ルート復帰、バインディング復帰、クエリ復帰の時系列はどうか。
非因果の Tata の公告と根本原因をどのように分離したか。
実施宣言された対策のうち、どれが検証済みか。
残る未公開・不明点はどこか。

これらの問いは完全性ではなく、制御と結果の境界を監査可能にすることを要件とする。

比較境界が重要である

Cloudflare は、ルーティングや 1.1.1.1 関連で複数の障害報告を公開している。これらを一括の一般障害として扱うと、修正すべき制御が不明瞭になる。

2022年6月の停止は BGP エクスポートポリシー順序や Multi-Colo PoP 構成、段階的な変更検証が中心であり、既に別の Daniel Kade 記事として扱われている。2025年7月の事例は、レガシーサービストポロジーの誤関連付けによりリゾルバープレフィックスが全域で撤回された事象である。

2024年6月の 1.1.1.1 障害は、ルートハイジャックとルートリークが中心だった [20]。メカニズムは 2025年7月の内部撤回とは異なる。

7月に観測された Tata Communications India の広告は並行現象で、Cloudflare は因果から切り離している [1]。2024年の比較対象と同一扱いにしたり、停止原因として混在させるべきではない。

機能差分の故障は同じ「グローバル設定」という語で同一にはならない。2025年記事の境界は、サービス対プレフィックスの不正紐付け、全世界トポロジー更新、ルート撤回、エッジバインディング削除、公開再帰 DNS の層別復旧という点に絞られる。

情報源の制約

Cloudflare のポストモーテムは、障害機構、タイムライン、影響プレフィックス、トラフィック経路差異、復旧、対策を最も詳述した公開情報である。これは一次情報である。公開レコードは、完全な設定グラフ、コンパイラ、内部ルータ状態、全エッジホスト、変更承認、全アラート、顧客影響一覧、内部意思決定記録を開示していない [1]。

Cloudflare Radar は公開 DNS/ルーティング観測を提供するが、Cloudflare 運営の選択データと同社ネットワーク由来であり、すべての経路、リゾルバー、ISP、ユーザー経路を網羅しない [2][3]。

現行の Cloudflare ドキュメントは公開リゾルバー、上位解決、ネットワーク運用者利用、Data Localization Suite、IP アドレス、ピアリング文脈を説明する。しかし時間と共に更新されるため、2025年7月の私的構成や対策の完全実装状態を単独で証明するものではない [4]-[11]。

RFC は DNS、Anycast、BGP、暗号化 DNS、起点検証、運用実践を定義するが、Cloudflare の私的実装、契約上の義務、法的注意義務を確定しない [12]-[19]。

2024年6月のポストモーテムは事象境界の比較素材であり、7月2025年の同時原因を示すものではない [20]。

本記事は悪意、隠蔽、過失、違法、民事責任、顧客損失総数、個別責任を立証しない。RPKI が停止を防止したとは主張していない。報告された対策がすべて実装・有効であるとも主張していない。

77%のトラフィック比率は、ルート再広告後の Cloudflare 内部比較に対する相対値であり、ユニーク利用者回復率ではない。23% はバインディング削除を受けたエッジサーバ数を示す。

これらの制約は説明責任の分析を妨げない。むしろ、詳細な事後報告から持続的制御証明へ移るために、必要な追加証拠を明示する。

結論

Cloudflare の2025年 1.1.1.1 停止は、眠っていたトポロジー記録が自動化で経路撤回に変換されたことから始まった。リゾルバーは DNS 処理自体の誤りからではなく、到達経路喪失で停止した。非本番サービストポロジーが本番リゾルバープレフィックスを参照し、後続のテスト拠点追加が全世界リフレッシュを引き起こした。結果としてトポロジーは1つのオフライン拠点へ縮退し、本番広告が撤回、フリートの一部でエッジバインディングが消えた [1]。

この障害は顧客体験としては DNS 停止であり、機構上はルート状態障害である。到達できない利用者はリゾルバーを使えない。異なるトランスポートとエンドポイント集合が異なる帰結を生んだ。ルート再広告は 77% 程度までしか戻らず、エッジバインディングとサービス状態が追従して初めて完全に近づいた。

説明責任の核は、設定チェックの一般的要求を増やすことではない。次のような具体的証拠連鎖である。

各本番サービスプレフィックスの一意の責任者。
グローバルなルート・バインディング効果のレンダリング済みプレビュー。
ゼロ生存拠点を防ぐ硬い不変条件。
実コンパイラと刷新経路を踏む代表カナリア。
独立した BGP と顧客経路観測。
ルート、エッジバインディング、リゾルバー状態の照合。
単一のインシデント変更責任者と検証済み緊急復旧経路。
対策が現在も稼働していることの証拠。

RPKI、BGP コレクタ、トポロジー記録、変更チケット、ステータスページはすべて寄与する。だが、これらはいずれも稼働中のサービスの代替にはならない。起点認可は可用性を保証しない。ルートはリゾルバー回答を保証しない。健全なプロセスは到達性を保証しない。意図されたトポロジーはデプロイ結果を保証しない。

それが Heng.lu の現実層であり、番号資源とサービス記録は一意性・正確性・安全性・継続性を持つ必要がある。これにより運用監査性が成立する。台帳は、パケット到達を強制する主権的宣言ではない。最終的な成立条件は、健全な場所からの継続広告、エッジの継続バインディング、正常リゾルバー回答、そして通常制御が誤る時にも維持される復旧経路である。

Cloudflare のポストモーテムは、明瞭な因果記録と関連対策を提示している。次の段階は継続的証拠である。再発し得るクロス環境参照を拒否し、ゼロ生存拠点出力を抑止し、ルートとバインディングの照合を実施し、復旧を演習し、例外を継続記録するテストを運用することだ。

大規模インフラは、少ない宣言で巨大な構成群を制御し続ける。適切な対応は、Anycast や自動化そのものを捨てることではない。むしろ、権限を可視化することだ。小さな入力が展開後にどのような全域出力を生むかをデプロイ前に示すこと。記録が管理する資源を識別すること。失敗し得る実機構を表すカナリアを準備すること。そして復旧は意図した設定の文字列だけでなく、実ユーザーがサービスを完了できるときに閉じること。

Cloudflare の2025年1.1.1.1 停止は経路撤回で検証する DNS 責任

要約