要約

  • 署名済みゾーンと有効期限内の RRSIG が残っていれば、秘密鍵を失った後もしばらく Secure 応答は可能である。しかし、それは古い状態が検証できるという証拠であって、鍵の回収や新しい信頼経路の完成を示さない。
  • ZSK の復旧は Pre-Publication、KSK の復旧は Double-DS、CSK の復旧は退役待ちを延ばした Double-DS が中心となる。親と子、署名とキャッシュの時計を別々に追わなければならない。
  • 完了判定には、全権威インスタンスとセカンダリの装荷、DS と DNSKEY の TTL 通過、正負両方の独立リゾルバ検証、SOA・NSEC/NSEC3・ZONEMD の整合性、複数ネットワークからの業務確認が必要である。

復旧を支えるのは、残存する古い状態

秘密鍵が「inoperable」であるとは、信頼の連鎖にある DNSKEY の秘密部分が新しい署名を作れない状態をいう。鍵が漏えいしたものの技術的には署名できる状態とは異なる。また、ここで想定されるのは完全な署名済みゾーンがどこかに残っている場合だけである。権威サーバーから回収できることもあるが、動作するバックアップ秘密鍵がなければ鍵そのものは元に戻らない。再建できるのは、別の鍵による署名機能である。

この手順を扱う中心文書は draft-ietf-dnsop-dnssec-keyrestore-02 である。2026 年 9 月 13 日の確認時点で、IETF Datatracker はこれを DNSOP ワーキンググループの active Internet-Draft、revision 02 としており、最終更新日は 2026 年 8 月 10 日である。RFC ではなく、Informational を目指す作業中の文書で、内容は今後変わり得る。対象は事前署名方式であり、オンライン署名は扱わない。ルートゾーンも対象外である。新しいトラストアンカーが広く届くまでの時間が RRSIG の寿命を超え得るためだ。

故障直後も応答が Secure になり得る理由は単純である。権威サーバーが正しく署名された旧ゾーンを保持し、RRSIG の有効期限がまだ切れていないからだ。ところが、その時点で観測できるのは「過去に作られた署名が今も検証できる」という事実だけである。秘密鍵が存在すること、新しい RRset を署名できること、新鍵が全サーバーへ届いたこと、親の DS が更新されたこと、利用者のキャッシュが切り替わったことの証明にはならない。

猶予の終端は一つではない。重要な RRSIG の expiration、DNSKEY・DS・署名に残る TTL、親子それぞれの伝播時間、セカンダリの装荷遅延が重なって限界を作る。古い DNSKEY や RRSIG を不用意に削除したり、旧鍵では再署名できないレコードを変更したりすれば、運用者自身が猶予を短くする。したがって署名装置は明示的な指示まで DNSKEY を削除してはならず、古い RRSIG も維持することが望ましい。装置が旧署名を保持できない場合、旧 DNSKEY RRset の署名を除く旧 RRSIG を公開前に手作業で戻す必要がある。

最初に確保すべきものは、最後に正しかった署名済みゾーンの変更不能な複製である。DNSKEY、親 DS、全 RRSIG の inception と expiration、SOA、NSEC または NSEC3、ZONEMD を同じ時点で棚卸しする。障害対応中のアルゴリズム変更は、すでに進行中でない限り避ける。まず現行アルゴリズムで機能を取り戻し、その後に通常のアルゴリズムロールオーバーを行う方が、同時に変わる要素を少なくできる。

役割の違いが復旧手順を分ける

ZSK だけが使えず、KSK は使える場合

旧 ZSK で新しい署名を作れないため、初期段階ではゾーンデータを変更できない。使える方法は Pre-Publication である。Tpub に新 ZSK を DNSKEY RRset へ追加し、使えない旧 ZSK と、その鍵で作られた RRSIG を残す。KSK が使えるので、変更後の DNSKEY RRset には署名できる。

ただし、新しい DNSKEY を入れるためだけに SOA を変更するべきではない。変更された SOA を旧 ZSK で署名できないからである。既存レコードへの肯定応答が検証できても、存在しない名前や型への応答では NSEC/NSEC3 が古い状態と食い違い、bogus になる可能性がある。通常の serial 更新に依存するセカンダリには、新ゾーンを手動で転送または装荷させる必要がある。

