要約

  • RFC 8901はIETF合意によるInformational文書であり、Standards Trackの義務でも、特定事業者の実装証明でもない。
  • 二つのモデルはいずれも、各事業者のDNSKEY RRsetに全署名者の有効ZSKを含める。これがなければ、リゾルバーはAの鍵をキャッシュしたままBの署名を受け取り、フェイルオーバー時に応答を拒否し得る。
  • ゾーン所有者は障害前に、公開鍵交換、KSKと親DSの接続方式、共通アルゴリズム、鍵更新の時間軸を調整する。第二事業者は、その証拠がそろうまでは候補経路にすぎない。

応答経路は残り、検証経路は切れた

二社が同じゾーンを独立に署名して提供するとする。検証リゾルバーはsecure delegationをたどり、Provider AからDNSKEY RRsetを取得し、親DSで認証してキャッシュする。その状態が有効なうちにAへ到達できなくなり、リゾルバーはBへ問い合わせる。Bは自社ZSKで署名したRRSIGと回答を返す。

Bは稼働中である。それでも、Aから得たDNSKEY集合にBの有効ZSKがなければ、その署名を検証できない。別の権威を再試行して遅延が増えるか、再試行上限に達するか、下流クライアントが先にタイムアウトする。RFC 8901はリゾルバーを変更しない。通常の検証が経路変更を越えられるよう、署名者側の公開状態をそろえる。

別ネットワーク、別契約、複数NSは権威到達性の候補を示す。しかし、Aで認証した鍵ビューがBの署名を検証できるとは示さない。暗号学的な経路も切り替わって初めて冗長性が成立する。

二つの保管モデルと一つの不変条件

Model 1では、ゾーン所有者が共通KSKと親DSを管理し、各事業者は固有ZSKを持つ。所有者は全ZSK公開鍵を集め、統合DNSKEY RRsetを作り、共通KSKで署名して全事業者へ配る。鍵が不変でもDNSKEYのRRSIG期限前には再署名と再配布が必要だ。

親の入口は一つで、どの事業者も同じ署名済みオブジェクトを返せる。一方、KSK保管、定期署名、API権限、配布が共通障害面になる。一か所の古いコピーだけで、鍵管理上の成功は分裂状態へ変わる。

Model 2では、各事業者が固有KSKとZSKを持つ。互いの公開ZSKを自分のDNSKEYへ取り込み、自分のKSKで署名する。親DSは各KSKへのDSを含む。秘密鍵保管は分散するが、公開状態は増える。AのKSK更新は親DSを変え、AのZSK更新は他社が公開すべきDNSKEYを変える。

鍵更新は分散トランザクションである

Model 1でAが新ZSKを生成しても、すぐには使えない。所有者が取得し、統合集合に追加し、署名し、全事業者へ展開する。すべての権威面への伝播とDNSKEY TTLが終わってから有効化する。旧鍵の削除は、その鍵で署名されたデータと最長TTLが不要になるまで待つ。KSK更新は親DSの公開とキャッシュも横断する。

Model 2でも、Aは新ZSKを所有者へ渡し、Bなど全署名者へimportさせる。import、双方の全権威面への伝播、DNSKEY TTLが終わるまで通常データへの使用を待つ。旧鍵の撤去も逆向きに同じ連携を行う。

「鍵を作った」「APIが200」「一度DNSKEYが正しかった」は完了証拠ではない。export、所有者受領、全社import、全権威面の公開、TTL経過、各社回答を使う独立検証、その後の有効化または撤去を時系列で残す必要がある。

アルゴリズムと否定応答

参加事業者は共通のDNSSEC署名アルゴリズム、または同一のアルゴリズム集合を使う。DNSKEYに複数アルゴリズムがあれば、RFC 4035の署名要件がゾーンRRsetに及ぶ。互換性のない選択は二社構成だけでは解消しない。

NSEC/NSEC3の否定証明は応答内で完結するため方式を混在させること自体は可能だが、NSEC混在はNSEC3の列挙耐性を弱め、恒常的な差異は負キャッシュ効率を落とし得る。RFC 8901は単一方式を好み、統一できない場合も差異を最小化する。

A/AAAAだけの確認では足りない。正の応答が通っても、存在しない名前や型の問い合わせが別の署名・証明・キャッシュ経路を露出させる。

この文書が証明しないこと

RFC 8901は、特定事業者のAPI、外部ZSK import、実運用、障害、可用性改善、採用率を証明しない。DNSSEC validationも商業上の委任、アプリケーション健全性、トラフィック切替を証明しない。観測したデータ、署名、鍵、信頼連鎖の限定された関係を示すだけである。

したがって結論は狭い。第二事業者の購入は依存を一つ減らす可能性がある。最初の事業者が消える前に、所有者が共通鍵ビュー、親DS、アルゴリズム、更新時間軸を再現できて初めてDNSSEC冗長性になる。

情報源