要約

  • DENIC が公表した最終報告によれば、2026年5月5日の.de DNSSEC 障害は、4月に運用入りした第3世代署名システムの ZSK ロールオーバー処理で、社内製ロールオーバーエージェントが複数の HSM に同一の鍵対を配布せず、HSM ごとに異なる鍵対を作ったことに起因した。複数の鍵は同じメタデータと鍵タグ33834を持ったが、公開された DNSKEY に対応する秘密鍵を保持していた HSM は一つだけだった。
  • その結果、有効だったのは当該 HSM が生成した署名だけであり、DENIC は実務上およそ3分の1の署名が検証可能だったと説明している。この比率は署名出力の関係であって、.de ドメイン、利用者、トラフィック、問い合わせ、可用性の割合ではない。問題は、分散した権威 DNS サービスが、無効な共有署名状態を全体に広げる前に止められたかどうかである。

2026年5月5日夜から6日未明にかけての.de 障害は、単純な停止ではなかった。権威 DNS の応答が物理的に消えたというより、DNSSEC の信頼の連鎖の下で、署名されたデータが検証に耐えない状態になった。DNS における委任は、親ゾーンが子ゾーンへの案内を返し、再帰リゾルバがその情報をたどることで成立する。DNSSEC が有効な環境では、単に応答が返るだけでは足りない。DNSKEY、RRSIG、DS、NSEC3 などの関係が、公開された信頼の連鎖と一致していなければ、検証するリゾルバはそのデータを「使ってよい名前解決情報」として扱わない。

この事件で重要なのは、.de という大規模なトップレベルドメインの権威サービスが、地理的に分散され、ネットワーク的にも分離された拠点を持ち、複数の HSM を使っていたにもかかわらず、共有されるべき署名状態が壊れた点である。anycast、複数サイト、複数 HSM は、ノード障害、経路障害、設備障害への耐性を高める。しかし、それらの各地点が同じ暗号的に無効な状態、または相互に整合しない状態を配布するなら、冗長性は継続性ではなく障害の複製になる。名前空間の運用責任は、サーバーが多いことでは終わらない。公開前の完全な検証、異常時に配布を止める権限、既知の正しいゾーンへ戻す手順、そして外部から確認できる復旧証拠までを含む。

このため、本番トポロジーとの同等性は、ラック数や拠点数の比較ではなく、どの署名源がどの鍵状態を持ち、どの候補ゾーンをどの順序で署名し、その成果物が公開前にどの検証者へ渡るかという関係で評価されるべきである。権威 DNS の配布網が堅牢でも、署名候補を作る段階で HSM ごとの状態が分岐し、その分岐が候補ゾーンの承認過程で見えないなら、配布能力は統制の代わりにならない。運用環境の強さは、障害時にも応答を返せるかだけでなく、返してよい応答だけを公開できるかで測られる。

DENIC の公式な時系列は慎重に扱う必要がある。同社の解決告知は、5月5日21時57分から顕著な影響があったとし、6日00時08分に正しいゾーンの配布が始まり、01時15分までに以前の運用状態が復元されたと説明している。これは DENIC が自ら示した登録管理側の運用区間である。一方、Cloudflare は自社の1.1.1.1リゾルバ側の観測として、より早い段階で検証失敗を確認したと説明している。両者は観測点が違う。Cloudflare の時刻を DENIC の内部障害開始時刻に置き換えることも、DENIC の21時57分を世界中の利用者における唯一の開始時刻にすることもできない。記事で扱うべきなのは、登録管理側の正式な経過と、再帰リゾルバ側から見えた検証失敗を分けて記録することである。

技術的な中核は、ZSK ロールオーバーにある。ZSK はゾーン内のレコードセットに署名する鍵であり、ロールオーバーでは新旧の鍵、署名、公開 DNSKEY、キャッシュ、検証者の挙動が正しい順序で移行しなければならない。DENIC の最終報告によれば、問題の署名システムは Knot DNS、社内製コンポーネント、複数の HSM を組み合わせた第3世代のシステムで、2026年4月に運用へ入った。障害は、通常の DNSSEC 鍵ロールオーバー中に発生した。同社は、Knot DNS の不具合、HSM の不具合、侵害、古典的な鍵タグ衝突を原因から除外している。この境界は重要である。ここで起きたのは、同じ鍵タグ33834を持つ複数の異なる鍵素材が、ロールオーバーエージェントの誤った動作によって生まれた状態であり、単に二つの独立した鍵が偶然同じタグになったという話ではない。

