2026-05-06 — Sebastiaan Neuteboom、Christian Elmerot、Max Worsley — 読了目安: 8分
概要
- 2026年5月5日 19:30 UTC頃、.de（ドイツの国別トップレベルドメイン）を運営するレジストリ DENIC が、.de ゾーンに対して誤った DNSSEC 署名を公開し始めました。
- DNSSEC を検証するリゾルバは仕様に従いこれらを拒否し、クライアントに対して SERVFAIL を返す必要がありました。Cloudflare が運用する公開 DNS リゾルバ
1.1.1.1 も例外ではありませんでした。
- .de はインターネット上で最大級の ccTLD であり、Cloudflare Radar でもグローバルに広く照会される TLD の上位に常にランクされています。その階層レベルでの障害は何百万ものドメインを到達不能にする可能性があります。
以下では、我々が観測した事象、影響、そして DENIC が問題を解決する間に適用した一時的な緩和策について説明します。
DNSSEC の仕組み
DNSSEC（Domain Name System Security Extensions）は DNS に暗号学的な検証を追加する仕組みです。ゾーンが DNSSEC で署名されると、各レコードセットには RRSIG レコードとして知られるデジタル署名が付随し、リゾルバはそのレコードが改ざんされていないことを検証できます。
- DoT や DoH のような暗号化された DNS プロトコルとは異なり、DNSSEC はプライバシーではなく整合性を目的としています。レコードは可視のままですが、その真正性を証明できます。
- DNSSEC の特徴は、保護対象のレコードと署名が一緒に伝搬することです。これにより、レスポンスがどれだけキャッシュやホップを経由しても整合性を検証できます。キャッシュされたレコードは新規のものと同様に検証可能です。
- DNSSEC はチェーン・オブ・トラスト上に構築されています。ルートゾーン（リゾルバにハードコードされたトラストアンカー）から始まり、各ゾーンはDelegation Signer（DS）レコードを介して子ゾーンに信頼を委譲します。親ゾーンの DS レコードは子ゾーンの公開鍵の暗号ハッシュを含みます。リゾルバが
example.de を検証する際には、ルート → .de → example.de のチェーンを検証します。
- チェーンのどこかが壊れると、その下位にあるすべてが検証失敗になり、TLD（例：
.de）の誤設定がその下にあるすべてのドメインに影響する理由です。
- ゾーンは一般的に ZSK（Zone Signing Key）と KSK（Key Signing Key）の2種類の鍵を使います。ZSK はゾーンのレコードを署名するため、KSK は ZSK 自体を署名するために使われます。KSK の公開鍵は親ゾーンの DS レコードが指すもので、チェーン・オブ・トラストを固定します。
- ZSK のローテーションは比較的単純で、新しい鍵を生成してゾーンを再署名し、キャッシュの有効期限を待ちます。KSK のローテーションは親の DS レコードを更新する必要があり、レジストラやレジストリとの調整が必要になることが多く、より複雑です。
- 鍵ローテーション中には、旧鍵が廃止され新鍵が導入される重要なウィンドウが存在します。ゾーンに公開された DNSKEY レコードに対して検証できない鍵で署名が公開された場合、署名手順の失敗、タイミングの誤り、または新鍵の完全な配布前などの理由で、リゾルバはレスポンスを拒否して SERVFAIL を返すしかありません。
今回我々が観測した事象
- 2026年5月5日 19:30 UTC頃、DENIC が
.de ゾーンに対して誤った DNSSEC 署名を公開し始めました。検証リゾルバはこれらを拒否して SERVFAIL を返す必要がありました。1.1.1.1 も例外ではありません。
- （記事内のグラフ参照）19:30 UTC の直後に SERVFAIL が急増し、その後の3時間でキャッシュされたレコードの有効期限が切れるにつれて徐々に増加しました。各ドメインのキャッシュが切れてリゾルバが DENIC に新しいコピーを取りに行くと、再び壊れた署名を受け取り失敗が始まったためです。
- 同時にクエリ量の大幅な増加も見られました。これは DNS 障害時に典型的で、クライアントが失敗したクエリを再試行（多くの場合3回以上）するため、生のクエリ数が膨らみます。したがって SERVFAIL 率は実際のユーザー影響よりも悪く見えることがあり、多くは同一ユーザーが同一ドメインを再試行しているクエリです。
- 驚くべき点は NOERROR レートが比較的安定していたことです。これは次に説明する “serve stale” の働きによるものです。
Serve stale（期限切れキャッシュの継続提供）
- 再帰的リゾルバは各レコードの TTL（Time-to-Live）の間、受け取ったレコードをキャッシュします。TTL の間はオーソリティブネームサーバに戻らずキャッシュから直接返します。TTL が切れたら新しいコピーを取得して再キャッシュします。
- 障害中、最新のリクエストは SERVFAIL に終わりました。DNSSEC 署名が壊れており、リゾルバは正しくそれらを拒否しました。しかし、多くの
.de レコードは事象発生前のキャッシュに残っていました。これらをただちに破棄してユーザーに SERVFAIL を返す代わりに、1.1.1.1 は TTL を越えてそれらを返し続けました。これを “serving stale” と呼びます。
1.1.1.1 は RFC 8767 を実装しており、この動作を形式化しています。上流での解決に失敗した場合、リゾルバはエラーを返すのではなく期限切れのキャッシュを継続提供することができます。これは上流の障害のインパクトを大きく緩和し、運用者が対応する時間を稼ぎます。- 記事内のグラフは、stale 提供を除外した場合に NOERROR が 19:30 以降に着実に低下することを示しています。これらは、ユーザーが良好な応答を受け取ったのが単にそのレコードがキャッシュに残っていたからにすぎないケースです。
我々の緩和策
- 問題は主に我々の制御外のものであり、serve stale がその役割を果たしていましたが、多くのユーザーには依然として正当な影響がありました。幸い、状況を改善するために取れる行動がいくつかありました。
Negative Trust Anchors（NTA）
- RFC 7646 は Negative Trust Anchor（NTA）の概念を定義しています。通常の DNSSEC 動作では、検証リゾルバはチェーンのルートにあるトラストアンカー（公開鍵）を保持します。DNSSEC で署名された各ゾーンはトラストアンカーを持ち、各子ゾーンはそれに基づいて検証を行います。
- チェーンをつなぐ暗号署名が壊れるとレスポンスは拒否され SERVFAIL になります。NTA は明示的な例外であり、特定のゾーンを未署名（unsigned）と見なすようリゾルバに指示し、そのゾーン配下の名前に対する検証をバイパスします。NTA はまさにこの種のインシデントのために存在します。
- TLD オペレータが壊れた署名を公開すると、すべての DNSSEC 検証リゾルバはその TLD 配下のすべてのドメインで SERVFAIL を返さざるを得ません。それらのドメイン自体に問題があるわけではなく、親ゾーンの誤設定が原因です。その状況で SERVFAIL を返し続けることはセキュリティ価値を提供しません：失敗は既に公知であり修正中です。RFC 7646 は TLD の誤設定を NTA の主要なユースケースとして明示的に挙げています。
実際に我々が展開した内容
1.1.1.1 には我々独自のリゾルバ（内部では Big Pineapple と呼んでいます）があり、これが 1.1.1.1 for Families、Gateway DNS、DNS Firewall 等にも電力を供給しています。現時点で我々はネイティブな NTA 機構を実装していません。- 代わりに既存のオーバーライドルール機構を使い、
.de を "insecure zone" とマークし、.de のクエリを DNSSEC が有効でないかのように解決するようにしました。これは RFC に正式定義された NTA と同等の機能ですが、RFC 上の正式な NTA 実装ではありません。
- DNSSEC 検証をバイパスする決定は意図的なトレードオフです。検証が無い間、
.de ドメインはインシデント期間中に実際の攻撃に対して脆弱になります。しかし、このようなインシデントでは署名の失敗が広範かつ公知であり、インターネット上のすべての検証リゾルバに等しく影響していました。そのため我々はこのリスクを容認可能と判断しました。内部のインシデントルームでの言い回しを引用すると：
「今 .de の名前を解決している 1.1.1.1 の利用者で、未検証の応答よりも SERVFAIL を望む者はいない。」
- 我々は緩和策を 22:17 UTC に展開し、これが
1.1.1.1 に対する影響の終わりを意味しました。対応は DNS オペレータ間のチャネル（DNS-OARC Mattermost）でも共有しました。
オリジン解決に対する緩和策
1.1.1.1 は誰でもアクセスできる公開リゾルバですが、Cloudflare の CDN プラットフォームサービスを利用する顧客に対しては特別な責任があります。.de のオリジン名を使っている顧客もこの障害の影響を受けていました。- Cloudflare は公開の
1.1.1.1 サービスとは別の内部向けリゾルバをオリジン解決用に運用しています。影響を緩和するため、内部リゾルバでも同様に .de に対する NTA 相当の処置を適用し、影響を受けた顧客のオリジン接続性を回復しました。
Extended DNS Errors（拡張 DNS エラー）
- 緩和策展開前は、キャッシュから提供できないクエリは
1.1.1.1 から SERVFAIL を受け取っていました。各 SERVFAIL には RFC 8914 で定義された Extended DNS Error（EDE）コードが含まれ、クライアントに何が間違ったかの詳細を与えます。
- 一部のリゾルバは EDE 6（DNSSEC Bogus）を返し、壊れた署名を直接指摘する記述メッセージを返していました。これは正しい挙動です：
EDE: 6 (DNSSEC Bogus): RRSIG with malformed signature found for example.de/nsec3 (keytag=33834)
- 一方
1.1.1.1 は EDE 22（No Reachable Authority）を返していました。これは表面的には上流ネームサーバへの接続問題を示唆し、DNSSEC 検証失敗とは異なる印象を与えます。原因は我々のトラストチェーン検証器から EDE コードを伝播する方法にバグがあったためです。検証器が bogus な署名を検出すると DNSSEC Bogus の EDE コードを生成しますが、これがレスポンスに挿入されていませんでした。代わりにリゾルバの外側の層は再帰解決に問題があると見なし、エラーコード無しでフォールバックして “No Reachable Authority” と報告しました。これにより根本の DNSSEC 原因が隠蔽されていました。
- 我々はこれが
1.1.1.1 利用者にとって有益でないことを認識しており、DNSSEC エラーが表面に出るようにレスポンスを修正する予定です。
DNSSEC は技術として失敗したのか？
- DNS はほとんどのインターネット通信における重要なチェーンの一部です。この障害と適用した緩和策だけを見て DNSSEC が技術として失敗したと結論づけるのは簡単です。しかし、誤設定された技術はそれに依存するユーザーに対して破綻するリスクを常に孕みます。
- たとえば、海底ケーブルをサメがかじれる状態で放置するのが悪いからといって、海底ケーブル自体の重要性が否定されるわけではありません。むしろ我々が適切に保護できなかったことを示しています。同様に、この件は DNSSEC が改ざんから DNS 応答を信頼できるようにする重要な役割を果たしていることを否定するものではありません。
#HugOps
- 深刻なインシデントは誰も望みませんが、スケールで重要なインフラを運用する者には起こり得ます。その際、DNS コミュニティは互いに助け合う傾向があります。インシデントはオペレータ間の関係の重要性も浮き彫りにします。DNS は分散システムであり、単一組織が全てを支配するわけではありません。信頼を保ち、レジストリ、リゾルバ運用者、広いコミュニティ間での開かれた連絡線を維持することが安定稼働には不可欠です。
- DNS-OARC のようなフォーラムはまさにこれを提供します：オペレータが組織の境界を越えて迅速に連携できる共有メーリングリストやチャットルームです。
DENIC は本件について短いブログ記事を公開しており、そこで以下のように述べています：
「障害は定期的に予定されていた鍵ロールオーバーに関連しています。この過程で、検証不可能な署名が生成・配布されました。予防措置として、正確な技術的原因が特定されるまで今後のロールオーバーは停止されています。」
我々は DENIC の詳細な分析が出るのを待っています。
今回のインシデントからの学び
- このインシデントは DNS 階層の構造的な現実を浮き彫りにしました：TLD レベルのレジストリが障害を起こすと、その TLD の下にあるすべてのドメインが影響を受けるということです。
（原文はここで切れていました。）