8. Validator Considerations (バリデータに関する考慮事項)

8.1. Responses with Unknown Hash Types (未知のハッシュタイプを含むレスポンス)

バリデータ (validator) は未知のハッシュタイプを持つ NSEC3 RR を無視しなければなりません。これの実際的な結果は, そのような NSEC3 RR のみを含むレスポンスは一般的に偽造 (bogus) と見なされることです。

8.2. Verifying NSEC3 RRs (NSEC3 RR の検証)

バリデータは Flags フィールドの値がゼロまたは 1 以外の NSEC3 RR を無視しなければなりません (MUST)。

バリデータは, レスポンスに含まれる NSEC3 RR がそのゾーンに対して互いに異なるハッシュアルゴリズム (hash algorithm), イテレーション (iterations), またはソルト (salt) の値を含む場合, レスポンスを偽造として扱ってもかまいません。

8.3. Closest Encloser Proof (最近接包含者証明)

最近接包含者証明 (closest encloser proof) を検証するために, バリデータは次の条件を満たす最長の名前 X を見つけなければなりません:

X は QNAME の祖先 (ancestor) であり, レスポンスに存在する NSEC3 RR によって一致 (matched) します。これは最近接包含者 (closest encloser) の候補です, そして
X より 1 ラベル長い名前 (ただし依然として QNAME の祖先または QNAME と等しい) が, レスポンスに存在する NSEC3 RR によってカバー (covered) されます。

この証明を検証する可能性のあるアルゴリズムの 1 つは次のとおりです:

SNAME=QNAME を設定します。フラグをクリアします。
SNAME が存在するかどうかをチェックします:
- レスポンスに SNAME に一致する NSEC3 RR がない場合 (つまり, オーナー名が SNAME のハッシュと同じで, ゾーン名に単一ラベルとして前置された NSEC3 RR), フラグをクリアします。
- レスポンスに SNAME をカバーする NSEC3 RR がある場合, フラグを設定します。
- レスポンスに一致する NSEC3 RR があり, フラグが設定されている場合, 証明は完了であり, SNAME が最近接包含者です。
- レスポンスに一致する NSEC3 RR があるがフラグが設定されていない場合, レスポンスは偽造です。
SNAME を左から 1 ラベル切り詰め, ステップ 2 に進みます。

最近接包含者が発見されたら, バリデータは最近接包含者を元のオーナー名として持つ NSEC3 RR が適切なゾーンからのものであることを確認しなければなりません。DNAME タイプビットは設定されていてはならず, NS タイプビットは SOA タイプビットが設定されている場合にのみ設定されてもかまいません。そうでない場合, これは攻撃者がそれらを使用してサーバーが権限を持たない RR の存在を偽って否定していることの指標となります。

以下の説明では, "X の最近接 (証明可能な) 包含者証明" というフレーズは, 上記のアルゴリズム (または同等のアルゴリズム) が X の祖先がその最近接包含者であることを証明することによって X が存在しないことを証明することを意味します。

8.4. Validating Name Error Responses (名前エラーレスポンスの検証)

バリデータは, レスポンスに QNAME の最近接包含者証明が存在すること, および最近接包含者でのワイルドカード (つまり, アスタリスクラベルを最近接包含者に前置して形成された名前) をカバーする NSEC3 RR が存在することを検証しなければなりません。

8.5. Validating No Data Responses, QTYPE is not DS (No Data レスポンスの検証, QTYPE が DS でない場合)

バリデータは, QNAME に一致する NSEC3 RR が存在し, その Type Bit Maps フィールドに QTYPE と CNAME タイプの両方が設定されていないことを検証しなければなりません。

このテストは, NSEC3 RR が空の非終端 (empty non-terminal) に対応するために存在する場合もカバーすることに注意してください。その場合, NSEC3 RR は空の Type Bit Maps フィールドを持ちます。

8.6. Validating No Data Responses, QTYPE is DS (No Data レスポンスの検証, QTYPE が DS の場合)

レスポンスに QNAME に一致する NSEC3 RR がある場合, その NSEC3 RR の Type Bit Maps フィールドに DS と CNAME に対応するビットが設定されていてはなりません。

そのような NSEC3 RR がない場合, バリデータは QNAME の最近接証明可能包含者証明がレスポンスに存在すること, および "next closer" 名前をカバーする NSEC3 RR が Opt-Out ビットを設定していることを検証しなければなりません。

8.7. Validating Wildcard No Data Responses (ワイルドカード No Data レスポンスの検証)

バリデータは QNAME の最近接包含者証明を検証しなければならず, アスタリスクラベルを最近接包含者に前置して生成されたワイルドカード名に一致するレスポンスに存在する NSEC3 RR を見つけなければなりません。さらに, ワイルドカードに一致する NSEC3 RR では QTYPE と CNAME の両方に対応するビットが設定されていてはなりません。

8.8. Validating Wildcard Answer Responses (ワイルドカード回答レスポンスの検証)

レスポンス内の検証されたワイルドカード回答 RRSet は, QNAME の (候補) 最近接包含者をバリデータに提供します。この最近接包含者は, 生成ワイルドカード (generating wildcard) の直接の祖先です。

バリデータは, QNAME への "next closer" 名前をカバーする NSEC3 RR がレスポンスに存在することを検証しなければなりません。これは QNAME 自体が存在せず, レスポンスを生成するために正しいワイルドカードが使用されたことを証明します。

8.9. Validating Referrals to Unsigned Subzones (未署名サブゾーンへの委任の検証)

委任における委任名 (delegation name) は, 委任レスポンスの権威セクション (authority section) に存在する NS RRSet のオーナー名です。

委任名に一致するレスポンスに NSEC3 RR が存在する場合, バリデータは NSEC3 RR の Type Bit Maps フィールドで NS ビットが設定され DS ビットが設定されていないことを確認しなければなりません。バリデータはまた, NSEC3 RR が正しい (つまり親) ゾーンからのものであることを確認しなければなりません。これは, この NSEC3 RR の Type Bit Maps フィールドで SOA ビットが設定されていないことを確認することによって行われます。

NS ビットの存在は DNAME ビットの不在を意味するため, NSEC3 RR の Type Bit Maps フィールドで DNAME ビットをチェックする必要はないことに注意してください。

委任名に一致する NSEC3 RR が存在しない場合, バリデータは委任名の最近接証明可能包含者証明を検証しなければなりません。バリデータは, 委任名への "next closer" 名前をカバーする NSEC3 RR で Opt-Out ビットが設定されていることを検証しなければなりません。