要約

  • CDSとCDNSKEYは、子DNS運用者が望む委任パラメーターを表す。親側エージェントは、信号を認証し、委任された全ネームサーバーの全アドレスを調べ、二つの表現の整合性と検証経路の継続性を確認してからでなければ動けない。
  • NOTIFY(CDS)は発見を早めるだけで、変更を許可しない。受理、親ゾーンへの公開、旧キャッシュの失効、外部バリデーターによる観測には、それぞれ独立した証拠が必要である。

多数決にしてはいけない瞬間

鍵ロールオーバーの準備が終わり、新しいDNSKEY RRsetには正しい署名がある。CDSとCDNSKEYも期待どおりだ。運用画面は最寄りの権威サーバーを一度問い合わせ、「準備完了」と表示した。

親側エージェントはDSを変更しなかった。委任に含まれる各ネームサーバー名の全IPv4・IPv6アドレスへ問い合わせたところ、一つのセカンダリーだけが古い組を返したからだ。

これは特定事業者の障害報告ではなく、規則の意味を明らかにするための分析例である。新しい値が多数派でも、子が一つの明確な将来状態を提供したことにはならない。親側が多数決や更新時刻の推測で選べば、子の意思を受信するのではなく作り出してしまう。

この場面には複数の「公開」がある。プロビジョニング系への書き込み、権威サービス全体での提供、親DSの生成、親ゾーンへの反映、再帰キャッシュからの旧値消失は別の出来事だ。一つの緑色表示で束ねると、どこで状態が止まったのか説明できない。

子は親ゾーンを書き換えられない

DNSSECの委任では、親がDS RRsetを公開し、そのDSが子のDNSKEYを指す。子は自分のDNSKEY RRsetを公開して署名する。第三者のバリデーターは、この境界を越える連鎖を使う。

RFC 7344が定義したCDSはDS形式の情報を、CDNSKEYは親側がDSを計算できる鍵情報を子ゾーン頂点から伝える。どちらも「望む委任状態」を機械可読にする信号であり、親ゾーンに対するリモート書き込み命令ではない。

親側エージェントはレジストリ、レジストラ、再販業者などになり得る。登録者・レジストラ・レジストリの連鎖では、複数主体が親側変更を実行できる場合もある。そのときは、誰が受信し、どの経路を優先し、手動変更後に自動処理をいつ再開するかを明示しなければならない。

境界は子の自律性を否定しない。子は鍵、署名、権威配信を管理する。親は自分が署名して公開する信頼リンクに責任を持つ。共通規則は相互運用に必要な最小限の検査へ絞られるべきで、親に子の事業や配置を統治する権限を与えるものではない。

サーバー名ではなく全アドレスを見る

RFC 9975は整合性確認の対象を具体化した。親側エージェントは検証リゾルバーを使い、親の委任に記載された各ネームサーバー名の全IPアドレスを取得する。利用できるグルーレコードも含め、各アドレスに対象RRsetを問い合わせる。

一つのホスト名が複数のA・AAAAを持つことは普通で、anycastや複数DNS事業者は異なる配信経路を持つ。制御系での完成報告ではなく、委任が実際に外部へ提供する応答が検査対象である。

受信した応答どうしの整合性が必要であり、NODATAも応答に含まれる。不一致があれば処理を中止し、作成・変更・削除のいずれも実施しない。片方を新しそうだと推測する余地はない。

到達不能は不一致とは違う。後で再試行し、指数バックオフを使い、別ネットワークから確認することで、一時障害と恒常的な問題を分ける。監査記録も「応答なし」「値が矛盾」「DNSSEC検証失敗」を分離しなければならない。

CDSとCDNSKEYは同じ意思の二表現

CDSを処理すれば、子が選んだDSダイジェスト表現を使える。CDNSKEYを処理すれば、親が鍵からDSを計算してダイジェストを選べる。親の入力形式の好みを一般的に発見する仕組みはないため、RFC 10026は、好みが既知でない限り両方を公開するよう求める。

二つを公開する目的は互換性であり、二つの異なる提案を出すためではない。同じ鍵集合を示さなければならず、矛盾時には親がどちらかを選ばず拒否する。

暗号方式の判断はIANAのDNSSECアルゴリズムおよびDSダイジェスト登録を参照する。ソフトウェアに埋め込まれた古い前提を永久の規則にしてはならない。決定記録には、入力、計算結果、適用した方針の版を残す必要がある。

受理の核心は検証を切らさないこと

全サーバーが同じ信号を返しても、結果のDSが安全とは限らない。RFC 10026は、そのDSを配備した場合にDNSSEC検証が継続できることを確認し、失敗すれば変更を取り消すよう求める。

結果DSが参照する少なくとも一つの鍵で、子DNSKEY RRsetのRRSIGを妥当な方式で検証できなければならない。ロールオーバー中に新旧鍵を重ねるのは、旧DSを保持するキャッシュと新DSを見たキャッシュの双方へ経路を残すためである。

この検査が親側権限の正当な範囲だ。親は自分が公開する共通信頼リンクを壊さないようにする。子のDNS事業者、商流、鍵変更の商業的理由を承認する必要はない。追加の法的・暗号的要件があるなら、規則、版、責任者を示して再現可能にすべきだ。

Running-Code Primacyの観点では、文書の発行やレコードの存在だけで現実は変わらない。互換実装が検査し、親が公開し、稼働中のバリデーターが連鎖をたどれて初めて採用が確認される。

初回導入には別の認証経路が要る

すでに安全な委任なら、既存のDNSSEC連鎖で後続のCDS/CDNSKEYを認証できる。最初のDS登録では、その連鎖自体がまだない。子頂点の署名だけを根拠にすると、存在しない親リンクで自己認証する循環になる。

RFC 9615は、DNS運用者の署名済みシグナリングゾーンに置く認証信号を定義した。親側は権威ネームサーバーに結び付いたシグナリングゾーンを検証し、子ごとの_dsboot情報を用いて、まだ安全でない子のCDS/CDNSKEYを認証する。

ただし、非常に長い子名や、ゾーン内ネームサーバーだけを使う委任など対象外がある。製品は「自動化対応」だけでなく、認証済み初回導入、既存安全委任の更新、従来回復経路を分けて示すべきである。

削除にも明示信号がある。RFC 8078は、アルゴリズム0、ダイジェスト種別0、ダイジェスト00のCDSをDNSSEC削除要求として定義する。CDSが見えないことは削除意思ではない。配信遅延や設定ミスと区別できない沈黙から不可逆操作を推測してはならない。

通知は確認を始める合図

多数の子ゾーンを周期走査するだけでは発見が遅れる。RFC 9859のDSYNCにより、親は通知受付先を公表できる。子はCDS/CDNSKEY変更後、その宛先へNOTIFY(CDS)を送る。

通知が証明するのは「見に行くべき時」だけである。親側は改めて権威データを取得し、認証し、全アドレスの整合性を確認し、DSを計算して継続性を検査する。

通知が失われれば定期照合で後から見つけられる。重複通知は同じ結果を返すべきで、偽通知も権威データが変わっていなければDSを作れない。監視では、通知受信と変更受理を同じ成功値にしない。

親が公開してからキャッシュ移行が始まる

親側の受理応答は、ゾーン公開を証明しない。親の権威サーバーでDS指紋、ゾーン版、TTLを観測して初めて公開の証拠になる。

それでも再帰リゾルバーは旧DSをTTLまで保持する。移行期には観測地点によって親状態が違う。新旧どちらを見ても有効な鍵経路を維持する設計が必要だ。

RFC 10026は、変更直後の新DS TTLを一時的におよそ5〜15分へ下げ、ロールバックを速めるよう勧める。旧RRsetがキャッシュから消える時間を経た後で通常値へ戻す。新しい短いTTLは、すでに保存された旧値を書き換えない。

外部確認は旧TTLの期間を覆い、複数ネットワークの再帰リゾルバーでDS、利用DNSKEY、検証結果を記録する。一回の成功は一経路の証明であって、全世界の収束証明ではない。

自動化には独立した回復路を残す

鍵更新は例外ではなく通常保守である。顧客ポータルを守る一般的なレジストラ／レジストリ更新ロックだけを理由に、認証済みDS自動保守を止めるべきではない。

一方、自動経路を唯一の経路にしてもならない。署名鍵の喪失、事業者の非対応、移行中の複数送信者競合に備え、RFC 10026は手動を含む別のDS保守手段を要求する。

回復路は、失われた鍵や故障したDNS事業者から独立して認証でき、同水準の履歴を残すべきだ。手動介入後に自動処理を一時停止することはあり得るが、再開条件不明の永久停止にしてはならない。

情報源