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


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
DNSセキュリティ(DNSSEC)次の安全(NSEC)資源データフォーマット

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.
   この文書はインターネット共同体のためのインターネット標準化作業中のプ
   ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
   態とこのプロトコル状態は「インターネット公式プロトコル標準」(STD
   1)の現在の版を参照してください。このメモの配布は無制限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (2004).

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.
   この文書は完全に資源レコード(RR)タイプ空間をカバーするためのDN
   S次安全(NSEC)資源レコードの資源データフォーマットの「種別ビッ
   トマップ」フィールドのワイヤフォーマットを再定義します。

Table of Contents
目次

   1.  Introduction
   1.  はじめに
   2.  The NSEC Resource Record
   2.  NSEC資源レコード
       2.1.  NSEC RDATA Wire Format
       2.1.  NSEC資源データワイヤフォーマット
             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.  NSEC資源データのワイルドカード名の包含
       2.2.  The NSEC RR Presentation Format
       2.2.  NSEC資源レコード表示フォーマット
       2.3.  NSEC RR Example
       2.3.  NSEC資源レコード例
   3.  IANA Considerations
   3.  IANAの考慮
   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.
   DNS[6][7]のNSEC[5]資源レコード(RR)は、DNS所有者名と種別
   の非実在の証明で使用します。NSEC資源レコードはRFC2535[2]で
   記述されるようにNXT RRに基づいていて、名前と種別コード以外は同じ
   です。NXT RRの資源データフォーマットは、資源データが最初の127
   の種別の存在についての情報を運ぶことができるという点で、限界がありま
   す。RFC2535は拡張メカニズムを指定するために1ビットを留保しま
   したが、メカニズムは実際には定義されませんでした。

   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.
   最初の127のタイプコードが割り当てられた後で、実装済みのDNSSE
   Cサーバとリゾルバに拡張メカニズムを開発する必要があるのを避けるため
   に、この文書は完全に資源レコード種別空間をカバーするように、NSEC
   資源データの「種別ビットマップ」フィールドフォーマットを再定義します。

   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.
   この文書は種別ビットマップの新しいフォーマットを紹介します。種別ビッ
   トマップフォーマットに求められる特性は、種別コードの完全な範囲に対応
   すること、所有者名に対し少数の種別がある一般的な場合に、使うスペース
   が比較的少ないこと、全ての種別を持つ所有者名が、およそ8.5キロバイト
   のパケットで表現可能なこと、表現の実装が簡単であること、です。タイプ
   ビットマップである特定の種別の存在を効率的に検索することは必要条件で
   はありません。

   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.
   便利さと完全性のために、この文書はRFC2535[2]とその更新のRFC
   3755[5]の仕様に基づくNSEC資源レコードの構文と意味を示し、種別
   ビットマップの構文以外の変更をしません。

   This document updates RFC 2535 [2] and RFC 3755 [5].
   この文書はRFC2535[2]とRFC3755[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"はBCP
   14、RFC2119[1]で記述したように、解釈されるはずです。

2.  The NSEC Resource Record
2.  NSEC資源レコード

   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].
   NSEC資源レコードは2つの異なるものをリストアップします:ゾーンの
   正規順序での次の資源レコード集合の所有者名と、NSEC資源レコードの
   所有者名に存在している資源レコード種別の集合。ゾーン内のNSEC資源
   レコードの完全な集合は、どの資源レコード集合がゾーンに存在するかを示
   し、それぜゾーンの所有者名の連鎖を形成します。この情報は、RFC25
   35[2]で記述されるように、DNSデータに存在しない事の証明を提供する
   ために使われます。

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

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

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

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

   The RDATA of the NSEC RR is as shown below:
   NSECRR資源データは下記の通りです:
 
                         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).
   次のドメイン名フィールドはゾーンの正規順で次の資源レコードの所有者名
   を含んでいます。ゾーンの中の最後のNSECレコードの次のドメイン名
   フィールドの値は、ゾーンの頂上の名前(ゾーンのSOA資源レコードの所
   有者名)です。

   A sender MUST NOT use DNS name compression on the Next Domain Name
   field when transmitting an NSEC RR.
   送信者が、NSEC資源レコードを伝達する時、次のドメイン名フィールド
   にDNS名前圧縮を使ってはなりません(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.
   所定のゾーンで権威がない資源レコード集合の所有者名(例えばグルーレコー
   ド)は、その所有者名に少なくとも1つの正式な資源レコード集合が存在し
   ない限り、次のドメイン名でリストアップされてはなりません(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.
   資源レコード種別空間は256のブロックに分割され、それぞれ16ビット
   の資源レコード種別空間の下位8ビットを表します。少なくとも1つの資源
   レコードを含むブロックが、1オクテットのウインドウブロック番号(0か
   ら255)と、ウインドウブロックのビットマップに使うオクテット数を含
   む1オクテットのビットマップ長(1から32)と、ビットマップに使われ
   た最大32オクテット(256ビット)でコード化されます。

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

   "|" 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.
   それぞれのビットマップがウインドウブロックの下位8ビットの資源レコー
   ド種別を、ネットワークビット順でコード化します。最初のビットはビット
   0です。ウインドウブロック0で、ビット1が資源レコード種別1(A)に
   対応し、ビット2が資源レコード種別2(NS)に対応し、以下同じです。
   ウインドウブロックで、ビット1が資源レコード (RR) 種別257に対応し、
   ビット2が資源レコード種別258に対応します。もしビットが1に設定さ
   れるなら、これはその種類の資源レコード集合がNSEC資源レコードの所
   有者名に対して存在していることを示します。もしビットが0に設定される
   なら、これはその種類の資源レコード集合がNSEC資源レコードの所有者
   名に対して存在していないことを示します。

   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.
   ウィンドウブロック0のビット0が存在しない資源レコード種別0に対応す
   るので、これは0が設定されなくてはなりません(MUST)。検証後に、検証者
   はウィンドウブロック0のビット0の値を無視しなくてはなりません(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.
   RFC2929[3](3.1章)で示されるメタタイプやQTYPEに対するビット
   と、Qタイプとメタタイプだけに割当てるために確保された範囲のビットは、
   これらがゾーンデータに現われないから、0に設定されなければなりません
   (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)。各
   ブロックのビットマップ長は、そのブロックの中のNSEC資源レコードの
   所有者名に存在する資源レコード種別の中で、最大の種別コードで決定され
   ます。指定されない後続するオクテットはゼロと解釈されなくてはなりませ
   ん(MUST)。

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

   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.
   もしワイルドカード所有者名がゾーンにあるなら、ワイルドカードラベル
   ("*")が文字通りの記号として取り扱われ、そして他のNSEC資源レコード
   を生成する目的の所有者名と同じに扱われます。ワイルドカード所有者名が、
   ワイルドカード拡張なしで、次のドメイン名フィールドに現われます。RF
   C2535[2]は存在しない事の証明でのワイルドカードの影響を記述します。

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

   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.
   種別ビットマップフィールドのリストは資源レコード種別の名称の連続とし
   て描かれます。名称が知られていない時、RFC3597[4](5章)で記
   述された種別表現が使われなくてはなりません(MUST)。

2.3.  NSEC RR Example
2.3.  NSEC資源レコード例

   The following NSEC RR identifies the RRsets associated with
   alfa.example.com. and the next authoritative name after
   alfa.example.com.
   次のNSEC資源レコードは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.
   最初の4つのテキストフィールドは名前とTTLとクラスと資源レコード種
   別(NSEC)を指定します。エントリhost.example.com.は正規順で
   alfa.example.com.の後の次の正式な名前です。AとMXとRRSIGと
   NSECとTYPE1234の名称は、名前alfa.example.comに関するAと
   MXとRRSIGとNSECとTYPE1234資源レコード集合があるこ
   とを示します。

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

      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].
   リゾルバがこのNSECレコードを検証できると想定し、これは
   beta.example.comが存在しないか、alfa.example.comと結び付けられた
   AAAAレコードがないことを証明するために使うことができます。非存在
   の証明がRFC2535[2]で論じられます。

3.  IANA Considerations
3.  IANAの考慮

   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].
   この文書は新しいIANAの考慮を導入しません、なぜならこの文書で使わ
   れたプロトコルパラメータのすべてがすでにRFC3755[5]によって
   割り当てられたからです。

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

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

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.  著作権表示全文

   Copyright (C) The Internet Society (2004).
   著作権(C)インターネット学会(2004)。

   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.
   この文書はBCP78に含まれる権利と許可と制限の適用を受け、そしてこ
   の中に明らかにされる以外は著者がすべての権利を維持します。

   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.
   この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
   正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
   可能かの範囲について、IETFは何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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.
   IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、http://www.ietf.org/iprにあるIETFオンライン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は興味を持った誰からでもこの標準を実行するのに必要な技術をカ
   バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
   めます。どうかietf-ipr@ietf.orgのIETFに情報を伝えてください。

Acknowledgement
謝辞

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

[]Japanese translation by Ishida So