RFC3845 ＤＮＳセキュリティ（ＤＮＳＳＥＣ）次の安全（ＮＳＥＣ）資源データフォーマット

この文書はRFC3845の日本語訳（和訳）です。この文書の翻訳内容の正確さは保障できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の配布は元のＲＦＣ同様に無制限です。

Network Working Group J. Schlyter, Ed.
Request for Comments: 3845 August 2004
Updates: 3755, 2535
Category: Standards Track

DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
ＤＮＳセキュリティ（ＤＮＳＳＥＣ）次の安全（ＮＳＥＣ）資源データフォーマット

Status of this Memo
この文書の状態

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。

Abstract
概要

This document redefines the wire format of the "Type Bit Map" field
in the DNS NextSECure (NSEC) resource record RDATA format to cover
the full resource record (RR) type space.
この文書は完全に資源レコード（ＲＲ）タイプ空間をカバーするためのＤＮ
Ｓ次安全（ＮＳＥＣ）資源レコードの資源データフォーマットの「種別ビッ
トマップ」フィールドのワイヤフォーマットを再定義します。

Table of Contents
目次

1. Introduction
1. はじめに
2. The NSEC Resource Record
2. ＮＳＥＣ資源レコード
2.1. NSEC RDATA Wire Format
2.1. ＮＳＥＣ資源データワイヤフォーマット
2.1.1. The Next Domain Name Field
2.1.1. 次のドメイン名フィールド
2.1.2. The List of Type Bit Map(s) Field
2.1.2. 種別ビットマップフィールドのリスト
2.1.3. Inclusion of Wildcard Names in NSEC RDATA
2.1.3. ＮＳＥＣ資源データのワイルドカード名の包含
2.2. The NSEC RR Presentation Format
2.2. ＮＳＥＣ資源レコード表示フォーマット
2.3. NSEC RR Example
2.3. ＮＳＥＣ資源レコード例
3. IANA Considerations
3. ＩＡＮＡの考慮
4. Security Considerations
4. セキュリティの考察
5. References
5. 参考文献
5.1. Normative References
5.1. 参照する参考文献

5.2. Informative References
5.2. 有益な参考文献
6. Acknowledgements
6. 謝辞
7. Author's Address
7. 著者のアドレス
8. Full Copyright Statement
8. 著作権表示全文

1. Introduction
1. はじめに

The DNS [6][7] NSEC [5] Resource Record (RR) is used for
authenticated proof of the non-existence of DNS owner names and
types. The NSEC RR is based on the NXT RR as described in RFC 2535
[2], and is similar except for the name and typecode. The RDATA
format for the NXT RR has the limitation in that the RDATA could only
carry information about the existence of the first 127 types. RFC
2535 did reserve a bit to specify an extension mechanism, but the
mechanism was never actually defined.
ＤＮＳ[6][7]のＮＳＥＣ[5]資源レコード（ＲＲ）は、ＤＮＳ所有者名と種別
の非実在の証明で使用します。ＮＳＥＣ資源レコードはＲＦＣ２５３５[2]で
記述されるようにＮＸＴ ＲＲに基づいていて、名前と種別コード以外は同じ
です。ＮＸＴ ＲＲの資源データフォーマットは、資源データが最初の１２７
の種別の存在についての情報を運ぶことができるという点で、限界がありま
す。ＲＦＣ２５３５は拡張メカニズムを指定するために１ビットを留保しま
したが、メカニズムは実際には定義されませんでした。

In order to avoid needing to develop an extension mechanism into a
deployed base of DNSSEC aware servers and resolvers once the first
127 type codes are allocated, this document redefines the wire format
of the "Type Bit Map" field in the NSEC RDATA to cover the full RR
type space.
最初の１２７のタイプコードが割り当てられた後で、実装済みのＤＮＳＳＥ
Ｃサーバとリゾルバに拡張メカニズムを開発する必要があるのを避けるため
に、この文書は完全に資源レコード種別空間をカバーするように、ＮＳＥＣ
資源データの「種別ビットマップ」フィールドフォーマットを再定義します。

This document introduces a new format for the type bit map. The
properties of the type bit map format are that it can cover the full
possible range of typecodes, that it is relatively economical in the
amount of space it uses for the common case of a few types with an
owner name, that it can represent owner names with all possible types
present in packets of approximately 8.5 kilobytes, and that the
representation is simple to implement. Efficient searching of the
type bitmap for the presence of certain types is not a requirement.
この文書は種別ビットマップの新しいフォーマットを紹介します。種別ビッ
トマップフォーマットに求められる特性は、種別コードの完全な範囲に対応
すること、所有者名に対し少数の種別がある一般的な場合に、使うスペース
が比較的少ないこと、全ての種別を持つ所有者名が、およそ８.５キロバイト
のパケットで表現可能なこと、表現の実装が簡単であること、です。タイプ
ビットマップである特定の種別の存在を効率的に検索することは必要条件で
はありません。

