概要
2026年5月5日（UTC 19:30頃）、.de国別トップレベルドメイン（TLD）のレジストリオペレーターであるDENICが、.deゾーンに対して不正なDNSSEC署名を公開し始めました。DNSSEC仕様に従う検証DNSリゾルバーは、これらの署名を拒否してSERVFAILをクライアントに返す必要がありました。これはCloudflareが運用する公開DNSリゾルバーである1.1.1.1も例外ではありませんでした。
ドイツの国別トップレベルドメインである.deは、インターネット上で最大級のドメインの1つです。Cloudflare Radarでは、グローバルに最も広くクエリされるTLDの中で常に上位にランクされています。DNS階層のこのレベルでの障害は、数百万のドメインに到達不可能にする可能性があります。
この記事では、私たちが目撃したこと、これらのイベントの影響、およびDENICが問題を解決している間に適用した一時的な緩和策について説明します。
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つのタイプの鍵を使用します：
- Zone Signing Key（ZSK）：ゾーンのレコードに署名するために使用
- Key Signing Key（KSK）：ZSK自体に署名するために使用
KSKの公開鍵は、親ゾーンのDSレコードが指すもので、信頼チェーンを固定します。
ZSKのローテーションは比較的簡単です：新しい鍵を生成し、ゾーンのレコードに再署名し、キャッシュの有効期限が切れるのを待ちます。KSKのローテーションはより複雑です。親のDSレコードも更新する必要があり、多くの場合、レジストラーまたはレジストリとの調整が必要です。
鍵のローテーション中に、古い鍵がフェーズアウトされ、新しい鍵がフェーズインされる重要なウィンドウがあります。ゾーンで公開されている署名が、リゾルバーがゾーンの公開DNSKEY記録に対して検証できない鍵で作成されている場合（署名ステップが失敗したため、タイミングが間違っていたため、または新しい鍵がまだ完全に配布されていないため）、リゾルバーは応答を拒否してSERVFAILを返す以外に選択肢がありません。
私たちが目撃したこと
2026年5月5日（UTC 19:30頃）、.de TLDのオペレーターであるDENICが、.deゾーンに対して不正なDNSSEC署名を公開し始めました。DNSSEC仕様に従う検証リゾルバーは、これらのレコードを拒否してSERVFAILを返す必要がありました。1.1.1.1も例外ではありませんでした。
以下のグラフは、障害中に1.1.1.1が.deクエリに対して返したレスポンスコードを示しています。
UTC 19:30でのSERVFAILの即座のスパイク後、キャッシュされたレコードがゆっくりと有効期限切れになるにつれて、その後の3時間で着実に上昇しました。各ドメインのキャッシュされたレコードが有効期限切れになり、リゾルバーがDENICに新しいコピーを取得しに戻ると、壊れた署名を取得して失敗し始めました。
また、クエリボリュームの大幅な増加も見られます。これはDNS障害中に典型的です。クライアントが失敗したクエリを再試行し、多くの場合3回以上、生の数字を膨らませるためです。SERVFAIL率は実際のユーザーへの影響よりも深刻に見えます。これらのクエリの多くは、同じユーザーが同じドメインを再試行することを表しているためです。
驚くべきことは、NOERROR率が障害全体を通じて比較的安定していたことです。これは「serve stale」が機能していることです。次のセクションで説明します。
Serve Stale
再帰的リゾルバーは、権威的ネームサーバーから受け取ったレコードを、各レコードのTTL（Time-to-Live）の期間キャッシュします。レコードがキャッシュされている間、リゾルバーは権威的ネームサーバーに戻らずに直接それを提供します。TTLが有効期限切れになると、リゾルバーは新しいコピーを取得して再キャッシュします。
障害中、新しくリクエストされたレコードはSERVFAILに解決されました。DNSSEC署名は壊れており、リゾルバーは正しくそれらを拒否しました。しかし、多くの.deレコードは障害が始まる前からキャッシュに残っていました。それらを即座に破棄してユーザーにSERVFAILを返す代わりに、1.1.1.1はそれらをTTLを超えて提供し続けました。これは「serving stale」と呼ばれます。
1.1.1.1はRFC 8767を実装しており、この動作を形式化しています。アップストリーム解決が失敗した場合、リゾルバーはエラーを返す代わりに、有効期限切れのキャッシュされたレコードを提供し続けることができます。これはアップストリーム障害の影響を大幅に緩和し、オペレーターが対応する時間を稼ぎます。
以下のグラフは、障害中のstale提供レスポンスを除外した.deクエリのレスポンスコードを示しています。
stale提供レスポンスがない場合、NOERROR率はUTC 19:30から着実に低下します。これらは、ユーザーが良い答えを受け取ったクエリを表しており、それはレコードがまだキャッシュに存在していたためだけです。
私たちの緩和策
問題は主に私たち自身の制御外にあり、serve staleが機能していましたが、多くのユーザーにとって正当な影響がまだありました。幸いなことに、状況を改善するために私たちが取ることができるいくつかのアクションがありました。
Negative Trust Anchors
RFC 7646は、Negative Trust Anchor（NTA）の概念を定義しています。通常のDNSSEC操作では、検証リゾルバーは信頼アンカーのセットを維持します：信頼チェーンのルートにある公開鍵です。DNSSECで署名された各DNSゾーンには信頼アンカーがあり、すべての子ゾーンはそれに基づいて独自の信頼アンカーを構築します。
チェーンをリンクする暗号化署名が壊れている場合、応答は拒否され、SERVFAILになります。
NTAは明示的な例外です。リゾルバーに特定のゾーンを未署名であるかのように扱うよう指示し、そのゾーンの下の名前の検証をバイパスします。NTAはまさにこのタイプの障害のために存在します。
TLDオペレーターが壊れた署名を公開する場合、すべてのDNSSEC検証リゾルバーはそのTLDの下のすべてのドメインに対してSERVFAILを返すことを強制されます。これらのドメイン自体に何か問題があるためではなく、親ゾーンが設定ミスであるためです。その状況でSERVFAILを返し続けることはセキュリティ値を提供しません：失敗はすでに既知で、公開されており、修正されています。
RFC 7646は、NTAの主な使用例としてTLDの設定ミスを明示的に名付けています。
実際にデプロイしたもの
1.1.1.1の場合、Big Pineappleと呼ばれる独自のリゾルバーがあり、1.1.1.1 for Families、Gateway DNS、DNS Firewallなども強化しています。現時点では、ネイティブNTAメカニズムを実装していません。代わりに、既存のオーバーライドルールメカニズムを使用して.deを非セキュアゾーンとしてマークしました。これにより、すべての.deクエリはDNSSECが有効になっていないかのように解決されます。これはNTAと機能的に同等ですが、RFC では正式に定義されていません。
DNSSEC検証をバイパスする決定は、意図的なトレードオフです。DNSSEC検証がなければ、.deドメインは障害の期間中、本物の攻撃に対して脆弱になります。このような障害中に、署名の失敗が広範囲で、公開で確認され、インターネット上のすべての検証リゾルバーに等しく影響を与えたため、これを受け入れ可能と判断しました。
内部インシデントルームで述べられたように：「現在.de名を解決している1.1.1.1のユーザーで、検証されていないレスポンスよりもSERVFAILを好む人はいません。」
私たちはUTC 22:17に緩和策をロールアウトしました。これは1.1.1.1への影響の終了を示しました。私たちはこれをDNS-OARC Mattermostで他のDNSオペレーターと通信しました。
オリジン解決の緩和
すべてのインターネットユーザーが1.1.1.1リゾルバーにアクセスできますが、CDNプラットフォームサービスを使用している顧客に対して特別な責任があります。.deオリジン名を持つ顧客もこの障害の影響を受けました。
Cloudflareは、公開利用可能な1.1.1.1サービスとは異なる、オリジン解決用の別の内部リゾルバーを運用しています。影響を緩和するために、内部リゾルバーサービスで.deに対して同様のNTAを適用し、影響を受けた顧客のオリジン接続を復元しました。
Extended DNS Errors
緩和策の前に、キャッシュから提供できなかったクエリは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検証の失敗ではなく、アップストリームネームサーバーとの接続の問題を示唆しています。
原因は、信頼チェーン検証器からDNSSEC EDEコードを伝播する方法のバグです。検証器が不正な署名を検出すると、DNSSEC Bogus EDEコードを作成しますが、これはレスポンスに挿入されることはありません。代わりに、リゾルバーの外側のレイヤーは再帰的解決に問題があり、エラーコードがなく、「No Reachable Authority」を報告することにフォールバックします。これは基礎となるDNSSEC原因を曖昧にします。
1.1.1.1ユーザーにとってこれが役に立たないことを認識しており、DNSSEC エラーを表示するようにレスポンスを修正します。
DNSSECは技術として失敗したのか？
DNSはほとんどのインターネット通信のリクエストチェーンの重要な部分です。この障害と適用された緩和策がDNSSECが技術として失敗したことを意味すると結論付けるのは簡単です。
しかし、設定ミスされたテクノロジーは、それに依存するユーザーに対して破損するリスクがあります。サメが噛むために海底に露出した重要な光ファイバーケーブルを放置することは、今日のインターネット通信における水中ケーブルが果たす重要な役割を無効にしません。それは、私たちがそれを正確に保護することに失敗したことを強調しているだけです。
同じことがここにも当てはまります。DNSSECは、悪意のある行為者による改ざんなしにDNS応答に依存できることを確保する上で重要な役割を果たしています。
#HugOps
誰も深刻な障害を好みません。残念ながら、これらのことは重要なインフラストラクチャを大規模に運用している誰もが経験します。それが起こるとき、DNSコミュニティは互いに現れる傾向があります。
このような障害は、オペレーター間の関係が重要である理由も強調しています。DNSは分散型システムであり、単一の組織がそのすべてを制御しておらず、それを確実に実行し続けることは、レジストリ、リゾルバーオペレーター、およびより広いコミュニティ間の相互信頼とオープンな通信ラインに依存しています。
DNS-OARCのようなフォーラムは、まさにこれを提供します：共有メーリングリストとチャットルーム。オペレーターは、何か問題が発生したときに組織の境界を越えて迅速に調整できます。
DENICは障害に関する短いブログ投稿を公開しており、次のように述べています：「障害は定期的にスケジュールされた鍵ローテーションに関連しています。このプロセス中に、検証不可能な署名が生成および配布されました。予防措置として、正確な技術的原因が特定されるまで、将来のローテーションは中止されています。」
彼ら自身の分析が準備できたときに、もっと聞くことを期待しています。
この障害からの教訓
この障害は、DNS階層の構造的現実を強調しています：TLDレベルのレジストリが失敗すると、そのTLDの下のすべてのドメインが影響を受けます。