要点

  • draft-ietf-dnsop-dnssec-keyrestore-02が扱うのは、利用可能なバックアップなしに秘密鍵が操作不能となる一方、完全な事前署名済みゾーンと有効な署名が残る場合である。
  • 安全な復旧には、RRSIGの失効、子側DNSKEYの伝播、親側DSの掲載、セカンダリの再読込、キャッシュの退役という別々の時計がある。署名者だけで全部を進めることはできない。
  • 各遷移の権限、計算、観測証拠を分けた「復旧時計の受領記録」を残すべきだ。これはDaniel Kadeのガバナンス提案であり、IETFの要件ではない。

この事故では「まだ名前が引ける」が安心材料にならない。古いRRSIGが有効な間、バリデータは整合したDNSKEY、署名、親のDSを組み合わせられる。しかし新しいアドレスや緊急のメール設定を安全に署名できないなら、ゾーンは稼働しているのではなく、過去の状態に凍結されている。

2026年8月10日公開のDNSSEC Key Restore第02版は、DNSOPワーキンググループのActive Internet-Draftである。レンダリング文書ではInformationalを意図しているが、まだ更新、置換、失効があり得る作業文書だ。RFCでもBCPでもなく、著者が所属するRIPE NCCのサービス約束でもない。対象は事前署名方式であり、オンライン署名とルートゾーンは明示的に対象外である。

ここで復旧するのは失われた秘密鍵ではない。バックアップがなければ元の秘密鍵は戻らない。新しい鍵を導入し、古い公開鍵と署名を必要な期間だけ残すことで、ゾーンを再び署名できる状態へ移す。

「操作不能」と「危殆化」を分ける

草案のinoperableは、秘密部分が署名を生成できない状態を指す。機器故障、災害、操作ミス、悪意ある行為が原因になり得る。秘密鍵が漏えいしても署名できるなら、それは別の問題だ。操作不能は継続性を脅かし、危殆化は攻撃者による署名の可能性を加える。分類を誤れば、残すべきものと止めるべきものを逆にしかねない。

障害発生時点でゾーンは正しく署名され、配信されている場合がある。RRSIGの有効期間が数日残ることも多い。ただし、それは保証された復旧時間ではない。実際の余裕は、各RRsetの署名失効時刻、配信中の内容、リゾルバが保持する組合せで決まる。設定上の標準寿命ではなく、最も早い実データの境界を調べる必要がある。

この間に署名ソフトが秘密部分のないDNSKEYを自動削除すれば、まだ必要な検証材料まで失う。草案は古いDNSKEYを残し、古いRRSIGも保持するよう求める。実装が削除する場合には手動で戻す場面もある。生産能力を失った鍵でも、キャッシュが旧署名を参照する間は信頼の部品である。

ZSK障害では子側の伝播が時計になる

ZSKが使えずKSKが使える場合、新しいZSKをDNSKEY RRsetに追加し、動作中のKSKでその集合を署名できる。だがプライマリに鍵が現れた瞬間を「Ready」とは呼べない。権威サーバへの伝播時間とDNSKEY TTLを待つ必要があり、草案はIpub = Dprp + TTLkeyと表す。

その後、新ZSKでゾーンを署名する。旧ZSKの撤去はさらに後だ。署名処理、ゾーン伝播、旧RRSIGがキャッシュから消える期間を合わせ、Iret = Dsgn + Dprp + TTLsigを満たさなければならない。障害、公開、準備完了、利用開始、撤去可能は別の状態である。

IETF 126の議事録には、ZSKだけを失っても継続性は失われないという指摘がある。重要なのは、その継続性を変更可能性と取り違えないことだ。既存応答が検証できても、ゾーン更新は新しい署名経路が整うまで止まる。

KSK障害では親の手続きが時計になる

KSKの置換は子ゾーン内だけで完結しない。新しい鍵への信頼には親ゾーンのDSが必要である。第02版はDouble-DSを使い、新DSを提出し、親で登録・公開されるのを待ち、伝播とDS TTLを経てから子側の新KSKを有効化する。

親での公開はTpub = Tsbm + Dreg、準備完了にはさらにIpubP = DprpP + TTLdsがかかる。RFC 7583も、親と連携するKSKの時刻はゾーン管理者だけの支配下にないと説明する。受付APIの成功は、DSが公開された証拠でもキャッシュが切り替わった証拠でもない。

