この文書は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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。