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

5. NSEC リソースレコード

NSEC（Next SECure、次セキュア）リソースレコード（RR）は、署名済みゾーン内に特定の所有者名（owner name）が存在しないこと、または特定のリソースレコード型が存在しないことを証明するために使用される。NSEC RR は、ゾーン内で正規順に並んだ次の所有者名を列挙することによってこれを実現する。

NSEC RR の RDATA フォーマットは以下のとおりである。

                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                      Next Domain Name                         /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                       Type Bit Maps                           /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NSEC RR の RDATA は以下のように表現および符号化される。

  • 次のドメイン名（NEXT DOMAIN NAME）は、正規順に並んだゾーン内の次の所有者名（この名前は当該 NSEC RR の所有者名と異なる MUST である）であり、正規形式のドメイン名（wire format）で表される。
  • タイプビットマップ（TYPE BIT MAPS）は、NSEC RR の所有者名に関連付けられたリソースレコード型の集合を識別する。タイプビットマップはコンパクトなビットマップ形式で符号化され、そのフォーマットは第 5.1 節で記述する。

5.1. NSEC RDATA のタイプビットマップフィールド​

タイプビットマップは、1 つ以上のウィンドウブロック（window block）の列として符号化される。各ウィンドウブロックの構造は以下のとおりである。

    +--------+--------+--------+--------+--------+--------+
    |  Window|  Bitmap Length |        Bitmap            |
    +--------+--------+--------+--------+--------+--------+

ここで：

  • Window は 8 ビット符号なし整数であり、型コードの上位 8 ビット（すなわち型コードを 256 で割った商）を識別する。
  • Bitmap Length は 8 ビット符号なし整数であり、そのウィンドウブロック内のビットマップの長さ（バイト単位）を識別し、1 から 32 の範囲である。
  • Bitmap は Bitmap Length バイトのビットマップであり、そのウィンドウ内の型コードを網羅する。ビットマップ内の各ビットは 1 つの型コードに対応する。第 0 ビット（最上位ビット）は Window × 256 の型コードに対応し、第 7 ビット（最下位ビット）は Window × 256 + 7 の型コードに対応する。

タイプビットマップは、NSEC RR の所有者名に関連付けられた各 RR 型の対応するビットを含まなければならない（MUST）。所有者名が複数の RR 型に関連付けられている場合、それらの型はすべてタイプビットマップに表現されなければならない（MUST）。

タイプビットマップは、Window フィールドの昇順で並ばなければならず（MUST）、また 32 バイトを超える長さのウィンドウブロックや重複するウィンドウブロックを含んではならない（MUST NOT）。

NSEC RR の検証器は、タイプビットマップを使用して以下をチェックする。

  • NSEC RR の所有者名に与えられた RR 型が存在するか（型の存在証明）。
  • NSEC RR の所有者名と次のドメイン名の間に、正規順で他の名前が存在しないか（名前の不存在証明）。

5.2. NSEC RDATA の次のドメイン名フィールド​

NEXT DOMAIN NAME フィールドは、正規順（canonical order）で NSEC RR の所有者名の直後に続く所有者名を含まなければならない（MUST）。ゾーン内の最後の NSEC RR の NEXT DOMAIN NAME フィールドは、そのゾーン内の最初の NSEC RR の所有者名（すなわちゾーンの先頭へのラップアラウンド）を含まなければならない（MUST）。

これは、検証器が存在しない名前を要求したときに、その名前がゾーン内に存在しないことを証明するために使用される。検証器は、所有者名が正規順で要求された名前の前にあり、かつ NEXT DOMAIN NAME が正規順で要求された名前の後に位置する NSEC RR を見つける。

5.3. NSEC 表現フォーマット​

NSEC RR の表現フォーマット（presentation format）は以下のとおりである。

  • 次のドメイン名は、正規形式（すなわち圧縮なし）のドメイン名テキストで表される。
  • タイプビットマップは、空白で区切られたリソースレコード型のリスト（たとえば RRSIG NSEC SOA NS A）で表される。未知の型は RFC 3597 表記を使用する。

例：

    example.com. 3600 IN NSEC www.example.com. A RRSIG NSEC

5.4. NSEC RR に関する特記事項​

NSEC RR はゾーン内の名前の存在を露呈するため、プライバシー上の考慮事項をもたらす可能性がある。NSEC RR はゾーンを担当する署名者によって生成 MUST であり、かつゾーンの DNSKEY と一致する鍵を使用して署名 MUST である。

検証器は、名前または型の不存在を証明するとき、NSEC RR が示す正規順の区間に、証明される不存在の名前または型が確かに含まれないことをチェック MUST である。

関連章ナビゲーション：