要約

  • DNSSECの鍵更新は複数の状態を通る工程であり、鍵セレモニーの時刻だけでは表せない。
  • 権威DNSサーバー群への反映、キャッシュ失効、親DS、トラストアンカーの保留期間は別々に進む。
  • 有効な検証の組合せが旧鍵を必要とする限り、旧鍵は運用上まだ必要である。
  • 有効化、退役、削除はロールオーバー管理記録に基づいて判断する。

予定どおり終わった鍵セレモニーを想像してほしい。新しいDNSKEYは公開され、署名装置は正しい署名を作り、管理画面も成功を示す。計画時刻に旧鍵を削除すると、その後、一部の検証リゾルバー利用者だけがSERVFAILを受け始める。権威サーバー近くの監視は正常なままだ。

暗号が急に弱くなったのではない。運用モデルが複数の時計をセレモニーの時計に重ねてしまった。

RFC 7583 は鍵を、生成、公開、準備完了、使用中、退役、参照不要、削除といった状態で捉える。鍵は見えていても準備が整っていないことがある。使用中でも全リゾルバーが使えるとは限らない。退役後もキャッシュ内のデータが旧鍵を必要とする場合がある。安全とは、DNSKEY、RRSIG、KSKならDSの組合せが変化する間も、少なくとも一つの検証経路を保つことだ。

第一の時計は権威DNSサーバー群への反映である。プライマリーに新鍵を置いても、すべての権威DNSサーバーへ瞬時に届くわけではない。RFC 7583は準備完了までの区間に伝播遅延を含める。RFC 6781 のZSK事前公開も同じ考え方で、新DNSKEYを導入し、権威DNSサーバー群へ反映させ、DNSKEYのTTLが経過してから本番データの署名に使う。

第二の時計はリゾルバーのキャッシュにある。検証器は古いDNSKEY RRsetと新しいRRSIGを組み合わせることも、新しい鍵集合と古い署名を組み合わせることもある。採用した方式はその交差状態を検証可能に保たなければならない。事前公開では新鍵を使用前に待たせ、署名切替後も旧鍵を残す。二重署名では新旧の鍵と署名を重ね、応答サイズと引き換えに分かりやすい互換期間を作る。

第三の時計は親ゾーンの委任である。ZSK更新は一つのゾーン内で完結できるが、KSK更新は通常、子のDNSKEYと親が公開するDSをつなぐ。DSを親へ提出した事実は、DNSで公開された事実ではない。新DSを実際に観測し、旧DSのTTLを考慮し、後継経路が成立するまで従来の検証経路を維持する必要がある。

第四の時計は RFC 5011 に従う設定済みトラストアンカーである。新しいSEP鍵は保留状態から始まる。追加保留期間が終わった後、リゾルバーはその鍵を含むDNSKEY RRsetをもう一度取得して検証してから、トラストアンカーとして受け入れる。追加保留期間は30日または最初に観測したRRsetの元のTTL満了のうち長い方である。削除では、規定された失効または不在の観測を経てトラストアンカーがRemoved状態へ移り、その後も内部記録を30日間保持してから消去する。この保持期間はリゾルバー内のトラストアンカー状態に固有であり、ゾーンからDNSKEYを削除する一般的な許可ではない。この時計は検証器内部にあり、ゾーン運用者が直接進めることはできない。

四つは同じカウントダウンを表示する時計ではない。開始イベントも所有者も、証明する状態遷移も違う。「新鍵を公開済み」という表示だけでは有効化を認められない。一地点で署名検証に成功しても旧鍵削除の根拠にはならない。親の受付通知はキャッシュ失効を証明しない。30日が過ぎてもRFC 5011が求める後続取得が起きたとは限らない。

必要なのはロールオーバーの運用記録である。ゾーン、方式、鍵タグ、アルゴリズムを識別し、各状態への移行時刻を残す。観測地点ごとのDNSKEY、RRSIG、DS、TTL、伝播上限、署名有効期間を保存し、提出、権威DNSサーバー群での観測、キャッシュ失効を分ける。

RFC 5011対象には、トラストポイント、最初の検証観測、保留期限、受入れを完了する後続観測も必要だ。すべての対象で代表的なリゾルバー群の検証結果を記録する。各段階を進める権限者と、ロールバックを開始する証拠も明記する。

これにより完了の言葉が正確になる。「セレモニー実施」は管理作業の完了である。「新鍵が有効」は選択した方式で検証互換性が成立した状態である。「旧鍵を削除可能」は適用されるキャッシュやアンカーがもう依存していない状態である。日付が近くても、意味は同じではない。

情報源

RFC 7583 — DNSSEC鍵ロールオーバーのタイミング、RFC 6781 — DNSSEC運用実務、RFC 5011 — DNSSECトラストアンカーの自動更新。