7. Authoritative Server Considerations (権威サーバーの考慮事項)

7.1 Zone Signing (ゾーン署名)

NSEC3 を使用するゾーンは, 次のプロパティを満たさなければなりません (MUST):

ゾーン内の権威的な RRSet を所有する各オーナー名には, 対応する NSEC3 RR が必要です (MUST)。未署名委任に対応するオーナー名には, 対応する NSEC3 RR がある場合があります (MAY)。しかし, 対応する NSEC3 RR がない場合, 委任への "次近接" 名をカバーする Opt-Out NSEC3 RR が存在しなければなりません (MUST)。他の非権威的な RR は NSEC3 RR によって表されません。
各空の非終端 (empty non-terminal) には, 対応する NSEC3 RR が必要です (MUST)。ただし, 空の非終端が Opt-Out NSEC3 RR によってカバーされる安全でない委任からのみ派生している場合を除きます。
任意の NSEC3 RR の TTL 値は, ゾーン SOA RR の minimum TTL 値フィールドと同じであるべきです (SHOULD)。
署名されたゾーン内のすべての NSEC3 RR の Type Bit Maps フィールドは, NSEC3 RR 自体によってのみ提供されるタイプを除き, 元のオーナー名に存在するすべてのタイプの存在を示さなければなりません (MUST)。これは, NSEC3 タイプ自体が Type Bit Maps に存在しないことを意味することに注意してください。

以下の手順は, NSEC3 RR の適切な構築方法を説明しています。これが唯一の可能な方法ではありません。

ハッシュアルゴリズムと salt および反復回数の値を選択します。
ゾーン内の各一意の元のオーナー名に対して NSEC3 RR を追加します。
- Opt-Out が使用されている場合, 未署名委任のオーナー名は除外される場合があります (MAY)。
- NSEC3 RR のオーナー名は, 元のオーナー名のハッシュで, ゾーン名に単一のラベルとして前置されます。
- Next Hashed Owner Name フィールドは現時点では空白のままにします。
- Opt-Out が使用されている場合, Opt-Out ビットを1に設定します。
- 衝突検出の目的で, オプションで元のオーナー名を NSEC3 RR と共に追跡します。
- さらに, 衝突検出の目的で, オプションでアスタリスクラベルを前置した元のオーナー名に対応する追加の NSEC3 RR を作成し (つまり, このオーナー名の子としてワイルドカードが存在するかのように), この元のオーナー名を追跡します。この NSEC3 RR を一時的としてマークします。
元のオーナー名の各 RRSet に対して, Type Bit Maps フィールドの対応するビットを設定します。
apex と元のオーナー名の間のラベル数の差が1より大きい場合, apex と元のオーナー名の間のすべての空の非終端に対して追加の NSEC3 RR を追加する必要があります。このプロセスにより, 重複したハッシュ化されたオーナー名を持つ NSEC3 RR が生成される場合があります。オプションで, 衝突検出のために, これらの NSEC3 RR の元のオーナー名を追跡し, ステップ1と同様の方法でワイルドカード衝突用の一時的な NSEC3 RR を作成します。
NSEC3 RR のセットをハッシュ順序でソートします。
同一のハッシュ化されたオーナー名を持つ NSEC3 RR を, NSEC3 RR のセットによって表されるタイプの和集合から成る Type Bit Maps フィールドを持つ単一の NSEC3 RR に置き換えることによって結合します。元のオーナー名が追跡されていた場合, すべての一致する NSEC3 RR が同じ元のオーナー名を持つべきであるため, 結合時に衝突を検出できます。可能性のある一時的な NSEC3 RR は破棄します。
各 NSEC3 RR で, ハッシュ順序における次の NSEC3 RR の値を使用して, 次のハッシュ化されたオーナー名を挿入します。ゾーン内の最後の NSEC3 RR の次のハッシュ化されたオーナー名には, ハッシュ順序における最初の NSEC3 RR のハッシュ化されたオーナー名の値が含まれます。
最後に, 同じ Hash Algorithm, Iterations, および Salt フィールドを持つ NSEC3PARAM RR をゾーン apex に追加します。

