Cloudflareが内部ソフトウェアのエラーで障害を発生させた件の分析結果を公表、何が原因だったのか

プライバシー面を重視したパブリックDNS「1.1.1.1」で2023年10月4日に発生した障害について、1.1.1.1を運営するCloudflareが原因や再発防止策をまとめてブログに投稿しました。投稿によると、他者からの攻撃を受けた訳ではなく、障害発生の原因は内部ソフトウェアのエラーによるものとのことです。

1.1.1.1 lookup failures on October 4th, 2023
https://blog.cloudflare.com/1-1-1-1-lookup-failures-on-october-4th-2023/

今回の障害は日本時間で2023年10月4日の16時から20時にかけて発生し、Cloudflareが提供するDNSサービス「1.1.1.1」のほか、1.1.1.1を使用するCloudflare PagesやWARPなどのサービスが影響を受けました。

DNSは「ドメインネームシステム」の略称で、「cloudflare.com」などのドメイン名から実際にアクセスする際に必要なIPアドレスを引き出す役割を持っています。例えばcloudflare.comにアクセスする場合、「.com」というトップレベルドメイン(TLD)を管理するサーバーにcloudflare.comのアドレス情報を管理するサーバーを教えてもらう必要があります。そして、「.com」などTLDのサーバーがどこにあるのかという「ルートゾーン」の情報はルートサーバーで公開されています。

Cloudflareはルートゾーンのコピーを「1.1.1.1」のサービス内に保存しており、ルートサーバーにアクセスできない場合でも高速に応答することを可能にしています。

ルートゾーンの情報が更新されるとCloudflare側で保存しているコピーの情報も更新します。通常の場合、1日2回のペースで更新されるとのこと。

2023年9月21日、ルートゾーンに新たなレコード「ZONEMD」が追加されました。ZONEMDの内容は単なるルートゾーン情報のチェックサムだったものの、1.1.1.1の解析システムに問題があり、ZONEMDの内容を解析できませんでした。新たなルートゾーンの取得に失敗したため、Cloudflareは9月21日のZONEMD追加前のルートゾーンのキャッシュを利用したり、直接ルートサーバーに問い合わせたりしてDNSサービスの提供を続けました。

しかし2023年10月4日16時、9月21日バージョンのルートゾーンのDNSSECの有効期限が切れ、古いルートゾーンのキャッシュを使用しているサーバーで署名を検証できずにSERVFAILというエラー応答が増加。障害の発生に至りました。

下図は障害発生時刻付近のDNSクエリの応答をまとめたものです。通常時は約3％で推移しているSERVFAILが、世界標準時7時にDNSSECの有効期限が切れてから最大で約15％まで上昇していることが分かります。

Cloudflareではカーネルアップデートなどのタスクのためにリゾルバサーバーを定期的に再起動しています。9月21日から10月4日までの間に再起動したインスタンスは起動時にルートゾーンのロードに失敗しており、ルートサーバーに問い合わせるようになっていたほか、Serve Stale機能によって失効済みのデータを配信できたことなどの理由によって被害が軽減できたと述べられています。

今回の再発防止に向けて、Cloudflareは下記の通り対策を行うとのことです。

◆可視性
古いルートゾーンを使用する際にアラートを出して通知します。

◆耐久性
ルートゾーンの取得・配布方法を見直し、新たなレコードタイプを中断無く処理できるようにします。

◆テスト
ZONEMDについてのテストを行っていたものの、ルートゾーンの解析に失敗した場合に何が起きるかを適切にテストしていなかった点を踏まえ、カバレッジと関連するプロセスを改善していきます。

◆設計
特定の期限を過ぎたルートゾーンのコピーを使用するべきではないため、キャッシュされたルートゾーンの有効期限をより適切に管理します。