公開ゾーンには一つの DNSKEY だけが書き込まれた。しかし、その DNSKEY に対応する秘密鍵を持っていた HSM は一つだけだった。他の HSM は同じ鍵タグとメタデータを持ちながら、異なる秘密鍵で署名を作った。検証側から見れば、鍵タグの表示やメタデータだけでは十分ではない。RRSIG は、公開された DNSKEY と暗号的に対応していなければならない。対応する秘密鍵で作られた署名だけが検証に通る。DENIC が「実務上およそ3分の1の署名が有効だった」と説明するのは、この署名生成の関係を指している。3台相当の署名源のうち一つだけが公開鍵と一致する署名を作れた、という種類の説明であり、3分の1の.de ドメインだけが動いた、3分の1の利用者だけが影響を免れた、3分の1の問い合わせが成功した、という意味ではない。

ここで必要になる証拠は、単に「HSM が応答した」という稼働証跡ではない。HSM ごとに、どの鍵素材が存在し、それがどの公開 DNSKEY に対応し、どのゾーンシリアルまたは候補ゾーンに対してどの RRSIG を生成したのかを結び付ける記録が要る。鍵タグとメタデータが同じであることは検索や運用上の識別には役立つが、暗号的な同一性の証明ではない。候補ゾーンの検証では、HSM 別の署名出力を公開鍵に照合し、照合に失敗した署名源を公開経路から外す、または候補全体を不合格にする処理が必要になる。そうした証拠がなければ、複数 HSM 構成は鍵素材の分散保管を示しても、共有された署名状態の正しさを示さない。

さらに、ゾーン更新が進むなかで SOA レコードも変更され、再署名された。したがって、検証結果は時間とレコードの組み合わせによって揺れ得た。ある時点でキャッシュに残っていた署名、別の時点で権威サーバーから得た署名、リゾルバが検証した NSEC3 応答、SOA の更新状態は、同じ利用者体験として単純に平均化できない。障害の大きさを評価するには、権威側の署名出力、再帰リゾルバのキャッシュ状態、serve-stale の有無、DNSSEC 検証の有無、アプリケーションの再試行挙動を分ける必要がある。公開記録だけでは、全ドメイン、全利用者、全ネットワークの時系列可用性を精密に測ることはできない。

NSEC3 の影響も、この事故を単なる DNSSEC 利用ドメインの問題に限定できない理由である。NSEC3 は、存在しない名前や DS が存在しないことを認証付きで示すために使われる。親ゾーンである.de が、ある子ドメインに DS がないことを証明する場合、その否定応答にも署名が関わる。DENIC は、NSEC3 署名が無効になったことで、DNSSEC を使っていない子ドメインの委任情報であっても、検証リゾルバから見ると bogus と判定され得たと説明している。つまり、子ドメイン自身が DNSSEC 署名を運用しているかどうかだけでは、影響範囲を切り分けられない。親ゾーンの認証付き否定が壊れると、署名していない子への委任でさえ、検証するリゾルバの前では信頼できない情報になる。

この点は、DNSSEC の責任を誤って描かないためにも必要である。検証リゾルバが失敗したのは、任意の可用性方針で名前解決を止めたからではない。公開された信頼の連鎖に照らして認証できないデータを拒否したからである。DNSSEC の設計では、署名が検証できない状態を安全な応答として通すことは、信頼の意味を崩す。したがって、問題は「検証リゾルバが厳しすぎた」ことではなく、親ゾーン側が検証可能な署名状態を配布できなかったこと、または配布前に止められなかったことである。非検証リゾルバがデータを返し続けたことは、利用者から見ると一部の到達性を保ったように見えるが、それは DNSSEC の認証を使わない経路であり、署名済み名前空間の正しさを証明するものではない。

