要約
- NSECとNSEC3が認証するのは、署名済みゾーンの内容に関する具体的な否定命題である。証明は署名者、ゾーン境界、問い合わせ型、TTL、署名期間に拘束される。
- Opt-OutはDSを持たない委任をNSEC3チェーンから省略できる。署名区間が非セキュア経路を示しても、その区間の全名称が不存在だとは限らない。
認証された「ない」は永遠の不存在ではない
リゾルバーが存在しないアドレスレコードを問い合わせると、権威サーバーはNXDOMAIN、または名前は存在するが要求型がない応答を返す。署名済みゾーンなら、検証リゾルバーは信頼の連鎖、署名、NSECまたはNSEC3の否定証明を確認できる。
これにより、攻撃者が正しい応答を偽の否定へ置き換えることは難しくなる。ただしRFC 4035の射程は「署名済みゾーンにRRsetが存在しない」ことである。全履歴を検索した結論でも、ラベルの法的・契約的資格を判定した結果でもない。
同じ不在は、未登録、期限切れ、保留、プロビジョニング障害、委任移動、署名者の誤ったゾーン生成から生じうる。DNSSECは公開されたデータが信頼できる鍵から来たかを検証する。どの原因が正しいかは別の記録が必要だ。
NSECは並び順を証拠にする
NSECは既存のowner nameを正規順序で次の名前へ結び、自分の名前に存在する型をbitmapで示す。署名された区間は両端の間に別のowner nameがないことを証明し、bitmapは名前が存在しても特定型がないことを証明する。
したがってNXDOMAINとNODATAは異なる。前者は名前、後者は型を否定する。empty non-terminalは自分にRRsetがなくても子孫を持てる。wildcardがあれば、完全一致だけでなく、より近いwildcard候補がないことも証明対象になる。
検証結果は単純な「missing」ではない。どのゾーンが答えを持つはずか、どの区間が名前を覆うか、bitmapが何を示すか、wildcardが介在しないか、署名期間とDS/DNSKEY連鎖が有効かを積み上げた小さな論証である。
NSECの順序はゾーン列挙も可能にする。NSEC3はこの直接的な可視性を弱めるために導入された。検証可能性を高めるデータが、同時に運用構造を明かすことがある。
NSEC3のハッシュは秘密箱ではない
NSEC3は公開パラメータで名前をハッシュし、ハッシュ値の区間に署名する。リゾルバーはclosest encloser、問い合わせ名、wildcard候補を計算して証明を組み立てる。
直接読めなくても、予測可能な名前はオフラインで試せる。IANAレジストリで割り当て済みのNSEC3ハッシュは現在SHA-1だけである。RFC 9276は、反復回数を増やしても現代の推測攻撃を十分に止めず、署名側と検証側の負担を増やすと説明する。通常は反復ゼロ、空のsalt、列挙を問題にしないならNSECを選ぶという指針だ。
大きな数字を選ぶことと、共有安全性を高めることは同じではない。実装が何を守り、誰に継続費用を負わせるかで判断すべきである。
Opt-Outは意図的に未確定領域を残す
大規模な親ゾーンでは、DSを持たない子委任のたびにNSEC3と署名を置くとデータ量が増える。Opt-Outは一部の非セキュア委任と、それに由来するempty non-terminalをチェーンから省ける。
これは圧縮だけではない。RFC 7129は、Opt-Out NSEC3が区間内の名前の存在を証明も否定もできないと明記する。検証者は認証済みDSがないことを示し、その先をinsecureとして扱えるが、省略された全ラベルを不存在にしてはならない。
監視画面が緑の「authenticated」だけを残し、name_absent=trueへ変換すると、最重要の制約を失う。区間、Opt-Out、DS不在、潜在する非セキュア委任、最終検証状態を別々に保存する必要がある。
紛争時にも境界は同じだ。DSのない子が実際に委任され、Opt-Out区間に含まれることはある。親の署名証明だけでは、登録機関の意図、全権威インスタンスの整合、取引を戻すべきかは決まらない。
キャッシュが否定証明を預かる
RFC 2308はnegative cachingを定義する。RFC 8020のNXDOMAIN cutは、受理した不存在の下位を一定期間到達不能として扱える。RFC 8198は検証済みNSEC/NSEC3区間から別の否定応答を合成することを認める。
この仕組みは遅延、権威負荷、重複問い合わせによるプライバシー漏えいを減らす。一方、利用者は権威へ再照会されていない応答を受けることがある。権威ゾーンが更新済みでも、古い証明がTTLと署名期間内なら合成応答はプロトコル上有効になりうる。
監査には問い合わせ名と型、rcode、ゾーン、証明レコード、closest encloser、wildcard、Opt-Out、受信時刻、TTL、署名開始・終了、信頼連鎖、権威応答か合成かを残す。NXDOMAINの画面だけでは、後から意思決定を帰属できない。
否定署名は削除命令ではない
レジストリやレジストラは登録取引を管理し、権威運用者はゾーンを公開し、登録者は契約上の権利を持ち、審査機関は与えられた救済だけを扱い、再帰リゾルバーはキャッシュを管理する。NSECがこれらの権限を一つにすることはない。
証明は通知、支払、資格終了、異議申立ての有無を示さない。第三者への登録権を与えず、署名者を名前の所有者にも変えない。
責任ある台帳は、登録・資格記録、認可されたプロビジョニング判断、署名済みゾーン版、外部リゾルバー観測を結びながら分離する。ゾーンは公開された運用現実であり、他の記録はその形成理由と是正可能性を説明する。
薄い共通台帳
Heng Luの最小層の考え方なら、共有層が区別すべきものはvalidated data、validated absence、insecure delegation、bogus evidenceである。誰が名前に値するかを裁く世界機関は不要だ。
技術結果を決めるのは実行中のzone cut、DS/DNSKEY連鎖、NSEC3パラメータ、区間、Opt-Out、wildcard、TTL、署名期間、検証ポリシーである。政策文書は壊れた証明を直せず、正しい署名は私的政策を主権へ変えない。
正確な結論は狭い。DNSSECは、限定時間に署名済みゾーンが何を含まなかったかを認証する。なぜ不在か、誰が得るべきかは、別の証拠と決定である。
出典
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/the-bill-of-rights-of-uniqueness-coordination/
- https://www.rfc-editor.org/rfc/rfc2308
- https://www.rfc-editor.org/rfc/rfc4033
- https://www.rfc-editor.org/rfc/rfc4034
- https://www.rfc-editor.org/rfc/rfc4035
- https://www.rfc-editor.org/rfc/rfc5155
- https://www.rfc-editor.org/rfc/rfc7129
- https://www.rfc-editor.org/rfc/rfc8020
- https://www.rfc-editor.org/rfc/rfc8198
- https://www.rfc-editor.org/rfc/rfc9276
- https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
