4. NSEC リソースレコード (The NSEC Resource Record)
NSEC リソースレコードは2つの別々の内容をリストします。権威データまたは委任点 (delegation point) の NS RRset を含む次の所有者名 (ゾーンの正規順序での)、および NSEC RR の所有者名に存在する RR タイプのセット [RFC3845] です。ゾーン内の NSEC RR の完全なセットは、ゾーン内にどの権威 RRset が存在するかを示し、またゾーン内の権威所有者名のチェーンを形成します。この情報は、[RFC4035] に記述されているように、DNS データの認証された不存在証明 (authenticated denial of existence) を提供するために使用されます。
ゾーン内のすべての権威名は NSEC チェーンの一部でなければならないため、NSEC RR は CNAME RR を含む名前に存在しなければなりません (MUST)。これは、名前に CNAME が存在する場合、その名前で許可される唯一のタイプであると述べていた従来の DNS 仕様 [RFC1034] に対する変更です。署名されたゾーンでは、RRSIG (セクション3を参照) と NSEC は、CNAME リソースレコードと同じ名前に存在しなければなりません (MUST)。
ゾーン署名者がゾーンに含める必要がある NSEC RR を正確に決定する方法については、[RFC4035] を参照してください。
NSEC RR タイプの type 値は 47 です。
NSEC RR はクラス独立です。
NSEC RR は、SOA の最小 TTL フィールドと同じ TTL 値を持つべきです (SHOULD)。これはネガティブキャッシング ([RFC2308]) の精神に則っています。
4.1. NSEC RDATA ワイヤ形式 (NSEC RDATA Wire Format)
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. Next Domain Name フィールド (The Next Domain Name Field)
Next Domain フィールドには、権威データを持つまたは委任点 NS RRset を含む次の所有者名 (ゾーンの正規順序での) が含まれます。正規順序の説明についてはセクション 6.1 を参照してください。ゾーン内の最後の NSEC レコードの Next Domain Name フィールドの値は、ゾーンの頂点 (zone apex) の名前 (ゾーンの SOA RR の所有者名) です。これは、NSEC RR の所有者名がゾーンの正規順序での最後の名前であることを示します。
送信者は、NSEC RR を送信するときに Next Domain Name フィールドで DNS 名前圧縮を使用してはなりません (MUST NOT)。
指定されたゾーンが権威を持たない RRset の所有者名 (グルーレコードなど) は、同じ所有者名に少なくとも1つの権威 RRset が存在しない限り、Next Domain Name にリストしてはなりません (MUST NOT)。
4.1.2. Type Bit Maps フィールド (The Type Bit Maps Field)
Type Bit Maps フィールドは、NSEC RR の所有者名に存在する RRset タイプを識別します。
RR タイプ空間は256のウィンドウブロックに分割され、各ブロックは16ビット RR タイプ空間の下位8ビットを表します。少なくとも1つのアクティブな RR タイプを持つ各ブロックは、単一のオクテットのウィンドウ番号 (0から255)、単一のオクテットのビットマップ長 (1から32) (ウィンドウブロックのビットマップに使用されるオクテット数を示す)、および最大32オクテット (256ビット) のビットマップを使用してエンコードされます。
ブロックは、NSEC RR RDATA 内で昇順の数値順序で存在します。
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
ここで "|" は連結を示します。
各ビットマップは、ウィンドウブロック内の RR タイプの下位8ビットを、ネットワークビット順序でエンコードします。最初のビットはビット0です。ウィンドウブロック0の場合、ビット1は RR タイプ1 (A) に対応し、ビット2は RR タイプ2 (NS) に対応し、以下同様です。ウィンドウブロック1の場合、ビット1は RR タイプ257に対応し、ビット2は RR タイプ258に対応し、以下同様です。ビットが設定されている場合、そのタイプの RRset が NSEC RR の所有者名に存在することを示します。ビットがクリアされている場合、そのタイプの RRset が NSEC RR の所有者名に存在しないことを示します。
疑似タイプ (pseudo-types) を表すビットはクリアされていなければならず (MUST)、ゾーンデータには表示されません。遭遇した場合、読み取り時に無視されなければなりません (MUST)。
存在するタイプがないブロックは含めてはなりません (MUST NOT)。ビットマップ内の後続のゼロオクテットは省略されなければなりません (MUST)。各ブロックのビットマップの長さは、NSEC RR の所有者名に存在する RR タイプのセットの中で、そのブロック内で最大の数値を持つタイプコードによって決定されます。指定されていない後続のゼロオクテットは、ゼロオクテットとして解釈されなければなりません (MUST)。
委任点での NSEC RR のビットマップには特別な注意が必要です。委任 NS RRset および親ゾーンが権威データを持つ任意の RRset に対応するビットは設定されなければならず (MUST)、親が権威を持たない任意の非 NS RRset に対応するビットはクリアされていなければなりません (MUST)。
ゾーンは、グルーレコードのみを保持するドメイン名の NSEC RR を含めてはなりません (MUST NOT)。
4.1.3. NSEC RDATA へのワイルドカード名の包含 (Inclusion of Wildcard Names in NSEC RDATA)
ワイルドカード所有者名がゾーンに現れる場合、ワイルドカードラベル ("*") はリテラルシンボルとして扱われ、NSEC RR を生成する目的で他の所有者名と同じように扱われます。ワイルドカード所有者名は、ワイルドカード展開なしで Next Domain Name フィールドに表示されます。[RFC4035] は、ワイルドカードが認証された不存在証明に与える影響を説明しています。
4.2. NSEC RR 表示形式 (The NSEC RR Presentation Format)
RDATA 部分の表示形式は以下の通りです。
Next Domain Name フィールドはドメイン名として表現されます。
Type Bit Maps フィールドは RR タイプニーモニックのシーケンスとして表現されます。ニーモニックが不明な場合、[RFC3597] のセクション5で説明されている TYPE 表現を使用しなければなりません (MUST)。
4.3. NSEC RR の例 (NSEC RR Example)
以下の NSEC RR は、alfa.example.com に関連付けられた RRset を識別し、alfa.example.com の後の次の権威名を識別します。
alfa.example.com. 86400 IN NSEC host.example.com. (
A MX RRSIG NSEC TYPE1234 )
最初の4つのテキストフィールドは、名前、TTL、クラス、および RR タイプ (NSEC) を指定します。エントリ host.example.com. は、正規順序で alfa.example.com の後の次の権威名です。A、MX、RRSIG、NSEC、および TYPE1234 ニーモニックは、名前 alfa.example.com に関連付けられた A、MX、RRSIG、NSEC、および TYPE1234 RRset が存在することを示します。
上記の NSEC RR の RDATA セクションは次のようにエンコードされます。
0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20
検証者がこの NSEC レコードを認証できると仮定すると、これを使用して beta.example.com が存在しないことを証明したり、alfa.example.com に関連付けられた AAAA レコードが存在しないことを証明したりできます。認証された不存在証明については [RFC4035] で議論されています。
関連章へのナビゲーション: