ハクソク

世界を動かす技術を、日本語で。

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

314日前原文(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を使ってるのかも。

└

僕の（Unifi）ルーターは自動DoHに設定してあって、CloudflareとGoogleを使ってると思う。特に問題はなかったから、CloudflareのDoHが動いてたか、ダウン中にGoogleの方を使ってたんだろうね。

└

それには同意できないな。ここでの実際の根本原因は、経験豊富な管理者である僕ですら理解するのに苦労するような専門用語に覆われている。これは企業のニュースピークだよ。「レガシー」っていうのは明確な用語じゃなくて、抽象化して曖昧にするために使われてる。> レガシーコンポーネントは、段階的なデプロイメント手法を活用していない。Cloudflareはこれらのシステムを廃止することで、現代的な進行中の健康管理されたデプロイメントプロセスを提供し、段階的に早期の指標を示し、適宜ロールバックできるようにする。これが何を意味するのかは分かるけど、こんな難解な企業用語で書く必要は全くないよ。

└

面白いな。今日、新しいドメインを設定してたんだけど、20分くらいの間、1台のノートパソコンでFirefoxからしかアクセスできなかった。GoogleのDNSツールではアクティブって表示されてたし、解決できるAmazonサーバーにSSH接続もできた。私のローカルネットワークはそれを全く認識してなかった。キャッシュをフラッシュしてもダメだった。結局、そのFirefoxブラウザがCloudflareのDoHを使うように設定されてたんだ。

└

最初の部分で共有されている全くの誤ったタイムラインを除けば、良いまとめだね。

影響の検出が遅れたのには驚いたよ。彼らの内部ヘルスサービスが、メインプロトコルのトラフィックが急に期待値の約10%に落ち込んだことに気づくのに5分以上かかったんだ。そんな大規模な監視に関わったことがないけど、こんな極端な状況では1分以内にアラームが鳴ると思ってた。どうしてそうなったのか、そしてそれがその分野のプロにとって合理的なのか驚くべきことなのか、詳しく知りたいな。

└

驚かないよ。例えば、メトリック集計サービスがあって、そのサービスがクラッシュしたとする。どうなるかって？メトリックが遅延して、オーケストレーションシステムがそのサービスを別の場所に再デプロイするまで、メトリックが100%落ちたように見えるんだ。ほとんどのオーケストレーションは、ノードの一時的な障害（ネットワークのちょっとした乱れみたいな）を想定して、再デプロイに1秒かかるからね。だから、1分でアラートを出すと、何もないのに午前2時に人を起こすことになる。もし5分で自動解決することが続いたら、また午前2時に人を起こし続けるとどうなる？人は辞めるか、最終的にはアラートを5分に調整することになるよ。データがないことと実際の落ち込みを区別できることもあるけど、「人を常に呼び出すと、みんな辞める」というポイントが重要だと思う。アラームが厳しすぎると人が起こされ続けるから、アラームは緩めるべきだし、それが5分になる理由の一つだね。

└

検出の速さと誤検知率の間には常に緊張関係があるよね。NagiosやIcingaみたいな従来の監視システムでは、チェックが3回連続で失敗したときだけイベントやアラートを開く設定があるんだ。誤って失敗するチェックは結構あるからね。自動で直る監視チェックのアラートをオペレーターに大量に送ると、無駄にストレスを与えちゃって、アラート盲目になっちゃう。最初の反応は「様子を見よう」ってなるから。CFのDNSサービスほどの露出があるサービスを運営したことはないけど、信頼できる検出に8分かかったのはあまり驚かないな。

└

このサービスにはSLAがないことを忘れないでね。

同じDLSサービスに対して構成変更が行われた。この変更は、テスト用の場所を非生産サービスに接続したもので、この場所自体は稼働していなかったが、変更がグローバルにネットワーク構成のリフレッシュを引き起こした。今なんて言ったの？テストがグローバルな生産変更を引き起こしたの？ > 以前の構成エラーにより、1.1.1.1リゾルバのIPアドレスが非生産サービスにリンクされていたため、非生産サービスの設定を変更した際に、その1.1.1.1のIPが意図せず含まれてしまった。別のサービスがすでに生産で使用されているアドレスルートを吸い上げるプロセスがあるの？

多くのユーザーにとって、1.1.1.1リゾルバーを使って名前を解決できないということは、基本的にすべてのインターネットサービスが利用できないということを意味しました。普通、どのデバイスにも2つのDNSサーバーがリストされているんじゃないの？ じゃあ、2つ目もダウンしてたの？そうじゃないなら、どうしてそれに切り替えなかったの？

└

すべてのユーザーが2つのDNSサーバーを設定しているわけじゃないの？

└

Androidの設定で、ネットワークとインターネット、プライベートDNSのところでは、「プライベートDNSプロバイダーのホスト名」に1つしか入れられないよ（私の知る限りでは）。ちなみに、なんでIP（1.1.1.1）を受け付けないのか全然理解できない。アドレス（one.one.one.one）を指定しなきゃいけないのはおかしいよね。DNSサーバーから解決されるアドレスより、IPからDNSサーバーを設定する方が理にかなってると思うんだけど :/

└

1.1.1.1はリゾルバーサービス全体を指す呼び名でもあるし、影響のセクションでは（どうやら）1.0.0.0/24と1.1.1.0/24の両方が影響を受けたって言ってるみたいだね（他の範囲も含めて）。

└

普通は1.1.1.1と1.0.0.1をペアにすると思うけど、これが正しければ、両方ともダウンしてたってことだね。

└

俺のMikrotikルーター（あと、見た感じ全てのルーターも）DoHアドレスを一つ以上サポートしてないんだよね。

└

もしできるなら、自分で運営してみるのもいいよ。

└

それと、自分の近くにあるDNSを使うことを強くおすすめするよ。ISPsがDNSをいじったり（ブロックとか）しないところだと、通常は応答時間がかなり良くなるからね。もしデバイスが適切なフェイルオーバーをサポートしていないなら、ルーターにローカルDNSフォワーダーを使うか、外部のものを使うといいよ。

約1時間のダウンタイムは、1ヶ月の0.13%または1年の0.0114%に相当するね。このサービスに対するCloudflareの社内のサービスレベル目標（SLO）を見てみたいな。https://www.cloudflare.com/r2-service-level-agreement/を見つけたけど、これは有料サービス向けみたいだから、このダウンタイムは7月を「= 99.0%」の範囲に入れることになるね。有料で契約してたら、10%の返金がもらえることになるよ。

└

年間で99.9%以上は「信頼性の維持」って観点から見てもそうだと思うよ。

20分のトラブルで1.1.1.1の利用が20%も減ったのは興味深いね。Cloudflareはこういう問題で苦労してるのがよく分からない。これが初めてじゃないし、最後でもないだろうし。8.8.8.8と8.8.4.4は、ほぼ10年間ダウンタイムが一秒もなかったのに。ローカルな問題はあったけど、それはインターネットのせいで、Google自体がいろんなサービスで大規模なダウンタイムを経験してる時でも動いてたからね。

└

DNSには可用性だけじゃなくて、速度やプライバシーも大事だよね。ヨーロッパのユーザーは、アメリカの企業がCLOUD法の対象になるより、https://european-alternatives.eu/category/public-dnsに載ってる代替案の方が好まれるかもしれないね。

面白い副作用だけど、GluetunのDockerイメージはDNS解決に1.1.1.1を使ってるんだ。だから、アウトageのせいでGluetunのヘルスチェックが失敗して、イメージが止まっちゃった。もしトレントのトラフィックを見れる方法があったら、20分のスランプがあったに違いないね。

どんなレガシーシステムを指してるのか、ぜひ知りたいな。