新 ZSK の準備完了は、いずれか一台で見えた時点ではない。Ipub = Dprp + TTLkey を待つ。Dprp は全権威インスタンスへの伝播、TTLkey はキャッシュされた旧 DNSKEY RRset が残り得る時間である。Trdy = Tpub + Ipub になって初めて ready と判断できる。その後は新 ZSK で変更後のゾーンを署名し、旧 RRSIG を取り除けるが、旧 ZSK はまだ DNSKEY に残す。

旧 ZSK を退役できるのは、さらに Iret = Dsgn + Dprp + TTLsig が過ぎた後である。署名生成の遅延、権威側の伝播、最長の RRSIG TTL をすべて含む。Double-Signature も理論上は可能だが、データを変更できるまで Dsgn + Dprp + max(TTLkey, TTLsig) を要するため、復旧には遅い。

KSK が使えない場合

旧 KSK は変更後の DNSKEY RRset に署名できない。そこで子側から始める Pre-Publication ではなく、親側に新しい検証経路を先に作る Double-DS を使う。ZSK も同時に使えないなら、二つを一度に直さず、KSK 機能を先に復旧する。

新 DS を Tsbm に提出しても、まだ公開ではない。登録処理の遅延 Dreg を経て Tpub に親ゾーンへ現れ、その後 IpubP = DprpP + TTLds を待つ。DprpP はすべての親権威インスタンスへの伝播、TTLds は古い DS を保持するリゾルバキャッシュの寿命である。Trdy = Tpub + IpubP までは、新 KSK を安全に有効化する条件がそろっていない。レジストラやレジストリによる受理通知は、提出処理の証拠にすぎず、親ゾーン全体での公開や TTL 通過を証明しない。

有効化時には、新 KSK を子の DNSKEY に加え、新 KSK で DNSKEY RRset を署名する。旧 KSK は子の DNSKEY から外せるが、ZSK は残す。ZSK も故障している場合は SOA を保ち、セカンダリの装荷を確認したうえで、先の ZSK 手順へ進む。親の旧 DS は直ちに消してはならない。旧子 DNSKEY をキャッシュしているリゾルバのため、Tact から Iret = DprpC + TTLkey の間は維持し、最短でも Trem = Tact + Iret まで待つ。

CDS/CDNSKEY による通常の自動化も、この局面では成立しないことがある。ZSK または CSK が使えないと、新たに置く CDS/CDNSKEY を暗号学的に検証できない。さらに頂点へ新しいレコード型を加えると NSEC/NSEC3 の type bitmap が変わるが、その変更にも署名が必要である。親側の手作業または帯域外手続きが必要になる理由である。RFC 8078 と RFC 10026 は親子間自動化の基礎を示すが、自動化の通常経路が利用可能だという前提そのものを事故時には検証しなければならない。

CSK が使えない場合

一つの CSK が DNSKEY と通常のゾーンデータの両方を署名する設計では、二つの役割の待ち時間が結び付く。利用できるのは調整した Double-DS である。親に新 DS を公開し、Dreg と IpubP = DprpP + TTLds を完了してから、新 CSK を有効化する。

有効化時に新 CSK を追加して DNSKEY RRset を署名する一方、旧 CSK と旧 RRSIG は保持する。危険な SOA 変更は避け、全セカンダリを明示的に装荷させる。退役待ちは Iret = Dsgn + DprpC + max(TTLkey, TTLsig) である。Trem = Tact + Iret に達し、必要な観測がそろうまでは、親の旧 DS、子の旧 CSK、旧署名を一体として維持する。その後に三者を除去して初めて、通常のゾーン変更へ戻れる。

ゾーンの「同じ」をどう確かめるか

DNSKEY RRset を変更すれば、既存の ZONEMD digest は無効になる。変更後のゾーンについて新しい ZONEMD を生成し、DNSSEC 署名を付けなければならない。RFC 8976 が示すように、ゾーン内容、ZONEMD、ZONEMD を覆う RRSIG、NSEC/NSEC3 の構築には順序がある。ZONEMD が正しく検証できれば、その方式における内容完全性の証拠にはなるが、DS から DNSKEY、RRSIG へ続く信頼の連鎖や、実サービスの可用性を代替しない。

