2025年7月14日のCloudflare 1.1.1.1インシデント

2025年7月16日原文(blog.cloudflare.com)

概要

2025年7月14日、Cloudflareの 1.1.1.1 Resolverサービス が世界的に約1時間ダウン
原因は 内部の設定ミス によるもので、攻撃やBGPハイジャックではない
影響範囲は 全世界の1.1.1.1利用者 で、多くのインターネットサービスが利用不能に
DoH（DNS-over-HTTPS）経由のトラフィックは ほぼ影響なし
今後の再発防止策として 段階的展開や監視強化 を実施予定

Cloudflare 1.1.1.1 Resolver 世界規模障害の詳細

発生日時 ：2025年7月14日 21:52 UTC ～ 22:54 UTC（約1時間）
影響範囲 ：1.1.1.1 Resolverサービスの 全世界的な停止
原因： レガシーシステムの設定ミス によるIPアドレス広告の誤動作
影響内容 ：
- 1.1.1.1を利用する多くのユーザーが DNS解決不可 となり、インターネットサービス全般が利用不能
- 対象IP範囲：1.1.1.0/24、1.0.0.0/24、2606:4700:4700::/48 など
- UDP・TCP・DoT経由のDNSトラフィックが 即座に大幅減少
- DoH（cloudflare-dns.com経由）は 影響を受けず、ほぼ通常通り稼働

障害発生の経緯

2025-06-06 ：DLSサービス向けの設定変更時、誤って1.1.1.1のプレフィックスを含めてしまう
- この時点では 実動作に影響なし、アラートも発生せず
2025-07-14 21:48 ：非本番サービス用の設定変更が全グローバルネットワークに波及
- 1.1.1.1のIPが 誤って非本番サービスに紐付けられ、広告が撤回
2025-07-14 21:52 ：DNSトラフィックが 世界的に急減
2025-07-14 22:01 ：内部アラート発動、インシデント宣言
2025-07-14 22:20 ：設定を 元に戻す修正作業を開始
2025-07-14 22:54 ：全拠点で 復旧完了、トラフィック正常化

技術的要因と分析

レガシーシステムと新システム の混在管理による運用負荷
- レガシーでは データセンターごとに手動リスト管理、更新ミスが発生しやすい
- 新システムでは IPアドレスをハードコーディングせず、段階的展開とヘルスチェックが可能
今回の障害は グローバルな即時撤回 を招き、順次展開による安全性が確保されていなかった
障害時、 BGPルート撤回とともにTata Communications IndiaによるBGPハイジャック も発生
- ただし、これは障害の 原因ではなく、結果的に表面化した別事象

復旧と今後の対策

設定を 即時リバート し、BGP広告を再開
一部エッジサーバーで IPバインディングが外れており、段階的に再適用
進行中のシステム移行 や設定管理プロセスの見直しを実施
- 今後は 段階的展開（カナリアリリース） と 監視強化 を徹底
- レガシーシステムの運用終了を推進

まとめと教訓

設定ミスがグローバルサービス全体に波及 しうるリスクの顕在化
段階的展開・自動監視・レビュー体制 の重要性
利用者・顧客への 影響の大きさと迅速な対応 の必要性
Cloudflareは 同様の障害防止に向けた改善策 を継続的に実施予定

Hackerたちの意見

事件の後、トラフィックが完全に元のレベルに戻らなかったのは興味深いね。最近、OpenWrtで「luci-app-https-dns-proxy」パッケージを使い始めたんだけど、これはCloudflareとGoogle DNSの両方を使うように設定されてるんだ。DoHはほとんど影響を受けなかったから、障害には気づかなかったよ。（もしDoHが影響を受けてたら、たぶんGoogle DNSに切り替わってたと思うけど。）

└

その件については、最後の方で詳しく話してるね。どうやら一部のサーバーはもっと直接的な介入が必要だったみたい。

└

事件の後、トラフィックが完全に元のレベルに戻らなかったのは興味深いね。体験的に言うと、ステータスページに載る前にDNSが壊れてるって気づいて、上流のDNSをGoogleに切り替えたんだ。まだ戻すのはやってないけど。

└

事件の後、トラフィックが完全に元に戻らなかったのは興味深いね。クライアントはリクエストを送るたびにそのリクエストをしなくて済むようにDNS解決をキャッシュするから、あるクライアントがかなりの期間キャッシュを保持していた可能性があるね。

1.1.1.1と1.0.0.1が同じ変更の影響を受けるなんて、マジでびっくりだね。これからは全く別のプロバイダーをDNSバックアップとして使うべきかも。8.8.8.8とか9.9.9.9とか。

└

1.1.1.1と1.0.0.1は同じサービスで提供されてるんだ。冗長な完全に別のバックアップとして宣伝されてるわけじゃないしね…。

└

それってずっとそうじゃなかった？

└

一般的に「DNSバックアップ」なんてものはないよ。ほとんどのクライアントはリストから適当に一つを選ぶだけで、失敗した場合に他のものに切り替えるわけじゃないからね。だから、もし一つがダウンしたら、リクエストがタイムアウトすることが多いよ。

└

一般的に、DNSの設計理念は、最も大きな会社が運営しているものではなく、あなたに最も近いDNSリゾルバを使うことなんだ。ただ、異なる地域、異なるバックボーン、異なるプロバイダーの複数のリゾルバを選ぶのは良いアイデアだし、Anycastアドレスは使わない方がいいよ。Anycastはちょっと変なことになることがあるからね。でも、これがトラブルシューティングを難しくすることもある。DNSは必ずしも期待通りに動くわけじゃないから。

└

そうだよね、もうそうなってるんじゃない？俺のPi-holeは両方ともOpenDNS、Quad9、CloudFlareを使ってるし、ほとんどのデバイスは両方のPi-holeを使ってるよ。

良いまとめだね。 > DoH（DNS-over-HTTPS）のトラフィックは比較的安定してたってことは注目に値するね。ほとんどのDoHユーザーは、手動またはブラウザを通じてcloudflare-dns.comのドメインを使って公共DNSリゾルバーにアクセスしてるから、IPアドレスではないんだ。面白いことに、昨日これに影響を受けたよ。ルーターにはCloudflare DoHが有効になってるはずだったけど、何も解決できなかった。DNSサーバーを8.8.8.8に変更したら問題が解決したよ。

└

DoHってどうやって動くの？なんかcloudflare-dns.comのIPを最初に知っておく必要があるみたい。もしかしたら、ルーターがこれに1.1.1.1を使ってるのかも。

Hacker Newsで議論の続きを見る

ハクソク