Network Working Group R. Arends
Request for Comments: 4034 Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
3755, 3757, 3845 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
Resource Records for the DNS Security Extensions
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.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.
このドキュメントは、DNSセキュリティ拡張機能（DNSSEC）を説明するドキュメントファミリの一部です。 DNSセキュリティ拡張機能は、DNSのソース認証を提供するリソースレコードとプロトコル変更のコレクションです。 このドキュメントでは、公開キー（DNSKEY）、委任署名者（DS）、リソースレコードデジタル署名（RRSIG）、および認証された存在の拒否（NSEC）リソースレコードを定義します。 各リソースレコードの目的と形式について詳しく説明し、各リソースレコードの例を示します。
This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.
このドキュメントはRFC 2535を廃止し、RFC 2535へのすべての更新からの変更を組み込みます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Related Documents . . . . . . . . . . . 3
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3
2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4
2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4
2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4
2.1.2. The Protocol Field . . . . . . . . . . . . . . 5
2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5
2.1.4. The Public Key Field . . . . . . . . . . . . . 5
2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5
2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5
2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6
3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6
3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7
3.1.1. The Type Covered Field . . . . . . . . . . . . 7
3.1.2. The Algorithm Number Field . . . . . . . . . . 8
3.1.3. The Labels Field . . . . . . . . . . . . . . . 8
3.1.4. Original TTL Field . . . . . . . . . . . . . . 8
3.1.5. Signature Expiration and Inception Fields. . . 9
3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9
3.1.7. The Signer's Name Field. . . . . . . . . . . . 9
3.1.8. The Signature Field. . . . . . . . . . . . . . 9
3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10
3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
4.1.1. The Next Domain Name Field . . . . . . . . . . 13
4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13
4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14
4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14
4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16
5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16
5.1.3. The Digest Type Field. . . . . . . . . . . . . 17
5.1.4. The Digest Field . . . . . . . . . . . . . . . 17
5.2. Processing of DS RRs When Validating Responses . . . . 17
5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17
5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
6. Canonical Form and Order of Resource Records . . . . . . . . 18
6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18
6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations. . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . 23
A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
A.1.1. Private Algorithm Types. . . . . . . . . . . . 25
A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
The DNS Security Extensions (DNSSEC) introduce four new DNS resource record types: DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This document defines the purpose of each resource record (RR), the RR's RDATA format, and its presentation format (ASCII representation).
DNSセキュリティ拡張機能（DNSSEC）は、DNS公開キー（DNSKEY）、リソースレコード署名（RRSIG）、ネクストセキュア（NSEC）、および委任署名者（DS）の4つの新しいDNSリソースレコードタイプを導入します。 このドキュメントでは、各リソースレコード（RR）の目的、RRのRDATA形式、およびその表示形式（ASCII表現）を定義しています。
This document is part of a family of documents defining DNSSEC, which should be read together as a set.
このドキュメントは、DNSSECを定義する一連のドキュメントの一部であり、セットとして一緒に読む必要があります。
[RFC4033] contains an introduction to DNSSEC and definition of common terms; the reader is assumed to be familiar with this document. [RFC4033] also contains a list of other documents updated by and obsoleted by this document set.
[RFC4033]には、DNSSECの紹介と一般的な用語の定義が含まれています。 読者はこのドキュメントに精通していると想定されます。 [RFC4033]には、このドキュメントセットによって更新され、廃止された他のドキュメントのリストも含まれています。
[RFC4035] defines the DNSSEC protocol operations.
[RFC4035]はDNSSECプロトコル操作を定義します。
The reader is also assumed to be familiar with the basic DNS concepts described in [RFC1034], [RFC1035], and the subsequent documents that update them, particularly [RFC2181] and [RFC2308].
読者は、[RFC1034]、[RFC1035]で説明されている基本的なDNSの概念、およびそれらを更新する後続のドキュメント、特に[RFC2181]および[RFC2308]にも精通していると想定されます。
This document defines the DNSSEC resource records. All numeric DNS type codes given in this document are decimal integers.
このドキュメントでは、DNSSECリソースレコードを定義します。 このドキュメントに記載されているすべての数値DNSタイプコードは、10進整数です。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は [RFC2119]で説明されているように解釈されます。
DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets). The public keys are stored in DNSKEY resource records and are used in the DNSSEC authentication process described in [RFC4035]: A zone signs its authoritative RRsets by using a private key and stores the corresponding public key in a DNSKEY RR. A resolver can then use the public key to validate signatures covering the RRsets in the zone, and thus to authenticate them.
DNSSECは、公開キー暗号化を使用して、DNSリソースレコードセット（RRset）の署名と認証を行います。 公開鍵はDNSKEYリソースレコードに保存され、[RFC4035]で説明されているDNSSEC認証プロセスで使用されます。ゾーンは、秘密鍵を使用して権限のあるRRsetに署名し、対応する公開鍵をDNSKEY RRに保存します。 リゾルバは、公開鍵を使用して、ゾーン内のRRsetをカバーする署名を検証し、それによりそれらを認証できます。
The DNSKEY RR is not intended as a record for storing arbitrary public keys and MUST NOT be used to store certificates or public keys that do not directly relate to the DNS infrastructure.
DNSKEY RRは、任意の公開鍵を保存するためのレコードとして意図されておらず、DNSインフラストラクチャに直接関連しない証明書または公開鍵を保存するために使用してはなりません。
The Type value for the DNSKEY RR type is 48.
DNSKEY RRタイプのタイプ値は48です。
The DNSKEY RR is class independent.
DNSKEY RRはクラスに依存しません。
The DNSKEY RR has no special TTL requirements.
DNSKEY RRには特別なTTL要件はありません。
The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 octet Protocol Field, a 1 octet Algorithm Field, and the Public Key Field.
DNSKEY RRのRDATAは、2オクテットのフラグフィールド、1オクテットのプロトコルフィールド、1オクテットのアルゴリズムフィールド、および公開キーフィールドで構成されます。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Protocol | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Public Key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+ | フラグ| プロトコル| アルゴリズム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ / / /公開キー/ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's owner name MUST be the name of a zone. If bit 7 has value 0, then the DNSKEY record holds some other type of DNS public key and MUST NOT be used to verify RRSIGs that cover RRsets.
Flagsフィールドのビット7は、ゾーンキーフラグです。 ビット7の値が1の場合、DNSKEYレコードはDNSゾーンキーを保持し、DNSKEY RRの所有者名はゾーンの名前でなければなりません。 ビット7の値が0の場合、DNSKEYレコードは他の種類のDNS公開キーを保持し、RRsetをカバーするRRSIGの検証に使用してはなりません。
Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a key intended for use as a secure entry point. This flag is only intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behavior during the signature validation process in any way based on the setting of this bit. This also means that a DNSKEY RR with the SEP bit set would also need the Zone Key flag set in order to be able to generate signatures legally. A DNSKEY RR with the SEP set and the Zone Key flag not set MUST NOT be used to verify RRSIGs that cover RRsets.
Flagsフィールドのビット15は、[RFC3757]で説明されているSecure Entry Pointフラグです。 ビット15の値が1の場合、DNSKEYレコードは、安全なエントリポイントとして使用するためのキーを保持しています。 このフラグは、このDNSKEYレコードの使用目的に関するゾーン署名またはデバッグソフトウェアへのヒントとしてのみ使用されます。 バリデータは、このビットの設定に基づいて、署名の検証プロセス中に動作を変更してはなりません。 これは、SEPビットが設定されたDNSKEY RRも、署名を合法的に生成できるようにするために、ゾーンキーフラグを設定する必要があることを意味します。 SEPが設定され、ゾーンキーフラグが設定されていないDNSKEY RRは、RRsetをカバーするRRSIGを検証するために使用してはなりません。
Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon creation of the DNSKEY RR and MUST be ignored upon receipt.
ビット0〜6および8〜14は予約済みです。これらのビットは、DNSKEY RRの作成時に値0を持たなければならず、受信時に無視する必要があります。
The Protocol Field MUST have value 3, and the DNSKEY RR MUST be treated as invalid during signature verification if it is found to be some value other than 3.
プロトコルフィールドの値は3でなければならず、DNSKEY RRは3以外の値であることが判明した場合、署名検証中に無効として扱われなければなりません。
The Algorithm field identifies the public key's cryptographic algorithm and determines the format of the Public Key field. A list of DNSSEC algorithm types can be found in Appendix A.1
アルゴリズムフィールドは、公開キーの暗号化アルゴリズムを識別し、公開キーフィールドの形式を決定します。 DNSSECアルゴリズムタイプのリストは、付録A.1にあります。
The Public Key Field holds the public key material. The format depends on the algorithm of the key being stored and is described in separate documents.
公開鍵フィールドには、公開鍵素材が保持されます。 この形式は、保存されるキーのアルゴリズムに依存し、別のドキュメントで説明されています。
Although the Protocol Field always has value 3, it is retained for backward compatibility with early versions of the KEY record.
プロトコルフィールドは常に値3を持ちますが、KEYレコードの初期バージョンとの後方互換性のために保持されます。
The presentation format of the RDATA portion is as follows:
RDATA部分の表示形式は次のとおりです。
The Flag field MUST be represented as an unsigned decimal integer. Given the currently defined flags, the possible values are: 0, 256, and 257.
Flagフィールドは、符号なしの10進整数として表されなければなりません。 現在定義されているフラグを指定すると、可能な値は0、256、および257です。
The Protocol Field MUST be represented as an unsigned decimal integer with a value of 3.
プロトコルフィールドは、値3の符号なし10進整数として表されなければなりません。
The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic as specified in Appendix A.1.
アルゴリズムフィールドは、付録A.1で指定されているように、符号なし10進整数またはアルゴリズムニーモニックのいずれかで表されなければなりません。
The Public Key field MUST be represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see [RFC3548].
公開鍵フィールドは、公開鍵のBase64エンコードとして表されなければなりません。 Base64テキスト内では空白を使用できます。 Base64エンコーディングの定義については、[RFC3548]を参照してください。
The following DNSKEY RR stores a DNS zone key for example.com.
次のDNSKEY RRは、example.comのDNSゾーンキーを格納します。
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U aNvv4w== )
example.com。DNSKEY25635 IN86400（AQPSKmynfzW4kyBv015MUG2DeIQ3のCbl+ BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL742iU/ TpPSEDhm2SNKLijfUppn1U aNvv4w==）
The first four text fields specify the owner name, TTL, Class, and RR type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in the Flags field has value 1. Value 3 is the fixed Protocol value. Value 5 indicates the public key algorithm. Appendix A.1 identifies algorithm type 5 as RSA/SHA1 and indicates that the format of the RSA/SHA1 public key field is defined in [RFC3110]. The remaining text is a Base64 encoding of the public key.
最初の4つのテキストフィールドは、所有者名、TTL、クラス、およびRRタイプ（DNSKEY）を指定します。 値256は、フラグフィールドのゾーンキービット（ビット7）の値が1であることを示します。値3は固定プロトコル値です。 値5は公開鍵アルゴリズムを示します。 付録A.1は、アルゴリズムタイプ5をRSA / SHA1として識別し、RSA / SHA1公開キーフィールドの形式が[RFC3110]で定義されていることを示しています。 残りのテキストは、公開キーのBase64エンコードです。
DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets). Digital signatures are stored in RRSIG resource records and are used in the DNSSEC authentication process described in [RFC4035]. A validator can use these RRSIG RRs to authenticate RRsets from the zone. The RRSIG RR MUST only be used to carry verification material (digital signatures) used to secure DNS operations.
DNSSECは、公開キー暗号化を使用して、DNSリソースレコードセット（RRset）の署名と認証を行います。 デジタル署名はRRSIGリソースレコードに保存され、[RFC4035]で説明されているDNSSEC認証プロセスで使用されます。 バリデーターはこれらのRRSIG RRを使用して、ゾーンからのRRsetを認証できます。 RRSIG RRは、DNS操作を保護するために使用される検証資料（デジタル署名）を運ぶためにのみ使用されなければなりません。
An RRSIG record contains the signature for an RRset with a particular name, class, and type. The RRSIG RR specifies a validity interval for the signature and uses the Algorithm, the Signer's Name, and the Key Tag to identify the DNSKEY RR containing the public key that a validator can use to verify the signature.
RRSIGレコードには、特定の名前、クラス、およびタイプのRRsetの署名が含まれます。 RRSIG RRは、署名の有効期間を指定し、アルゴリズム、署名者の名前、およびキータグを使用して、検証者が署名の検証に使用できる公開キーを含むDNSKEY RRを識別します。
Because every authoritative RRset in a zone must be protected by a digital signature, RRSIG RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [RFC1034], which stated that if a CNAME is present for a name, it is the only type allowed at that name. A RRSIG and NSEC (see Section 4) MUST exist for the same name as a CNAME resource record in a signed zone.
ゾーン内のすべての信頼できるRRsetはデジタル署名で保護する必要があるため、CNAME RRを含む名前にはRRSIG RRが存在する必要があります。 これは、従来のDNS仕様[RFC1034]に対する変更であり、名前にCNAMEが存在する場合、その名前で許可される唯一のタイプであると述べています。 署名されたゾーンのCNAMEリソースレコードと同じ名前のRRSIGとNSEC（セクション4を参照）が存在する必要があります。
The Type value for the RRSIG RR type is 46.
RRSIG RRタイプのタイプ値は46です。
The RRSIG RR is class independent.
RRSIG RRはクラスに依存しません。
An RRSIG RR MUST have the same class as the RRset it covers.
RRSIG RRは、それがカバーするRRsetと同じクラスを持たなければなりません。
The TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers. This is an exception to the [RFC2181] rules for TTL values of individual RRs within a RRset: individual RRSIG RRs with the same owner name will have different TTL values if the RRsets they cover have different TTL values.
RRSIG RRのTTL値は、それがカバーするRRsetのTTL値と一致しなければなりません。 これは、RRset内の個々のRRのTTL値に関する[RFC2181]ルールの例外です。同じ所有者名を持つ個々のRRSIG RRは、それらがカバーするRRsetが異なるTTL値を持つ場合、異なるTTL値を持ちます。
The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original TTL field, a 4 octet Signature Expiration field, a 4 octet Signature Inception field, a 2 octet Key tag, the Signer's Name field, and the Signature field.
RRSIG RRのRDATAは、2オクテットのType Coveredフィールド、1オクテットのAlgorithmフィールド、1オクテットのLabelsフィールド、4オクテットの元のTTLフィールド、4オクテットの署名有効期限フィールド、4オクテットの署名開始フィールド、2 オクテットキータグ、署名者の名前フィールド、および署名フィールド。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Covered | Algorithm | Labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Inception | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+ | 対象タイプ| アルゴリズム| ラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | 元のTTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | 署名の有効期限| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | 署名の開始| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ | キータグ| / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+署名者の名前/ / / +-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+ / / /署名/ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+
The Type Covered field identifies the type of the RRset that is covered by this RRSIG record.
Type Coveredフィールドは、このRRSIGレコードでカバーされるRRsetのタイプを識別します。
The Algorithm Number field identifies the cryptographic algorithm used to create the signature. A list of DNSSEC algorithm types can be found in Appendix A.1
[アルゴリズム番号]フィールドは、署名の作成に使用される暗号化アルゴリズムを識別します。 DNSSECアルゴリズムタイプのリストは、付録A.1にあります。
The Labels field specifies the number of labels in the original RRSIG RR owner name. The significance of this field is that a validator uses it to determine whether the answer was synthesized from a wildcard. If so, it can be used to determine what owner name was used in generating the signature.
Labelsフィールドは、元のRRSIG RR所有者名のラベルの数を指定します。 このフィールドの重要性は、バリデーターがそれを使用して、回答がワイルドカードから合成されたかどうかを判断することです。 その場合、署名の生成に使用された所有者名を判別するために使用できます。
To validate a signature, the validator needs the original owner name that was used to create the signature. If the original owner name contains a wildcard label ("*"), the owner name may have been expanded by the server during the response process, in which case the validator will have to reconstruct the original owner name in order to validate the signature. [RFC4035] describes how to use the Labels field to reconstruct the original owner name.
署名を検証するには、バリデーターには署名の作成に使用された元の所有者名が必要です。 元の所有者名にワイルドカードラベル（ "*"）が含まれている場合、所有者名は応答プロセス中にサーバーによって拡張されている可能性があります。 [RFC4035]は、Labelsフィールドを使用して元の所有者名を再構築する方法を説明しています。
The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the wildcard label (if present). The value of the Labels field MUST be less than or equal to the number of labels in the RRSIG owner name. For example, "www.example.com." has a Labels field value of 3, and "*.example.com." has a Labels field value of 2. Root (".") has a Labels field value of 0.
Labelsフィールドの値は、所有者名を終わらせるヌル（ルート）ラベルまたはワイルドカードラベル（存在する場合）をカウントしてはなりません（MUST NOT）。 Labelsフィールドの値は、RRSIG所有者名のラベルの数以下でなければなりません。 たとえば、「www.example.com」。 Labelsフィールドの値は3で、「*。example.com」です。 ラベルフィールド値は2です。ルート（ "。"）のラベルフィールド値は0です。
Although the wildcard label is not included in the count stored in the Labels field of the RRSIG RR, the wildcard label is part of the RRset's owner name when the signature is generated or verified.
ワイルドカードラベルは、RRSIG RRの[ラベル]フィールドに格納されているカウントには含まれませんが、署名が生成または検証されるときに、ワイルドカードラベルはRRsetの所有者名の一部になります。
The Original TTL field specifies the TTL of the covered RRset as it appears in the authoritative zone.
元のTTLフィールドは、権限ゾーンに表示される対象RRsetのTTLを指定します。
The Original TTL field is necessary because a caching resolver decrements the TTL value of a cached RRset. In order to validate a signature, a validator requires the original TTL. [RFC4035] describes how to use the Original TTL field value to reconstruct the original TTL.
元のTTLフィールドは、キャッシュリゾルバがキャッシュされたRRsetのTTL値を減らすために必要です。 署名を検証するには、バリデーターに元のTTLが必要です。 [RFC4035]では、元のTTLフィールド値を使用して元のTTLを再構成する方法について説明しています。
The Signature Expiration and Inception fields specify a validity period for the signature. The RRSIG record MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication after the expiration date.
Signature ExpirationおよびInceptionフィールドは、署名の有効期間を指定します。 RRSIGレコードは、開始日より前の認証に使用してはならず、有効期限後の認証に使用してはなりません。
The Signature Expiration and Inception field values specify a date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The longest interval that can be expressed by this format without wrapping is approximately 136 years. An RRSIG RR can have an Expiration field value that is numerically smaller than the Inception field value if the expiration field value is near the 32-bit wrap-around point or if the signature is long lived. Because of this, all comparisons involving these fields MUST use "Serial number arithmetic", as defined in [RFC1982]. As a direct consequence, the values contained in these fields cannot refer to dates more than 68 years in either the past or the future.
Signature Expiration and Inceptionフィールドの値は、1970年1月1日00:00:00 UTCから経過した32ビットの符号なし秒数の形式で日付と時刻を指定し、うるう秒は無視します。 この形式でラッピングなしで表現できる最長の間隔は約136年です。 有効期限フィールドの値が32ビットのラップアラウンドポイントに近い場合、または署名の有効期間が長い場合、RRSIG RRの有効期限フィールドの値は、開始フィールドの値よりも数値的に小さくなります。 このため、これらのフィールドを含むすべての比較では、[RFC1982]で定義されているように、「シリアル番号算術」を使用する必要があります。 直接的な結果として、これらのフィールドに含まれる値は、過去または未来のいずれかで68年を超える日付を参照できません。
The Key Tag field contains the key tag value of the DNSKEY RR that validates this signature, in network byte order. Appendix B explains how to calculate Key Tag values.
[キータグ]フィールドには、この署名をネットワークバイト順で検証するDNSKEY RRのキータグ値が含まれます。 付録Bでは、キータグ値の計算方法について説明します。
The Signer's Name field value identifies the owner name of the DNSKEY RR that a validator is supposed to use to validate this signature. The Signer's Name field MUST contain the name of the zone of the covered RRset. A sender MUST NOT use DNS name compression on the Signer's Name field when transmitting a RRSIG RR.
署名者の名前フィールドの値は、検証者がこの署名の検証に使用することになっているDNSKEY RRの所有者名を識別します。 署名者の名前フィールドには、カバーされるRRsetのゾーンの名前が含まれていなければなりません。 送信者は、RRSIG RRを送信するときに署名者の名前フィールドでDNS名圧縮を使用してはなりません。
The Signature field contains the cryptographic signature that covers the RRSIG RDATA (excluding the Signature field) and the RRset specified by the RRSIG owner name, RRSIG class, and RRSIG Type Covered field. The format of this field depends on the algorithm in use, and these formats are described in separate companion documents.
Signatureフィールドには、RRSIG RDATA（Signatureフィールドを除く）およびRRSIGオーナー名、RRSIGクラス、RRSIG Type Coveredフィールドで指定されたRRsetをカバーする暗号署名が含まれます。 このフィールドの形式は使用中のアルゴリズムに依存し、これらの形式は別の関連ドキュメントで説明されています。
A signature covers the RRSIG RDATA (excluding the Signature Field) and covers the data RRset specified by the RRSIG owner name, RRSIG class, and RRSIG Type Covered fields. The RRset is in canonical form (see Section 6), and the set RR(1),...RR(n) is signed as follows:
署名は、RRSIG RDATA（署名フィールドを除く）をカバーし、RRSIG所有者名、RRSIGクラス、およびRRSIGタイプカバーフィールドで指定されたデータRRsetをカバーします。 RRsetは標準形式（セクション6を参照）であり、セットRR（1）、... RR（n）は次のように署名されます。
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
署名= sign（RRSIG_RDATA | RR（1）| RR（2）...）ここで
"|" denotes concatenation;
「|」 連結を示します。
RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the Signature field excluded;
RRSIG_RDATAは、正規形式の署名者の名前フィールドと署名フィールドが除外されたRRSIG RDATAフィールドのワイヤ形式です。
RR(i) = owner | type | class | TTL | RDATA length | RDATA
RR（i）=所有者| タイプ| クラス| TTL | RDATAの長さ| RDATA
"owner" is the fully qualified owner name of the RRset in canonical form (for RRs with wildcard owner names, the wildcard label is included in the owner name);
「owner」は、正規形式のRRsetの完全修飾所有者名です（ワイルドカード所有者名を持つRRの場合、所有者名にワイルドカードラベルが含まれます）。
Each RR MUST have the same owner name as the RRSIG RR;
各RRには、RRSIG RRと同じ所有者名が必要です。
Each RR MUST have the same class as the RRSIG RR;
各RRは、RRSIG RRと同じクラスを持たなければなりません。
Each RR in the RRset MUST have the RR type listed in the RRSIG RR's Type Covered field;
RRset内の各RRは、RRSIG RRのType CoveredフィールドにリストされたRRタイプを持たなければなりません。
Each RR in the RRset MUST have the TTL listed in the RRSIG Original TTL Field;
RRsetの各RRは、RRSIG Original TTLフィールドにリストされたTTLを持たなければなりません。
Any DNS names in the RDATA field of each RR MUST be in canonical form; and
各RRのRDATAフィールド内のDNS名はすべて正規形式でなければなりません。 そして
The RRset MUST be sorted in canonical order.
RRsetは標準的な順序でソートされなければなりません。
See Sections 6.2 and 6.3 for details on canonical form and ordering of RRsets.
正規形式とRRsetの順序付けの詳細については、セクション6.2および6.3を参照してください。
The presentation format of the RDATA portion is as follows:
RDATA部分の表示形式は次のとおりです。
The Type Covered field is represented as an RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in [RFC3597], Section 5, MUST be used.
Type Coveredフィールドは、RRタイプのニーモニックとして表されます。 ニーモニックが不明の場合、[RFC3597]、セクション5で説明されているTYPE表現を使用する必要があります。
The Algorithm field value MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic, as specified in Appendix A.1.
アルゴリズムフィールド値は、付録A.1で指定されているように、符号なしの10進整数またはアルゴリズムニーモニックのいずれかで表現する必要があります。
The Labels field value MUST be represented as an unsigned decimal integer.
Labelsフィールド値は、符号なしの10進整数として表されなければなりません。
The Original TTL field value MUST be represented as an unsigned decimal integer.
オリジナルのTTLフィールド値は、符号なしの10進整数として表現されなければなりません。
The Signature Expiration Time and Inception Time field values MUST be represented either as an unsigned decimal integer indicating seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where:
署名有効期限および開始時刻フィールドの値は、1970年1月1日00:00:00 UTCからの秒数を示す符号なし10進整数、またはUTCのYYYYMMDDHHmmSSの形式で表されなければなりません。
YYYY is the year (0001-9999, but see Section 3.1.5);
MM is the month number (01-12);
DD is the day of the month (01-31);
HH is the hour, in 24 hour notation (00-23);
mm is the minute (00-59); and
SS is the second (00-59).
Note that it is always possible to distinguish between these two formats because the YYYYMMDDHHmmSS format will always be exactly 14 digits, while the decimal representation of a 32-bit unsigned integer can never be longer than 10 digits.
YYYYMMDDHHmmSS形式は常に正確に14桁であるが、32ビット符号なし整数の10進表現は10桁を超えることはできないため、これら2つの形式を常に区別できることに注意してください。
The Key Tag field MUST be represented as an unsigned decimal integer.
キータグフィールドは、符号なしの10進整数として表されなければなりません。
The Signer's Name field value MUST be represented as a domain name.
署名者の名前フィールドの値は、ドメイン名として表されなければなりません。
The Signature field is represented as a Base64 encoding of the signature. Whitespace is allowed within the Base64 text. See Section 2.2.
署名フィールドは、署名のBase64エンコードとして表されます。 Base64テキスト内では空白を使用できます。 セクション2.2を参照してください。
The following RRSIG RR stores the signature for the A RRset of host.example.com:
次のRRSIG RRは、host.example.comのA RRsetの署名を保存します。
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 20030220173103 2642 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
host.example.com。RRSIG A5 3 8640020030322173103（200302201731032642 example.com。oJB1W6WNGv+ ldvQ3WDG0MQkg5IEhjRip8WTr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+ v6o B9wfuh3DTJXUAfI/ M0zmO/ zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o=）IN86400
The first four fields specify the owner name, TTL, Class, and RR type (RRSIG). The "A" represents the Type Covered field. The value 5 identifies the algorithm used (RSA/SHA1) to create the signature. The value 3 is the number of Labels in the original owner name. The value 86400 in the RRSIG RDATA is the Original TTL for the covered A RRset. 20030322173103 and 20030220173103 are the expiration and inception dates, respectively. 2642 is the Key Tag, and example.com. is the Signer's Name. The remaining text is a Base64 encoding of the signature.
最初の4つのフィールドは、所有者名、TTL、クラス、およびRRタイプ（RRSIG）を指定します。 「A」は、Type Coveredフィールドを表します。 値5は、署名の作成に使用されるアルゴリズム（RSA / SHA1）を識別します。 値3は、元の所有者名のラベルの数です。 RRSIG RDATAの値86400は、対象A RRsetの元のTTLです。 20030322173103と20030220173103は、それぞれ有効期限と開始日です。 2642はキータグであり、example.comです。 署名者の名前です。 残りのテキストは、署名のBase64エンコードです。
Note that combination of RRSIG RR owner name, class, and Type Covered indicates that this RRSIG covers the "host.example.com" A RRset. The Label value of 3 indicates that no wildcard expansion was used. The Algorithm, Signer's Name, and Key Tag indicate that this signature can be authenticated using an example.com zone DNSKEY RR whose algorithm is 5 and whose key tag is 2642.
RRSIG RRの所有者名、クラス、および対象タイプの組み合わせは、このRRSIGが「host.example.com」A RRsetをカバーすることを示すことに注意してください。 ラベル値3は、ワイルドカード拡張が使用されなかったことを示します。 アルゴリズム、署名者の名前、およびキータグは、アルゴリズムが5でキータグが2642のexample.comゾーンDNSKEY RRを使用してこの署名を認証できることを示します。
The NSEC resource record lists two separate things: the next owner name (in the canonical ordering of the zone) that contains authoritative data or a delegation point NS RRset, and the set of RR types present at the NSEC RR's owner name [RFC3845]. The complete set of NSEC RRs in a zone indicates which authoritative RRsets exist in a zone and also form a chain of authoritative owner names in the zone. This information is used to provide authenticated denial of existence for DNS data, as described in [RFC4035].
NSECリソースレコードには、2つの個別の事柄がリストされています：権限のあるデータまたは委任ポイントNS RRsetを含む次の所有者名（ゾーンの標準的な順序）、およびNSEC RRの所有者名[RFC3845]に存在するRRタイプのセット。 ゾーン内のNSEC RRの完全なセットは、ゾーンに存在する信頼できるRRsetを示し、ゾーン内の信頼できる所有者名のチェーンを形成します。 [RFC4035]で説明されているように、この情報はDNSデータの認証された存在の拒否を提供するために使用されます。
Because every authoritative name in a zone must be part of the NSEC chain, NSEC RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [RFC1034], which stated that if a CNAME is present for a name, it is the only type allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist for the same name as does a CNAME resource record in a signed zone.
ゾーン内のすべての信頼できる名前はNSECチェーンの一部である必要があるため、CNAME RRを含む名前にはNSEC RRが存在する必要があります。 これは、従来のDNS仕様[RFC1034]に対する変更であり、名前にCNAMEが存在する場合、その名前で許可される唯一のタイプであると述べています。 署名済みゾーンのCNAMEリソースレコードと同じ名前のRRSIG（セクション3を参照）とNSECが存在する必要があります。
See [RFC4035] for discussion of how a zone signer determines precisely which NSEC RRs it has to include in a zone.
ゾーン署名者がどのNSEC RRをゾーンに含める必要があるかを正確に決定する方法については、[RFC4035]を参照してください。
The type value for the NSEC RR is 47.
NSEC RRのタイプ値は47です。
The NSEC RR is class independent.
NSEC RRはクラスに依存しません。
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([RFC2308]).
NSEC RRは、SOA最小TTLフィールドと同じTTL値を持つ必要があります。 これは、ネガティブキャッシュの精神に基づいています（[RFC2308]）。
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 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Type Bit Maps / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+ /次のドメイン名/ +-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /タイプビットマップ/ +-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+
The Next Domain field contains the next owner name (in the canonical ordering of the zone) that has authoritative data or contains a delegation point NS RRset; see Section 6.1 for an explanation of canonical ordering. 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). This indicates that the owner name of the NSEC RR is the last name in the canonical ordering of the zone.
[次のドメイン]フィールドには、信頼できるデータがあるか、委任ポイントNS RRsetを含む次の所有者名（ゾーンの正規の順序）が含まれます。 正規の順序付けの説明については、セクション6.1を参照してください。 ゾーンの最後のNSECレコードのNext Domain Nameフィールドの値は、ゾーンの頂点の名前（ゾーンのSOA RRの所有者名）です。 これは、NSEC 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 for which the given zone is not authoritative (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.
特定のゾーンが信頼できないRRsetの所有者名（グルーレコードなど）は、同じ所有者名に少なくとも1つの信頼できるRRsetが存在しない限り、次のドメイン名にリストしてはいけません。
The Type Bit Maps field identifies the RRset types that exist at the NSEC RR's owner name.
Type Bit Mapsフィールドは、NSEC RRの所有者名に存在するRRsetタイプを識別します。
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）、およびup 32オクテット（256ビット）のビットマップ。
Blocks are present in the NSEC RR RDATA in increasing numerical order.
NSEC RR RDATAには、番号順に昇順でブロックが存在します。
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
タイプビットマップフィールド=（ウィンドウブロック番号|ビットマップ長|ビットマップ）+
where "|" denotes concatenation.
ここで、「|」 連結を示します。
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, it indicates that an RRset of that type is present for the NSEC RR's owner name. If a bit is clear, it indicates that no RRset of that type is present for the NSEC RR's owner name.
各ビットマップは、ウィンドウブロック内の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の所有者名に存在しないことを示します。
Bits representing pseudo-types MUST be clear, as they do not appear in zone data. If encountered, they MUST be ignored upon being read.
疑似タイプを表すビットは、ゾーンデータに表示されないため、クリアする必要があります。 発生した場合、それらは読み取られても無視されなければなりません。
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タイプのセットの中で、そのブロック内で最大の数値を持つタイプコードによって決定されます。 指定されていない後続のゼロオクテットは、ゼロオクテットとして解釈されなければなりません。
The bitmap for the NSEC RR at a delegation point requires special attention. Bits corresponding to the delegation NS RRset and the RR types for which the parent zone has authoritative data MUST be set; bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be clear.
委任ポイントでのNSEC RRのビットマップには、特別な注意が必要です。 親ゾーンが信頼できるデータを持っている委任NS RRsetおよびRRタイプに対応するビットを設定する必要があります。 親が信頼できない非NS RRsetに対応するビットは明確でなければなりません。
A zone MUST NOT include an NSEC RR for any domain name that only holds glue records.
ゾーンには、グルーレコードのみを保持するドメイン名のNSEC RRを含めることはできません。
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 the purposes of generating NSEC RRs. Wildcard owner names appear in the Next Domain Name field without any wildcard expansion. [RFC4035] describes the impact of wildcards on authenticated denial of existence.
ワイルドカード所有者名がゾーンに表示される場合、ワイルドカードラベル（ "*"）はリテラルシンボルとして扱われ、NSEC RRを生成する目的で他の所有者名と同じように扱われます。 ワイルドカードの所有者名は、ワイルドカードを展開せずに[次のドメイン名]フィールドに表示されます。 [RFC4035]は、認証された存在の否定に対するワイルドカードの影響を説明しています。
The presentation format of the RDATA portion is as follows:
RDATA部分の表示形式は次のとおりです。
The Next Domain Name field is represented as a domain name.
[次のドメイン名]フィールドは、ドメイン名として表されます。
The Type Bit Maps field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPE representation described in [RFC3597], Section 5, MUST be used.
Type Bit Mapsフィールドは、RRタイプのニーモニックのシーケンスとして表されます。 ニーモニックが不明な場合、[RFC3597]、セクション5で説明されているTYPE表現を使用する必要があります。
The following NSEC RR identifies the RRsets associated with alfa.example.com. and identifies the next authoritative name after alfa.example.com.
次のNSEC RRは、alfa.example.comに関連付けられたRRsetを識別します。 そして、alfa.example.comの次の信頼できる名前を識別します。
alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 )
alfa.example.com。 86400 IN NSEC host.example.com。 （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 that 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、およびTYPE1234ニーモニックは、alfa.example.comという名前に関連付けられたA、MX、RRSIG、NSEC、およびTYPE1234 RRsetがあることを示しています。
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
Assuming that the validator can authenticate this NSEC record, it could be used to prove that beta.example.com does not exist, or to prove that there is no AAAA record associated with alfa.example.com. Authenticated denial of existence is discussed in [RFC4035].
バリデーターがこのNSECレコードを認証できると仮定すると、beta.example.comが存在しないことを証明するため、またはalfa.example.comに関連付けられたAAAAレコードがないことを証明するために使用できます。 認証された存在の拒否については、[RFC4035]で説明されています。
The DS Resource Record refers to a DNSKEY RR and is used in the DNS DNSKEY authentication process. A DS RR refers to a DNSKEY RR by storing the key tag, algorithm number, and a digest of the DNSKEY RR. Note that while the digest should be sufficient to identify the public key, storing the key tag and key algorithm helps make the identification process more efficient. By authenticating the DS record, a resolver can authenticate the DNSKEY RR to which the DS record points. The key authentication process is described in [RFC4035].
DSリソースレコードはDNSKEY RRを参照し、DNS DNSKEY認証プロセスで使用されます。 DS RRは、キータグ、アルゴリズム番号、およびDNSKEY RRのダイジェストを保存することにより、DNSKEY RRを参照します。 ダイジェストは公開キーを識別するのに十分なはずですが、キータグとキーアルゴリズムを保存すると、識別プロセスがより効率的になります。 DSレコードを認証することにより、リゾルバーはDSレコードが指すDNSKEY RRを認証できます。 鍵認証プロセスは[RFC4035]で説明されています。
The DS RR and its corresponding DNSKEY RR have the same owner name, but they are stored in different locations. The DS RR appears only on the upper (parental) side of a delegation, and is authoritative data in the parent zone. For example, the DS RR for "example.com" is stored in the "com" zone (the parent zone) rather than in the
DS RRとそれに対応するDNSKEY RRの所有者名は同じですが、それらは異なる場所に保存されます。 DS RRは、委任の上位（親）側にのみ表示され、親ゾーンの信頼できるデータです。 たとえば、「example.com」のDS RRは、「com」ゾーン（親ゾーン）ではなく「com」ゾーンに保存されます
"example.com" zone (the child zone). The corresponding DNSKEY RR is stored in the "example.com" zone (the child zone). This simplifies DNS zone management and zone signing but introduces special response processing requirements for the DS RR; these are described in [RFC4035].
「example.com」ゾーン（子ゾーン）。 対応するDNSKEY RRは、「example.com」ゾーン（子ゾーン）に保存されます。 これにより、DNSゾーン管理とゾーン署名が簡素化されますが、DS RRに特別な応答処理要件が導入されます。 これらは[RFC4035]で説明されています。
The type number for the DS record is 43.
DSレコードのタイプ番号は43です。
The DS resource record is class independent.
DSリソースレコードはクラスに依存しません。
The DS RR has no special TTL requirements.
DS RRには特別なTTL要件はありません。
The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet Algorithm field, a 1 octet Digest Type field, and a Digest field.
DS RRのRDATAは、2オクテットのキータグフィールド、1オクテットのアルゴリズムフィールド、1オクテットのダイジェストタイプフィールド、およびダイジェストフィールドで構成されます。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm | Digest Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+ | キータグ| アルゴリズム| ダイジェストタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ / / /ダイジェスト/ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Key Tag field lists the key tag of the DNSKEY RR referred to by the DS record, in network byte order.
Key Tagフィールドには、DSレコードによって参照されるDNSKEY RRのキータグがネットワークバイト順にリストされます。
The Key Tag used by the DS RR is identical to the Key Tag used by RRSIG RRs. Appendix B describes how to compute a Key Tag.
DS RRで使用されるキータグは、RRSIG RRで使用されるキータグと同じです。 付録Bでは、キータグの計算方法について説明します。
The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DS record.
Algorithmフィールドには、DSレコードによって参照されるDNSKEY RRのアルゴリズム番号がリストされます。
The algorithm number used by the DS RR is identical to the algorithm number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm number types.
DS RRで使用されるアルゴリズム番号は、RRSIGおよびDNSKEY RRで使用されるアルゴリズム番号と同じです。 付録A.1には、アルゴリズム番号のタイプがリストされています。
The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY RR. The Digest Type field identifies the algorithm used to construct the digest. Appendix A.2 lists the possible digest algorithm types.
DS RRは、DNSKEY RRのダイジェストを含めることにより、DNSKEY RRを参照します。 Digest Typeフィールドは、ダイジェストの作成に使用されるアルゴリズムを識別します。 付録A.2には、可能なダイジェストアルゴリズムタイプがリストされています。
The DS record refers to a DNSKEY RR by including a digest of that DNSKEY RR.
DSレコードは、DNSKEY RRのダイジェストを含めることにより、DNSKEY RRを参照します。
The digest is calculated by concatenating the canonical form of the fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, and then applying the digest algorithm.
ダイジェストは、DNSKEY RRの完全修飾所有者名の正規形式とDNSKEY RDATAを連結し、ダイジェストアルゴリズムを適用することによって計算されます。
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
ダイジェスト= digest_algorithm（DNSKEY所有者名| DNSKEY RDATA）;
"|" denotes concatenation
「|」 連結を示します
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
DNSKEY RDATA =フラグ| プロトコル| アルゴリズム| 公開鍵。
The size of the digest may vary depending on the digest algorithm and DNSKEY RR size. As of the time of this writing, the only defined digest algorithm is SHA-1, which produces a 20 octet digest.
ダイジェストのサイズは、ダイジェストアルゴリズムとDNSKEY RRサイズによって異なる場合があります。 このドキュメントの執筆時点では、定義されているダイジェストアルゴリズムはSHA-1のみであり、20オクテットのダイジェストを生成します。
The DS RR links the authentication chain across zone boundaries, so the DS RR requires extra care in processing. The DNSKEY RR referred to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be used in the validation process.
DS RRは、ゾーンの境界を越えて認証チェーンをリンクするため、DS RRの処理には特別な注意が必要です。 DS RRで参照されるDNSKEY RRは、DNSSECゾーンキーでなければなりません。 DNSKEY RRフラグには、フラグビット7を設定する必要があります。 DNSKEYフラグがDNSSECゾーンキーを示していない場合、検証プロセスでDS RR（およびそれが参照するDNSKEY RR）を使用してはなりません（MUST NOT）。
The presentation format of the RDATA portion is as follows:
RDATA部分の表示形式は次のとおりです。
The Key Tag field MUST be represented as an unsigned decimal integer.
キータグフィールドは、符号なしの10進整数として表されなければなりません。
The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic specified in Appendix A.1.
アルゴリズムフィールドは、符号なしの10進整数として、または付録A.1で指定されたアルゴリズムニーモニックとして表されなければなりません。
The Digest Type field MUST be represented as an unsigned decimal integer.
ダイジェストタイプフィールドは、符号なしの10進整数として表されなければなりません。
The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text.
ダイジェストは、大文字と小文字を区別しない16進数のシーケンスとして表現する必要があります。 16進テキスト内で空白を使用できます。
The following example shows a DNSKEY RR and its corresponding DS RR.
次の例は、DNSKEY RRとそれに対応するDS RRを示しています。
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw== ) ; key id = 60485
dskey.example.com。DNSKEY IN86400 25635（AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/ M5+ X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc NOF+ EPbtG9DMBmADjFDc2w/ R ljwvFw==）。 キーID = 60485
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 98631FAD1A292118 )
dskey.example.com。 86400 IN DS 60485 5 1（2BB183AF5F22588179A53B0A 98631FAD1A292118）
The first four text fields specify the name, TTL, Class, and RR type (DS). Value 60485 is the key tag for the corresponding "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm used by this "dskey.example.com." DNSKEY RR. The value 1 is the algorithm used to construct the digest, and the rest of the RDATA text is the digest in hexadecimal.
最初の4つのテキストフィールドは、名前、TTL、クラス、およびRRタイプ（DS）を指定します。 値60485は、対応する「dskey.example.com」のキータグです。 DNSKEY RR、および値5は、この「dskey.example.com」で使用されるアルゴリズムを示します。 DNSKEY RR。 値1はダイジェストの作成に使用されるアルゴリズムで、RDATAテキストの残りは16進数のダイジェストです。
This section defines a canonical form for resource records, a canonical ordering of DNS names, and a canonical ordering of resource records within an RRset. A canonical name order is required to construct the NSEC name chain. A canonical RR form and ordering within an RRset are required in order to construct and verify RRSIG RRs.
このセクションでは、リソースレコードの標準形式、DNS名の標準順序、およびRRset内のリソースレコードの標準順序を定義します。 NSEC名前チェーンを構築するには、正規名の順序が必要です。 RRSIG RRを構築および検証するには、RRセット内での標準RRフォームと順序付けが必要です。
For the purposes of DNS security, owner names are ordered by treating individual labels as unsigned left-justified octet strings. The absence of a octet sorts before a zero value octet, and uppercase US-ASCII letters are treated as if they were lowercase US-ASCII letters.
DNSセキュリティの目的で、所有者名は、個々のラベルを符号なしの左揃えのオクテット文字列として扱うことによって順序付けられます。 オクテットがない場合、ゼロ値オクテットの前にソートされ、大文字のUS-ASCII文字は小文字のUS-ASCII文字として扱われます。
To compute the canonical ordering of a set of DNS names, start by sorting the names according to their most significant (rightmost) labels. For names in which the most significant label is identical, continue sorting according to their next most significant label, and so forth.
DNS名のセットの標準的な順序を計算するには、最も重要な（右端の）ラベルに従って名前を並べ替えることから始めます。 最も重要なラベルが同じ名前の場合、次に重要なラベルに従ってソートを続けます。
For example, the following names are sorted in canonical DNS name order. The most significant label is "example". At this level, "example" sorts first, followed by names ending in "a.example", then by names ending "z.example". The names within each level are sorted in the same way.
たとえば、次の名前は正規のDNS名の順序で並べ替えられます。 最も重要なラベルは「例」です。 このレベルでは、「example」が最初にソートされ、次に「a.example」で終わる名前、次に「z.example」で終わる名前がソートされます。 各レベル内の名前は同じ方法でソートされます。
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
\001.z.example
*.z.example
\200.z.example
For the purposes of DNS security, the canonical form of an RR is the wire format of the RR where:
DNSセキュリティの目的では、RRの標準形式はRRのワイヤ形式です。ここで、
1. every domain name in the RR is fully expanded (no DNS name compression) and fully qualified;
1. RR内のすべてのドメイン名は完全に展開され（DNS名の圧縮なし）、完全修飾されています。
2. all uppercase US-ASCII letters in the owner name of the RR are replaced by the corresponding lowercase US-ASCII letters;
2. RRの所有者名のすべての大文字のUS-ASCII文字は、対応する小文字のUS-ASCII文字に置き換えられます。
3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters;
3. RRのタイプがNS、MD、MF、CNAME、SOA、MB、MG、MR、PTR、HINFO、MINFO、MX、HINFO、RP、AFSDB、RT、SIG、PX、NXT、NAPTR、KXの場合 、SRV、DNAME、A6、RRSIG、またはNSEC。RDATAに含まれるDNS名のすべての大文字のUS-ASCII文字は、対応する小文字のUS-ASCII文字に置き換えられます。
4. if the owner name of the RR is a wildcard name, the owner name is in its original unexpanded form, including the "*" label (no wildcard substitution); and
4. RRの所有者名がワイルドカード名である場合、所有者名は「*」ラベルを含む元の展開されていない形式になります（ワイルドカード置換なし）。 そして
5. the RR's TTL is set to its original value as it appears in the originating authoritative zone or the Original TTL field of the covering RRSIG RR.
5. RRのTTLは、発信元の権限ゾーンまたはカバーするRRSIG RRの元のTTLフィールドに表示される元の値に設定されます。
For the purposes of DNS security, RRs with the same owner name, class, and type are sorted by treating the RDATA portion of the canonical form of each RR as a left-justified unsigned octet sequence in which the absence of an octet sorts before a zero octet.
DNSセキュリティの目的で、同じ所有者名、クラス、およびタイプを持つRRは、各RRの標準形式のRDATA部分を、左揃えの符号なしオクテットシーケンスとして処理することでソートされます。 ゼロオクテット。
[RFC2181] specifies that an RRset is not allowed to contain duplicate records (multiple RRs with the same owner name, class, type, and RDATA). Therefore, if an implementation detects duplicate RRs when putting the RRset in canonical form, it MUST treat this as a protocol error. If the implementation chooses to handle this protocol error in the spirit of the robustness principle (being liberal in what it accepts), it MUST remove all but one of the duplicate RR(s) for the purposes of calculating the canonical form of the RRset.
[RFC2181]は、RRsetに重複レコード（同じ所有者名、クラス、タイプ、およびRDATAを持つ複数のRR）を含めることを許可しないことを指定します。 したがって、RRsetを標準形式にするときに、実装が重複RRを検出した場合、これをプロトコルエラーとして扱わなければなりません。 実装がロバストネス原則の精神でこのプロトコルエラーを処理することを選択した場合（受け入れられるものは寛容である）、RRsetの標準形式を計算する目的で、重複RRの1つを除くすべてを削除する必要があります。
This document introduces no new IANA considerations, as all of the protocol parameters used in this document have already been assigned by previous specifications. However, since the evolution of DNSSEC has been long and somewhat convoluted, this section attempts to describe the current state of the IANA registries and other protocol parameters that are (or once were) related to DNSSEC.
このドキュメントで使用されるすべてのプロトコルパラメータは以前の仕様で既に割り当てられているため、このドキュメントでは新しいIANAの考慮事項を紹介していません。 ただし、DNSSECの進化は長く複雑であるため、このセクションでは、DNSSECに関連する（または以前に関連した）IANAレジストリおよびその他のプロトコルパラメーターの現在の状態を説明しようとします。
Please refer to [RFC4035] for additional IANA considerations.
IANAに関する追加の考慮事項については、[RFC4035]を参照してください。
DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol described in [RFC2931] and to the transaction KEY Resource Record described in [RFC2930].
DNSリソースレコードタイプ：[RFC2535] SIG 24、25、および30をそれぞれSIG、KEY、およびNXT RRに割り当てました。 [RFC3658] DNSリソースレコードタイプ43をDSに割り当てました。 [RFC3755]は、タイプ46、47、および48をそれぞれRRSIG、NSEC、およびDNSKEY RRに割り当てました。 [RFC3755]は、タイプ30（NXT）を、[RFC2931]で説明されている「SIG（0）」トランザクションセキュリティプロトコルおよび説明されているトランザクションKEYリソースレコードに対するタイプ24（SIG）および25（KEY）の廃止および制限された使用としてマークしました [RFC2930]で。
DNS Security Algorithm Numbers: [RFC2535] created an IANA registry for DNSSEC Resource Record Algorithm field numbers and assigned values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] altered this registry to include flags for each entry regarding its use with the DNS security extensions. Each algorithm entry could refer to an algorithm that can be used for zone signing, transaction security (see [RFC2931]), or both. Values 6-251 are available for assignment by IETF standards action ([RFC3755]). See Appendix A for a full listing of the DNS Security Algorithm Numbers entries at the time of this writing and their status for use in DNSSEC.
DNSセキュリティアルゴリズム番号：[RFC2535]は、DNSSECリソースレコードアルゴリズムのフィールド番号のIANAレジストリを作成し、値1〜4および252〜255を割り当てました。 [RFC3110]は値5を割り当てました。[RFC3755]はこのレジストリを変更して、DNSセキュリティ拡張機能での使用に関する各エントリのフラグを含めるようにしました。 各アルゴリズムエントリは、ゾーン署名、トランザクションセキュリティ（[RFC2931]を参照）、またはその両方に使用できるアルゴリズムを参照できます。 値6〜251は、IETF標準アクション（[RFC3755]）による割り当てに使用できます。 この記事の執筆時点でのDNSセキュリティアルゴリズム番号エントリの完全なリストおよびDNSSECで使用するためのステータスについては、付録Aを参照してください。
[RFC3658] created an IANA registry for DNSSEC DS Digest Types and assigned value 0 to reserved and value 1 to SHA-1.
[RFC3658] DNSSEC DS Digest TypesのIANAレジストリを作成し、予約済みに値0を割り当て、SHA-1に値1を割り当てました。
KEY Protocol Values: [RFC2535] created an IANA Registry for KEY Protocol Values, but [RFC3445] reassigned all values other than 3 to reserved and closed this IANA registry. The registry remains closed, and all KEY and DNSKEY records are required to have a Protocol Octet value of 3.
KEYプロトコル値：[RFC2535]はKEYプロトコル値のIANAレジストリを作成しましたが、[RFC3445]は3以外のすべての値を予約し、このIANAレジストリを閉じて閉じました。 レジストリは閉じられたままであり、すべてのKEYおよびDNSKEYレコードには、プロトコルオクテット値3が必要です。
Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, this registry only contains assignments for bit 7 (the ZONE bit) and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]). As stated in [RFC3755], bits 0-6 and 8-14 are available for assignment by IETF Standards Action.
KEYおよびDNSKEY RRのフラグビット：[RFC3755]は、DNSSEC KEYおよびDNSKEY RRフラグビット用のIANAレジストリを作成しました。 最初、このレジストリにはビット7（ZONEビット）とビット15（セキュアエントリポイントフラグ（SEP）ビット。[RFC3757]を参照）の割り当てのみが含まれています。 [RFC3755]で述べられているように、ビット0〜6および8〜14は、IETF標準アクションによる割り当てに使用できます。
This document describes the format of four DNS resource records used by the DNS security extensions and presents an algorithm for calculating a key tag for a public key. Other than the items described below, the resource records themselves introduce no security considerations. Please see [RFC4033] and [RFC4035] for additional security considerations related to the use of these records.
このドキュメントでは、DNSセキュリティ拡張機能で使用される4つのDNSリソースレコードの形式について説明し、公開キーのキータグを計算するアルゴリズムを示します。 以下に説明する項目を除き、リソースレコード自体にはセキュリティ上の考慮事項はありません。 これらのレコードの使用に関連する追加のセキュリティの考慮事項については、[RFC4033]および[RFC4035]を参照してください。
The DS record points to a DNSKEY RR by using a cryptographic digest, the key algorithm type, and a key tag. The DS record is intended to identify an existing DNSKEY RR, but it is theoretically possible for an attacker to generate a DNSKEY that matches all the DS fields. The probability of constructing a matching DNSKEY depends on the type of digest algorithm in use. The only currently defined digest algorithm is SHA-1, and the working group believes that constructing a public key that would match the algorithm, key tag, and SHA-1 digest given in a DS record would be a sufficiently difficult problem that such an attack is not a serious threat at this time.
DSレコードは、暗号ダイジェスト、キーアルゴリズムタイプ、およびキータグを使用してDNSKEY RRをポイントします。 DSレコードは既存のDNSKEY RRを識別することを目的としていますが、理論的には、攻撃者がすべてのDSフィールドに一致するDNSKEYを生成することが可能です。 一致するDNSKEYを構築する確率は、使用中のダイジェストアルゴリズムのタイプによって異なります。 現在定義されている唯一のダイジェストアルゴリズムはSHA-1であり、ワーキンググループは、DSレコードで指定されたアルゴリズム、キータグ、およびSHA-1ダイジェストに一致する公開キーを構築することは、そのような攻撃にとって十分に難しい問題であると考えています 現時点では深刻な脅威ではありません。
The key tag is used to help select DNSKEY resource records efficiently, but it does not uniquely identify a single DNSKEY resource record. It is possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm type, and the same key tag. An implementation that uses only the key tag to select a DNSKEY RR might select the wrong public key in some circumstances. Please see Appendix B for further details.
キータグは、DNSKEYリソースレコードを効率的に選択するために使用されますが、単一のDNSKEYリソースレコードを一意に識別するものではありません。 2つの異なるDNSKEY RRが同じ所有者名、同じアルゴリズムタイプ、同じキータグを持つことは可能です。 キータグのみを使用してDNSKEY RRを選択する実装では、状況によっては間違った公開キーを選択する場合があります。 詳細については、付録Bを参照してください。
The table of algorithms in Appendix A and the key tag calculation algorithms in Appendix B include the RSA/MD5 algorithm for completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as explained in [RFC3110].
付録Aのアルゴリズムの表と付録Bのキータグ計算アルゴリズムには、完全性のためにRSA / MD5アルゴリズムが含まれていますが、[RFC3110]で説明されているように、RSA / MD5アルゴリズムはお勧めできません。
This document was created from the input and ideas of the members of the DNS Extensions Working Group and working group mailing list. The editors would like to express their thanks for the comments and suggestions received during the revision of these security extension specifications. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, [RFC4033] includes a list of some of the participants who were kind enough to comment on these documents.
このドキュメントは、DNS Extensionsワーキンググループおよびワーキンググループメーリングリストのメンバーの意見とアイデアから作成されました。 編集者は、これらのセキュリティ拡張仕様の改訂中に受け取ったコメントと提案に感謝します。 DNSSECが開発中の10年間に貢献したすべての人を明示的にリストすることは不可能ですが、[RFC4033]にはこれらの文書にコメントするのに十分親切な参加者のリストが含まれています。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982] Elz、R。およびR. Bush、「シリアル番号演算」、RFC 1982、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。、およびR. Bush、「DNS仕様の明確化」、RFC 2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308] Andrews、M。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、1998年3月。
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC2536] Eastlake 3rd、D.、「ドメインネームシステム（DNS）のDSAキーとSIG」、RFC 2536、1999年3月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931] Eastlake 3rd、D。、「DNS要求およびトランザクション署名（SIG（0）s）」、RFC 2931、2000年9月。
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110] Eastlake 3rd、D。、「ドメインネームシステム（DNS）のRSA / SHA-1 SIGとRSA KEY」、RFC 3110、2001年5月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445] Massey、D。、およびS. Rose、「KEYリソースレコード（RR）の範囲の制限」、RFC 3445、2002年12月。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[RFC3548] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 3548、2003年7月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、A。、「不明なDNSリソースレコード（RR）タイプの処理」、RFC 3597、2003年9月。
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[RFC3658] Gudmundsson、O。、「委任署名者（DS）リソースレコード（RR）」、RFC 3658、2003年12月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755] Weiler、S。、「委任署名者（DS）のレガシーリゾルバ互換性」、RFC 3755、2004年5月。
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.
[RFC3757] Kolkman、O.、Schlyter、J。、およびE. Lewis、「ドメインネームシステムキー（DNSKEY）リソースレコード（RR）セキュアエントリポイント（SEP）フラグ」、RFC 3757、2004年4月
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル修正」、RFC 4035、2005年3月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake 3rd、D。、「ドメインネームシステムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999.
[RFC2537] Eastlake 3rd、D.、「ドメインネームシステム（DNS）のRSA / MD5 KEYとSIG」、RFC 2537、1999年3月。
[RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999.
[RFC2539] Eastlake 3rd、D。、「ドメインネームシステム（DNS）でのDiffie-Hellmanキーのストレージ」、RFC 2539、1999年3月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930] Eastlake 3rd、D。、「DNSの秘密鍵確立（TKEY RR）」、RFC 2930、2000年9月。
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004.
[RFC3845] Schlyter、J。、「DNSセキュリティ（DNSSEC）NextSECure（NSEC）RDATAフォーマット」、RFC 3845、2004年8月。
Appendix A. DNSSEC Algorithm and Digest Types
付録A. DNSSECアルゴリズムとダイジェストタイプ
The DNS security extensions are designed to be independent of the underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS resource records all use a DNSSEC Algorithm Number to identify the cryptographic algorithm in use by the resource record. The DS resource record also specifies a Digest Algorithm Number to identify the digest algorithm used to construct the DS record. The currently defined Algorithm and Digest Types are listed below. Additional Algorithm or Digest Types could be added as advances in cryptography warrant them.
DNSセキュリティ拡張機能は、基礎となる暗号化アルゴリズムに依存しないように設計されています。 DNSKEY、RRSIG、およびDSリソースレコードはすべて、DNSSECアルゴリズム番号を使用して、リソースレコードで使用されている暗号化アルゴリズムを識別します。 DSリソースレコードは、ダイジェストアルゴリズム番号も指定して、DSレコードの構築に使用されるダイジェストアルゴリズムを識別します。 現在定義されているアルゴリズムとダイジェストタイプを以下にリストします。 暗号化の進歩が保証する場合、追加のアルゴリズムまたはダイジェストタイプを追加できます。
A DNSSEC aware resolver or name server MUST implement all MANDATORY algorithms.
DNSSEC対応のリゾルバまたはネームサーバーは、すべての必須アルゴリズムを実装する必要があります。
A.1. DNSSEC Algorithm Types
A.1。 DNSSECアルゴリズムタイプ
The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the security algorithm being used. These values are stored in the "Algorithm number" field in the resource record RDATA.
DNSKEY、RRSIG、およびDS RRは、8ビット数を使用して、使用されているセキュリティアルゴリズムを識別します。 これらの値は、リソースレコードRDATAの「アルゴリズム番号」フィールドに保存されます。
Some algorithms are usable only for zone signing (DNSSEC), some only for transaction security mechanisms (SIG(0) and TSIG), and some for both. Those usable for zone signing may appear in DNSKEY, RRSIG, and DS RRs. Those usable for transaction security would be present in SIG(0) and KEY RRs, as described in [RFC2931].
一部のアルゴリズムはゾーン署名（DNSSEC）でのみ使用でき、一部はトランザクションセキュリティメカニズム（SIG（0）およびTSIG）でのみ使用でき、一部は両方で使用できます。 ゾーン署名に使用可能なものは、DNSKEY、RRSIG、およびDS RRに表示される場合があります。 [RFC2931]で説明されているように、トランザクションセキュリティに使用可能なものはSIG（0）およびKEY RRに存在します。
Zone
Value Algorithm [Mnemonic] Signing References Status
----- -------------------- --------- ---------- ---------
0 reserved
1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
2 Diffie-Hellman [DH] n [RFC2539] -
3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
4 Elliptic Curve [ECC] TBA -
5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
252 Indirect [INDIRECT] n -
253 Private [PRIVATEDNS] y see below OPTIONAL
254 Private [PRIVATEOID] y see below OPTIONAL
255 reserved
6 - 251 Available for assignment by IETF Standards Action.
6-251 IETF標準アクションによる割り当てに使用可能。
A.1.1. Private Algorithm Types
A.1.1。 プライベートアルゴリズムタイプ
Algorithm number 253 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with a wire encoded domain name, which MUST NOT be compressed. The domain name indicates the private algorithm to use, and the remainder of the public key area is determined by that algorithm. Entities should only use domain names they control to designate their private algorithms.
アルゴリズム番号253は個人使用のために予約されており、特定のアルゴリズムに割り当てられることはありません。 DNSKEY RRの公開鍵領域とRRSIG RRの署名領域は、ワイヤエンコードされたドメイン名で始まります。これは圧縮してはいけません。 ドメイン名は使用するプライベートアルゴリズムを示し、公開キー領域の残りはそのアルゴリズムによって決定されます。 エンティティは、制御するドメイン名のみを使用して、プライベートアルゴリズムを指定する必要があります。
Algorithm number 254 is reserved for private use and will never be assigned to a specific algorithm. The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with an unsigned length byte followed by a BER encoded Object Identifier (ISO OID) of that length. The OID indicates the private algorithm in use, and the remainder of the area is whatever is required by that algorithm. Entities should only use OIDs they control to designate their private algorithms.
アルゴリズム番号254は個人使用のために予約されており、特定のアルゴリズムに割り当てられることはありません。 DNSKEY RRの公開鍵領域とRRSIG RRの署名領域は、符号なしの長さのバイトで始まり、その長さのBERエンコードされたオブジェクト識別子（ISO OID）が続きます。 OIDは使用中のプライベートアルゴリズムを示し、残りの領域はそのアルゴリズムに必要なものです。 エンティティは、制御するOIDのみを使用して、プライベートアルゴリズムを指定する必要があります。
A.2. DNSSEC Digest Types
A.2。 DNSSECダイジェストタイプ
A "Digest Type" field in the DS resource record types identifies the cryptographic digest algorithm used by the resource record. The following table lists the currently defined digest algorithm types.
DSリソースレコードタイプの「ダイジェストタイプ」フィールドは、リソースレコードで使用される暗号ダイジェストアルゴリズムを識別します。 次の表に、現在定義されているダイジェストアルゴリズムの種類を示します。
VALUE Algorithm STATUS
0 Reserved -
1 SHA-1 MANDATORY
2-255 Unassigned -
Appendix B. Key Tag Calculation
付録B.キータグの計算
The Key Tag field in the RRSIG and DS resource record types provides a mechanism for selecting a public key efficiently. In most cases, a combination of owner name, algorithm, and key tag can efficiently identify a DNSKEY record. Both the RRSIG and DS resource records have corresponding DNSKEY records. The Key Tag field in the RRSIG and DS records can be used to help select the corresponding DNSKEY RR efficiently when more than one candidate DNSKEY RR is available.
RRSIGおよびDSリソースレコードタイプのキータグフィールドは、公開キーを効率的に選択するためのメカニズムを提供します。 ほとんどの場合、所有者名、アルゴリズム、およびキータグの組み合わせにより、DNSKEYレコードを効率的に識別できます。 RRSIGとDSの両方のリソースレコードには、対応するDNSKEYレコードがあります。 複数の候補DNSKEY RRが利用可能な場合、RRSIGおよびDSレコードのキータグフィールドを使用して、対応するDNSKEY RRを効率的に選択できます。
However, it is essential to note that the key tag is not a unique identifier. It is theoretically possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm, and the same key tag. The key tag is used to limit the possible candidate keys, but it does not uniquely identify a DNSKEY record. Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR.
ただし、キータグは一意の識別子ではないことに注意してください。 理論的には、2つの異なるDNSKEY RRが同じ所有者名、同じアルゴリズム、同じキータグを持つことは可能です。 キータグは、可能な候補キーを制限するために使用されますが、DNSKEYレコードを一意に識別するものではありません。 実装は、キータグがDNSKEY RRを一意に識別すると想定してはなりません。
The key tag is the same for all DNSKEY algorithm types except algorithm 1 (please see Appendix B.1 for the definition of the key tag for algorithm 1). The key tag algorithm is the sum of the wire format of the DNSKEY RDATA broken into 2 octet groups. First, the RDATA (in wire format) is treated as a series of 2 octet groups. These groups are then added together, ignoring any carry bits.
キータグは、アルゴリズム1を除くすべてのDNSKEYアルゴリズムタイプで同じです（アルゴリズム1のキータグの定義については、付録B.1を参照してください）。 キータグアルゴリズムは、DNSKEY RDATAのワイヤー形式を2オクテットグループに分割した合計です。 最初に、RDATA（ワイヤー形式）は一連の2オクテットグループとして扱われます。 これらのグループは、キャリービットを無視して加算されます。
A reference implementation of the key tag algorithm is as an ANSI C function is given below, with the RDATA portion of the DNSKEY RR is used as input. It is not necessary to use the following reference code verbatim, but the numerical value of the Key Tag MUST be identical to what the reference implementation would generate for the same input.
キータグアルゴリズムのリファレンス実装は、ANSI C関数を以下に示すとおりです。DNSKEYRRのRDATA部分が入力として使用されます。 次の参照コードを逐語的に使用する必要はありませんが、キータグの数値は、参照実装が同じ入力に対して生成するものと同一でなければなりません。
Please note that the algorithm for calculating the Key Tag is almost but not completely identical to the familiar ones-complement checksum used in many other Internet protocols. Key Tags MUST be calculated using the algorithm described here rather than the ones complement checksum.
キータグを計算するアルゴリズムは、他の多くのインターネットプロトコルで使用されている使い慣れた1の補数チェックサムとほぼ同一であることに注意してください。 キータグは、チェックサムを補完するものではなく、ここで説明するアルゴリズムを使用して計算する必要があります。
The following ANSI C reference implementation calculates the value of a Key Tag. This reference implementation applies to all algorithm types except algorithm 1 (see Appendix B.1). The input is the wire format of the RDATA portion of the DNSKEY RR. The code is written for clarity, not efficiency.
次のANSI Cリファレンス実装は、キータグの値を計算します。 このリファレンス実装は、アルゴリズム1を除くすべてのアルゴリズムタイプに適用されます（付録B.1を参照）。 入力は、DNSKEY RRのRDATA部分のワイヤ形式です。 コードは、効率ではなく明確にするために書かれています。
/*
* Assumes that int is at least 16 bits.
* First octet of the key tag is the most significant 8 bits of the
* return value;
* Second octet of the key tag is the least significant 8 bits of the
* return value.
*/
unsigned int
keytag (
unsigned char key[], /* the RDATA part of the DNSKEY RR */
unsigned int keysize /* the RDLENGTH */
)
{
unsigned long ac; /* assumed to be 32 bits or larger */
int i; /* loop index */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i & 1) ? key[i] : key[i] << 8;
ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}
B.1. Key Tag for Algorithm 1 (RSA/MD5)
B.1。 アルゴリズム1のキータグ（RSA / MD5）
The key tag for algorithm 1 (RSA/MD5) is defined differently from the key tag for all other algorithms, for historical reasons. For a DNSKEY RR with algorithm 1, the key tag is defined to be the most significant 16 bits of the least significant 24 bits in the public key modulus (in other words, the 4th to last and 3rd to last octets of the public key modulus).
アルゴリズム1（RSA / MD5）のキータグは、歴史的な理由により、他のすべてのアルゴリズムのキータグとは異なって定義されます。 アルゴリズム1のDNSKEY RRの場合、キータグは、公開鍵モジュラスの最下位24ビットの最上位16ビット（つまり、公開鍵モジュラスの最後から4番目、最後から3番目のオクテット）に定義されます。 ）。
Please note that Algorithm 1 is NOT RECOMMENDED.
アルゴリズム1は推奨されないことに注意してください。
Authors' Addresses
著者のアドレス
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
EMail: roy.arends@telin.nl
メール：roy.arends@telin.nl
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City、CA 94063 USA
EMail: sra@isc.org
メール：sra@isc.org
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Matt Larson VeriSign、Inc. 21345 Ridgetop Circle Dulles、VA 20166-6503アメリカ合衆国
EMail: mlarson@verisign.com
メール：mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
ダンマッセイコロラド州立大学コンピュータサイエンス学部フォートコリンズ、コロラド州80523-1873
EMail: massey@cs.colostate.edu
メール：massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
スコットローズ国立標準技術研究所100 Bureau Drive Gaithersburg、MD 20899-8920 USA
EMail: scott.rose@nist.gov
メール：scott.rose@nist.gov
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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/SHE 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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、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開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンライン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は、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。