RFC4034 日本語訳
4034 Resource Records for the DNS Security Extensions. R. Arends, R.Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT=63879 bytes) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3007, RFC3597, RFC3226) (Updated by RFC4470) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Arendsがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4034Telematica Instituutは以下を時代遅れにします。 2535、3008、3090、3445、3655、3658、Austein3755、3757、3845ISCがアップデートするR.: 1034 1035 2136 2181 2308 3225 M.ラーソン3007、3597、3226ベリサインCategory: 標準化過程D.マッシーコロラド州立大学S.は2005年のNIST行進のときに上昇しました。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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 Security Extensions(DNSSEC)について説明するドキュメントの家族の一部です。 DNS Security ExtensionsはDNSのために認証をソースに提供するリソース記録とプロトコル変更の収集です。 このドキュメントは存在(NSEC)リソース記録の公開鍵(DNSKEY)、代表団署名者(DS)、リソース記録デジタル署名(RRSIG)、および認証された否定を定義します。 それぞれのリソース記録の目的と形式は詳細に説明されます、そして、それぞれのリソース記録に関する例は出されます。
This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.
このドキュメントは、RFC2535を時代遅れにして、すべてのアップデートからRFC2535までの変化を取り入れます。
Arends, et al. Standards Track [Page 1] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 バックグラウンドと関連ドキュメント. . . . . . . . . . . 3 1.2。 リザーブドワード. . . . . . . . . . . . . . . . . . . . 3 2。 DNSKEYリソース記録. . . . . . . . . . . . . . . . . 4 2.1。 DNSKEY RDATAは形式. . . . . . . . . . . . . . . 4 2.1.1を配線します。 旗の分野。 . . . . . . . . . . . . . . . 4 2.1.2. プロトコル分野. . . . . . . . . . . . . . 5 2.1.3。 アルゴリズム分野。 . . . . . . . . . . . . . 5 2.1.4. 公開鍵分野. . . . . . . . . . . . . 5 2.1.5。 DNSKEY RDATAに関する注は.52.2を設計します。 DNSKEY RRプレゼンテーション形式。 . . . . . . . . . . 5 2.3. DNSKEY RRの例. . . . . . . . . . . . . . . . . . 6 3。 RRSIGリソース記録. . . . . . . . . . . . . . . . . 6 3.1。 RRSIG RDATAは形式を配線します。 . . . . . . . . . . . . . . . 7 3.1.1. タイプは分野. . . . . . . . . . . . 7 3.1.2をカバーしました。 アルゴリズムナンバーフィールド. . . . . . . . . . 8 3.1.3。 ラベル分野. . . . . . . . . . . . . . . 8 3.1.4。 元のTTL分野. . . . . . . . . . . . . . 8 3.1.5。 署名満了と始まり分野。 . . 9 3.1.6. キー・タグ分野。 . . . . . . . . . . . . . . 9 3.1.7. 署名者の名前欄。 . . . . . . . . . . . 9 3.1.8. 署名分野。 . . . . . . . . . . . . . 9 3.2. RRSIG RRプレゼンテーション形式. . . . . . . . . . . 10 3.3。 RRSIG RRの例. . . . . . . . . . . . . . . . . . . 11 4。 nsecリソース記録. . . . . . . . . . . . . . . . . . 12 4.1。 nsec RDATAは形式. . . . . . . . . . . . . . . . 13 4.1.1を配線します。 次のドメイン名分野. . . . . . . . . . 13 4.1.2。 タイプビットマップ分野。 . . . . . . . . . . . 13 4.1.3. ワイルドカードの包含はnsecでRDATAを命名します。 . . 14 4.2. nsec RRプレゼンテーション形式。 . . . . . . . . . . . 14 4.3. nsec RRの例。 . . . . . . . . . . . . . . . . . . . 15 5. DSリソース記録. . . . . . . . . . . . . . . . . . . 15 5.1。 DS RDATAは形式. . . . . . . . . . . . . . . . . 16 5.1.1を配線します。 キー・タグ分野。 . . . . . . . . . . . . . . 16 5.1.2. アルゴリズム分野。 . . . . . . . . . . . . . 16 5.1.3. ダイジェストタイプ分野。 . . . . . . . . . . . . 17 5.1.4. ダイジェスト分野. . . . . . . . . . . . . . . 17 5.2。 応答. . . . 17 5.3を有効にするときのDS RRsの処理。 DS RRプレゼンテーション形式。 . . . . . . . . . . . . 17 5.4. DS RRの例。 . . . . . . . . . . . . . . . . . . . . 18 6. リソース記録. . . . . . . . 18 6.1の標準形と注文。 正準なDNSはオーダー. . . . . . . . . . . . . . . 18 6.2を命名します。 正準なRRは形成します。 . . . . . . . . . . . . . . . . . . 19 6.3. RRsetの中で注文する正準なRR。 . . . . . . . . 20 7. IANA問題。 . . . . . . . . . . . . . . . . . . . . 20 8. セキュリティ問題。 . . . . . . . . . . . . . . . . . . 21
Arends, et al. Standards Track [Page 2] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[2ページ]。
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
9. 承認. . . . . . . . . . . . . . . . . . . . . . 22 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1。 引用規格. . . . . . . . . . . . . . . . . 22 10.2。 有益な参照. . . . . . . . . . . . . . . . 23A.DNSSECアルゴリズムとダイジェストタイプ。 . . . . . . . . . . . . . 24 A.1。 DNSSECアルゴリズムは.24A.1.1をタイプします。 個人的なアルゴリズムタイプ。 . . . . . . . . . . . 25 A.2。 DNSSECはタイプを読みこなします。 . . . . . . . . . . . . . . . . . 25 B.キー・タグ計算。 . . . . . . . . . . . . . . . . . . . . 25 B.1。 アルゴリズム1(RSA/MD5)のためのキー・タグ。 . . . . . . . . . . 27人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 28の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 29
1. Introduction
1. 序論
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 Security Extensions(DNSSEC)は4つの新しいDNSリソースレコード種類を紹介します: DNS公開鍵(DNSKEY)、次にリソース記録署名(RRSIG)は(nsec)、および代表団署名者(DS)を安全にします。 このドキュメントはそれぞれのリソース記録(RR)、RRのRDATA形式、およびそのプレゼンテーション形式(ASCII表現)の目的を定義します。
1.1. Background and Related Documents
1.1. バックグラウンドと関連ドキュメント
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進整数です。
1.2. Reserved Words
1.2. リザーブドワード
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Arends, et al. Standards Track [Page 3] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[3ページ]。
2. The DNSKEY Resource Record
2. DNSKEYリソース記録
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リソースレコードセット(RRsets)にサインして、認証するのに公開鍵暗号を使用します。 公開鍵は、DNSKEYリソース記録に格納されて、[RFC4035]で説明されたDNSSEC認証過程に使用されます: ゾーンは、秘密鍵を使用することによって正式のRRsetsにサインして、DNSKEY RRに対応する公開鍵を格納します。 そして、レゾルバは、ゾーンで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タイプのためのType値は48です。
The DNSKEY RR is class independent.
DNSKEY RRはクラスの独立者です。
The DNSKEY RR has no special TTL requirements.
DNSKEY RRには、どんな特別なTTL要件もありません。
2.1. DNSKEY RDATA Wire Format
2.1. DNSKEY RDATAワイヤ形式
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八重奏Flags Field、1つの八重奏のプロトコルField、1つの八重奏のAlgorithm Field、およびPublic Key Fieldから成ります。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| プロトコル| アルゴリズム| 公開鍵
2.1.1. The Flags Field
2.1.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はZone Key旗です。 ビット7に値1があるなら、DNSKEY記録はDNSゾーンかぎを握ります、そして、DNSKEY RRの所有者名はゾーンの名前であるに違いありません。 ビット7に値0があるなら、DNSKEY記録は、ある他のタイプのDNS公開鍵を保持して、RRsetsを覆うRRSIGsについて確かめるのに使用されてはいけません。
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
Flags分野のビット15は[RFC3757]で説明されたSecure Entry Point旗です。 ビット15に値1があるなら、DNSKEY記録は、キーが使用のために安全なエントリー・ポイントとして意図するままにします。 この旗がそうである、唯一
Arends, et al. Standards Track [Page 4] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[4ページ]。
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.
ゾーン調印へのヒントであることを意図するか、またはこのDNSKEYの意図している使用に関してソフトウェアをデバッグして、記録してください。 validatorsは何らかの方法でこのビットの設定に基づく署名合法化の過程の間、彼らの振舞いを変更してはいけません。 また、これは、また、9月ビットがセットしたことでのDNSKEY RRが、署名を法的に発生させることができるようにZone Key旗を設定する必要を意味します。 RRsetsを覆うRRSIGsについて確かめるのに9月のセットとZone Key旗がセットしていないDNSKEY RRを使用してはいけません。
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を持たなければならなくて、領収書で無視しなければなりません。
2.1.2. The Protocol Field
2.1.2. プロトコル分野
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.
Fieldが3以外の何らかの値であることがわかっているなら署名照合の間、病人として扱われた状態で3、およびDNSKEY RR MUSTを評価させなければならないプロトコル。
2.1.3. The Algorithm Field
2.1.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
Algorithm分野は、公開鍵の暗号アルゴリズムを特定して、Public Key分野の形式を決定します。 Appendix A.1でDNSSECアルゴリズムタイプのリストを見つけることができます。
2.1.4. The Public Key Field
2.1.4. 公開鍵分野
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.
Public Key Fieldは公開鍵の材料を保ちます。 形式は、収納されるキーのアルゴリズムによって、別々のドキュメントで説明されます。
2.1.5. Notes on DNSKEY RDATA Design
2.1.5. DNSKEY RDATAデザインに関する注
Although the Protocol Field always has value 3, it is retained for backward compatibility with early versions of the KEY record.
プロトコルFieldには、値3がいつもありますが、それはKEY記録の早めのバージョンとの後方の互換性のために保有されます。
2.2. The DNSKEY RR Presentation Format
2.2. DNSKEY RRプレゼンテーション形式
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.
無記名の10進整数としてFlag分野を表さなければなりません。 現在定義された旗を考えて、可能な値は以下の通りです。 0、256、および257。
The Protocol Field MUST be represented as an unsigned decimal integer with a value of 3.
3の値に従った無記名の10進整数としてプロトコルFieldを表さなければなりません。
The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic as specified in Appendix A.1.
無記名の10進整数として、または、Appendix A.1の指定されるとしてのアルゴリズムニーモニックとしてAlgorithm分野を表さなければなりません。
Arends, et al. Standards Track [Page 5] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[5ページ]。
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].
Public Keyをコード化するBase64としてPublic Key分野を表さなければなりません。 空白はBase64テキストの中に許容されています。 Base64コード化の定義に関しては、[RFC3548]を見てください。
2.3. DNSKEY RR Example
2.3. DNSKEY RRの例
The following DNSKEY RR stores a DNS zone key for example.com.
以下のDNSKEY RRはDNSのゾーン主要なfor example.comを格納します。
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
Cbl+BBZH4b/0PY1kxkmvHjcZc8no
kfzj31GajIQKY+5CptLr3buXA10h
WqTkF7H6RfoRqXQeogmMHfpftf6z
Mv1LyBUgia7za6ZEzOJBOztyvhjL
742iU/TpPSEDhm2SNKLijfUppn1U
aNvv4w== )
example.com。 86400 DNSKEY256 3 5で( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/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.
TTL、Class、およびRRは、最初の4つのテキストフィールドが所有者名を指定するのをタイプします(DNSKEY)。 値256は、Flags分野のZone Keyビット(ビット7)には値1があるのを示します。 値3は固定プロトコル値です。 値5は公開鍵アルゴリズムを示します。 付録A.1は、アルゴリズムタイプ5がRSA/SHA1であると認識して、RSA/SHA1公開鍵分野の書式が[RFC3110]で定義されるのを示します。 残っているテキストは公開鍵をコード化するBase64です。
3. The RRSIG Resource Record
3. RRSIGリソース記録
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リソースレコードセット(RRsets)にサインして、認証するのに公開鍵暗号を使用します。 デジタル署名は、RRSIGリソース記録に格納されて、[RFC4035]で説明されたDNSSEC認証過程に使用されます。 validatorは、ゾーンからRRsetsを認証するのにこれらのRRSIG RRsを使用できます。 RRSIG RR MUST、単に使用されて、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は、validatorが署名について確かめるのに使用できる公開鍵を含むDNSKEY RRを特定するのに正当性間隔を署名に指定して、Algorithm、SignerのName、およびKey Tagを使用します。
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を保護しなければならないので、RRSIG RRsはCNAME RRを含む名前のために存在していなければなりません。 これは伝統的なDNS仕様[RFC1034]への変化です。(それは、CNAMEが名前のために存在しているなら、それがその名前で許容された唯一のタイプであると述べました)。 RRSIGとNSEC(セクション4を見る)はCNAMEリソース記録と同じ名前のためにサインされたゾーンに存在しなければなりません。
Arends, et al. Standards Track [Page 6] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[6ページ]。
The Type value for the RRSIG RR type is 46.
RRSIG RRタイプのためのType値は46です。
The RRSIG RR is class independent.
RRSIG RRはクラスの独立者です。
An RRSIG RR MUST have the same class as the RRset it covers.
RRSIG RR MUSTには、それが覆う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.
TTLが評価するそれが覆うRRsetのRRSIG RR MUSTマッチのTTL値。 これはRRsetの中の個々のRRsのTTL値のための[RFC2181]規則への例外です: 同じ所有者名がある個々のRRSIG RRsには、彼らが覆うRRsetsが異なったTTL値を持っていると、異なったTTL値があるでしょう。
3.1. RRSIG RDATA Wire Format
3.1. RRSIG RDATAワイヤ形式
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八重奏Original TTL分野、4八重奏Signature Expiration分野、4八重奏Signature Inception分野、2八重奏Keyタグ、Signerの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 署名満了| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 署名始まり| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キー・タグ| 署名者..名前..署名
3.1.1. The Type Covered Field
3.1.1. タイプの覆われた分野
The Type Covered field identifies the type of the RRset that is covered by this RRSIG record.
Type Covered分野はこのRRSIG記録で覆われているRRsetのタイプを特定します。
Arends, et al. Standards Track [Page 7] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[7ページ]。
3.1.2. The Algorithm Number Field
3.1.2. アルゴリズムナンバーフィールド
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
Algorithm Number分野は署名を作成するのに使用される暗号アルゴリズムを特定します。 Appendix A.1でDNSSECアルゴリズムタイプのリストを見つけることができます。
3.1.3. The Labels Field
3.1.3. ラベル分野
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所有者名のラベルの数を指定します。 この分野の意味はvalidatorが答えがワイルドカードから統合されたかどうか決定するのにそれを使用するということです。 そうだとすれば、どんな所有者名が署名を発生させる際に使用されたかを決定するのにそれを使用できます。
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は署名を作成するのに使用された最初の所有者名を必要とします。 最初の所有者名がワイルドカードラベル(「*」)を含んでいるなら、所有者名は応答の過程の間、サーバによって広げられているかもしれません、validatorが署名を有効にするために最初の所有者名を再建するために持っているどの場合に。 [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分野の値は所有者名を終えるヌル(根)ラベルかワイルドカードラベルのどちらかを数えてはいけません(存在しているなら)。 Labels分野の値はRRSIG所有者名のラベルの、より数以下でなければなりません。 「例えば、"www.example.com"には、3のLabels分野価値、および」 *.example.comがあること」において、2のLabels分野価値があります。 根、(「」、)、ラベルに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のLabels分野に格納されたカウントに含まれていませんが、署名が発生するか、または確かめられるとき、ワイルドカードラベルはRRsetの所有者名の一部です。
3.1.4. Original TTL Field
3.1.4. 元のTTL分野
The Original TTL field specifies the TTL of the covered RRset as it appears in the authoritative zone.
Original 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値を減少させるので、Original TTL分野が必要です。 署名を有効にするために、validatorはオリジナルのTTLを必要とします。 [RFC4035]はオリジナルのTTLを再建するのにOriginal TTL分野価値を使用する方法を説明します。
Arends, et al. Standards Track [Page 8] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[8ページ]。
3.1.5. Signature Expiration and Inception Fields
3.1.5. 署名満了と始まり分野
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とInception分野値は日付を指定します、そして、1970年1月1日の協定世界時0時0分0秒以来秒の32ビットの符号のない数の形の時間は経過しました、飛躍秒を無視して、ネットワークバイトオーダーで。 この形式でラッピングなしで言い表すことができる最長間隔はおよそ136年です。 RRSIG RRは満了分野価値が32ビットの巻きつけて着るドレスポイントの近くにあるか、または署名が長いならInception分野価値が生きたより数の上で小さいExpiration分野価値を持つことができます。 これのために、これらの分野にかかわるすべての比較が[RFC1982]で定義されるように「通し番号演算」を使用しなければなりません。 直接の結果として、これらの分野に保管されていた値は過去か未来のどちらかに68年以上日付を参照できません。
3.1.6. The Key Tag Field
3.1.6. キー・タグ分野
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.
Key Tag分野はこの署名を有効にするDNSKEY RRのキー・タグ値を含んでいます、ネットワークバイトオーダーで。 付録Bで、Key Tag値について計算する方法がわかります。
3.1.7. The Signer's Name Field
3.1.7. 署名者の名前欄
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.
SignerのName分野価値は所有者名(validatorがこの署名を有効にするのに使用するべきであるDNSKEY RR)を特定します。 SignerのName分野は覆われたRRsetのゾーンの名前を含まなければなりません。 RRSIG RRを伝えるとき、送付者はSignerのNameフィールドでDNS名前圧縮を使用してはいけません。
3.1.8. The Signature Field
3.1.8. 署名分野
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分野は(Signature分野を除きます)、RRSIG所有者名によって指定されたRRset、RRSIGのクラス、およびRRSIG Type CoveredがさばくRRSIG RDATAを覆う暗号の署名を含んでいます。 この分野の形式を使用中のアルゴリズムに依存します、そして、これらの形式は別々の仲間ドキュメントで説明されます。
3.1.8.1. Signature Calculation
3.1.8.1. 署名計算
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(Signature Fieldを除いた)を覆っていて、RRSIG所有者名、RRSIGのクラス、およびRRSIG Type Covered分野によって指定されたデータRRsetを覆っています。 標準形(セクション6を見る)、およびセットRR(1)にはRRsetがあります…RR(n)は以下の通りサインされます:
Arends, et al. Standards Track [Page 9] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[9ページ]。
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
署名=は(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はSignerのName分野が標準形にあって、Signature分野が除かれている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)(ワイルドカード所有者名があるRRsに関して、ワイルドカードラベルは所有者名に含まれている)です。
Each RR MUST have the same owner name as the RRSIG RR;
各RR MUSTには、RRSIG RRと同じ所有者名があります。
Each RR MUST have the same class as the RRSIG RR;
各RR MUSTには、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 FieldにTTLを記載させなければなりません。
Any DNS names in the RDATA field of each RR MUST be in
canonical form; and
それぞれのRR MUSTの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を見てください。
3.2. The RRSIG RR Presentation Format
3.2. RRSIG RRプレゼンテーション形式
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]で説明されるTYPE表現(セクション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.
無記名の10進整数として、または、アルゴリズムニーモニックとしてAlgorithm分野価値を表さなければなりません、Appendix A.1で指定されるように。
The Labels field value MUST be represented as an unsigned decimal integer.
無記名の10進整数としてLabels分野価値を表さなければなりません。
Arends, et al. Standards Track [Page 10] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[10ページ]。
The Original TTL field value MUST be represented as an unsigned decimal integer.
無記名の10進整数としてOriginal 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日の協定世界時0時0分0秒、またはUTCのフォームYYYYMMDDHHmmSSで秒を示す無記名の10進整数としてSignature Expiration TimeとInception Time分野値を表さなければなりません、どこ:
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).
YYYYが年である、(セクション3.1.5を)見るのを除いた0001-9999 MMは月の番号(01-12)です。 DDは月(01-31)の日です。 24時間の記法(00-23)でHHは時間です。 mmは分(00-59)です。 そして、SSは2番目の(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ケタになるので、これらの2つの形式を見分けるのがいつも可能であることに注意してください、32ビットの符号のない整数の10進表現が10ケタより長い間であることができる、決してそうしません。
The Key Tag field MUST be represented as an unsigned decimal integer.
無記名の10進整数としてKey Tag分野を表さなければなりません。
The Signer's Name field value MUST be represented as a domain name.
ドメイン名としてSignerのName分野価値を表さなければなりません。
The Signature field is represented as a Base64 encoding of the signature. Whitespace is allowed within the Base64 text. See Section 2.2.
Signature分野は署名をコード化するBase64として表されます。 空白はBase64テキストの中に許容されています。 セクション2.2を見てください。
3.3. RRSIG RR Example
3.3. RRSIG RRの例
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。 86400 RRSIG A5 3 86400 20030322173103で(20030220173103 2642example.com oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o=)
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
TTL、Class、およびRRは、最初の4つの分野が所有者名を指定するのをタイプします(RRSIG)。 「A」はタイプの覆われた分野を表します。 値5は署名を作成するのに使用される(RSA/SHA1)アルゴリズムを特定します。 値3は最初の所有者名のLabelsの数です。 RRSIG RDATAの値86400は覆われたA RRsetのためのOriginal TTLです。 そして20030322173103と20030220173103が満了である。
Arends, et al. Standards Track [Page 11] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[11ページ]。
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.
それぞれ始期。 2642は、Key Tagと、example.comです。SignerのものはNameですか? 残っているテキストは署名をコード化する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所有者名、クラス、およびType Coveredの組み合わせが、このRRSIGが"host.example.com"A RRsetを覆うのを示すことに注意してください。 3のLabel値は、ワイルドカード拡大が全く使用されなかったのを示します。 Algorithm、SignerのName、およびKey Tagは、アルゴリズムが5であり、キー・タグが2642であるexample.comゾーンDNSKEY RRを使用することでこの署名を認証できるのを示します。
4. The NSEC Resource Record
4. nsecリソース記録
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リソース記録リストtwoはものを切り離します: 信頼すべきデータか代表団ポイントNS RRsetを含む次の所有者名(ゾーンの正準な注文における)、およびNSEC RRの所有者名前[RFC3845]に出席しているRRタイプのセット。 ゾーンのNSEC RRsの完全なセットは、ゾーンでどの正式のRRsetsがゾーンに存在していて、また、正式の所有者名のチェーンを形成するかを示します。 この情報は、存在の認証された否定をDNSデータに提供するのに[RFC4035]で説明されるように使用されます。
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チェーンの一部であるに違いないので、NSEC RRsはCNAME RRを含む名前のために存在していなければなりません。 これは伝統的なDNS仕様[RFC1034]への変化です。(それは、CNAMEが名前のために存在しているなら、それがその名前で許容された唯一のタイプであると述べました)。 RRSIG(セクション3を見る)とNSEC MUSTは同じ名前のためにCNAMEリソース記録のようにサインされたゾーンに存在しています。
See [RFC4035] for discussion of how a zone signer determines precisely which NSEC RRs it has to include in a zone.
ゾーン署名者が、それがゾーンにどのNSEC RRsを含まなければならないかをどう正確に決定するかに関する議論に関して[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 SHOULDには、SOAの最小のTTL分野と同じTTL値があります。 否定的キャッシュ([RFC2308])の精神にはこれがあります。
Arends, et al. Standards Track [Page 12] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[12ページ]。
4.1. NSEC RDATA Wire Format
4.1. nsec RDATAワイヤ形式
The RDATA of the NSEC RR is as shown below:
以下で示されるとしてNSEC RRのRDATAがあります:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
次..ドメイン名..タイプ..ビットマップ
4.1.1. The Next Domain Name Field
4.1.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.
Next Domain分野は信頼すべきデータを持っているか、または代表団ポイント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を伝えるとき、送付者はNext Domain Nameフィールドで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.
少なくとも1正式のRRsetが同じ所有者名で存在していない場合、Next Domain Nameに所有者名(与えられたゾーンが正式でない(接着剤記録などの)RRsets)を記載してはいけません。
4.1.2. The Type Bit Maps Field
4.1.2. タイプビットマップ分野
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までの)がウィンドウブロックのビットマップに使用される八重奏の数、およびビットマップの最大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.
「どこ」|「連結を指示します。」
Arends, et al. Standards Track [Page 13] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[13ページ]。
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に文通されます、そして、RRへのビット2は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も含んではいけません。
4.1.3. Inclusion of Wildcard Names in NSEC RDATA
4.1.3. nsec RDATAでのワイルドカード名の包含
If a wildcard owner name appears in a zone, the wildcard label ("*")
is treated as a literal symbol and is treated the same as any other
owner name for 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 RRsを発生させる目的のために同じようにいかなる他の所有者名としても扱われます。 ワイルドカード所有者名はNext Domain Name分野に少しもワイルドカード拡大なしで現れます。 [RFC4035]は存在の認証された否定でのワイルドカードの衝撃について説明します。
4.2. The NSEC RR Presentation Format
4.2. nsec RRプレゼンテーション形式
The presentation format of the RDATA portion is as follows:
RDATA部分のプレゼンテーション形式は以下の通りです:
The Next Domain Name field is represented as a domain name.
Next 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]で説明されたTYPE表現(セクション5)を使用しなければなりません。
Arends, et al. Standards Track [Page 14] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[14ページ]。
4.3. NSEC RR Example
4.3. nsec RRの例
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。 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.
TTL、Class、およびRRは、最初の4つのテキストフィールドが名前を指定するのをタイプします(NSEC)。 エントリーhost.example.com alfa.example.comコネの後の次の正式の名前は正準なオーダーですか? A、Mx、RRSIG、NSEC、およびTYPE1234ニーモニックは、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
どんな'0×04'h''o''s''0×07'e''x''a'も''p''l''e'0×03'存在'c''o'0×00 0×00 0×06 0×40 0×01 0×00 0×00 0×00 0×03 0×04 0x1b0x00 0×00でない、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×00、0×20
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].
validatorがこのNSEC記録を認証できると仮定する場合、それは、beta.example.comが存在しないと立証するか、またはalfa.example.comに関連しているどんなAAAA記録もないと立証するのに使用されるかもしれません。 [RFC4035]で存在の認証された否定について議論します。
5. The DS Resource Record
5. DSリソース記録
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 Resource RecordはDNSKEY RRについて言及して、DNS DNSKEY認証過程に使用されます。 DNSKEY RRのキー・タグ、アルゴリズム番号、およびダイジェストを格納することによって、DS 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"ゾーン(親ゾーン)に格納されます。
Arends, et al. Standards Track [Page 15] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[15ページ]。
"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要件もありません。
5.1. DS RDATA Wire Format
5.1. DS RDATAワイヤ形式
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八重奏Key Tag分野、1つの八重奏Algorithm分野、1つの八重奏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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キー・タグ| アルゴリズム| ダイジェストタイプ| ダイジェスト
5.1.1. The Key Tag Field
5.1.1. キー・タグ分野
The Key Tag field lists the key tag of the DNSKEY RR referred to by the DS record, in network byte order.
DNSKEY RRのキー・タグがDSで示したKey Tag分野リストは記録します、ネットワークバイトオーダーで。
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によって使用されたKey TagはRRSIG RRsによって使用されたKey Tagと同じです。 付録BはKey Tagを計算する方法を説明します。
5.1.2. The Algorithm Field
5.1.2. アルゴリズム分野
The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DS record.
DNSKEY RRのアルゴリズム番号がDSで示したAlgorithm分野リストは記録します。
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はアルゴリズム数のタイプを記載します。
Arends, et al. Standards Track [Page 16] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[16ページ]。
5.1.3. The Digest Type Field
5.1.3. ダイジェストタイプ分野
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.
そのDNSKEY RRのダイジェストを含んでいることによって、DS RRはDNSKEY RRについて言及します。 Digest Type分野はダイジェストを構成するのに使用されるアルゴリズムを特定します。 付録A.2は可能なダイジェストアルゴリズムタイプを記載します。
5.1.4. The Digest Field
5.1.4. ダイジェスト分野
The DS record refers to a DNSKEY RR by including a digest of that DNSKEY RR.
そのDNSKEY RRのダイジェストを含んでいることによって、DS記録は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 RDATAと共に完全に適切な所有者名(DNSKEY RR)の標準形を連結して、次に、ダイジェストアルゴリズムを適用することによって、計算されます。
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
=ダイジェスト_アルゴリズム(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です。(そのSHA-1は20八重奏ダイジェストを製作します)。
5.2. Processing of DS RRs When Validating Responses
5.2. 応答を有効にするときのDS RRsの処理
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は処理における余分な注意を必要とします。 DNSSECゾーンが主要であったならDS RR MUSTで言及されたDNSKEY RR。 DNSKEY RR FlagsはFlagsビット7を設定させなければなりません。 DNSKEY旗がDNSSECゾーンキーを示さないなら、合法化の過程でDS RR(そして、それが参照をつけるDNSKEY RR)を使用してはいけません。
5.3. The DS RR Presentation Format
5.3. DS RRプレゼンテーション形式
The presentation format of the RDATA portion is as follows:
RDATA部分のプレゼンテーション形式は以下の通りです:
The Key Tag field MUST be represented as an unsigned decimal integer.
無記名の10進整数としてKey Tag分野を表さなければなりません。
The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic specified in Appendix A.1.
無記名の10進整数として、または、Appendix A.1で指定されたアルゴリズムニーモニックとしてAlgorithm分野を表さなければなりません。
The Digest Type field MUST be represented as an unsigned decimal integer.
無記名の10進整数としてDigest Type分野を表さなければなりません。
Arends, et al. Standards Track [Page 17] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[17ページ]。
The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text.
大文字と小文字を区別しない16進数字の系列としてDigestを表さなければなりません。 空白は16進テキストの中に許容されています。
5.4. DS RR Example
5.4. DS RRの例
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。 86400 DNSKEY256 3 5(AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw=)で。 主要なイド=60485
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
98631FAD1A292118 )
dskey.example.com。 86400 DS60485 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.
TTL、Class、およびRRは、最初の4つのテキストフィールドが名前を指定するのをタイプします(DS)。 値60485は対応する"dskey.example.com"のためのキー・タグです。 DNSKEY RR、値5はこの"dskey.example.com"によって使用されたアルゴリズムを指示します。 DNSKEY RR。 値1はダイジェストを構成するのに使用されるアルゴリズムです、そして、RDATAテキストの残りは16進のダイジェストです。
6. Canonical Form and Order of Resource Records
6. リソース記録の標準形と注文
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.
このセクションはRRsetの中でリソース記録のための標準形、DNS名の正準な注文、およびリソース記録の正準な注文を定義します。 正準な名前オーダーが、チェーンというNSEC名を構成するのに必要です。 RRSIG RRsを組み立てて、確かめるために正準なRRフォームとRRsetの中で注文するのを必要とします。
6.1. Canonical DNS Name Order
6.1. 正準なDNS名前オーダー
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セキュリティの目的のために、所有者名は、無記名の左で正当な八重奏ストリングとして個々のラベルを扱うことによって、注文されます。 ゼロが八重奏を評価して、大文字している米国-ASCII手紙がまるでそれらが小文字の米国-ASCII手紙であるかのように扱われる前に八重奏の欠如は分類します。
Arends, et al. Standards Track [Page 18] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[18ページ]。
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.
1セットの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名前オーダーで分類されます。 最も重要なラベルは「例」です。 このレベルでは、「例」は1番目を分類します、続いて、「a.の例」に終わる名前と、そして、「z.の例」を終わらせる名前を分類します。 同様に、各レベルの中の名前は分類されます。
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
%%BODY%%01.z.example
*.z.example
\200.z.example
例のa.例のyljkjljk.a.例のZ.a.例のzABC.a. EXAMPLE z.例の%%BODY%%01.z.例*.z.例の\200.z.の例
6.2. Canonical RR Form
6.2. 正準なRRフォーム
For the purposes of DNS security, the canonical form of an RR is the wire format of the RR where:
RRの標準形がDNSセキュリティの目的のための、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)のすべての大文字している米国-ASCII手紙を対応する小文字の米国-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のタイプがMINFO、MxのNS、MD、MF、CNAME、SOA、MB、MG、さん、PTR、HINFO、HINFO、RP、AFSDB、RT、SIG、PX、NXT、NAPTR、KX、SRV、DNAME、A6、RRSIG、またはNSECであるなら、RDATAの中に含まれたDNS名のすべての大文字している米国-ASCII手紙を対応する小文字の米国-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のOriginal TTL分野に現れるように元の値に用意ができています。
Arends, et al. Standards Track [Page 19] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[19ページ]。
6.3. Canonical RR Ordering within an RRset
6.3. RRsetの中で注文する正準なRR
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部分を扱うことによって、分類されます。
[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と複数のRRs)を含むことができないと指定します。 したがって、標準形にRRsetを入れるとき、実現が写しRRsを検出するなら、それはプロトコル誤りとしてこれを扱わなければなりません。 実現が、堅牢性の原則(それが受け入れるものでは、寛容である)の精神におけるこのプロトコル誤りを扱うのを選ぶなら、それはRRsetの標準形について計算する目的のために写しRR(s)の1つ以外のすべてを取り除かなければなりません。
7. IANA Considerations
7. IANA問題
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]はそれぞれタイプ24、25、および30をSIG、KEY、およびNXT RRsに配属しました。 [RFC3658]はDNS Resource Record Type43をDSに割り当てました。 [RFC3755]はそれぞれタイプ46、47、および48をRRSIG、NSEC、およびDNSKEY RRsに選任しました。 [RFC2931]で説明された「SIG(0)」取引セキュリティプロトコルと、そして、取引の主要なリソース記録へのタイプ24(SIG)と25(KEY)のObsoleteと制限された使用が[RFC2930]で説明したようにまた、マークされた[RFC3755]は30(NXT)をタイプします。
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 Resource Record Algorithm分野番号と割り当てられた値1-4と252-255のためにIANA登録を作成しました。 [RFC3110]は値5を割り当てました。 [RFC3755]は、DNSセキュリティ拡張子で使用に関して各エントリーのための旗を含むようにこの登録を変更しました。 それぞれのアルゴリズムエントリーはゾーン調印、取引セキュリティ([RFC2931]を見る)、または両方に使用できるアルゴリズムを示すかもしれません。 値6-251はIETF規格動作([RFC3755])による課題に利用可能です。 この書くこととそれらの状態時点で、DNS Security Algorithm民数記エントリーの詳細な一覧表のためにDNSSECにおける使用に関してAppendix Aを見てください。
Arends, et al. Standards Track [Page 20] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[20ページ]。
[RFC3658] created an IANA registry for DNSSEC DS Digest Types and
assigned value 0 to reserved and value 1 to SHA-1.
DNSSEC DS Digest Typesと割り当てられた値0がSHA-1に1を予約して、評価するように、[RFC3658]はIANA登録を作成しました。
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]はKEYプロトコルValuesのためのIANA Registryを作成しましたが、再選任されて[RFC3445]、3を除いて、すべてがこのIANA登録を予約されて閉じられるのに評価します。 登録は閉じられたままで残っています、そして、すべてのKEYとDNSKEY記録が、3のプロトコルOctet価値を持つのに必要です。
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 RRsでビットに旗を揚げさせてください: [RFC3755]はIANA登録をDNSSEC KEYとDNSKEY RRフラグビット作成しました。 初めは、この登録はビット7(ZONEビット)とビット15のための課題を含むだけです(Secure Entry Point旗(9月)に噛み付きました; [RFC3757]を見てください)。 [RFC3755]に述べられているように、ビットは0-6と8-14にIETF Standards Actionによる課題に有効です。
8. Security Considerations
8. セキュリティ問題
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を選択するのにキー・タグだけを使用する実現はいくつかの事情の間違った公開鍵を選択するかもしれません。 さらに詳しい明細についてはAppendix Bを見てください。
Arends, et al. Standards Track [Page 21] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[21ページ]。
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].
Appendix AのアルゴリズムのテーブルとAppendix Bのキー・タグ計算アルゴリズムは完全性のためのRSA/MD5アルゴリズムを含んでいますが、RSA/MD5アルゴリズムはNOT RECOMMENDEDです、[RFC3110]で説明されるように。
9. Acknowledgements
9. 承認
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作業部会とワーキンググループメーリングリストのメンバーの入力と考えから作成されました。 エディタはこれらのセキュリティファイル拡張仕様書の改正の間に受領されたコメントと提案のために感謝したがっています。 明らかに10年間DNSSECが開発中であった貢献している皆を記載するのは不可能でしょうが、[RFC4033]は何人かのこれらのドキュメントを批評するほど親切であった関係者のリストを含んでいます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC1982]ElzとR.とR.ブッシュ、「通し番号演算」、RFC1982、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2308] アンドリュース、M.、「DNS質問(DNS NCACHE)の否定的キャッシュ」、RFC2308、1998年3月。
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
System (DNS)", RFC 2536, March 1999.
[RFC2536] イーストレーク3番目と、D.と、「ドメインネームシステム(DNS)におけるDSAキーとSIG」(RFC2536)は1999を行進させます。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000.
2000年の[RFC2931]イーストレークD.、「DNS要求と取引署名(SIG(0)s)」、RFC2931 9月3日。
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110] イーストレーク3番目と、D.と、「ドメインネームシステム(DNS)におけるRSA/SHA-1SIGとRSAキー」(RFC3110)は2001がそうするかもしれません。
Arends, et al. Standards Track [Page 22] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[22ページ]。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3445] RFC3445、「主要なリソース記録(RR)の範囲を制限し」て、マッシー、D.、およびS.は上昇して、12月は2002です。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3548]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3597]グスタファソン、A.、「未知のDNSリソース記録(RR)タイプの取り扱い」、RFC3597、2003年9月。
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
[RFC3658]グドムンソン、O.、「代表団署名者(DS)リソース記録(RR)」、RFC3658、2003年12月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004.
[RFC3755]ウィーラー(S.、「代表団署名者(DS)のための遺産レゾルバの互換性」、RFC3755)は2004がそうするかもしれません。
[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.ルイス、「ドメインネームシステムの主要な(DNSKEY)リソース記録(RR)安全なエントリー・ポイント(9月)旗」、RFC3757(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.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[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.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
10.2. Informative References
10.2. 有益な参照
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2535] イーストレーク3番目、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
Name System (DNS)", RFC 2537, March 1999.
[RFC2537] イーストレーク3番目と、D.と、「ドメインネームシステム(DNS)におけるRSA/MD5キーとSIG」(RFC2537)は1999を行進させます。
[RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC2539] イーストレーク3番目、D.、「ドメインネームシステム(DNS)における、ディフィー-ヘルマンKeysの格納」、RFC2539、1999年3月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2930] イーストレーク3番目、D.、「DNS(TKEY RR)のための秘密鍵設立」、RFC2930、2000年9月。
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
RDATA Format", RFC 3845, August 2004.
[RFC3845] Schlyter、J.、「DNSセキュリティ(DNSSEC)NextSECure(nsec)RDATA形式」、RFC3845、2004年8月。
Arends, et al. Standards Track [Page 23] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[23ページ]。
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 Algorithm Numberを使用します。 また、DSリソース記録は、DS記録を構成するのに使用されるダイジェストアルゴリズムを特定するためにDigest Algorithm Numberを指定します。 現在定義されたAlgorithmとDigest Typesは以下に記載されています。 暗号における進歩がそれらを保証するとき、追加AlgorithmかDigest Typesを加えることができました。
A DNSSEC aware resolver or name server MUST implement all MANDATORY algorithms.
DNSSECの意識しているレゾルバかネームサーバがすべてのMANDATORYアルゴリズムを実行しなければなりません。
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 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)とKEY 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
参照状態にサインするゾーン値のアルゴリズム[ニーモニック]----- -------------------- --------- ---------- --------- 0 1予約されたRSA/MD5[RSAMD5]n[RFC2537]NOT RECOMMENDED2ディフィー-ヘルマン[DH]n[RFC2539]--3DSA/SHA-1[DSA]y[RFC2536]OPTIONAL4Elliptic Curve[ECC]Tba--兵士の[PRIVATEDNS]yが、OPTIONAL254の下で兵士の[PRIVATEOID]yが見るのを見るOPTIONAL255が予約した5RSA/SHA-1[RSASHA1]y[RFC3110]MANDATORY252Indirect[INDIRECT]n--253未満
6 - 251 Available for assignment by IETF Standards Action.
IETF Standards Actionによる課題のために利用可能な6--251。
Arends, et al. Standards Track [Page 24] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[24ページ]。
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.
アルゴリズムNo.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.
アルゴリズムNo.254は、私的使用目的で予約されて、特定のアルゴリズムに決して割り当てられないでしょう。 無記名の長さのバイトがBERによって続かれている状態で、DNSKEY RRの公開鍵領域とRRSIG RRの署名領域はその長さのコード化されたObject Identifier(ISO OID)を始めます。 OIDは使用中の個人的なアルゴリズムを示します、そして、領域の残りはそのアルゴリズムによって必要とされることなら何でもです。 実体は彼らが彼らの個人的なアルゴリズムを指定するために制御するOIDsを使用するだけであるべきです。
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 -
状態0が予約した値のアルゴリズム--1 義務的な2-255が割り当てなかったSHA-1、-
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リソースレコード種類のKey Tag分野は効率的に公開鍵を選択するのにメカニズムを提供します。 多くの場合、所有者名、アルゴリズム、およびキー・タグの組み合わせは効率的にDNSKEY記録を特定できます。 RRSIGとDSリソース記録の両方には、対応するDNSKEY記録があります。 1候補DNSKEY RRが利用可能であるときに、効率的に対応するDNSKEY RRを選択するのを助けるのにRRSIGとDS記録のKey Tag分野を使用できます。
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を特定すると仮定してはいけません。
Arends, et al. Standards Track [Page 25] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[25ページ]。
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に関してAppendix B.1を見てください)。 キー・タグアルゴリズムは2つの八重奏グループに細かく分けられたDNSKEY RDATAのワイヤ形式の合計です。 まず最初に、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機能を以下に与えるRDATAと共に、DNSKEY RRの部分が入力されるように使用されているということです。 以下の参照コードを逐語的に使用するのは必要ではありませんが、Key Tagの数値は参照実現が同じ入力のために発生させることと同じであるに違いありません。
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.
Key Tagについて計算するためのアルゴリズムはチェックサムが他の多くのインターネットプロトコルに使用した身近なもの補数と完全でない、しかし、ほとんど同じです。 ここでもの補数のチェックサムよりむしろ説明されたアルゴリズムを使用して、主要なTagsについて計算しなければなりません。
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参照実現はKey Tagの値について計算します。 この参照実現はアルゴリズム1以外のすべてのアルゴリズムタイプに適用されます(Appendix 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.
*/
/**は、intが少なくとも16ビットであると仮定します。 * キー・タグの最初の八重奏は*リターン価値の最も重要な8ビットです。 * キー・タグの2番目の八重奏は*リターン価値の最も重要でない8ビットです。 */
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 */
無記名のint keytag、(無記名の炭のキー[]、RDATAが分けるDNSKEY RR*/無記名のint keysize/*の/*、RDLENGTH*/)、無記名の長いac; *が32ビットか、より大きい*/int iであると仮定した/; /*輪インデックス*/
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i & 1) ? key[i] : key[i] << 8;
ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}
(i=0 ; ac=0、i<はkeysizeされます; + + i)というac+=(iと1)? キー[i]のために: キー[i]<<8。 ac+=(ac>>16)と0xFFFF。 リターンacと0xFFFF。 }
Arends, et al. Standards Track [Page 26] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[26ページ]。
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ビットの(言い換えれば、持続する4番目と公開鍵係数の最後の八重奏への3番目)の公開鍵係数で最も重要な16ビットになるように定義されます。
Please note that Algorithm 1 is NOT RECOMMENDED.
Algorithm1はNOT RECOMMENDEDです。
Arends, et al. Standards Track [Page 27] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[27ページ]。
Authors' Addresses
作者のアドレス
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
ロイArends Telematica Instituut Brouwerijstraat1 7523XCエンスヘーデNL
EMail: roy.arends@telin.nl
メール: roy.arends@telin.nl
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブAusteinインターネットSystems共同体950憲章通りカリフォルニア94063レッドウッドシティー(米国)
EMail: sra@isc.org
メール: sra@isc.org
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
マットラーソンベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: mlarson@verisign.com
メール: mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
ダン・マッシー・コロラド州立大学コンピュータサイエンス学部フォートコリンズ、CO80523-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
スコットRoseの規格の国家の研究所と技術100事務局Drive MD20899-8920ゲイザースバーグ(米国)
EMail: scott.rose@nist.gov
メール: scott.rose@nist.gov
Arends, et al. Standards Track [Page 28] RFC 4034 DNSSEC Resource Records March 2005
Arends、他 規格は2005年のDNSSECリソース記録行進のときにRFC4034を追跡します[28ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Arends, et al. Standards Track [Page 29]
Arends、他 標準化過程[29ページ]
一覧
スポンサーリンク