ハッシュ衝突が検出された場合, 新しい salt を選択し, 署名プロセスを再開する必要があります。

7.2 Zone Serving (ゾーン提供)

この仕様は, 権威サーバーによって生成される DNSSEC 対応 DNS 応答を変更します。特に, そのような応答での NSEC RR の使用を NSEC3 RR に置き換えます。

以下の応答ケースでは, DNSSEC [RFC4035] によって規定された NSEC RR は, 同じ事実を証明する NSEC3 RR に置き換えられます。NSEC RR を含まない応答は, この仕様によって変更されません。

複数の NSEC3 RR を含む応答を返す場合, すべての NSEC3 RR は同じハッシュアルゴリズム, 反復回数, および salt 値を使用しなければなりません (MUST)。Flags フィールドの値はゼロまたは1でなければなりません (MUST)。

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

多くの NSEC3 応答には, 最近接包含者の証明が必要です。これは, QNAME のある祖先が QNAME の最近接包含者であることの証明です。

この証明は, (最大) 2つの異なる NSEC3 RR で構成されます:

最近接 (証明可能) 包含者にマッチする NSEC3 RR。
最近接包含者への "次近接" 名をカバーする NSEC3 RR。

最初の NSEC3 RR は本質的に可能な最近接包含者を提案し, その特定の包含者が実際に存在することを証明します。2番目の NSEC3 RR は, 可能な最近接包含者が最近接であることを証明し, QNAME (および QNAME と最近接包含者の間の祖先) が存在しないことを証明します。

これらの NSEC3 RR は, 以降の説明で総称して "最近接包含者証明" と呼ばれます。

たとえば, 存在しない "alpha.beta.gamma.example." オーナー名に対する最近接包含者証明は, "gamma.example." が最近接包含者であることを証明する場合があります。この応答には, "gamma.example." にマッチする NSEC3 RR が含まれ, "beta.gamma.example." ("次近接" 名) をカバーする NSEC3 RR も含まれます。

Opt-Out (セクション 6) を使用している場合, 実際の最近接包含者が Opt-Out スパンによってカバーされる安全でない委任であるか, その一部であるため, 実際の最近接包含者を証明できない可能性があります。この場合, 実際の最近接包含者を証明する代わりに, 最近接証明可能包含者が使用されます。つまり, 最近接包含権威名が代わりに使用されます。この場合, この証明に使用される NSEC3 RR のセットは, "最近接証明可能包含者証明" と呼ばれます。

7.2.2 Name Error Responses (名前エラー応答)

QNAME の非存在を証明するために, 最近接包含者証明と, 最近接包含者の (存在しない) ワイルドカード RR をカバーする NSEC3 RR を応答に含めなければなりません (MUST)。この (最大) 3つの NSEC3 RR のコレクションは, QNAME が存在しないことと, QNAME にマッチした可能性のあるワイルドカードも存在しないことの両方を証明します。

たとえば, "gamma.example." が QNAME の最近接証明可能包含者である場合, "*.gamma.example." をカバーする NSEC3 RR が応答の authority セクションに含まれます。

7.2.3 No Data Responses, QTYPE is not DS (No Data 応答, QTYPE が DS でない場合)

サーバーは, QNAME にマッチする NSEC3 RR を含めなければなりません (MUST)。この NSEC3 RR は, Type Bit Maps フィールドに QTYPE または CNAME に対応するビットが設定されていてはなりません (MUST NOT)。

7.2.4 No Data Responses, QTYPE is DS (No Data 応答, QTYPE が DS の場合)

QNAME にマッチする NSEC3 RR がある場合, サーバーはそれを応答で返さなければなりません (MUST)。この NSEC3 RR の Type Bit Maps フィールドで DS および CNAME に対応するビットが設定されていてはなりません (MUST NOT)。

