RFC 3845 - DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3845
タイトル : RFC 3845 - DNSセキュリティ（DNSSEC）NextSecure（NSEC）RDATA形式
翻訳編集 : 自動生成

[要約] RFC 3845は、DNSセキュリティ（DNSSEC）のNSEC RDATAフォーマットに関する仕様を提供しています。このRFCの目的は、DNSSECにおけるNSECレコードのデータ形式を定義し、DNSセキュリティの実装と運用を向上させることです。

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）NextSecure（NSEC）RDATA形式

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

著作権（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.

このドキュメントでは、DNS NextSecure（NSEC）リソースレコードRDATA形式の「タイプビットマップ」フィールドのワイヤー形式を再定義し、完全なリソースレコード（RR）タイプスペースをカバーします。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . .  2
       2.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . .  3
             2.1.1.  The Next Domain Name Field . . . . . . . . . . .  3
             2.1.2.  The List of Type Bit Map(s) Field  . . . . . . .  3
             2.1.3.  Inclusion of Wildcard Names in NSEC RDATA  . . .  4
       2.2.  The NSEC RR Presentation Format  . . . . . . . . . . . .  4
       2.3.  NSEC RR Example  . . . . . . . . . . . . . . . . . . . .  5
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       5.1.  Normative References . . . . . . . . . . . . . . . . . .  6
       5.2.  Informative References . . . . . . . . . . . . . . . . .  6
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
   7.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7

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 RRは、RFC 2535 [2]に記載されているNXT RRに基づいており、名前とタイプセコードを除いて類似しています。NXT RRのRDATA形式には、RDATAが最初の127型の存在に関する情報のみを伝えることができるという点で制限があります。RFC 2535は、拡張メカニズムを指定するために少し予約しましたが、メカニズムは実際に定義されませんでした。

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型コードが割り当てられたら、DNSSEC認識サーバーとリゾルバーの展開ベースに拡張メカニズムを開発する必要がないようにするために、このドキュメントは、NSEC RDATAの「タイプビットマップ」フィールドのワイヤー形式を再定義して、フルRRタイプスペース。

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.

このドキュメントでは、Type Bit Mapの新しい形式を紹介します。タイプビットマップ形式のプロパティは、タイプコードの完全な範囲をカバーできることです。所有者名を持ついくつかのタイプの一般的なケースに使用するスペースの量は比較的経済的であり、所有者を表すことができます約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.

利便性と完全性のために、このドキュメントは、RFC 2535 [2]の仕様に基づいてNSEC RRの構文とセマンティクスを提示し、RFC 3755 [5]によって更新され、タイプビットマップの構文以外の変更は導入されません。

This document updates RFC 2535 [2] and RFC 3755 [5].

このドキュメントは、RFC 2535 [2]およびRFC 3755 [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].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [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リソースレコードには、ゾーンの標準的な順序付けの次のRRSetの所有者名と、NSEC RRの所有者名に存在するRRタイプのセットという2つの別々のものがリストされています。ゾーン内のNSEC RRSの完全なセットは、ゾーンにどのRRSetが存在するかを示し、ゾーン内に所有者名のチェーンを形成します。この情報は、RFC 2535 [2]で説明されているように、DNSデータの存在の認証された拒否を提供するために使用されます。

The type value for the NSEC RR is 47.

NSEC RRのタイプ値は47です。

The NSEC RR RDATA format is class independent and defined for all classes.

NSEC RR RDATA形式はクラス独立であり、すべてのクラスに対して定義されています。

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 RRは、SOA最小TTLフィールドと同じTTL値を持つ必要があります。これは否定的なキャッシュの精神にあります[8]。

2.1. NSEC RDATA Wire Format

2.1. NSEC RDATAワイヤ形式

The RDATA of the NSEC RR is as shown below:

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                         /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                   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).

次のドメイン名フィールドには、ゾーンの標準的な順序付けに次のRRの所有者名が含まれています。ゾーンの最後のNSECレコードの次のドメイン名フィールドの値は、ゾーン頂点（ゾーンのSOA RRの所有者名）の名前です。

A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR.

送信者は、NSEC RRを送信するときに、次のドメイン名フィールドでDNS名圧縮を使用しないでください。

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.

指定されたゾーン（接着剤レコードなど）に対して権威がないrrsetsの所有者名は、同じ所有者名に少なくとも1つの権威あるRRSetが存在しない限り、次のドメイン名にリストしてはなりません。

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.

RRタイプスペースは256のウィンドウブロックに分割され、それぞれが16ビットRRタイプスペースの低次8ビットを表します。少なくとも1つのアクティブなRRタイプを持つ各ブロックは、単一のオクテットウィンドウ数（0〜255）、単一のオクテットビットマップ長（1から32）を使用してエンコードされ、ウィンドウブロックのビットマップに使用されるオクテットの数を示し、アップします。32オクテット（256ビット）のビットマップ。

