Cloudflare 1.1.1.1 2025年7月14日の障害インシデント
(blog.cloudflare.com)- Cloudflare が2025年7月14日、サービストポロジー変更中に 1.1.1.1 パブリックDNS Resolver で62分間の全面障害を発生させた
- グローバルユーザーの大多数 が直接影響を受け、インターネットを利用できない現象を経験した
- 障害原因は 内部レガシーシステムの誤設定 であり、外部攻撃やBGPハイジャックとは無関係
- 障害は 誤った設定変更の蓄積 とネットワーク全体の再設定が重なって引き起こされた
- 再発防止策として 段階的デプロイシステムの導入 とレガシー構成システムの廃止計画を準備中
概要
2025年7月14日、Cloudflare はサービストポロジー変更中に 1.1.1.1 パブリックDNS Resolver でグローバルネットワーク障害を引き起こした。この障害により、1.1.1.1 および Gateway DNS サービスを利用していたユーザーは62分間にわたり インターネットサービスを利用できない、または深刻なサービス低下を経験した。これは内部レガシーシステムの 構成エラー に起因するものであり、外部攻撃や BGP ハイジャックによるものではない。
障害の範囲と影響
- 21:52 UTC ～ 22:54 UTC の間、1.1.1.1 Resolver は世界的に事実上動作不能な状態だった
- グローバル顧客の大多数がドメイン名を解決できず、インターネット利用そのものが不可能になった
- 障害発生状況は Cloudflare Radar で確認可能
- 障害理由は、Cloudflare が保有する IP アドレスをインターネットに広告するインフラを管理するレガシーシステムの 誤設定 によるもの
- 1.1.1.1 チャネルを通じて Cloudflare に到達していた全トラフィックに重大な影響が発生
障害発生の原因と背景
- Cloudflare は DNS Resolver などのグローバルサービスのために Anycast ルーティング を使用している
- さまざまな地域でサービスを提供しているが、一部のデータローカライゼーションを要求するサービスは特定地域に限定される
- 6月6日、将来の DLS（データローカライゼーション）サービス準備のための構成変更中、1.1.1.1 Resolver の IP 帯域が意図せず新しい DLS に含まれた
- このエラーはすぐには反映されず、実際には影響しなかったためアラートも発生しなかった
- 7月14日、テスト目的のオフライン拠点を DLS トポロジーに追加する変更が適用された
- この変更によってグローバルな ネットワーク構成が強制的に更新 され、既存のエラーが表面化した
- 1.1.1.1 Prefixes が世界中のデータセンターから撤回され、サービスが途絶した
障害タイムライン（要約）
- 2025-06-06 17:38: DLS サービス向け構成変更に 1.1.1.1 Prefixes を含める（影響なし、エラー潜伏）
- 2025-07-14 21:48: 構成変更によりネットワーク全体の構成を再読み込み、1.1.1.1 Prefixes のグローバルな撤回開始
- 2025-07-14 21:52: グローバル DNS トラフィック急減
- 2025-07-14 22:01: 内部アラート、障害を宣言
- 2025-07-14 22:20: 以前の構成へロールバック、サービス復旧手順を開始
- 2025-07-14 22:54: トラフィック正常化およびアラート解除、障害終了
障害の影響 IP とプロトコル
- 影響範囲: 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48 など、IPv4・IPv6 の広範な Prefixes
- UDP、TCP、DoT（DNS over TLS） を使うクエリで急激なトラフィック減少を観測
- DoH（DNS over HTTPS）は cloudflare-dns.com ドメインベースが多く、ほとんど影響を受けなかった
技術的な障害説明
1.1.1.1 Resolver サービス障害
- 6月6日の DLS 向け事前構成変更の過程で Prefixes の誤りが挿入された
- 7月14日、テスト目的でオフライン拠点が追加され、ネットワーク全体の設定が更新された
- この過程で 1.1.1.1 Resolver Prefixes が世界的に単一のオフライン拠点のみに限定され、サービスが撤回された
技術的原因の分析
-
Cloudflare は現在、レガシーシステムと新しい戦略システム を並行運用し、アドレス空間ごとのルーティング広告を同期している
-
レガシーシステムは手動更新で、デプロイの段階性がないなど、エラー発生確率が高い
- ピアレビューや他エンジニアの確認はあったが、カナリアデプロイなど段階的反映を保証する仕組みがなかった
-
新しい方式はハードコードではなくトポロジー中心で、段階的な変更反映とモニタリング体制を導入
-
22:01、DNS Resolver アラート発生
-
内部 BGP ルーティングテーブルで Resolver ルートがすべて消失した事実を確認
-
Prefixes 撤回後、1.1.1.0/24 subnet は Tata Communications India（AS4755）から BGP 広告が試みられた
- これは一時的な Prefix Hijack に類似するが、事故とは直接関係ない
復旧手順と後続対応
- 22:20 UTC、以前の構成へロールバック し、Prefixes を再広告
- 約77%のトラフィックが即座に復旧
- 一部のエッジサーバーは自動リセットされており、手動変更管理システムで再反映が必要だった
- ネットワーク安全性のため通常は段階的ロールアウトを行うが、今回は検証後に迅速適用した
- 22:54、すべての拠点が正常復帰
今後の改善策
- 段階的デプロイ体制（Stage Deployment）の導入: レガシーなデプロイ方式を廃止し、ヘルスベースの自動ロールバック構造を導入
- レガシーシステム廃止の加速: 危険な手作業の構成とデプロイ方式を除去し、文書化とテストカバレッジを強化
結論
Cloudflare 1.1.1.1 DNS Resolver の障害は 内部構成エラー によるものであり、Cloudflare は今後 安定性改善と再発防止策 の導入に全力で取り組んでいる。顧客に迷惑をかけたことを謝罪し、将来は類似事態を最小化するための措置を継続的に強化する予定だ。
1件のコメント
Hacker Newsのコメント
多くのユーザーにとって、1.1.1.1 リゾルバ（DNS）が動作しないということは、ほぼすべてのインターネットサービスにアクセスできなくなることを意味する。とはいえ、普通はすべてのデバイスに DNS サーバーを 2 つ設定しないだろうか。2 つ目もダウンしていたのか、それともなぜそちらに切り替わらなかったのか気になる
Private DNS provider hostnameを 1 つしか入力できない（私の知る限り）。そしてなぜ IP（1.1.1.1）を受け付けず、必ずアドレス（one.one.one.one）を要求するのか理解できない。DNS サーバーを指定するなら IP で設定する方がずっと合理的だ.は何十年も問題なく動いてきたが、1.1.1.1 で問題が起きる主因は DNS 自体ではなく Anycast にある。Cloudflare（や Google など）は「vanity」IP アドレスにこだわっており、この種の IP を実現するには Anycast を使う必要がある。本当の問題は DNS ではなく Anycast だ。複数のプロバイダーを選んで設定することを勧めるおよそ 20 分の障害で 1.1.1.1 のトラフィックが約 20% 減少したのは興味深い。Cloudflare がこのような単純で古典的な問題を繰り返しているのは不思議だ（今回が最初でもなく、最後でもなさそうだ）。Google の 8.8.8.8 と 8.8.4.4 は、ほぼ 10 年にわたり世界規模で (1) 1 秒のダウンタイムもなかった。(1: 一部地域的な問題はあったが、それはインターネット側の問題であり、Google の各種サービスが深刻な障害に見舞われたときでも DNS 自体は正常に動き続けていた)
影響の検知に 5 分以上かかったこと（メインプロトコルトラフィックが 10% まで落ちてそのまま維持されたにもかかわらず）に驚いた。あれほど大規模なシステムを運用したことはないが、このレベルなら即座にアラートが出るものだと思っていた。専門家たちがこれを妥当と考えるのか気になる
良い要約だ。DoH（HTTPS ベースの DNS）は多くの場合
cloudflare-dns.comドメイン経由でアクセスされるが（手動設定またはブラウザ）、IP アドレスではないため比較的影響が小さかったという点は興味深い。私は昨日影響を受けたが、ルーターで DoH を有効にしていたにもかかわらず何も引けず、8.8.8.8 に切り替えたら解決したcloudflare-dns.comの IP を知る必要があるのに、ルーターが 1.1.1.1 を使っていた可能性があるdnsmasqを使えば複数の DNS サーバーを同時に設定し、最も速く応答するサーバーを使う構成が可能だ。1 つのサービスがダウンしてもほとんど気づかないstrict-order設定なしでall-serversを使うと、dnsmasqは自動的にすべてのサーバーへ再試行リクエストを送る。ただしsystemd-resolvedを使う場合は順番にしか再試行しないため、異なるプロバイダーのサーバーを交互に並べることが重要だ。例のように IPv4 と IPv6 も組み合わせればフェイルオーバーはより速くなる。Quad9 の該当 IP アドレスはデフォルトでフィルタリングが有効だが、残り 2 つはそうではないため、解決結果が異なる可能性がある。個人的には DNSSEC（ドメインネームシステムセキュリティ拡張）の検証を重視するなら、検証するリゾルバとしないリゾルバを混在させるべきではない（例にある DNS はすべて DNSSEC をサポートしている）dnsmasqに信頼できる小規模 DNS の一覧を使うのは良さそうだが、複数の DNS プロバイダーに毎回リクエストを送るのはマナー違反なのではないかと悩んでいる。安定したプライバシー重視 DNS の一覧をどこで探せばいいのか分からないsystemd-resolvedを使えばデフォルトで DoT と DNSSEC をサポートしているので、似た動作を実現できる。集中型 DNS を完全に避けたければ、Tor デーモンを動かしてネットワーク上に DNS リゾルバを公開することもできる。複数のリゾルバも可能だall-servers設定がなくても、dnsmasqは定期的に各サーバーに対してリクエストをレースさせる（デフォルトでは 20 秒ごとに再試行）。突然の障害でも、影響を受けるのは数秒程度で済むはずだたとえ 1 時間の障害でも、月間では 0.13%、年間では 0.0114% にすぎない。Cloudflare がこのサービスに適用している SLO（サービスレベル目標）が気になる。リンク は見つけたが有料サービス専用だった。今回の障害で 7 月の可用性は
< 99.9% but >= 99.0%の区間に入り、この場合は利用料の 10% が返金されることになる事故後もトラフィックが完全には正常に戻っていない点が興味深い。最近 OpenWrt の
luci-app-https-dns-proxyを使って Cloudflare と Google DNS に同時に問い合わせるようにしているが、DoH への影響がほとんどなかったため障害に気づかなかった（DoH まで壊れていたとしても Google に自動で切り替わったはずだ）1.1.1.1 と 1.0.0.1 の両方が同じ変更の影響を受けたのは驚きだ。今後は DNS のバックアップには完全に別のプロバイダーを使うべきだろう（例: 8.8.8.8、9.9.9.9）
Cloudflare の内部トポロジーは、「legacy」と「strategic」のシステムが同期する形へと発展してきた。技術者にも非技術者にも現状を明確に説明した記事だ。マイグレーションの過程さえ興味深く感じられるようにうまく書かれている。事故による不便を謝罪し、今後の改善と再発防止に努めるというメッセージが印象的だ。このような企業姿勢は高く評価したい
legacyは技術者が主に使う用語で、strategicはマーケティングや非技術系リーダーが主に使う用語なので、両者を混ぜて使うとかえって双方にとって混乱と苛立ちの元になりうる複数のエンジニアがリブランディングをレビューしたにもかかわらず、1.1.1.0/24 がリルーティング一覧に追加されたミスを誰も見落とさなかったのは驚きだ。どんなヒューマンエラー、あるいは悪意によってこんなことが起きたのか気になる。DLS（Domain List Service）で 1.1.1.1/32 と 1.0.0.1/32 を単一ロケーションとして指定することを防ぐハードコードの例外処理が必要に見える