QNAME にマッチする NSEC3 RR がない場合, サーバーは QNAME の最近接証明可能包含者証明を返さなければなりません (MUST)。"次近接" 名をカバーする NSEC3 RR では, Opt-Out ビットを 1 に設定しなければなりません (MUST) (定義によりそうなっているはずです。Opt-Out ビットが設定されていない場合は, 何かが誤っています)。

サーバーが QNAME でゾーンカットの両側に対して権威的である場合, サーバーはゾーンカットの親側からの証明を返さなければなりません (MUST)。

7.2.5 Wildcard No Data Responses (ワイルドカード No Data 応答)

QNAME に対してワイルドカードマッチがあるが, QTYPE がその名前に存在しない場合, 応答には QNAME の最近接包含者証明を含めなければならず (MUST), ワイルドカードにマッチする NSEC3 RR を含めなければなりません (MUST)。この組み合わせは, QNAME 自体が存在しないことと, QNAME にマッチするワイルドカードが存在することの両方を証明します。QNAME の最近接包含者は, ワイルドカード RR の直接の祖先でなければならない (MUST) ことに注意してください (これが当てはまらない場合, 何かがうまくいっていません)。

7.2.6 Wildcard Answer Responses (ワイルドカード応答)

QNAME と QTYPE に対してワイルドカードマッチがある場合, 応答の answer セクションで返される展開されたワイルドカード RRSet に加えて, ワイルドカードマッチが有効であったことの証明を返さなければなりません。

この証明は, QNAME が存在しないことと, QNAME の最近接包含者とワイルドカードの直接の祖先が同じである (つまり, 正しいワイルドカードがマッチした) ことの両方を証明することによって達成されます。

この目的のために, ワイルドカードの直接の祖先の "次近接" 名をカバーする NSEC3 RR を返さなければなりません (MUST)。応答に展開されたワイルドカードの存在によってこの最近接包含者の存在が証明されるため, 最近接包含者にマッチする NSEC3 RR を返す必要はありません。

7.2.7 Referrals to Unsigned Subzones (未署名サブゾーンへの委任)

委任名にマッチする NSEC3 RR がある場合, その NSEC3 RR を応答に含めなければなりません (MUST)。NSEC3 RR の Type Bit Maps の DS ビットを設定してはなりません (MUST NOT)。

ゾーンが Opt-Out の場合, 委任に対応する NSEC3 RR が存在しない可能性があります。この場合, 最近接証明可能包含者証明を応答に含めなければなりません (MUST)。委任の "次近接" 名をカバーする含まれる NSEC3 RR は, Opt-Out フラグが1に設定されていなければなりません (MUST) (何かがうまくいっていない限り, これは当てはまります)。

7.2.8 Responding to Queries for NSEC3 Owner Names (NSEC3 オーナー名のクエリへの応答)

NSEC3 RR のオーナー名は, 他のオーナー名のように NSEC3 RR チェーンで表されません。その結果, 各 NSEC3 オーナー名は別の NSEC3 RR によってカバーされ, 事実上 NSEC3 RR の存在を否定します。これはパラドックスです。なぜなら, NSEC3 RR の存在はその RRSIG RRSet によって証明できるからです。

次のすべての条件が真である場合:

QNAME が既存の NSEC3 RR のオーナー名と等しい, および
QNAME にも QNAME の子孫にも RR タイプが存在しない,

その場合, 応答は Name Error 応答 (セクション 7.2.2) として構築されなければなりません (MUST)。言い換えれば, 権威ネームサーバーは, NSEC3 RR のオーナー名が存在しなかったかのように動作します。

NSEC3 RR は, AXFR または IXFR クエリの結果として返されることに注意してください。

7.2.9 Server Response to a Run-Time Collision (実行時衝突へのサーバー応答)

存在しない QNAME のハッシュが既存の NSEC3 RR のオーナー名と衝突する場合, サーバーは QNAME が存在しないことを証明する応答を返すことができません。この場合, サーバーは RCODE 2 (server failure) の応答を返さなければなりません (MUST)。

この文書で指定されているハッシュアルゴリズム SHA-1 では, このような衝突は非常に起こりにくいことに注意してください。

