[要約] RFC 4034は、DNSセキュリティ拡張（DNSSEC）のためのリソースレコードを定義しています。この文書の目的は、DNS応答の真正性と完全性を保証するために必要な新しいレコードタイプ（RRSIG、DNSKEY、NSEC、およびDSレコード）を導入することです。これらのレコードは、DNS情報の信頼性を高め、キャッシュポイズニングやその他の攻撃から保護するために利用されます。RFC 4034は、DNSSECの実装と展開において中心的な役割を果たし、RFC 4033（DNSSECの導入）、RFC 4035（DNSSECのプロトコルの詳細）、およびRFC 3833（DNS脅威分析）と密接に関連しています。
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
DNSセキュリティ拡張機能のリソースレコード
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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）は、4つの新しいDNSリソースレコードタイプの導入（DNS公開キー（DNSKEY）、リソースレコード署名（RRSIG）、次のセキュア（NSEC）、および委任署名者（DS）を導入します。このドキュメントは、各リソースレコード（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]、およびそれらを更新する後続のドキュメント、特に[RFC2181]および[RFC2308]に記載されている基本的なDNS概念に精通していると想定されています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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認証プロセスで使用されています。リゾルバーは、公開キーを使用して、ゾーン内のrrsetsをカバーする署名を検証し、それらを認証することができます。
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
フラグフィールドのビット7は、ゾーンキーフラグです。ビット7に値1の場合、DNSKEYレコードにはDNSゾーンキーがあり、DNSKEY RRの所有者名はゾーンの名前でなければなりません。ビット7に値0がある場合、DNSKEYレコードは他のタイプのDNS公開キーを保持し、RRSetsをカバーする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.
フラグフィールドのビット15は、[RFC3757]で説明されている安全なエントリポイントフラグです。ビット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がありますが、キーレコードの初期バージョンとの後方互換性のために保持されます。
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.
フラグフィールドは、署名のない小数整数として表す必要があります。現在定義されているフラグを考えると、考えられる値は0、256、および257です。
The Protocol Field MUST be represented as an unsigned decimal integer with a value of 3.
プロトコルフィールドは、値が3の符号なし小数整数として表す必要があります。
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で指定されているように、署名されていない小数整数またはアルゴリズムのニーモニックとして表す必要があります。
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エンコードとして表す必要があります。WhitespaceはBase64テキスト内で許可されています。Base64エンコーディングの定義については、[RFC3548]を参照してください。
The following DNSKEY RR stores a DNS zone key for example.com.
次のDNSKEY RRは、例えばDNSゾーンキーを保存します。
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U aNvv4w== )
Example.com。
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 RRSを使用して、ゾーンから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 RRSが存在する必要があります。これは、従来のDNS仕様[RFC1034]の変更です。これは、名前にCNAMEが存在する場合、その名前で許可されている唯一のタイプであると述べています。RRSIGとNSEC（セクション4を参照）は、署名ゾーンのCNAMEリソースレコードと同じ名前で存在する必要があります。
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 RRSは、カバーする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オクテットタイプの覆われたフィールド、1オクテットアルゴリズムフィールド、1オクテットラベルフィールド、4オクテットのオリジナルTTLフィールド、4オクテットシグネチャーの有効期限フィールド、4オクテットのシグネチャーインセプションフィールド、2で構成されています。Octetキータグ、署名者の名前フィールド、および署名フィールド。
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type Covered field identifies the type of the RRset that is covered by this RRSIG record.
タイプカバーされたフィールドは、この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.
ラベルフィールドは、元の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.
署名を検証するには、Validatorは署名を作成するために使用された元の所有者名を必要とします。元の所有者名にワイルドカードラベル（ "*"）が含まれている場合、所有者名は応答プロセス中にサーバーによって拡張された可能性があります。[RFC4035]は、ラベルフィールドを使用して元の所有者名を再構築する方法について説明します。
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.
ラベルフィールドの値は、所有者名を終了するnull（root）ラベルまたはワイルドカードラベル（存在する場合）のいずれかをカウントしてはなりません。ラベルフィールドの値は、RRSIGの所有者名のラベルの数以下でなければなりません。たとえば、「www.example.com」。ラベルフィールド値は3と「*.example.com」です。ラベルフィールド値は2です。root（ "。"）のラベルフィールド値は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.
WildCardラベルは、RRSIG RRのラベルフィールドに保存されているカウントには含まれていませんが、WildCardラベルは、署名が生成または検証されたときに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.
キャッシュリゾルバーがキャッシュされたRRSetのTTL値を減少させるため、元の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.
署名の有効期限と開始フィールドは、署名の有効期間を指定します。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.
署名の有効期限とインセプションフィールド値は、1970年1月1日以降に経過した32ビットの署名のない秒数の形式で日付と時刻を指定します。この形式でラッピングなしで表現できる最長の間隔は、約136年です。RRSIG RRは、有効期限フィールド値が32ビットラップアラウンドポイントの近くにある場合、または署名が長生きしている場合、インセプションフィールド値よりも数値的に小さい有効期限フィールド値を持つことができます。このため、[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.
署名フィールドには、RRSIG RDATA（署名フィールドを除く）とRRSIGの所有者名、RRSIGクラス、およびRRSIGタイプのカバーフィールドで指定された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を参照）、SET RR（1）、... RR（n）は次のように署名されています。
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
"|" 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は、signerの名前フィールドを標準形式のsignerの名前と署名フィールドを除く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);
「所有者」は、標準形式の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のタイプカバーフィールドにRRタイプがリストされている必要があります。
Each RR in the RRset MUST have the TTL listed in the RRSIG Original TTL Field;
RRSTの各RRは、RRSIGオリジナル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.
標準形式の詳細とRRSetsの順序付けについては、セクション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.
タイプカバーされたフィールドは、RRタイプのニーモニックとして表されます。ニーモニックがわからない場合、[RFC3597]に記載されているタイプ表現、セクション5を使用する必要があります。
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で指定されているように、署名されていない小数整数またはアルゴリズムとして表現する必要があります。
The Labels field value MUST be represented as an unsigned decimal integer.
ラベルのフィールド値は、署名のない小数整数として表す必要があります。
The Original TTL field value MUST be represented as an unsigned decimal integer.
元のTTLフィールド値は、署名されていない小数整数として表す必要があります。
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日以降の秒を示す符号なしの小数整数として表す必要があります。
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.
yyyymmdhhmmss形式は常に正確に14桁であるため、これら2つの形式を常に区別することができることに注意してください。
The Key Tag field MUST be represented as an unsigned decimal integer.
キータグフィールドは、署名のない小数整数として表す必要があります。
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エンコードとして表されます。WhitespaceはBase64テキスト内で許可されています。セクション2.2を参照してください。
The following RRSIG RR stores the signature for the A RRset of host.example.com:
次のRRSIG RRは、host.example.comの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。
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」は、覆われた型フィールドを表します。値5は、使用されたアルゴリズム（RSA/SHA1）を識別して署名を作成します。値3は、元の所有者名のラベルの数です。rrsig rdataの値86400は、カバーされた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であるExamp.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 RRSの完全なセットは、ゾーンにどの権威ある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 RRSが存在する必要があります。これは、従来のDNS仕様[RFC1034]の変更です。これは、名前にCNAMEが存在する場合、その名前で許可されている唯一のタイプであると述べています。RRSIG（セクション3を参照）とNSECは、署名ゾーンのCNAMEリソースレコードと同じ名前で存在する必要があります。
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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レコードの次のドメイン名フィールドの値は、ゾーン頂点（ゾーンの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.
与えられたゾーンが信頼できるものではないRRSetsの所有者名（接着剤レコードなど）は、同じ所有者名に少なくとも1つの権威あるRRSetが存在しない限り、次のドメイン名にリストしてはなりません。
The Type Bit Maps field identifies the RRset types that exist at the NSEC RR's owner name.
タイプビットマップフィールドは、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）を使用してエンコードされ、ウィンドウブロックのビットマップに使用されるオクテットの数を示し、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.
各ビットマップは、ネットワークビットの順序で、ウィンドウブロック内の低次の8ビットのRRタイプをエンコードします。最初のビットはビット0です。ウィンドウブロック0の場合、ビット1はRRタイプ1（a）に対応し、ビット2はRRタイプ2（NS）などに対応します。ウィンドウブロック1の場合、ビット1はRRタイプ257に、ビット2からRRタイプ258に対応します。ビットが設定されている場合、そのタイプのRRセットがNSEC RRの所有者名に存在することを示します。少し明確な場合、NSEC RRの所有者名にそのタイプのRRSetが存在しないことを示しています。
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.
タイプビットマップフィールドは、RRタイプのニーモニックのシーケンスとして表されます。ニーモニックが知られていない場合、[RFC3597]で説明されているタイプ表現、セクション5を使用する必要があります。
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に関連付けられた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 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 Mnemonicsは、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 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が存在しないことを証明するために使用できます。認証された存在の拒否は[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レコードを認証することにより、リゾルバーはDSKEY 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」ゾーン（親ゾーン）にではなく保存されます。
"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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Key Tag field lists the key tag of the DNSKEY RR referred to by the DS record, in network byte order.
キータグフィールドには、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 RRSで使用されるキータグと同じです。付録Bでは、キータグを計算する方法について説明します。
The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DS record.
アルゴリズムフィールドには、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 RRSで使用されるアルゴリズム番号と同一です。付録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を指します。ダイジェスト型フィールドは、ダイジェストの構築に使用されるアルゴリズムを識別します。付録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);
"|" denotes concatenation
"|"連結を示します
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
dnskey rdata = flags |プロトコル|アルゴリズム|公開鍵。
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 IT参照）は、検証プロセスで使用してはなりません。
The presentation format of the RDATA portion is as follows:
RDATA部分のプレゼンテーション形式は次のとおりです。
The Key Tag field MUST be represented as an unsigned decimal integer.
キータグフィールドは、署名のない小数整数として表す必要があります。
The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic specified in Appendix A.1.
アルゴリズムフィールドは、署名されていない小数整数として、または付録A. 1で指定されたアルゴリズムのニーモニックとして表す必要があります。
The Digest Type field MUST be represented as an unsigned decimal integer.
ダイジェスト型フィールドは、符号なし小数整数として表す必要があります。
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。キー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）を指定します。Value 60485は、対応する「dskey.example.com」の重要なタグです。DNSKEY RR、およびValue 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 RRSを構築および検証するには、標準的なRRフォームとRRSet内での順序付けが必要です。
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名の順序でソートされます。最も重要なラベルは「例」です。このレベルでは、「例」が最初に並べ替え、次に「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
例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セキュリティの目的のために、同じ所有者名、クラス、およびタイプのRRSは、各RRの標準形式のRDATA部分を、オクテットの存在下で存在する前に並べ替えられている左justifified未署名のオクテットシーケンスとして扱うことによってソートされます。ゼロオクテット。
[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を正規形式にするときに実装が重複したRRSを検出する場合、これをプロトコルエラーとして扱う必要があります。実装がこのプロトコルエラーを堅牢性の精神で処理することを選択した場合（それが受け入れるものにおいてリベラルである）、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、キー、およびNXT RRSにタイプ24、25、および30を割り当てました。[RFC3658] DNSリソースレコードタイプ43をDSに割り当てました。[RFC3755]タイプ46、47、および48をそれぞれRRSIG、NSEC、およびDNSKEY RRSに割り当てました。[RFC3755]は、[RFC2931]で説明されている「SIG（0）」トランザクションセキュリティプロトコルのタイプ24（SIG）および25（Key）の廃止および制限された使用として、タイプ30（NXT）を[RFC2931]および説明するトランザクションキーリソースレコードとしてマークしました。[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ダイジェストタイプのIANAレジストリを作成し、値0を予約済みに、値1にSHA-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.
主要なプロトコル値：[RFC2535]は、主要なプロトコル値のIANAレジストリを作成しましたが、[RFC3445]は3以外のすべての値を再割り当てして、このIANAレジストリを予約および閉鎖しました。レジストリは閉じられたままであり、すべてのキーレコードと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.
キーおよびDNSKEY RRSのフラグビット：[RFC3755]は、DNSSECキーとDNSKEY RRフラグビットのIANAレジストリを作成しました。当初、このレジストリには、ビット7（ゾーンビット）とビット15（セキュアエントリポイントフラグ（SEP）ビット、[RFC3757]を参照）の割り当てのみが含まれています。[RFC3755]に記載されているように、IETF標準アクションにより、0〜6および8-14のビットが割り当てられます。
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 RRSが同じ所有者名、同じアルゴリズムタイプ、および同じキータグを持つことができます。キータグのみを使用して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エクステンションワーキンググループおよびワーキンググループメーリングリストのメンバーの入力とアイデアから作成されました。編集者は、これらのセキュリティ拡張仕様の改訂中に受け取ったコメントと提案に感謝します。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。、「DSAキーとドメイン名システム（DNS）の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。、「RSA/SHA-1 SIGSおよびRSAキー内のドメイン名システム（DNS）」、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、「主要なリソースレコード（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。、「Legacy Resolver compatibility for Dedigation Signer（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。、「RSA/MD5キーとドメイン名システム（DNS）のキーと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 Keysのストレージ」、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 Security（DNSSEC）NextSecure（NSEC）RDATA形式」、RFC 3845、2004年8月。
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 Aware ResolverまたはName Serverは、すべての必須アルゴリズムを実装する必要があります。
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 RRSは、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 RRSに表示される場合があります。[RFC2931]で説明されているように、トランザクションセキュリティに使用可能なものはSIG（0）およびキーRRSに存在します。
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標準アクションにより割り当て可能。
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）が続き、その長さのBERエンコードされたオブジェクト識別子（ISO OID）から始まります。OIDは、使用中のプライベートアルゴリズムを示し、そのエリアの残りはそのアルゴリズムで必要とされるものは何でもあります。エンティティは、制御するOIDのみを使用してプライベートアルゴリズムを指定する必要があります。
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 -
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レコードがあります。RRSIGおよびDSレコードのキータグフィールドを使用して、複数の候補DNSKEY RRが利用可能な場合に対応する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 RRSが同じ所有者名、同じアルゴリズム、および同じキータグを持つことが可能です。キータグは、可能な候補キーを制限するために使用されますが、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つのOctetグループに分割されています。まず、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.
キータグを計算するためのアルゴリズムは、他の多くのインターネットプロトコルで使用されているおなじみの補完チェックサムとほぼ同一ではありませんが、ほぼ同一ではありません。キータグは、チェックサムを補完するものではなく、ここで説明するアルゴリズムを使用して計算する必要があります。
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;
}
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番目から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
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブオーストインインターネットシステムコンソーシアム950チャーターストリートレッドウッドシティ、カリフォルニア94063 USA
EMail: 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 USA
EMail: mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
ダンマッシーコロラド州立大学コンピュータサイエンス学部フォートコリンズ、コロラド州80523-1873
EMail: massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
スコットローズ国立標準技術研究所100ビューロードライブゲーサーズバーグ、メリーランド20899-8920 USA
EMail: scott.rose@nist.gov
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。