SOA serial の一致も、有用な版管理の手掛かりにとどまる。同じ serial は内容の暗号学的一致を保証しないうえ、復旧のため意図的に SOA を変えなければ、通常の NOTIFY、IXFR、AXFR の流れだけではセカンダリが更新を認識しない場合がある。マスター上のファイル変更を完了証拠にせず、測定可能な全 anycast バックエンド、unicast インスタンス、セカンダリに対して実際の DNSKEY、RRSIG、否定応答、ZONEMD を問い合わせる必要がある。

NSEC/NSEC3 の一つの応答が有効でも、それはある名前と型について一回の不存在証明が通っただけである。すべての type bitmap、すべての名前、すべてのサーバーが整合するとは限らない。同じく、新鍵による一つの RRSIG が検証できても、全 RRset の再署名、ZONEMD の一致、旧経路の退役可能性までは示さない。

観測点を増やしても、証明範囲は自動では広がらない

復旧証拠は時間順に積む必要がある。親側では、DS の依頼、受理、各権威サーバーでの公開、TTLds の経過を別の出来事として記録する。子側では、新 DNSKEY の publication、readiness、activation、RRset 全体の再署名、権威伝播、旧材料の retirement を分ける。この区別は RFC 7583 の状態モデルとも整合する。

次に、運用主体の異なる複数の検証リゾルバを使う。複数地域から、冷たいキャッシュと温まったキャッシュの両方で、通常の名前、存在しない名前、存在しない型、DNSKEY、DS を繰り返し問い合わせる。一台が Secure を返すのは、その瞬間の経路とキャッシュが正しかった証拠である。単一リゾルバのキャッシュを消して成功させても、世界中のキャッシュが TTL を越えたことにはならない。

最後にアプリケーションを測る。HTTP、TLS、ログイン、API 取引などが一回成功したことは、一つの利用経路が動いた証拠でしかない。DNSSEC を検証しないクライアントもあり、正しく解決してもトラフィック制御やバックエンドが誤っていることもある。新旧経路の重複期間から退役期間の終わりまで、複数ネットワークで DNS の結果とアプリケーション結果を対にして観測することで、初めて利用者側の連続性を評価できる。

観測値の読み方

観測した事実 そこから言えること まだ言えないこと
一台の権威サーバーに旧 DNSKEY と有効な旧 RRSIG がある その時点、そのノードの旧状態を検証できる 秘密鍵が残る、新署名が可能、全ノードが同一である
新 DNSKEY が一地点で見える 一つの公開点へ到達した 全権威への伝播と全旧キャッシュの消滅
新 DS が管理上受理された 申請が処理された 親ゾーンでの全面公開、TTLds 通過、リゾルバからの可視性
新鍵で一つの RRSIG が検証できた 特定 RRset の署名関係が正しい 全 RRset、否定証明、ZONEMD、退役条件が正しい
SOA serial が一致した 転送・版管理の手掛かり ゾーン内容の完全一致と全セカンダリの装荷
一つの独立リゾルバが Secure を返した その経路とキャッシュは検証できた 世界的なキャッシュ収束
アプリケーションが成功した 一つの業務経路が動いた 全利用者への連続性と DNSSEC 移行完了

実装面にも不確実性は残る。中心文書は Knot DNS で手順を検証したとしているが、手作業を含み、その経路では新しい ZONEMD digest の手動生成が支援されないとの注記もある。一つの実装試験を、全製品や全構成の対応証明に広げてはならない。また、式が保守的な安全幅になるのは、最大 TTL と伝播遅延を把握し、実際の公開を確認した場合だけである。列挙できないリゾルバキャッシュは、数学的な時刻を観測上の確実性へ自動変換してくれない。

復旧完了とは、秘密鍵を取り戻すことではない。それは、失われた署名能力を新しい鍵へ移し、古い検証経路を必要なだけ残し、最後に依存が消えたと証明してから閉じることである。古い状態を早く片付けることより、古い状態がいつ不要になったかを説明できることの方が重要だ。

参考資料