For convenience and completeness, this document presents the syntax
and semantics for the NSEC RR based on the specification in RFC 2535
[2] and as updated by RFC 3755 [5], thereby not introducing changes
except for the syntax of the type bit map.
便利さと完全性のために、この文書はＲＦＣ２５３５[2]とその更新のＲＦＣ
３７５５[5]の仕様に基づくＮＳＥＣ資源レコードの構文と意味を示し、種別
ビットマップの構文以外の変更をしません。

This document updates RFC 2535 [2] and RFC 3755 [5].
この文書はＲＦＣ２５３５[2]とＲＦＣ３７５５[5]を更新します。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [1].
この文書でのキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"はＢＣＰ
１４、ＲＦＣ２１１９[1]で記述したように、解釈されるはずです。

2. The NSEC Resource Record
2. ＮＳＥＣ資源レコード

The NSEC resource record lists two separate things: the owner name of
the next RRset in the canonical ordering of the zone, and the set of
RR types present at the NSEC RR's owner name. The complete set of
NSEC RRs in a zone indicate which RRsets exist in a zone, and form a
chain of owner names in the zone. This information is used to
provide authenticated denial of existence for DNS data, as described
in RFC 2535 [2].
ＮＳＥＣ資源レコードは２つの異なるものをリストアップします：ゾーンの
正規順序での次の資源レコード集合の所有者名と、ＮＳＥＣ資源レコードの
所有者名に存在している資源レコード種別の集合。ゾーン内のＮＳＥＣ資源
レコードの完全な集合は、どの資源レコード集合がゾーンに存在するかを示
し、それぜゾーンの所有者名の連鎖を形成します。この情報は、ＲＦＣ２５
３５[2]で記述されるように、ＤＮＳデータに存在しない事の証明を提供する
ために使われます。

The type value for the NSEC RR is 47.
ＮＳＥＣ資源レコードの種別値は４７です。

The NSEC RR RDATA format is class independent and defined for all
classes.
ＮＳＥＣ資源レコードの資源データフォーマットはクラスと独立で、全ての
クラスで定義されます。

The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
field. This is in the spirit of negative caching [8].
ＮＳＥＣ資源レコードはＳＯＡの最小ＴＴＬと同じＴＴＬを持つべきです
(SHOULD)。これはネガティブキャッシュ[8]の精神にあります。

2.1. NSEC RDATA Wire Format
2.1. ＮＳＥＣ資源データワイヤフォーマット

The RDATA of the NSEC RR is as shown below:
ＮＳＥＣＲＲ資源データは下記の通りです：

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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ List of Type Bit Map(s) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1. The Next Domain Name Field
2.1.1. 次のドメイン名フィールド