Window blocks are present in the NSEC RR RDATA in increasing numerical order.

NSEC RR RDATAには、数値順序が増えてウィンドウブロックが存在します。

"|" 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.

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は、存在しないRRタイプ0を指すため、0に設定する必要があります。

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.

RFC 2929 [3]（セクション3.1）で指定されているメタタイプまたはQTypesを表すビット、またはQTYPESおよびメタタイプへのみの割り当てのために予約されている範囲内で、ゾーンデータに表示されないため、0に設定する必要があります。遭遇した場合、読むときに無視する必要があります。

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.

存在するタイプのないブロックを含める必要はありません。ビットマップのトレーリングゼロオクテットを省略する必要があります。各ブロックのビットマップの長さは、NSEC RRの所有者名に存在するRRタイプのセットの中で、そのブロック内の最大数値値を持つタイプコードによって決定されます。指定されていないトレーリングゼロオクテットは、ゼロオクテットと解釈する必要があります。

2.1.3. Inclusion of Wildcard Names in NSEC RDATA

2.1.3. NSEC RDATAにワイルドカード名を含める

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 RRSを生成する目的で他の所有者名と同じ扱われます。ワイルドカードの所有者名は、ワイルドカードの拡張なしに次のドメイン名フィールドに表示されます。RFC 2535 [2]は、認証された存在の拒否に対するワイルドカードの影響について説明しています。

2.2. The NSEC RR Presentation Format

2.2. NSEC RRプレゼンテーション形式

The presentation format of the RDATA portion is as follows:

RDATA部分のプレゼンテーション形式は次のとおりです。

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.

タイプビットマップフィールドのリストは、RRタイプのニーモニックのシーケンスとして表されます。ニーモニックがわからない場合、RFC 3597 [4]（セクション5）に記載されているタイプ表現を使用する必要があります。

2.3. NSEC RR Example

2.3. NSEC RRの例

The following NSEC RR identifies the RRsets associated with alfa.example.com. and the next authoritative name after alfa.example.com.

次のNSEC RRは、alfa.example.comに関連付けられたRRSetsを識別します。そして、alfa.example.comの次の権威ある名前。

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

alfa.example.com。NSEC host.example.comの86400。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、クラス、およびRRタイプ（NSEC）という名前を指定します。エントリhost.example.com。Alfa.example.comの次の権威ある名前です。標準的な順序で。A、MX、RRSIG、NSEC、およびType1234Mnemonicsは、Alfa.example.comという名前に関連付けられたA、MX、RRSIG、NSEC、およびType1234 RRSetsがあることを示しています。

The RDATA section of the NSEC RR above would be encoded as:

上記の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

0x04 'H' 'o' 's' 't' 0x07 'e' '' '' '' 'M' 'P' 'l' 'e' 0x03 'c' 'o' 'M' 0x00 0x00 0x06 0x40 0x010x00 0x00 0x00 0x00 0x03 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

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].

ResolverがこのNSECレコードを認証できると仮定すると、beta.example.comが存在しないことを証明するために使用できます。または、alfa.example.comに関連するAAAAレコードがないことを証明するために使用できます。認証された存在の拒否は、RFC 2535 [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].

このドキュメントでは、このドキュメントで使用されているすべてのプロトコルパラメーターがすでにRFC 3755によって割り当てられているため、新しいIANAの考慮事項は紹介されていません[5]。

4. Security Considerations

4. セキュリティに関する考慮事項

The update of the RDATA format and encoding does not affect the security of the use of NSEC RRs.

RDATA形式とエンコードの更新は、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.

[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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

[2] EastLake 3rd、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。

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

[3] Eastlake 3rd、D.、Brunner-Williams、E。、およびB. Manning、「ドメイン名システム（DNS）IANAの考慮事項」、BCP 42、RFC 2929、2000年9月。

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

[4] Gustafsson、A。、「不明なDNSリソースレコード（RR）タイプの取り扱い」、RFC 3597、2003年9月。

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

[5] Weiler、S。、「Legacy Resolver Compatibility for Dedigation Signer（DS）」、RFC 3755、2004年5月。

5.2. Informative References

5.2. 参考引用

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

[6] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。

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

[7] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。

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

[8] Andrews、M。、「DNSクエリのネガティブキャッシュ（DNS ncache）」、RFC 2308、1998年3月。

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.

このドキュメントで説明されているエンコードは、当初マークアンドリュースによって提案されました。David BlackaとMichael Graffが提案した他のエンコーディング。

7. Author's Address

7. 著者の連絡先

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

Jakob Schlyter（編集者）Nic-se Box 5774 Stockholm SE-114 87 Sweden

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

8. Full Copyright Statement

8. 完全な著作権声明

著作権（c）The Internet Society（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.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78および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.

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エディター機能の資金は現在、インターネット協会によって提供されています。