要点

  • RFC 9083 は、親に DS レコードが存在する場合に delegationSigned を true と定義する。zoneSigned と DS または鍵データは、RDAP の secureDNS オブジェクト内で別々に扱われる。
  • このフィールドは登録証拠であり、ライブ検証結果ではない。DNSSEC の結論には、現在の親 DS、子の DNSKEY と RRSIG、権威サーバーの到達性、時刻上の有効性、特定したバリデーターの結果が必要である。

正確だが範囲の狭い真偽値

84.7.200.in-addr.arpa に対する LACNIC の RDAP 応答は、何を公開しているかを明確に示す。オブジェクトクラスは domain で、三つのネームサーバーを列挙する。secureDNS では zoneSigned と delegationSigned がともに false で、dsData は空の配列である。

これは取得時点で LACNIC が返した登録記録についての有用な証拠だ。しかし LACNIC 地域の全逆引きゾーンへ一般化できず、列挙されたサーバーの現在の稼働状態も示さない。応答にはリゾルバーのトレースも、検証を再構成できる DNS パケットも含まれない。

親の DS は連鎖の一部分

RFC 9083 は意味を意図的に分離する。zoneSigned はゾーンが署名済みかを示し、delegationSigned は親に DS があるかを示す。dsData はキータグ、アルゴリズム、ダイジェスト、ダイジェスト種別を記述でき、keyData は DNSKEY データを保持できる。

これらは登録データである。DNSSEC 検証は、特定時刻のライブ DNS 応答チェーンに対する処理だ。バリデーターは親 DS を取得し、子の DNSKEY と署名済みレコードを取得し、ダイジェストとアルゴリズムを照合し、署名と有効期間を確認し、到達不能や応答失敗を扱う。RDAP の真偽値は、これらの工程を暗黙に実行しない。

true でも false でも言い過ぎない

delegationSigned が true なら、裏付けられる表現は「RDAP 表現が親の DS 存在を報告している」である。子が対応する DNSKEY を公開していること、署名が現在有効であること、チェーンが信頼アンカーへ届くこと、特定リゾルバーで検証が成功することまでは証明しない。

false なら、フィールド定義上、親 DS がないと RDAP が表現している。欠如の理由、変更処理の途中かどうか、別の時刻でも同じかは分からない。正確な URL、応答バイト列、取得時刻を一緒に保存する必要がある。

二つの証拠面を別々に残す

登録面では RDAP domain の URL、ldhName、ネームサーバー一覧、secureDNS、DS・鍵配列、応答ハッシュ、取得時刻を保存する。運用面では親と子への DNS 問い合わせ、サーバーアドレス、応答コード、権威フラグ、DNSKEY、DS、RRSIG、バリデーター出力、時計条件を別に記録する。

現在の検証状態を述べられるのは、両方を比較した後だけである。それでも結果は指定した観測地点と時刻に限定される。暗号学的チェーンの成功だけで、所有権、契約上の権限、ホストの支配を確定することはできない。

情報源