The Next Domain Name field contains the owner name of the next RR in
the canonical ordering of the zone. The value of the Next Domain
Name field in the last NSEC record in the zone is the name of the
zone apex (the owner name of the zone's SOA RR).
次のドメイン名フィールドはゾーンの正規順で次の資源レコードの所有者名
を含んでいます。ゾーンの中の最後のＮＳＥＣレコードの次のドメイン名
フィールドの値は、ゾーンの頂上の名前（ゾーンのＳＯＡ資源レコードの所
有者名）です。

A sender MUST NOT use DNS name compression on the Next Domain Name
field when transmitting an NSEC RR.
送信者が、ＮＳＥＣ資源レコードを伝達する時、次のドメイン名フィールド
にＤＮＳ名前圧縮を使ってはなりません(MUST NOT)。

Owner names of RRsets that are not authoritative for the given zone
(such as glue records) MUST NOT be listed in the Next Domain Name
unless at least one authoritative RRset exists at the same owner
name.
所定のゾーンで権威がない資源レコード集合の所有者名（例えばグルーレコー
ド）は、その所有者名に少なくとも１つの正式な資源レコード集合が存在し
ない限り、次のドメイン名でリストアップされてはなりません(MUST NOT)。

2.1.2. The List of Type Bit Map(s) Field
2.1.2. 種別ビットマップフィールドのリスト

The RR type space is split into 256 window blocks, each representing
the low-order 8 bits of the 16-bit RR type space. Each block that
has at least one active RR type is encoded using a single octet
window number (from 0 to 255), a single octet bitmap length (from 1
to 32) indicating the number of octets used for the window block's
bitmap, and up to 32 octets (256 bits) of bitmap.
資源レコード種別空間は２５６のブロックに分割され、それぞれ１６ビット
の資源レコード種別空間の下位８ビットを表します。少なくとも１つの資源
レコードを含むブロックが、１オクテットのウインドウブロック番号（０か
ら２５５）と、ウインドウブロックのビットマップに使うオクテット数を含
む１オクテットのビットマップ長（１から３２）と、ビットマップに使われ
た最大３２オクテット（２５６ビット）でコード化されます。

Window blocks are present in the NSEC RR RDATA in increasing
numerical order.
ウインドウブロックはＮＳＥＣ資源レコードの資源データで存在しています。

"|" denotes concatenation
"|"が結合を示します。

Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +

Each bitmap encodes the low-order 8 bits of RR types within the
window block, in network bit order. The first bit is bit 0. For
window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
to RR type 2 (NS), and so forth. For window block 1, bit 1
corresponds to RR type 257, and bit 2 to RR type 258. If a bit is
set to 1, it indicates that an RRset of that type is present for the
NSEC RR's owner name. If a bit is set to 0, it indicates that no
RRset of that type is present for the NSEC RR's owner name.
それぞれのビットマップがウインドウブロックの下位８ビットの資源レコー
ド種別を、ネットワークビット順でコード化します。最初のビットはビット
０です。ウインドウブロック０で、ビット１が資源レコード種別１（Ａ）に
対応し、ビット２が資源レコード種別２（ＮＳ）に対応し、以下同じです。
ウインドウブロックで、ビット１が資源レコード (RR) 種別２５７に対応し、
ビット２が資源レコード種別２５８に対応します。もしビットが１に設定さ
れるなら、これはその種類の資源レコード集合がＮＳＥＣ資源レコードの所
有者名に対して存在していることを示します。もしビットが０に設定される
なら、これはその種類の資源レコード集合がＮＳＥＣ資源レコードの所有者
名に対して存在していないことを示します。

Since bit 0 in window block 0 refers to the non-existing RR type 0,
it MUST be set to 0. After verification, the validator MUST ignore
the value of bit 0 in window block 0.
ウィンドウブロック０のビット０が存在しない資源レコード種別０に対応す
るので、これは０が設定されなくてはなりません(MUST)。検証後に、検証者
はウィンドウブロック０のビット０の値を無視しなくてはなりません(MUST)。

Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3]
(section 3.1), or within the range reserved for assignment only to
QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
zone data. If encountered, they must be ignored upon reading.
ＲＦＣ２９２９[3]（３.１章）で示されるメタタイプやQTYPEに対するビット
と、Ｑタイプとメタタイプだけに割当てるために確保された範囲のビットは、
これらがゾーンデータに現われないから、０に設定されなければなりません
(MUST)。もし発生したら、読む際に無視されなくてはなりません。

Blocks with no types present MUST NOT be included. Trailing zero
octets in the bitmap MUST be omitted. The length of each block's
bitmap is determined by the type code with the largest numerical
value within that block, among the set of RR types present at the
NSEC RR's owner name. Trailing zero octets not specified MUST be
interpreted as zero octets.
現在タイプがないブロックが含まれてはなりません(MUST NOT)。ビットマッ
プの中の後続するゼロのオクテットは省略しなければなりません(MUST)。各
ブロックのビットマップ長は、そのブロックの中のＮＳＥＣ資源レコードの
所有者名に存在する資源レコード種別の中で、最大の種別コードで決定され
ます。指定されない後続するオクテットはゼロと解釈されなくてはなりませ
ん(MUST)。

2.1.3. Inclusion of Wildcard Names in NSEC RDATA
2.1.3. ＮＳＥＣ資源データのワイルドカード名の包含

If a wildcard owner name appears in a zone, the wildcard label ("*")
is treated as a literal symbol and is treated the same as any other
owner name for purposes of generating NSEC RRs. Wildcard owner names
appear in the Next Domain Name field without any wildcard expansion.
RFC 2535 [2] describes the impact of wildcards on authenticated
denial of existence.
もしワイルドカード所有者名がゾーンにあるなら、ワイルドカードラベル
("*")が文字通りの記号として取り扱われ、そして他のＮＳＥＣ資源レコード
を生成する目的の所有者名と同じに扱われます。ワイルドカード所有者名が、
ワイルドカード拡張なしで、次のドメイン名フィールドに現われます。ＲＦ
Ｃ２５３５[2]は存在しない事の証明でのワイルドカードの影響を記述します。

