DNSSEC の誤り：.de TLD 障害への対応

2026 年 5 月 5 日、日本時間午後 7 時 30 分頃（UTC）、ドイツの国別コードトップレベルドメイン（TLD）である .de のレジストリ運営者である DENIC は、.de ゾーンに対して誤った DNSSEC 署名の公開を開始しました。DNSSEC 仕様により、これらの署名を受信する検証型 DNS リゾルバはすべて、署名を拒否し、クライアント（Cloudflare が運用するパブリック DNS リゾルバである 1.1.1.1 を含む）に対して SERVFAIL を返すことが義務付けられています。 ドイツの国別コードトップレベルドメインである .de は、インターネット上で最も規模が大きいドメインの一つです。Cloudflare Radar において、この TLD は常に世界中で最も頻繁にクエリされる TLD の上位にランクインしています。DNS 階層のこのレベルでの障害は、数百万ものドメインへの到達不能を引き起こす可能性があります。 本稿では、私たちが観測した事象、これらの出来事がもたらした影響、そして DENIC が問題を解決する間に私たちが適用した一時的な緩和策について順を追って解説します。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4hF64h72z4oKRg28w0mDJm/7f535cf687750f9ea730c27fa5e729e3/BLOG-3309_2.png) DNSSEC の仕組み DNSSEC（Domain Name System Security Extensions）は、DNS に暗号化認証を追加します。ゾーンが DNSSEC で署名されると、各レコードセットにはデジタル署名である RRSIG レコードが付随し、リゾルバがレコードが改ざんされていないことを検証できるようになります。DNS over TLS (DoT) や DNS over HTTPs (DoH) などの暗号化 DNS プロトコルとは異なり、DNSSEC はプライバシーではなく完全性に関するものです。レコードは可視化されますが、その真正性を証明することができます。 DNSSEC の独自性は、署名が保護するレコードと一緒に伝播することにあります。これにより、レスポンスが通過したキャッシュやホップの数に関わらず、完全性を検証できます。キャッシュされたレコードも新鮮なレコードと同様に検証可能です。 DNSSEC は信頼の連鎖に基づいて構築されています。リゾルバにハードコードされた信頼アンカーを持つルートゾーンから始まり、各ゾーンは Delegation Signer (DS) レコードを介して子ゾーンへの信頼を委譲します。親ゾーンの DS レコードには、子ゾーンの公開鍵の暗号化ハッシュが含まれています。リゾルバが example.de を検証する際、連鎖を検証します：ルートが .de を信頼し、.de が example.de を信頼します。この連鎖のどこかで断絶すると、その下のすべてのものに対する検証が失敗するため、.de のような TLD での設定ミスは、その下にあるすべてのドメインに影響を及ぼすことになります。 ゾーンは通常、2 種類のキーを使用します。1 つはゾーンのレコード署名に使用される Zone Signing Key (ZSK) で、もう 1 つは ZSK 自体の署名に使用される Key Signing Key (KSK) です。KSK の公開鍵は、親ゾーンの DS レコードが指し示すものであり、信頼チェーンのアンカーとなります。ZSK のローテーションは比較的単純で、新しいキーを生成し、ゾーンのレコードを再署名してキャッシュの有効期限切れを待つだけです。一方、KSK のローテーションはより複雑です。親側の DS レコードも更新する必要があり、レジストラやレジストリとの調整が求められることが多いためです。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6EDg7LKirRAVrzXCYprNIv/f14a9e3a24595d898cc9a650e9101fdd/image13.png) キーローテーション中、古いキーが段階的に廃止され、新しいキーが段階的に導入される重要な期間が存在します。もしゾーンで公開されている署名が、リゾルバがゾーンの公開 DNSKEY レコードに対して検証できないキーによって作成された場合（署名ステップの失敗、タイミングの誤り、あるいは新キーの完全な配布がまだ完了していないことが原因であっても）、リゾルバは応答を拒否し、SERVFAIL を返すしかありません。 私たちが観測した現象 2026 年 5 月 5 日、UTC 時刻 19:30 頃、.de TLD の運用者である DENIC は、.de ゾーンに対して誤った DNSSEC 署名の公開を開始しました。これらのレコードを受信する検証リゾルバは、DNSSEC 仕様によりこれらを拒否し、SERVFAIL を返すことが義務付けられています。1.1.1.1 も例外ではありませんでした。 以下のグラフは、インシデント発生中の .de クエリに対して 1.1.1.1 が返した応答コードを示しています。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/78zFXArtjyc8vcUup4zr9L/4207aa01b3caad16392266b4c32037e7/BLOG-3309_4.png) UTC 19:30 に SERVFAIL（サービス失敗）が急増した後、キャッシュされたレコードが徐々に期限切れを迎えるにつれて、その後の 3 時間にわたって緩やかに上昇しました。各ドメインのキャッシュされたレコードが期限切れになると、リゾルバは DENIC から新しいコピーを要求しますが、そこで壊れた署名を受け取り、失敗し始めます。 また、クエリボリュームの大幅な増加も確認できます。これは DNS インシデント時に典型的な現象で、クライアントが失敗したクエリを通常 3 回以上再試行するため、生データの数値が膨れ上がります。SERVFAIL の割合は実際のユーザーへの影響よりも深刻に見えますが、これらのクエリの多くは同じユーザーが同じドメインを再試行しているものです。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2KpMo46Phe5HtxmP34FYMK/46a1281a625760f58d592cbde91943f8/BLOG-3309_5.png) 驚くべきことに、NOERROR（正常応答）の割合はインシデント全体を通じて比較的安定していました。これは「serve stale（古くなったレコードの提供）」の働きによるものです。これについては次のセクションで詳しく説明します。 Serve stale 再帰型リゾルバーは、権威ネームサーバーから受け取ったレコードを、各レコードの TTL（Time-to-Live）期間中にキャッシュします。レコードがキャッシュされている間、リゾルバーは権威ネームサーバーに再度問い合わせることなく、そのレコードを直接返却します。TTL が期限切れになると、リゾルバーは新しいコピーを取得して再キャッシュします。 障害発生中、新たに要求されたレコードは SERVFAIL として解決されました。DNSSEC の署名が破損しており、リゾルバーはこれを正しく拒絶しました。しかし、多くの .de レコードはインシデント開始前にキャッシュされたまま残っていました。1.1.1.1 はそれらを即座に破棄してユーザーに SERVFAIL を返すのではなく、TTL 期限を過ぎても引き続きこれらのレコードを提供し続けました。これは「stale serving（古くなったデータの提供）」と呼ばれます。 1.1.1.1 は RFC 8767 を実装しており、この動作を形式化しています。上位リゾルバーでの解決が失敗した場合、リゾルバーはエラーを返すのではなく、期限切れのキャッシュレコードの提供を継続できます。これにより、上位障害の影響を大幅に緩和し、オペレーターが対応する時間を確保することができます。 以下のグラフには、stale serving による応答を除いた .de クエリの応答コードが示されています。stale serving の応答を除くと、19:30 以降 NOERROR レートは着実に低下します。これは、レコードがまだキャッシュされていたため、ユーザーが正常な回答を受け取れたクエリを表しています。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3YUtnXiFixcdswxtGik46r/78082f4b4439130cf23ff1473448781a/BLOG-3309_6.png) 私たちの対策 問題は主に私たちの制御範囲外であり、"serve stale（古いキャッシュの提供）" がその役割を果たしていましたが、依然として多くのユーザーに実害がありました。幸いにも、状況を改善するために講じられるべき措置がいくつかありました。 ネガティブ・トラスト・アンカー (Negative Trust Anchors) RFC 7646 は、ネガティブ・トラスト・アンカー（NTA）の概念を定義しています。通常の DNSSEC 運用では、検証レスォルバーは信頼アンカーのセットを維持します。これは信頼チェーンのルートにある公開鍵です。DNSSEC で署名された各 DNS ゾーンには信頼アンカーが存在し、すべての子ゾーンはその上に独自の信頼アンカーを構築します。チェーン全体を結びつける暗号化署名が破綻した場合、応答は拒否され、SERVFAIL（サービス失敗）が発生します。NTA は明示的な例外です。これはレスォルバーに対して、特定のゾーンを未署名のものとして扱うよう指示し、そのゾーン内の名前に対する検証をバイパスさせます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4ZPkgIvIf1R9rlScLS7ofh/3483daabde429f99e5ca3bc2f6b5709f/BLOG-3309_7.png) NTA（Non-Temporal Allowlist：非一時的許可リスト）はまさにこのような事態のために存在します。TLD 運用者が破損した署名を公開した場合、DNSSEC 検証レスルバは、その TLD に属するすべてのドメインに対して SERVFAIL を返すことを余儀なくされます。これは、それらのドメイン自体に何らかの問題があるからではなく、親ゾーンの設定ミスが原因です。そのような状況で引き続き SERVFAIL を返し続けることは、セキュリティ上の価値を提供しません：この障害はすでに知られており、公開されており、修正も進んでいるからです。RFC 7646 は、NTA の主要なユースケースとして TLD の設定ミスを明確に挙げています。 私たちが実際に展開したもの 1.1.1.1 については、Big Pineapple と呼ぶ独自のレスルバを保有しており、これは Families や Gateway DNS、DNS Firewall などでも 1.1.1.1 を支えています。現時点では、ネイティブな NTA メカニズムを実装していません。代わりに、既存のオーバーライドルールメカニズムを使用して .de を「安全でないゾーン」としてマークし、すべての .de クエリが DNSSEC が有効化されていないかのように解決されるようにしています。これは NTA と同等の機能ですが、どの RFC にも正式に定義されたものではありません。 DNSSEC のバイパス決定は、意図的なトレードオフです。DNSSEC 検証を行わない場合、インシデントの期間中、.de ドメインは本格的な攻撃に対して脆弱になります。このようなインシデントにおいては、署名失敗が広範囲に及び、公的に確認されており、インターネット上のすべての検証レスバーに均等に影響を及ぼしているため、このリスクは許容できると判断しました。社内インシデントルームでの見解として、「現在、1.1.1.1 を利用して .de 名前の解決を試みるユーザーで、検証されていない応答よりも SERVFAIL（サービス失敗）を好む人はいない」という言葉がありました。 対策の展開は UTC 22:17 に完了し、これにより 1.1.1.1 の影響が終了しました。この情報は DNS-OARC Mattermost において他の DNS オペレーターとも共有されました。 Origin resolution mitigations インターネットユーザー全員が当社の 1.1.1.1 リゾルバーにアクセスできる一方で、CDN プラットフォームサービスを利用する顧客に対しては特に責任があります。.de のオリジン名を持つ顧客もこのアウトエージの影響を受けました。 Cloudflare は、一般公開されている 1.1.1.1 サービスとは別に、オリジン解決用の内部リゾルバーを運用しています。影響を緩和するため、内部リゾルバーサービスにおいても .de に対して同様の NTA（Not Trusted Authority：信頼できない権威）を適用し、影響を受けた顧客のオリジン接続性を回復させました。 Extended DNS Errors キャッシュから提供できないクエリに対しては、1.1.1.1 が SERVFAIL 応答を返していました。各 SERVFAIL には RFC 8914 で定義された拡張 DNS エラー (EDE) コードが含まれており、これによりクライアントは問題の詳細をより詳しく知ることができます。 一部のレスォルバは EDE 6（DNSSEC Bogus）を返しており、破損した署名を直接指し示す説明的メッセージが付随していました。これは正しい動作です: EDE: 6 (DNSSEC Bogus): example.de/nsec3 の RRSIG で不正な形式の署名が見つかりました (keytag=33834) 一方、1.1.1.1 は EDE 22（No Reachable Authority）を返しており、これは表面上はアップストリームネームサーバーとの接続問題を示唆するものであり、DNSSEC 検証の失敗とは異なります。 その原因は、信頼チェーン検証器から DNSSEC EDE コードを上流へ伝播させる処理におけるバグです。検証器が不正な署名を検出すると DNSSEC Bogus の EDE コードを作成しますが、このコードは応答に挿入されません。代わりに、レスォルバの外部層が再帰解決の問題を検出し、エラーコードがないため「No Reachable Authority」という報告にフォールバックしてしまいます。これにより、根本的な DNSSEC 原因が隠されてしまいます。 1.1.1.1 のユーザーにとってこれが役立たないことを認識しており、DNSSEC エラーを表面化させるように応答を修正する予定です。 これは DNSSEC という技術の失敗でしょうか？ DNS は、インターネット通信のほとんどにおいてリクエストチェーンの重要な一部です。今回の障害と適用された緩和策から、DNSSEC が技術として失敗したという結論を導き出すのは容易かもしれません。しかし、誤設定されたあらゆる技術は、それを利用するユーザーにとって機能不全に陥るリスクがあります。海底でシャークが噛みつくように放置された重要な光ファイバーケーブルが存在しても、それが今日のインターネット通信において海底ケーブルが果たす重要な役割を無効化するものではありません。それは単に、私たちが時としてそれを正確に保護しきれていなかったことを浮き彫りにしているだけです。ここでも同じことが言えます。DNSSEC は、悪意のある行為者による改ざんなく DNS 応答を信頼できることを保証する上で決定的な役割を果たしています。 #HugOps 誰も深刻なインシデントを起こしたくはありません。残念ながら、大規模に重要なインフラを運用しているすべての組織でこうした出来事は起こり得ます。それが起きたとき、DNS コミュニティは互いに支え合う傾向があります。 このようなインシデントは、オペレーター間の関係がなぜ重要なのかを浮き彫りにします。DNS は分散型システムであり、単一の組織がすべてを制御しているわけではなく、その信頼性の高い運用は、レジストリ、レスォルバー（resolver）オペレーター、およびより広いコミュニティの間における相互の信頼とオープンなコミュニケーションに依存しています。DNS-OARC などのフォーラムはまさにこれを提供しており、問題が発生した際にオペレーターが組織の境界を越えて迅速に調整できる共有メールリストやチャットルームが存在します。 DENIC は、今回のインシデントに関する短いブログ記事を公開し、「この障害は、定期的なスケジュールに基づくキーのローテーションに起因しています。このプロセス中に、検証不可能な署名が生成され配布されました。予防措置として、正確な技術的原因が特定されるまで、今後のローテーションは停止されています」と述べています。 彼ら自身の分析結果が準備され次第、さらに詳しい情報が得られることでしょう。 このインシデントから得られた教訓 今回のインシデントは、DNS 階層構造における構造的な現実を浮き彫りにしました。つまり、TLD レベルのレジストリが障害を起こすと、その TLD に属するすべてのドメインが同時に影響を受けるのです。これはホスティング先や使用するレスォルバーに関係なく同様です。この事象は DNSSEC 固有のものではなく、TLD のネームサーバーへの到達性が失われた場合にも同様のことが起こります。グローバルな DNS を機能させている階層構造こそが、上位での障害が下位へ伝播する原因ともなっています。 これに対する単純な解決策はありません。業界ができることは、発生時に迅速かつ一貫した対応を行うことです。今回のインシデントでは、インターネット上のレスォルバー運用者が独立して 1 時間以内にネガティブ・トラスト・アンカー（Negative Trust Anchors）を適用し、DENIC がゾーンの問題修正に取り組んでいる間も解決を復旧させました。運用プラクティス、DNS-OARC などの業界向けコミュニケーションチャネル、serve stale といった機能は、根本的な依存関係を解消することはできなくても、影響を軽減する役割を果たします。 また、私たち自身についても改善すべき点が見えてきました。今後は EDE エラー（Extended DNS Errors）の対応を強化し、DNSSEC のエラーをより明確に表面化させる取り組みを進めていきます。 DENIC のインシデント後の報告書を待ち望んでおり、一貫して示された透明性に対して感謝申し上げます。 DNSSEC の仕組みについてさらに詳しく知りたい場合は、当社の「DNSSEC はどのように機能するのか？」というページをご覧ください。また、リアルタイムの DNS 動向や TLD データは、Cloudflare Radar で常時フォロー可能です。

DNSSEC の誤り：.de TLD 障害への対応

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト