要約

  • RFC 5155 は、対象となる未署名委任を、Opt-Out フラグ付き NSEC3 レコードが覆う区間から個別に列挙しない運用を認めている。
  • そのレコードは、覆われた安全でない委任が存在するか否かを主張しない。認証する否定の範囲は、見た目より狭い。
  • 安全な委任に必要なのは署名された DS RRset と検証済みの信頼連鎖であり、近傍の NSEC3 署名が有効という事実だけでは足りない。
  • 運用記録は「DNSSEC 成功」と一括表示せず、安全、安全でない、bogus、判定不能を区別しなければならない。

あるリゾルバーのトレースで、すべての RRSIG が検証に成功し、NSEC3 のハッシュ区間も整合し、画面が緑になったとする。後の監査出力が、その緑の行を「子委任は保護済み」と要約した。しかし照会名は Opt-Out 区間内にある。証明は真正でも、結論は証明の射程を越えている。

これは特定のレジストリや運用者に関する事故例ではない。暗号検証の成功は、署名されたレコードが実際に述べている内容を拡張しないという、一般的な範囲の問題である。

Opt-Out が変えるもの

RFC 5155 は NSEC3 を、存在しないことを認証するハッシュ化方式として定義する。ゾーンは平文の所有者名を順番に並べる代わりに、ハッシュ順で次の所有者を指すレコードを署名する。

委任が多いゾーンで、未署名の各子ゾーンについて NSEC3 レコードと署名を維持するのは負担になり得る。Opt-Out は条件を満たす安全でない委任の所有者名を省略できる。フラグが立った NSEC3 レコードは、その区間にゼロ個以上の未署名委任を含み得るため、その部分のチェーンを作り直さずに委任を追加または削除できる。

この運用上の節約は証明の意味を変える。RFC 5155 が明示するとおり、Opt-Out NSEC3 レコードは、覆い得る安全でない委任の存在も不存在も主張しない。区間内の別の権威データについては認証済みの命題を示せるが、未署名の子ゾーンは完全な暗号学的目録から意図的に外されている。

有効な証明でも結果は「安全でない」になり得る

委任点では親ゾーン側の証拠が決定的である。RFC 5155 は、NS RRset に署名済み DS RRset が伴うものを安全な委任、NS はあるが DS がないものを安全でない委任として区別する。DS が親の認証済みデータと子の DNSKEY を結ぶ。

NSEC3 の RRSIG を検証できたことは、親がその NSEC3 命題に署名したことを証明するだけだ。覆われた子の DS を作り出すわけではなく、Opt-Out ビットだけで特定の委任の存在が示されるわけでもない。RFC 7129 は、Opt-Out レコードでは覆われる安全でない委任の存在を証明も否定もできず、それらの委任は DNSSEC の暗号学的保護を受けないと整理している。

したがってリゾルバーは、緑色の暗号プリミティブだけで分類してはならない。委任点を特定し、DS を見つけるかその不在を認証し、該当する NSEC3 証明を評価し、信頼連鎖がある場合に検証を続ける必要がある。

証明の範囲を結果から切り離さない

証拠には照会、応答コード、ゾーン、委任点を残す。NSEC3 では、ハッシュアルゴリズム、反復回数、salt、所有者ハッシュ、次所有者ハッシュ、タイプビットマップ、Opt-Out フラグを保存する。closest provable encloser が否定証明に使われた場合は、その材料と DNSKEY、RRSIG の各検証結果、信頼アンカーも必要になる。

キャッシュと時刻も結論の一部だ。TTL、署名の開始・失効時刻、親ゾーンの公開状態、リゾルバーのキャッシュ年齢が観測の有効範囲を決める。後から DS が追加または削除されれば、古い証拠が監査庫に残っていても委任の安全状態は変わる。