メインコンテンツまでスキップ

10. Special Considerations (特別な考慮事項)

10. Special Considerations (特別な考慮事項)​

10.1. Domain Name Length Restrictions (ドメイン名長の制限)​

この仕様を使用して署名されたゾーンには, 追加のドメイン名長の制限が課されます。特に, ハッシュ化されたオーナー名に変換されたときに [RFC1035] によって課される 255 オクテットの長さ制限を超える名前を持つゾーンは, この仕様を使用できません。

特定のゾーンにおけるドメイン名の実際の最大長は, ゾーン名の長さ (ドメイン名全体に対する) と使用される特定のハッシュ関数の両方に依存します。

例として, SHA-1 は 160 ビットのハッシュを生成します。160 ビットの base-32 エンコーディングは 32 文字になります。この 32 文字は, 単一オクテットの長さフィールドを含む単一ラベルとしてゾーン名に前置されます。SHA-1 を使用する場合のゾーン名の最大長は 222 オクテット (255 - 33) です。

10.2. DNAME at the Zone Apex (ゾーン頂点での DNAME)​

[RFC2672] のセクション 3 における DNAME 仕様には 'no-descendants' 制限があります。ノード N に DNAME RR が存在する場合, N のいかなる子孫にもデータが存在してはなりません。

N がゾーンの頂点 (apex) である場合, N の子孫に NSEC3 および RRSIG タイプが存在します。この仕様は, 頂点に DNAME が存在するかどうかに関係なく, 頂点の子孫に NSEC3 および RRSIG タイプを許可するように DNAME 仕様を更新します。

10.3. Iterations (イテレーション)​

使用されるイテレーション数を設定することにより, ゾーンオーナーはハッシュ計算のコスト, したがって辞書生成のコストを選択できます。これは, すべての時間に対して単一の事前計算された辞書の使用を防ぐソルトの効果とは異なることに注意してください。

明らかに, イテレーション数はゾーンオーナーのゾーンへの署名と提供のコスト, およびバリデータのゾーンからのレスポンス検証のコストにも影響します。したがって, イテレーション数に上限を課します。これは RRSet の検証コストを近似するイテレーション数に基づいています。

したがって, 制限は最小のゾーン署名鍵のサイズに基づいており, 最も近いテーブル値に切り上げられます (または鍵が最大のテーブル値より大きい場合は切り下げられます)。

ゾーンオーナーは, 指定された鍵サイズに対して以下のテーブルに示されているイテレーションより高い値を使用してはなりません。リゾルバは, バリデータが NSEC3 RR 上の署名が正しいことを検証した後, より高い値を持つレスポンスを安全でないものとして扱ってもかまいません。

Key SizeIterations
1024150
2048500
40962,500

このテーブルは, サイズ 1024 ビット (150 対 1), 2048 ビット (500 対 1), および 4096 ビット (2500 対 1) の鍵に対する SHA-1 計算のコストと RSA 検証のコストの比率の近似に基づいています。

SHA-1 計算と DSA 検証の比率はより高く (サイズ 1024 の鍵に対して 1500 対 1 です), より高いイテレーション数はパフォーマンスを低下させますが, DSA 検証は同じ鍵サイズに対して RSA よりすでに高価です。したがって, テーブルの値は鍵アルゴリズムに関係なく使用されなければなりません。

10.4. Transitioning a Signed Zone from NSEC to NSEC3 (署名されたゾーンの NSEC から NSEC3 への移行)​

すでに署名され信頼されているゾーンをこの仕様に移行する際, プロセス中にクライアント検証の失敗を防ぐために注意を払う必要があります。

基本的な手順は次のとおりです:

  1. すべての DNSKEY をセクション 2 で説明されているアルゴリズムエイリアスを使用する DNSKEY に移行します。ゾーンの DNSKEY RRSet を安全かつセキュアに変更する実際の方法は, この仕様の範囲外です。ただし, 最終結果は親のすべての DS RR が指定されたアルゴリズムエイリアスを使用することでなければなりません。

    この移行が完了した後, すべての NSEC3 非対応クライアントはゾーンを安全でないものとして扱います。この時点では, 権威サーバーはまだ NSEC RR を含む否定およびワイルドカードレスポンスを返します。

  2. 署名された NSEC3 RR をゾーンに追加します, 段階的にまたは一度にすべて。段階的に追加する場合, 最後に追加される RRSet は NSEC3PARAM RRSet でなければなりません。

  3. NSEC3PARAM RRSet の追加時に, サーバーはこの仕様に従って NSEC3 RR を使用した否定およびワイルドカードレスポンスの提供に切り替えます。

  4. NSEC RR を段階的にまたは一度にすべて削除します。

10.5. Transitioning a Signed Zone from NSEC3 to NSEC (署名されたゾーンの NSEC3 から NSEC への移行)​

DNSSEC [RFC4035] 署名ゾーンに安全に移行するには, 単に上記の手順を逆にします:

  1. NSEC RR を段階的にまたは一度にすべて追加します。

  2. NSEC3PARAM RRSet を削除します。これは, 否定およびワイルドカードレスポンスに NSEC RR を使用するようサーバーに信号を送ります。

  3. NSEC3 RR を段階的にまたは一度にすべて削除します。

  4. すべての DNSKEY を DNSSEC アルゴリズム識別子に移行します。この移行が完了した後, すべての NSEC3 非対応クライアントはゾーンを安全なものとして扱います。

に最終更新