試験環境の境界は、今回の責任分析で最も具体的な統制点である。DENIC によれば、試験環境は一つの場所に一つの HSM を置く構成だった。障害を引き起こした条件は複数 HSM が接続されて初めて現れるものだったため、その試験環境では実行されなかった。既存の試験シナリオ、外部監査、コールド並行運用は、この運用環境固有の挙動を露見させなかった。ここから導かれる結論は、試験をしていなかったという単純な非難ではない。試験で再現したトポロジーが、実際の署名状態の分散、同時性、HSM 間の鍵素材共有、共通メタデータ、失敗時の意味論を十分に表していたかが問われる。

本番に相当する運用環境と試験環境の一致は、DNSSEC 署名システムでは単なる設備のぜいたくではない。単一 HSM で動くコードパスは、複数 HSM で同じ鍵素材を一貫して保持し、同じ公開 DNSKEY に対して署名を作ることを証明しない。単一の署名源が正しく動くことと、分散した署名源が同じ暗号状態を共有することは別の性質である。とくに鍵タグやメタデータの一致は、鍵素材の一致を保証しない。署名出力の検証、HSM ごとの鍵指紋、DNSKEY と秘密鍵の対応、ゾーンシリアル、RRSIG 生成元、公開承認の記録が、公開前に一つの検証可能な台帳として結び付けられていなければ、分散構成は安全性の証明にならない。

候補ゾーンの検証は、この同等性を実務に落とし込む場所である。ロールオーバーの候補は、DNSKEY が存在する、RRSIG が存在する、SOA が更新された、という部品ごとの確認だけでは足りない。候補ゾーン全体を、検証リゾルバが実際に見る形に近づけて、存在する名前、存在しない名前、DS がない委任、DNSSEC を使う子と使わない子の境界まで通す必要がある。そこで失敗した候補は、修正可能な作業物であって、公開可能な成果物ではない。公開承認は、署名処理が終了したという合図ではなく、候補ゾーンが複数の検証経路で通ったことを示す独立した判断であるべきだ。

検知と介入の差も、同じくらい重要である。DENIC は、三つの継続的な試験・検証ツールが、署名の欠落または検証不能な署名を意図どおり検知したと説明している。しかし、その通知が正しく処理されず、無効な素材が広い影響を生む前の介入につながらなかった。監視システムが正しい異常を記録したことは、統制が存在した証拠ではあるが、利用者を守った証拠ではない。重要なのは、どの検証失敗が公開を自動的に止められるのか、誰がアラートを所有するのか、何分以内に確認しなければならないのか、未確認の場合にどの権限が停止または差し戻しを発動するのか、そしてどの成果物が「配布してよい署名済みゾーン」として承認されるのかである。

リリースを止める権限が曖昧な監視は、重大インフラでは弱い。検証ツールが赤信号を出しても、それが担当者の通知箱に残り、公開処理を止めず、既知の正しいゾーンへの切り替えを促さなければ、検知は遅延した記録にとどまる。DNSSEC では、誤った署名済み状態が配布されたあと、再帰リゾルバのキャッシュ、否定応答、TTL、利用者側の再試行が絡むため、回復は単に修正ファイルを置くより複雑になる。だからこそ、公開前検証、公開停止、ロールバック、正しいゾーンの配布開始、以前の運用状態の復元を別々に記録する必要がある。

公開停止の設計では、アラート所有者とリリース権限者の関係も明確でなければならない。アラートを受けた担当者が原因を完全に説明できるまで待つ設計では、署名済み状態の配布が先に進み得る。必要なのは、原因究明とは別に、検証不能な候補を配布しないための停止条件である。停止条件は、手動判断を排除するという意味ではなく、未確認のまま公開が進む経路を閉じるという意味である。候補ゾーンの検証失敗、HSM 別署名出力の不一致、NSEC3 否定応答の検証失敗、外部観測での bogus 判定は、それぞれ公開承認を保留する明示的な根拠になり得る。

Cloudflare の対応は、登録管理側の修復とは別の層にある。同社は、自社リゾルバで stale データを使うことで一部の影響を和らげ、権威側の署名問題を確認した後、.de に対して一時的な DNSSEC Negative Trust Anchor を適用したと説明している。Negative Trust Anchor は、壊れた署名済みゾーンを一時的に未署名のように扱う、ローカルで期限付きの例外である。この手段は、検証不能な状態で利用者の名前解決を回復させる可能性がある一方、セキュリティ判断を再帰リゾルバ運用者の側へ移す。したがって、これは DNSSEC を無効にすることが一般的な回復策だという根拠ではない。期限、対象、確認条件、再検証がある場合に限られる例外であり、登録管理側の署名状態を修復する代替にはならない。