7.3 Secondary Servers (セカンダリサーバー)

セカンダリサーバー (およびおそらく他のエンティティ) は, 否定応答に適切な NSEC3 RR のセットを選択できるようにするために, すべてのハッシュ化されたオーナー名に存在する NSEC3 パラメーター (つまり, ハッシュ, salt, および反復回数) を確実に決定する必要があります。これは, ゾーン apex に存在する NSEC3PARAM RR によって示されます。

複数の NSEC3PARAM RR が存在する場合, 複数の有効な NSEC3 チェーンが存在します。サーバーはそれらのうちの1つを選択しなければなりませんが, 任意の基準を使用してそうすることができます。

7.4 Zones Using Unknown Hash Algorithms (未知のハッシュアルゴリズムを使用するゾーン)

この仕様に従って署名されているが, 認識されない NSEC3 ハッシュアルゴリズム値を使用しているゾーンは, 効果的に提供できません。そのようなゾーンは, ロード時に拒否されるべきです (SHOULD)。サーバーは, そのようなゾーンに該当するクエリを処理する際に RCODE=2 (server failure) 応答で応答すべきです (SHOULD)。

7.5 Dynamic Update (動的更新)

NSEC3 を使用して署名されたゾーンは, 動的更新 [RFC2136] を受け入れる場合があります (MAY)。しかし, NSEC3 は動的更新にいくつかの特別な考慮事項をもたらします。

ゾーンでの名前の追加および削除は, 空の非終端の作成または削除を考慮しなければなりません (MUST)。

対応する NSEC3 RR を持つ名前を削除する場合, その名前によって作成された空の非終端に対応する NSEC3 RR を削除しなければなりません (MUST)。複数の名前が特定の空の非終端の存在を主張している場合があることに注意してください。
NSEC3 RR の追加を必要とする名前を追加する場合, 作成される空の非終端に対しても NSEC3 RR を追加しなければなりません (MUST)。つまり, 空の非終端にマッチする既存の NSEC3 RR がない場合, それを作成して追加する必要があります。

ゾーンに Opt-Out が存在することは, 一部の名前の追加または委任がゾーン内の NSEC3 RR への変更を必要としないことを意味します。

委任 RRSet を削除する場合, その委任に一致する NSEC3 RR がない場合, それはオプトアウトされています。この場合, それ以上何もする必要はありません。
委任 RRSet を追加する場合, 委任の "次近接" 名が既存の Opt-Out NSEC3 RR によってカバーされている場合, ゾーン内の NSEC3 RR を変更せずに委任を追加できます (MAY)。

ゾーンに Opt-Out が存在することは, NSEC3 RR を追加または削除する際に, 新しいまたは変更された NSEC3 RR に設定すべき Opt-Out フラグの値があいまいであることを意味します。サーバーは, あいまいさを解決するために次の基本的なルールのセットに従うべきです (SHOULD)。

これらのルールの中心的な概念は, カバーする NSEC3 RR の Opt-Out フラグの状態が保持されることです。

NSEC3 RR を削除する場合, 前の NSEC3 RR (次のハッシュ化されたオーナー名が変更されるもの) の Opt-Out フラグの値は変更されるべきではありません。
NSEC3 RR を追加する場合, Opt-Out フラグの値は, 以前に NSEC3 RR のオーナー名をカバーしていた NSEC3 RR の Opt-Out フラグの値に設定されます。つまり, 現在前の NSEC3 RR です。

問題のゾーンが Opt-Out フラグの使用と一致している場合 (つまり, ゾーン内のすべての NSEC3 RR がフラグに同じ値を持つ場合), これらのルールはその一貫性を保持します。ゾーンがフラグの使用と一致していない場合 (つまり, 部分的に Opt-Out ゾーン), これらのルールは Opt-Out フラグの使用の同じパターンを保持しません。

Opt-Out フラグを部分的に使用するゾーンの場合, その使用に論理的なパターンがある場合, サーバー上のローカルポリシーを使用してパターンを維持できます。