2.2. The NSEC RR Presentation Format
2.2. ＮＳＥＣ資源レコード表示フォーマット

The presentation format of the RDATA portion is as follows:
資源データ部の表示フォーマットは次の通りです：

The Next Domain Name field is represented as a domain name.
次のドメイン名フィールドはドメイン名であるとして書かれます。

The List of Type Bit Map(s) Field is represented as a sequence of RR
type mnemonics. When the mnemonic is not known, the TYPE
representation as described in RFC 3597 [4] (section 5) MUST be used.
種別ビットマップフィールドのリストは資源レコード種別の名称の連続とし
て描かれます。名称が知られていない時、ＲＦＣ３５９７[4]（５章）で記
述された種別表現が使われなくてはなりません(MUST)。

2.3. NSEC RR Example
2.3. ＮＳＥＣ資源レコード例

The following NSEC RR identifies the RRsets associated with
alfa.example.com. and the next authoritative name after
alfa.example.com.
次のＮＳＥＣ資源レコードはalfa.example.com.と、alfa.example.com.の後
の正式な名前とに、結びついた資源レコード集合を示します。

alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC
TYPE1234

The first four text fields specify the name, TTL, Class, and RR type
(NSEC). The entry host.example.com. is the next authoritative name
after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
TYPE1234 RRsets associated with the name alfa.example.com.
最初の４つのテキストフィールドは名前とＴＴＬとクラスと資源レコード種
別（ＮＳＥＣ）を指定します。エントリhost.example.com.は正規順で
alfa.example.com.の後の次の正式な名前です。ＡとＭＸとＲＲＳＩＧと
ＮＳＥＣとＴＹＰＥ１２３４の名称は、名前alfa.example.comに関するＡと
ＭＸとＲＲＳＩＧとＮＳＥＣとＴＹＰＥ１２３４資源レコード集合があるこ
とを示します。

The RDATA section of the NSEC RR above would be encoded as:
上記ＮＳＥＣ資源レコードの資源データ部は以下にコード化されます：

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

Assuming that the resolver can authenticate this NSEC record, it
could be used to prove that beta.example.com does not exist, or could
be used to prove that there is no AAAA record associated with
alfa.example.com. Authenticated denial of existence is discussed in
RFC 2535 [2].
リゾルバがこのＮＳＥＣレコードを検証できると想定し、これは
beta.example.comが存在しないか、alfa.example.comと結び付けられた
ＡＡＡＡレコードがないことを証明するために使うことができます。非存在
の証明がＲＦＣ２５３５[2]で論じられます。

3. IANA Considerations
3. ＩＡＮＡの考慮

This document introduces no new IANA considerations, because all of
the protocol parameters used in this document have already been
assigned by RFC 3755 [5].
この文書は新しいＩＡＮＡの考慮を導入しません、なぜならこの文書で使わ
れたプロトコルパラメータのすべてがすでにＲＦＣ３７５５［５］によって
割り当てられたからです。

4. Security Considerations
4. セキュリティの考察

The update of the RDATA format and encoding does not affect the
security of the use of NSEC RRs.
資源データフォーマットとコーディングの更新はＮＳＥＣ資源レコードを使
う際のセキュリティに影響を与えません。

5. References
5. 参考文献

5.1. Normative References
5.1. 参照する参考文献

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[2] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
2535, March 1999.

[3] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain
Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
September 2000.

[4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.

[5] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
(DS)", RFC 3755, May 2004.

5.2. Informative References
5.2. 有益な参考文献

[6] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.

[7] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
2308, March 1998.

6. Acknowledgements
6. 謝辞

The encoding described in this document was initially proposed by
Mark Andrews. Other encodings where proposed by David Blacka and
Michael Graff.
この文書で記述されたコーディングは初めにMark Andrewsによって提案され
ました。他のコーディングはDavid BlackaとMichael Graffによって提案さ
れました。

7. Author's Address
7. 著者のアドレス

Jakob Schlyter (editor)
NIC-SE
Box 5774
Stockholm SE-114 87
Sweden

EMail: jakob@nic.se
URI: http://www.nic.se/

8. Full Copyright Statement
8. 著作権表示全文

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そしてこ
の中に明らかにされる以外は著者がすべての権利を維持します。

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。

Intellectual Property
知的所有権

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。

Acknowledgement
謝辞

Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。

Japanese translation by Ishida So