serve-stale も同様に、権威側の障害を消す仕組みではない。期限切れに近い、または期限切れのキャッシュ済みデータを条件付きで使うことで、短時間の上流障害に対する利用者影響を緩和できる。しかし、キャッシュに残っていた内容、問い合わせ対象、リゾルバ設定、TTL、検証状態によって効果は変わる。あるリゾルバ利用者にとって到達性が保たれたとしても、それを.de 全体の可用性測定に置き換えることはできない。再帰リゾルバ側の緩和は、権威側の署名済み状態が壊れたという事実と、登録管理側がどの時点で正しいゾーンを再配布したかという事実を分けて評価しなければならない。

再帰側の緩和には、境界を越えない慎重さが必要である。Negative Trust Anchor や serve-stale は、検証不能な状態を正しい状態に変えるものではなく、利用者影響を一時的に抑えるための局所的な判断である。対象ゾーン、開始条件、終了条件、再検証、利用者への説明がなければ、緩和策は権威側の修復責任を曖昧にする。逆に、境界が明確であれば、再帰運用者は利用者の到達性を守りつつ、登録管理側の署名状態が回復したかどうかを別の証拠として扱える。ここでも重要なのは、可用性と認証のどちらか一方を絶対化することではなく、どの層がどの例外をいつ終えるかを記録することである。

この事故のアカウンタビリティは、個人攻撃ではなく、制御面の対応関係として整理すべきである。DENIC は.de の親ゾーン、権威 DNS、DNSSEC 署名運用、委任情報の正確性に対する中心的な記録保持者である。署名システムの所有者は、ZSK 生成、鍵素材の共有、DNSKEY 公開、RRSIG 生成、ゾーン更新を一貫した状態として保証する責任を持つ。HSM 運用者は、HSM が正常に動くかだけでなく、複数 HSM の鍵状態が同じ公開鍵に対応しているかを示す責任を持つ。試験環境の所有者は、単一 HSM の試験で十分と判断した理由、複数 HSM 特有の状態分裂をどう試験するか、今後どの条件を事前に実行するかを説明する必要がある。

リリース権限を持つ組織または役割は、検証不能な署名が検出されたときに、公開処理を止める責任を負う。単に監視ツールがあるだけでは足りない。公開前の候補ゾーンに対する全鎖検証、HSM 別署名出力の照合、NSEC3 否定応答を含む代表的な委任応答の検証、外部ネットワークからの検証、そして失敗時の停止条件が明文化されていなければならない。インシデント指揮は、検知、判断、停止、配布、告知、復旧確認の各時刻を分けて記録し、後から再現できる形で残す必要がある。広報は、利用者に対して「どの層が壊れたのか」「どの種類のリゾルバで影響が出るのか」「復旧とは何を意味するのか」を混同せず伝える責任を持つ。

再帰リゾルバ運用者にも独自の制御面がある。検証を行うリゾルバは、bogus な応答を拒否することで信頼の連鎖を守る。一方、serve-stale や Negative Trust Anchor を使う場合、その判断は一時的で、局所的で、監査可能でなければならない。対象ゾーン、開始時刻、終了条件、再検証、利用者影響、セキュリティ上の例外範囲を記録しなければ、緩和策自体が別のリスクになる。権威側が壊れたとき、再帰側がどこまで利用者保護のために例外を使うのかは、事前に設計された運用判断であるべきで、場当たり的な永続化であってはならない。

DENIC が公表した対策一覧は、重要な出発点である。同社は、コード確認の強化、アラート処理の改善、有効なゾーンへの切り替えの高速化、配布前の部分的な検証、追加作業が終わるまでのさらなる ZSK ロールオーバー停止、試験環境の拡張、外部によるセキュリティおよび手順の分析を挙げている。これらは妥当な方向を示すが、公表された時点では、すべての統制が完了し有効に機能したことの独立した証明ではない。後続の検証で必要になるのは、実装記録、複数 HSM 構成での試験結果、アラート訓練の結果、公開停止の実演、既知の正しいゾーンへの切り替え時間、外部からの検証ログである。

現在の制御スタックを評価するなら、第一に、署名前の鍵生成と鍵配布の不変条件を明示する必要がある。同じ鍵タグを持つだけでは不十分であり、同じ DNSKEY に対応する秘密鍵が、署名に参加するすべての HSM に正しく存在することを確認しなければならない。第二に、署名後のゾーン候補を、公開前に完全に検証する必要がある。DNSKEY、RRSIG、SOA、NSEC3、委任応答、DS 不在証明を含め、検証リゾルバが見る現実に近い形で確認するべきである。第三に、検証失敗は通知ではなくブロック条件でなければならない。担当者の判断を待つ場合でも、未確認のまま配布が進まないようにする設計が要る。

第四に、運用環境と同等の試験構成が必要である。単一 HSM の試験環境は、複数 HSM で異なる鍵素材が作られる故障モードを検出できない。少なくとも、HSM 数、接続関係、鍵配布手順、署名担当の選択、ゾーン公開までの流れが、実際の運用に近い条件で試されるべきである。第五に、ロールバックは「戻せるはず」という手順書ではなく、検証済みの成果物と所要時間で評価する必要がある。正しいゾーンの配布開始が00時08分、以前の運用状態の復元が01時15分という DENIC の時系列は、切り替え開始と状態復元を分けて見る必要があることを示している。将来の統制では、この間隔を短縮できるか、どの条件で自動または半自動に移れるかが問われる。

ロールバック訓練では、戻す先の成果物そのものが検証済みでなければならない。過去のゾーン状態へ戻すと言っても、公開 DNSKEY、対応する秘密鍵、RRSIG、SOA、NSEC3、委任応答がそろって検証に通る必要がある。さらに、配布開始と利用者側の回復観測は別の段階である。権威側が既知の正しいゾーンを出し始めても、再帰リゾルバのキャッシュ、否定応答、stale データ、例外設定が残るため、回復を一つの時刻だけで表すことはできない。訓練は、切り替え操作の速さだけでなく、検証側がいつ正しい状態を再び確認できるかまで含めて評価する必要がある。

第六に、外部検証を組み込む必要がある。権威側の内部ツールが検証したとしても、再帰リゾルバが実際に見る応答、異なるネットワークから見た検証結果、キャッシュと否定応答の相互作用は、内部だけでは測れない。独立した複数地点から候補ゾーンを検証し、公開後にも連続して検証し、問題があれば配布停止または切り戻しへつなげる設計が必要である。第七に、測定限界を正直に示す必要がある。公開記録には、欠陥コード、完全な配備図、HSM 選択の詳細、三つの検証ツールの生ログ、アラートの経路、ネットワーク別・ドメイン別・利用者別の影響、経済損失は含まれていない。これらを推測で埋めることは、技術的な責任分析を弱くする。

独立検証の限界は、批判を弱めるためではなく、正しい問いを残すために書くべきである。公開された資料からは、どの検証ツールがどの時点でどの署名を不合格にしたのか、アラートがどの経路を通り、誰が確認し、公開停止権限へどう接続されるはずだったのかまでは分からない。外部監査やコールド並行運用についても、公開記録だけでは、複数 HSM の分岐状態を実際に作って止めたかどうかを確認できない。したがって、結論は、未公開の内部事情を推測することではなく、次に必要な証拠を限定することに置くべきである。

この事故は、DNSSEC そのものの失敗として単純化すべきではない。DNSSEC は、壊れた署名状態を検証側に露出させた。検証リゾルバは、その露出を信頼できないデータとして扱った。問題は、署名を運用する側が、そのような状態を作り、配布し、検知したにもかかわらず、十分早く止められなかったことにある。DNSSEC を無効にすれば利用者が名前解決できた場面はあったとしても、それは信頼の連鎖を一時的に外す判断であって、登録管理側の正しい運用状態ではない。レジストリの継続性は、宣言や設備数ではなく、実行されるコード、公開される鍵、検証可能な署名、正確な委任記録、復旧可能な運用手順によって決まる。