CSKが操作不能なら、親側と子側の依存が重なる。CSKはDNSKEY集合とゾーンデータの双方に関わるため、新DSを先に安全に通し、新しい署名能力も戻さなければならない。旧CSKと旧RRSIGは、署名処理、子側伝播、DNSKEY TTLとRRSIG TTLの大きい方を含む退役期間まで残る。

自動化が止まると権限の所在が見える

通常時のCDS/CDNSKEYは、子から親へのDS保守を自動化できる。ところがZSKまたはCSKが署名できなければ、新しいCDS/CDNSKEY自体を通常の方法で検証できない。草案は該当するDS更新を手動経路へ戻す。

手動は無証拠を意味しない。DNSホスティング事業者は運用アカウントを、レジストラは顧客認証を、レジストリや親運用者は最終変更権を持つかもしれない。誰が子を代表し、誰が新鍵を検査し、誰が自動化の例外を承認し、誰が実掲載を確認したかを結ぶ必要がある。

セカンダリにも固有の問題がある。古い鍵で再署名できないSOAを変えずにDNSKEYを追加すると、IXFR/AXFRに依存するセカンダリが通常の更新を検知しない場合がある。そのときは各サーバへ強制ロードが必要だ。プライマリ一台の正しい応答は、権威系全体の一致を示さない。

DNSKEY RRsetの変更は既存ZONEMDダイジェストも無効にする。新しいダイジェストを作成し、署名し直さなければならない。草案のKnot DNS実装節は、記載された手順では手動の新規ダイジェスト生成をサポートしないと明記する。これは実装境界であって、製品一般の評価ではない。

IETF 126ではTTLと署名失効の比較を詳しくすること、実装例を示すことが求められた。発表者はKnot DNSで動作したと答え、議長は実装節を求めた。第02版の根拠はその分具体的になったが、複数実装間の相互運用性までは証明していない。

復旧時計を一枚の受領記録にする

開始時刻と終了時刻だけのインシデント票では足りない。受領記録はまず障害分類、鍵の役割、アルゴリズム、実際に配信中の署名の最短有効期限を記す。続いて旧DNSKEYとRRSIGの保持、新鍵が各権威サーバに現れた時刻、伝播測定、DNSKEY・DS・RRSIGのTTLを残す。

KSKやCSKでは、親への提出、本人性・権限確認、受付、公開観測、キャッシュ準備完了を別欄にする。セカンダリでは強制ロードした対象と観測内容を列挙する。ZONEMDでは新ダイジェストの有無、例外なら承認者と是正期限を示す。新規署名の完了、標本検証、旧材料の撤去可能時刻、実際の削除も分離する。

秘密を公開する必要はない。秘密鍵、HSM設定、個人情報は外に出さず、成果物ハッシュ、key tag、時刻、ポリシー版、観測RRset、組織上の責任主体で検証可能な連鎖を作れる。

全キャッシュを観測できるという主張も避ける。TTLは保守的な時間境界を与え、複数地点からの問い合わせは標本を与える。Dprp、TTLkey、TTLds、TTLsig、Dsgnの値が残れば、第三者は「なぜこの時点が安全か」を検討できる。計算根拠のない緑ランプでは検討できない。

提出済み、受付済み、公開済み、準備完了、利用中、撤去可能、削除済みは同義ではない。途中の一つを「復旧済み」と呼ぶと、証拠より先に結論が走る。

第02版は、残存署名を利用しながら署名機能を再建するための現実的な道筋を示す。しかし普遍的なRTO、親のSLA、全リゾルバの観測、監査様式は提供しない。ガバナンス上の核心は、残り時間が共有予算だという点にある。各時計を動かせる主体と、その進行を示す証拠が対応して初めて、復旧は説明可能になる。

出典

  1. DNSSEC Key Restore 第02版
  2. Datatracker文書ページ
  3. 文書履歴
  4. IETF 126 DNSOP議事録
  5. DNSOPの作業文書
  6. DNSOP憲章
  7. RFC 9364：DNS Security Extensions
  8. RFC 7583：DNSSEC鍵ロールオーバーの時刻設計
  9. RFC 8078：CDS/CDNSKEYによる親側DS管理
  10. RFC 8976：DNSゾーンのメッセージダイジェスト
  11. RFC 9499：DNS用語