この文書はRFC4034の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group R. Arends
Request for Comments: 4034 Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
3755, 3757, 3845 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
Resource Records for the DNS Security Extensions
ＤＮＳセキュリティ拡張のための資源レコード
Status of This Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
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.
この文書はＤＮＳセキュリティ拡張（ＤＮＳＳＥＣ）を記述する文書ファミ
リの一部です。ＤＮＳセキュリティ拡張はＤＮＳに情報源認証を提供する資
源レコードとプロトコル修正の集まりです。この文書は公開鍵（ＤＮＳＫＥ
Ｙ）と委任署名（ＤＳ）と資源レコードディジタル署名（ＲＲＳＩＧ）と存
在非認証（ＮＳＥＣ）資源レコードを定義します。それぞれの資源レコード
の目的とフォーマットは詳細で記述されます、そしてそれぞれの資源レコー
ドの例が与えられます。
This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535.
この文書はＲＦＣ２５３５とＲＦＣ２５３５へ組み込まれた全ての変更を時
代遅れにします。
Table of Contents
目次
1. Introduction
1. はじめに
1.1. Background and Related Documents
1.1. 背景と関連文書
1.2. Reserved Words
1.2. 予約語
2. The DNSKEY Resource Record
2. ＤＮＳＫＥＹ資源レコード
2.1. DNSKEY RDATA Wire Format
2.1. ＤＮＳＫＥＹ資源データワイヤフォーマット
2.1.1. The Flags Field
2.1.1. フラグフィールド
2.1.2. The Protocol Field
2.1.2. プロトコルフィールド
2.1.3. The Algorithm Field
2.1.3. アルゴリズムフィールド
2.1.4. The Public Key Field
2.1.4. 公開鍵フィールド
2.1.5. Notes on DNSKEY RDATA Design
2.1.5. ＤＮＳＫＥＹ資源データのデザインの注記
2.2. The DNSKEY RR Presentation Format
2.2. ＤＮＳＫＥＹ資源レコード表示フォーマット
2.3. DNSKEY RR Example
2.3. ＤＮＳＫＥＹ資源レコードの例
3. The RRSIG Resource Record
3. 資源レコード署名資源レコード
3.1. RRSIG RDATA Wire Format
3.1. 資源レコード署名資源データワイヤフォーマット
3.1.1. The Type Covered Field
3.1.1. 種別カバーフィールド
3.1.2. The Algorithm Number Field
3.1.2. アルゴリズム番号フィールド
3.1.3. The Labels Field
3.1.3. ラベルフィールド
3.1.4. Original TTL Field
3.1.4. 元のＴＴＬフィールド
3.1.5. Signature Expiration and Inception Fields
3.1.5. 署名期限と開始フィールズ
3.1.6. The Key Tag Field
3.1.6. 鍵タグフィールド
3.1.7. The Signer's Name Field
3.1.7. 署名者の名前フィールド
3.1.8. The Signature Field
3.1.8. 署名フィールド
3.2. The RRSIG RR Presentation Format
3.2. 資源レコード署名資源レコードの表示フォーマット
3.3. RRSIG RR Example
3.3. 資源レコード署名資源レコードの例。
4. The NSEC Resource Record
4. ＮＳＥＣ資源レコード
4.1. NSEC RDATA Wire Format
4.1. ＮＳＥＣ資源データワイヤフォーマット
4.1.1. The Next Domain Name Field
4.1.1. 次のドメイン名フィールド
4.1.2. The Type Bit Maps Field
4.1.2. 種別ビットマップフィールド
4.1.3. Inclusion of Wildcard Names in NSEC RDATA
4.1.3. ＮＳＥＣ資源データのワイルドカード名の包含
4.2. The NSEC RR Presentation Format
4.2. ＮＳＥＣ資源レコード表示フォーマット
4.3. NSEC RR Example
4.3. ＮＳＥＣ資源レコードの例
5. The DS Resource Record
5. 委任署名資源レコード
5.1. DS RDATA Wire Format
5.1. 委任署名資源データワイヤフォーマット
5.1.1. The Key Tag Field
5.1.1. 鍵タグフィールド
5.1.2. The Algorithm Field
5.1.2. アルゴリズムフィールド
5.1.3. The Digest Type Field
5.1.3. ダイジェスト種別フィールド
5.1.4. The Digest Field
5.1.4. ダイジェストフィールド
5.2. Processing of DS RRs When Validating Responses
5.2. 回答検証での委任署名資源レコード処理
5.3. The DS RR Presentation Format
5.3. 委任署名資源レコード表示フォーマット。
5.4. DS RR Example
5.4. 委任署名資源レコードの例
6. Canonical Form and Order of Resource Records
6. 正規形式と資源レコードの順序
6.1. Canonical DNS Name Order
6.1. 正規ＤＮＳ名前順序
6.2. Canonical RR Form
6.2. 正規資源レコード形式
6.3. Canonical RR Ordering within an RRset
6.3. 資源レコード集合の正規資源レコード順序
7. IANA Considerations
7. ＩＡＮＡの考慮
8. Security Considerations
8. セキュリティの考察
9. Acknowledgements
9. 謝辞
10. References
10. 参考文献
10.1. Normative References
10.1. 参照する参考文献
10.2. Informative References
10.2. 有益な参考文献
Appendix A. DNSSEC Algorithm and Digest Types
付録Ａ． ＤＮＳＳＥＣアルゴリズムとダイジェストタイプ
A.1. DNSSEC Algorithm Types
A.1. ＤＮＳＳＥＣアルゴリズム種別
A.1.1. Private Algorithm Types
A.1.1. 私的アルゴリズム種別
A.2. DNSSEC Digest Types
A.2. ＤＮＳＳＥＣダイジェスト種別
Appendix B. Key Tag Calculation
付録Ｂ． 鍵タグ計算
B.1. Key Tag for Algorithm 1 (RSA/MD5)
B.1. アルゴリズム１（ＲＳＡ／ＭＤ５）のための鍵タグ
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
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).
ＤＮＳセキュリティ拡張（ＤＮＳＳＥＣ）は４つの新しいＤＮＳ資源レコー
ド種別を導入します：ＤＮＳ公開鍵（ＤＮＳＫＥＹ）と資源レコード署名
（ＲＲＳＩＧ）と次の安全（ＮＳＥＣ）と委任署名者（ＤＳ）。この文書は
それぞれの資源レコード（ＲＲ）の目的、ＲＲの資源データ (ＲＤＡＴＡ)
フォーマットとその表示フォーマット（ＡＳＣＩＩ表現）を定義します。
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.
この文書はＤＮＳＳＥＣを定義する文書ファミリの一部で、そしてこれはセッ
トとして一緒に読まれるべきです。
[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]はＤＮＳＳＥＣの導入と共通用語の定義を含んでいます；読者はこ
の文書に精通していると考えられます。[RFC4033]はこの文書群によって更新
されるか時代遅れにされる他の文書のリストも含んでいます。
[RFC4035] defines the DNSSEC protocol operations.
[RFC4035]がＤＮＳＳＥＣプロトコルオペレーションを定義します。
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]とこれらを更新する以降の文書で記述さ
れた、基本的なＤＮＳの外延ンに精通していると考えられます。
This document defines the DNSSEC resource records. All numeric DNS
type codes given in this document are decimal integers.
この文書はＤＮＳＳＥＣ資源レコードを定義します。すべてのこの文書で与
えられたＤＮＳ種別コードの数は１０進整数です。
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"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[RFC2119]で記述されるように解釈します。
2. The DNSKEY Resource Record
2. ＤＮＳＫＥＹ資源レコード
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.
ＤＮＳＳＥＣはＤＮＳ資源レコード集合（ＲＲｓｅｔ）の署名と認証に公開
鍵暗号を使います。公開鍵はＤＮＳＫＥＹ資源レコードに保管され、
[RFC4035]で記述されたＤＮＳＳＥＣ認証プロセスで使われます：ゾーンが
秘密鍵を使うことによってその正式な資源レコード集合に署名し、対応する
公開鍵をＤＮＳＫＥＹ資源レコードに保存します。リゾルバがゾーンの資源
レコード集合をカバーしている署名の妥当性を検査し、そしてそれらを認証
するために公開鍵を使うことができます。
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.
ＤＮＳＫＥＹ資源レコードは任意の公開鍵を保存するレコードを意図しなく
て、そして直接ＤＮＳ基礎構造に関連していない証明書あるいは公開鍵の保
存に使用してはなりません(MUST NOT)。
The Type value for the DNSKEY RR type is 48.
ＤＮＳＫＥＹ資源レコード種別の種別値は４８です。
The DNSKEY RR is class independent.
ＤＮＳＫＥＹ資源レコードはクラスに依存しません。
The DNSKEY RR has no special TTL requirements.
ＤＮＳＫＥＹ資源レコードは特別なＴＴＬ条件を持っていません。
2.1. DNSKEY RDATA Wire Format
2.1. ＤＮＳＫＥＹ資源データワイヤフォーマット
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.
ＤＮＳＫＥＹ資源レコードの資源データは２オクテットフラグフィールドと、
１オクテットプロトコルフィールドと、１オクテットアルゴリズムフィール
ドと公開鍵フィールドから成り立ちます。
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
フラグフィールドのビット７はゾーン鍵フラグです。もしビット７が値１な
ら、ＤＮＳＫＥＹレコードはＤＮＳゾーン鍵を持ちます、そしてＤＮＳＫＥ
Ｙ資源レコードの所有者名はゾーンの名前に違いありません(MUST)。もしビッ
ト７が値０なら、ＤＮＳＫＥＹレコードは何か他の種別のＤＮＳ公開鍵を持
ち、そして資源レコード集合をカバーする資源レコード署名を検証するため
に使われてはなりません(MUST NOT)。
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.
フラグフィールドのビット１５は[RFC3757]で記述されたセキュリティ入口点
フラグです。もしビット１５が値１なら、ＤＮＳＫＥＹレコードはセキュリ
ティ入口点としての使用を意図された鍵を持ちます。このフラグはこのＤＮ
ＳＫＥＹレコードの意図する使用方法について、ゾーン署名やデバッグソフ
トウェアにヒントを意図するだけです；検証者はこのビットの設定に基よっ
て署名検証プロセスの動作を変更してはなりません(MUST NOT)。これはＳＥ
Ｐビットを設定したＤＮＳＫＥＹ資源レコードも、正当に署名を生成するこ
とが可能であるため、ゾーン鍵フラグの設定を必要とすることを意味します。
ＳＥＰが設定されゾーン鍵フラグが設定されていないＤＮＳＫＥＹ資源レコー
ドは資源レコード集合をカバーする資源レコード署名の実証に使われてはな
りません(MUST NOT)。
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.
ビット０-６と８-１４は予約です：これらのビットはＤＮＳＫＥＹＲＲの生
成時に値０にし(MUST)、受信時に無視されなくてはなりません(MUST)。
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.
プロトコルフィールドは値３でなくてはなりません(MUST)、そしてもし３以
外の値であることがわかるならＤＮＳＫＥＹ資源レコードは署名検証の際に
無効と扱われなくてはなりません(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
アルゴリズムフィールドは公開鍵の暗号のアルゴリズムを識別し、そして公
開鍵フィールドのフォーマットを決定します。ＤＮＳＳＥＣアルゴリズム種
別のリストが付録Ａ.１にあります。
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.
公開鍵フィールドは公開鍵材料を持ちます。フォーマットは保存される鍵の
アルゴリズムに依存し、別の文書で記述されます。
2.1.5. Notes on DNSKEY RDATA Design
2.1.5. ＤＮＳＫＥＹ資源データのデザインの注記
Although the Protocol Field always has value 3, it is retained for
backward compatibility with early versions of the KEY record.
プロトコルフィールドが常に値３ですが、これは鍵レコードの初期バージョ
ンとの逆方向互換性のために維持されます。
2.2. The DNSKEY RR Presentation Format
2.2. ＤＮＳＫＥＹ資源レコード表示フォーマット
The presentation format of the RDATA portion is as follows:
資源データ部の表示フォーマットは次の通りです：
The Flag field MUST be represented as an unsigned decimal integer.
Given the currently defined flags, the possible values are: 0, 256,
and 257.
フラグフィールドは符号なしの１０進整数で描きます(MUST)。現在定義され
たフラグの条件で可能な値は以下です：０、２５６、２５７
The Protocol Field MUST be represented as an unsigned decimal integer
with a value of 3.
プロトコルフィールドは３値で符号なしの１０進整数として描きます(MUST)。
The Algorithm field MUST be represented either as an unsigned decimal
integer or as an algorithm mnemonic as specified in Appendix A.1.
アルゴリズムフィールドは符号なしの１０進整数か、付録A.１で指定される
アルゴリズム名として表します(MUST)。
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].
公開鍵フィールドは公開鍵のBase６４コーディングとして描きます(MUST)。
空白スペースがベース６４テキストの中で許されます。ベース６４コーディ
ングの定義は[RFC3548]を見てください。
2.3. DNSKEY RR Example
2.3. ＤＮＳＫＥＹ資源レコードの例
The following DNSKEY RR stores a DNS zone key for example.com.
次のＤＮＳＫＥＹ資源レコードはexample.comのＤＮＳゾーン鍵を保管します。
example.com. 86400 IN DNSKEY 256 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.
最初の４つのテキストフィールドは所有者名とＴＴＬとクラスと資源レコー
ド種別（ＤＮＳＫＥＹ）を指定します。値２５６はフラグフィールドの中
ゾーン鍵ビット（ビット７）が値１であることを示します。値３は固定した
プロトコル値です。値５が公開鍵アルゴリズムを示します。付録A.１でアル
ゴリズム種別５がＲＳＡ／ＳＨＡ１であり、ＲＳＡ／ＳＨＡ１公開鍵フィー
ルドのフォーマットが[RFC3110]で定義されることを示します。残りのテキ
ストは公開鍵のべース６４コーディングです。
3. The RRSIG Resource Record
3. 資源レコード署名資源レコード
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.
ＤＮＳＳＥＣはＤＮＳ資源レコードセット（ＲＲｓｅｔ）に署名し認証をす
るために公開鍵暗号を使います。ディジタル署名が資源レコード署名資源レ
コードに保管され、そして[RFC4035]で記述されたＤＮＳＳＥＣ認証プロセス
で使われます。検証者はゾーンの資源レコード集合を認証するためにこれら
の資源レコード署名資源レコードを使うことができます。資源レコード署名
資源レコードはただがＤＮＳオペレーションを安全に保つために使う証明資
料（ディジタル署名）を運ぶためにだけ使えます(MUST)。
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.
資源レコード署名レコードが特定の名前とクラスと種別の資源レコード集合
の署名を含んでいます。資源レコード署名資源レコードは署名の有効期間を
指定し、そして署名の検証のために検証者が使うことができる公開鍵を含む
ＤＮＳＫＥＹ資源レコードを識別するためにアルゴリズムと署名者の名前と
鍵タグを使います。
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.
すべてのゾーンの正式な資源レコード集合はディジタル署名で守られなくて
はならないので、資源レコード署名資源レコードは、ＣＮＡＭＥ資源レコー
ドを含めて、名前に関して存在するに違いありません。これは、もし名前に
ＣＮＡＭＥが存在しているなら、ＣＮＡＭＥがその名前で許される唯一の種
別であると述べる、伝統的なＤＮＳ仕様書[RFC1034]に対する変更です。資
源レコード署名とＮＳＥＣ（４章参照）は署名されたゾーンのＣＮＡＭＥ資
源レコードの名前にも存在しなくてはなりません(MUST)。
The Type value for the RRSIG RR type is 46.
資源レコード署名資源レコード種別の種別値は４６です。
The RRSIG RR is class independent.
資源レコード署名資源レコードはクラスに依存しません。
An RRSIG RR MUST have the same class as the RRset it covers.
資源レコード署名資源レコードはカバーする資源レコード集合と同じクラス
です(MUST)。
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.
資源レコード署名資源レコードのＴＴＬ値はカバーする資源レコード集合の
ＴＴＬ値に一致します(MUST)。これは資源レコード集合の個別の資源レコー
ドのＴＴＬ値の[RFC2181]規則の例外です：同じ所有者名の個別の資源レコー
ド署名資源レコードは、もしそれらがカバーする資源レコード集合が異なる
ＴＴＬ値を持つなら、異なるＴＴＬ値を持つでしょう。
3.1. RRSIG RDATA Wire Format
3.1. 資源レコード署名資源データワイヤフォーマット
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.
資源レコード署名資源レコードの資源データは、２オクテットのカバー種別
フィールド、１オクテットアルゴリズムフィールド、１オクテットのラベル
フィールド、４オクテットの元ＴＴＬフィールド、４オクテット署名期限
フィールド、４オクテット署名開始フィールド、２つのオクテット鍵タグ、
署名者の名前フィールドと署名フィールドから成り立ちます。
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
種別カバーフィールドはこの資源レコード署名レコードによってカバーさ
れる資源レコード集合の種別を識別します。
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
アルゴリズム番号フィールドは署名を作るために使われた暗号のアルゴリズ
ムを識別します。ＤＮＳＳＥＣアルゴリズム種別のリストが付録Ａ.１にあ
ります。
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.
ラベルフィールドは、資源レコード署名資源レコードの元の所有者名のラベ
ルの数を指定します。このフィールドは検証者が答えがワイルドカードから
生成されたかどうか決定するために必要です。それでどの所有者名が署名を
生成する際に使われたか決定するのに使用できます。
To validate a signature, the validator needs the original owner name
that was used to create the signature. If the original owner name
contains a wildcard label ("*"), the owner name may have been
expanded by the server during the response process, in which case the
validator will have to reconstruct the original owner name in order
to validate the signature. [RFC4035] describes how to use the Labels
field to reconstruct the original owner name.
署名を有効にするために、検証者は署名を作るために使われた元の所有者名
を必要とします。もし元の所有者名がワイルドカードラベル("*")を含んで
いるなら、回答処理でサーバによって所有者名が拡張されたかもしれません、
この場合、検証者が署名を検証するための元の所有者名を再構築しなければ
ならないでしょう。[RFC4035]で元の所有者名を再構築するためにラベル
フィールドを使う方法を記述します。
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.
ラベルフィールドの値は、所有者名の終わりのヌルラベル（ルート）や（も
しある場合）ワイルドカードラベルを数えてはなりません(MUST NOT)。ラベ
ルフィールドの値は資源レコード署名の所有者名のラベルの数かそれ以下で
あるに違いありません(MUST)。例えば、"www.example.com."のラベルフィー
ルド値は３で、"*.example.com."のラベルフィールド値は２です。ルート
(".")のラベルフィールド値は０です。
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.
ワイルドカードラベルは資源レコード署名資源レコードのラベルフィールド
を数える際に含まれませんが、署名の生成や検証の際には資源レコード集合
の所有者名の一部になります。
3.1.4. Original TTL Field
3.1.4. 元のＴＴＬフィールド
The Original TTL field specifies the TTL of the covered RRset as it
appears in the authoritative zone.
元のＴＴＬフィールドは、カバーする資源レコード集合の、正式なゾーンで
の、ＴＴＬを指定します。
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.
元のＴＴＬフィールドは、キャッシュリゾルバがキャッシュした資源レコー
ド集合のＴＴＬ値を減少させるので、必要です。署名を有効にするために、
検証者が元のＴＴＬを必要とします。[RFC4035]で元のＴＴＬを再建するため
に元のＴＴＬフィールド値を使う方法を記述します。
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.
署名期限と開始フィールドは署名の有効期間を指定します。資源レコード署
名レコードは開始日付の前に認証に使われてはならなくて(MUST NOT)、そし
て有効期限後に認証に使われてはなりません(MUST NOT)。
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.
署名期限と開始フィールド値は、秒１９７０年１月１日００時００分からの
うるう秒を無視した経過秒を、ネットワークバイト順で３２ビットの符号な
し数のかたちで指定します。このフォーマットで表現できる最長間隔はおよ
そ１３６年です。資源レコード署名資源レコードは、もし期限フィールド値
が３２ビットの最終値に近いか、もし署名が長命であるなら、数値的に開始
フィールド値より小さい期限フィールド値を持つことができます。これの、
すべてのこれらのフィールドに関する比較は、[RFC1982]で定義されるように、
「シリアル算数」を使わなくてはなりません。直接の結果として、これらの
フィールドの内容値は６８年以上の過去あるいは未来の日付を示せません。
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.
鍵タグフィールドはこの署名を有効にするＤＮＳＫＥＹ資源レコードの、ネッ
トワークバイト順での鍵タグ値を含んでいます。付録Ｂが鍵タグ値を計算す
る方法を説明します。
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.
署名者の名前フィールド値は検証者がこの署名を有効にするために使うＤＮ
ＳＫＥＹ資源レコードの所有者名を識別します。署名者の名前フィールドは
カバーする資源レコード集合のゾーンの名前を含んでいなくてはなりません
(MUST)。送信者は資源レコード署名資源レコードを伝達する時、署名者の名
前フィールドに対してＤＮＳ名前圧縮を使ってはなりません(MUST NOT)。
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.
署名フィールドは暗号の署名を含み、これは資源レコード署名資源データ
（署名フィールドを除く）と、資源レコード署名所有者名と資源レコード署
名クラスと資源レコード署名種別カバーフィールドによって指定される資源
レコード集合をカバーします。このフィールドのフォーマットは使用するア
ルゴリズムに依存し、そしてこれらのフォーマットは別の関連文書で記述さ
れます。
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:
署名は、（署名フィールドを除く）資源レコード署名資源データと、資源レ
コード集合 (RRset) が資源レコード署名の所有者名と資源レコード署名のク
ラスと資源レコード署名種別カバーフィールドによって指定したデータをカ
バーします。資源レコード集合は正規形式（６章参照）であり、そして資源
レコード（１）〜資源レコード（ｎ）は次のように署名されます：
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は、署名者の名前フィールドを含む、正規形式で
署名フィールドを除く、資源レコード署名の資源データの
ワイヤフォーマットです；
RR(i) = owner | type | class | TTL | RDATA length | RDATA
"owner" is the fully qualified owner name of the RRset in
canonical form (for RRs with wildcard owner names, the
wildcard label is included in the owner name);
"owner"は正規形式の資源レコード集合の完全指定所有者名です
（ワイルドカード所有者名の資源レコードで、ワイルドカード
ラベルは所有者名に含められます）；
Each RR MUST have the same owner name as the RRSIG RR;
それぞれの資源レコードは資源レコード署名資源レコードと同
じ所有者名でなければなりません(MUST)；
Each RR MUST have the same class as the RRSIG RR;
それぞれの資源レコードは資源レコード署名資源レコードと同
じクラスでなければなりません(MUST)；
Each RR in the RRset MUST have the RR type listed in the
RRSIG RR's Type Covered field;
それぞれの資源レコード集合の資源レコードは、資源レコード
署名資源レコードの種別カバーフィールドでリストアップさ
れる資源レコード種別でなければなりません(MUST)；
Each RR in the RRset MUST have the TTL listed in the
RRSIG Original TTL Field;
資源レコード集合のそれぞれの資源レコードは、資源レコード
署名の元のＴＴＬフィールドで指定したＴＴＬでなければなり
ません(MUST)；
Any DNS names in the RDATA field of each RR MUST be in
canonical form; and
それぞれの資源レコードの資源データフィールド内のＤＮＳ名
は全て正規形式でなければなりません(MUST)；そして
The RRset MUST be sorted in canonical order.
資源レコード集合は正規順に並べられなければなりません(MUST)。
See Sections 6.2 and 6.3 for details on canonical form and ordering
of RRsets.
正規形式と資源レコード集合順序の詳細は６.２章と６.３章を見てください。
3.2. The RRSIG RR Presentation Format
3.2. 資源レコード署名資源レコードの表示フォーマット
The presentation format of the RDATA portion is as follows:
資源データ部の表示フォーマットは次の通りです：
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.
種別カバーフィールドは資源レコード種別の名称で記述します。名称を知ら
ない時は、[RFC3597]の５章で記述されたＴＹＰＥ表現が使われなくてはな
りません(MUST)。
The Algorithm field value MUST be represented either as an unsigned
decimal integer or as an algorithm mnemonic, as specified in Appendix
A.1.
アルゴリズムフィールド値は符号なし１０進数整数か、付録Ａ.１で指定され
るアルゴリズム名で表さなくてはなりません(MUST)。
The Labels field value MUST be represented as an unsigned decimal
integer.
ラベルフィールド値は符号なしの１０進の整数で表さなければなりません
(MUST)。
The Original TTL field value MUST be represented as an unsigned
decimal integer.
元のTTLフィールド値は符号なし１０進整数で描かなくてはなりません(MUST)。
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:
署名期限時間と開始時間フィールド値は１９７０年１月１日の
００：００：００ＵＴＣからの秒数を示す符号なし１０進整数、あるいは
ＵＴＣでYYYYMMDDHHmmSS形式で描かなくてはなりません(MUST)：
YYYY is the year (0001-9999, but see Section 3.1.5);
YYYYは年です（0001-9999、但し、３.１.５章を見てください）；
MM is the month number (01-12);
MMは月の数です（01-12）；
DD is the day of the month (01-31);
DDは月の日です（01-31）；
HH is the hour, in 24 hour notation (00-23);
HHは、２４時間表記の時間です（00-23）；
mm is the minute (00-59); and
mmが分です（00-59）；そして
SS is the second (00-59).
SSは秒です（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フォーマットが常に正確に１４の桁であるから、
これらの２つのフォーマットを区別することが常に可能なことに注意してく
ださい。
The Key Tag field MUST be represented as an unsigned decimal integer.
鍵タグフィールドは符号なし１０進整数で描かなくてはなりません(MUST)。
The Signer's Name field value MUST be represented as a domain name.
署名者の名前フィールド値はドメイン名で描かなくてはなりません(MUST)。
The Signature field is represented as a Base64 encoding of the
signature. Whitespace is allowed within the Base64 text. See
Section 2.2.
署名フィールドは署名のベース６４コーディングで描かきます。空白スペー
スがベース６４テキストの中で許されます。２.２章を見てください。
3.3. RRSIG RR Example
3.3. 資源レコード署名資源レコードの例。
The following RRSIG RR stores the signature for the A RRset of
host.example.com:
次の資源レコード署名資源レコードは host.example.comのＡ資源レコード
集合の署名を保存します：
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= )
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.
最初の４つのフィールドは所有者名とＴＴＬとクラスと資源レコード種別
（資源レコード署名）を指定します。「Ａ」は種別カバーフィールドを指
定します。値5は署名を作るために使われたアルゴリズム（ＲＳＡ／ＳＨＡ１）
を指定します。値3は元の所有者名のラベルの数です。資源レコード署名資源
データの値86400はカバーするＡ資源レコード集合の元のＴＴＬです。
20030322173103と20030220173103はそれぞれ期限と開始の日付です。2642は
鍵タグで、example.com.は署名者の名前です。残りのテキストは署名のベー
ス６４コーディングです。
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.
資源レコード署名資源レコードの所有者名とクラスと種別カバーの組合せは、
この資源レコード署名は"host.example.com"のＡ資源レコード集合をカバー
することを示すことに注意してください。ラベル値の３はワイルドカード拡
大が使われなかったことを示します。アルゴリズムと署名者名と鍵タグは、
署名がanexample.comゾーンのＤＮＳＫＥＹ資源レコードで署名され、そのＤ
ＮＳＫＥＹ資源レコードはアルゴリズムが５で鍵タグが2642であることを示
します。
4. The NSEC Resource Record
4. ＮＳＥＣ資源レコード
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].
ＮＳＥＣ資源レコードは２つの別の物をリストアップします：正式なデータ
あるいは委任ＮＳ資源レコード集合を持つ（ゾーンの正規順での）次の所有
者名と、ＮＳＥＣ資源レコードの所有者名に存在する資源レコード種別
[RFC3845]。ゾーンのＮＳＥＣ資源レコードの全体集合は、ゾーンに存在する
正式な資源レコード集合と、ゾーンの正式な所有者名の鎖を示します。この
情報は[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.
すべてのゾーンの正式な名前がＮＳＥＣ鎖の一部であるに違いないので、Ｎ
ＳＥＣ資源レコードはＣＮＡＭＥ資源レコードを含む名前にも存在している
に違いありません。これは伝統的なＤＮＳ仕様[RFC1034]に対する変更です、
伝統的なＤＮＳ仕様は名前にＣＮＡＭＥが存在しているなら、ＣＮＡＭＥが
その名前で許される唯一の種別と述べました。資源レコード署名（３章参照）
とＮＳＥＣは署名されたゾーンでＣＮＡＭＥ資源レコードと同じ名前に存在
しなくてはなりません(MUST)。
See [RFC4035] for discussion of how a zone signer determines
precisely which NSEC RRs it has to include in a zone.
ゾーン署名者がどのＮＳＥＣ資源レコードをゾーン含めなければならないか
決定する方法の論議は[RFC4035]を見てください。
The type value for the NSEC RR is 47.
ＮＳＥＣ資源レコードの種別値は４７です。
The NSEC RR is class independent.
ＮＳＥＣ資源レコードはクラスに依存しません。
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
field. This is in the spirit of negative caching ([RFC2308]).
ＮＳＥＣ資源レコードはＳＯＡの最小ＴＴＬフィールドと同じＴＴＬ値を持
つべきです(SHOULD)。これはネガティブキャッシュの精神です（[RFC2308]）。
4.1. NSEC RDATA Wire Format
4.1. ＮＳＥＣ資源データワイヤフォーマット
The RDATA of the NSEC RR is as shown below:
ＮＳＥＣ資源レコードの資源データは下記のとおりです：
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.
次のドメインフィールドは正式なデータを持つか、あるいは委任点のＮＳ資
源レコード集合を含む（ゾーンの正規順序での）次の所有者名を含んでいま
す；正規順序は６.１章を見てください。ゾーンの中の最後のＮＳＥＣレコー
ドの次のドメイン名フィールド値はゾーン頂上の名前（地域のＳＯＡ資源レ
コードの所有者名）です。これはＮＳＥＣ資源レコードの所有者名がゾーン
の正規順序で最後の名前であることを示します。
A sender MUST NOT use DNS name compression on the Next Domain Name
field when transmitting an NSEC RR.
送信者はＮＳＥＣ資源レコードを伝達する時、次のドメイン名フィールドの
ＤＮＳ名に名前圧縮を使ってはなりません(MUST NOT)。
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.
（接着用レコードの様な）そのゾーンで正式ではない資源レコード集合の所
有者名は、その名前に対して少なくとも１つの正式な資源レコード集合が存
在しない限り、次のドメイン名でリストアップされてはなりません。
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.
種別ビットマップフィールドはＮＳＥＣ資源レコードの所有者名に存在する
資源レコード集合種別を識別します。
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.
資源レコード種別空間は２５６のウィンドウ空間に分割され、それぞれが
１６ビットの種別空間の下位８ビットを表現します。少なくともひとつの存
在する資源レコード種別を含むブロックは、１オクテットのウィンドウ番号
（0から255）と、ウィンドウブロックのビットマップの長さを示す１オク
テットのビットマップ長（1から32）と、最大３２オクテット（２５６ビッ
ト）のビットマップを使ってコード化されます。
Blocks are present in the NSEC RR RDATA in increasing numerical
order.
ブロックは数の昇順でＮＳＥＣ資源レコード資源データに存在しています。
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.
それぞれのビットマップがウィンドウブロックの資源レコード種別の下位８
ビットを、ネットワークビット順でコード化します。最初のビットはビット
０です。ウィンドウブロック０で、ビット１が資源レコード種別１（Ａ）に
対応し、ビット２が資源レコード種別２（ＮＳ）に対応し、以下同様です。
ウィンドウブロック１で、ビット１が資源レコード種別２５７に、ビット２
が資源レコード種別２５８に対応します。もしビットが設定されるなら、そ
れはその種別の資源レコード集合がＮＳＥＣ資源レコードの所有者名に対し
て存在していることを示します。もしビットが設定されていなければ、それ
はその資源レコード集合がＮＳＥＣ資源レコードの所有者名に対して存在な
い事を示します。
Bits representing pseudo-types MUST be clear, as they do not appear
in zone data. If encountered, they MUST be ignored upon being read.
擬似種別は、ゾーンデータに現われないので、対応するビットはクリアしな
ければなりません(MUST)。もし存在するなら、読む場合に無視しなければな
りません(MUST)。
Blocks with no types present MUST NOT be included. Trailing zero
octets in the bitmap MUST be omitted. The length of each block's
bitmap is determined by the type code with the largest numerical
value, within that block, among the set of RR types present at the
NSEC RR's owner name. Trailing zero octets not specified MUST be
interpreted as zero octets.
現在種別がないブロックが含まれてはなりません(MUST NOT)。ビットマップ
の中の後続するゼロのオクテットが除かれなくてはなりません(MUST)。それ
ぞれのブロックのビットマップ長は、ＮＳＥＣ資源レコードの所有者名に存
在する資源レコードで、そのブロックの中で最も大きい数値の種別コードに
よって決定されます。明示しなかった後続するゼロのオクテットは、ゼロオ
クテットと解釈されなくてはなりません(MUST)。
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.
委任点においてのＮＳＥＣ資源レコードのビットマップは特別な注意を必要
とします。委任ＮＳ資源レコード集合に対応しているビットと、親ゾーンが
正式なデータとして持つ資源レコード種別に対するビットは設定されなくて
はなりません(MUST)；親で正式ではない非ＮＳ資源レコード集合に対応して
いるビットはクリアしなければなりません(MUST)。
A zone MUST NOT include an NSEC RR for any domain name that only
holds glue records.
接着用レコードを持つだけのドメイン名に対するＮＳＥＣ資源レコードを含
んではなりません(MUST NOT)。
4.1.3. Inclusion of Wildcard Names in NSEC RDATA
4.1.3. ＮＳＥＣ資源データのワイルドカード名の包含
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.
もしワイルドカード所有者名がゾーンに現われるなら、ワイルドカードラベ
ル（"*"）は通常の文字として扱われ、そしてＮＳＥＣ資源レコードを生成す
る目的では所有者名と同じに扱われます。ワイルドカード所有者名はワイル
ドカード拡大無しで次のドメイン名フィールドに現われます。[RFC4035]が非
存在の認証でのワイルドカードの影響を記述します。
4.2. The NSEC RR Presentation Format
4.2. ＮＳＥＣ資源レコード表示フォーマット
The presentation format of the RDATA portion is as follows:
資源データ部の表示フォーマットは次の通りです：
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.
種別ビットマップフィールドは資源レコード種別の名所の列として描かれま
す。名称を知らない時は、[RFC3597]の５章で記述されたＴＹＰＥ表現を使わ
なくてはなりません(MUST)。
4.3. NSEC RR Example
4.3. ＮＳＥＣ資源レコードの例
The following NSEC RR identifies the RRsets associated with
alfa.example.com. and identifies the next authoritative name after
alfa.example.com.
次のＮＳＥＣ資源レコードはalfa.example.com.と結び付けられた資源レコー
ド集合を識別して、そしてalfa.example.comの後に次の正式な名前を識別し
ます。
alfa.example.com. 86400 IN NSEC host.example.com. (
A MX RRSIG NSEC TYPE1234 )
The first four text fields specify the name, TTL, Class, and RR type
(NSEC). The entry host.example.com. is the next authoritative name
after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
and TYPE1234 RRsets associated with the name alfa.example.com.
最初の４つのテキストフィールドは名前とＴＴＬとクラスと資源レコード
種別（ＮＳＥＣ）を指定します。host.example.com.は正規順での
alfa.example.com.の後に次の正式な名前です。AとMXとRRSIGとNSECと
TYPE1234の名称は、alfa.example.com.の名前に関して、アドレスとメール
交換と資源レコード署名とＮＳＥＣと種別１２３４の資源レコードがあるこ
とを示します。
The RDATA section of the NSEC RR above would be encoded as:
上記のＮＳＥＣ資源レコードの資源データ部は以下の様にコード化されます：。
0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20
Assuming that the validator can authenticate this NSEC record, it
could be used to prove that beta.example.com does not exist, or to
prove that there is no AAAA record associated with alfa.example.com.
Authenticated denial of existence is discussed in [RFC4035].
検証者がこのＮＳＥＣレコードを本物と証明することができると想定すると、
これはbeta.example.comが存在しないことを証明するや、alfa.example.com
と結び付いたAAAAレコードがないことを証明するために使うことができます。
非存在の認証が[RFC4035]で論じられます。
5. The DS Resource Record
5. 委任署名資源レコード
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].
委任署名資源レコードはＤＮＳＫＥＹ資源レコードを示し、そしてＤＮＳの
ＤＮＳＫＥＹ認証プロセスで使われます。委任署名資源レコードは鍵タグと
アルゴリズム番号とＤＮＳＫＥＹ資源レコードのダイジェストを保存する事
でＤＮＳＫＥＹ資源レコードを示します。ダイジェストが公開鍵を識別する
のに十分であるが、鍵タグと鍵アルゴリズムを保存することが身分証明書プ
ロセスをより効率的にするのに役立つことに注意してください。委任署名レ
コードを本物と証明することによって、リゾルバが委任署名レコードが示す
ＤＮＳＫＥＹ資源レコードを認証することができます。鍵認証プロセスは
[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
"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"の委任署名資源レコードは"example.com"ゾーン（子ゾー
ン）ではなく"com"ゾーン（親ゾーン）に保存されます。対応するＤＮＳＫ
ＥＹ資源レコードは"example.com"ゾーン（子ゾーン）に保存されます。これ
はＤＮＳゾーン管理とゾーン署名を単純化しますが、委任署名資源レコード
のための特別な回答処理必要条件を導入します；これらは[RFC4035]で記述さ
れます。
The type number for the DS record is 43.
委任署名レコードの種別番号は４３です。
The DS resource record is class independent.
委任署名資源レコードはクラスに依存しません。
The DS RR has no special TTL requirements.
委任署名資源レコードは特別なＴＴＬ条件がありません。
5.1. DS RDATA Wire Format
5.1. 委任署名資源データワイヤフォーマット
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.
委任署名資源レコードの資源データは２オクテット鍵タグフィールドと１オ
クテットのアルゴリズムフィールドと１オクテットびダイジェスト種別
フィールドとダイジェストフィールドから成り立ちます。
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 /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
鍵タグフィールドはネットワークバイト順で委任署名レコードによって参照
された、ＤＮＳＫＥＹ資源レコードの鍵タグをリストアップします。
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.
委任署名資源レコードによって使われた鍵タグは資源レコード署名資源レコー
ドによって使われた鍵タグとまったく同じです。付録Ｂが鍵タグを計算する
方法を記述します。
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.
アルゴリズムフィールドは委任署名レコードが参照したＤＮＳＫＥＹ資源レ
コードのアルゴリズムの番号をリストアップします。
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.
委任署名資源レコードによって使ったアルゴリズム番号は、資源レコード署
名とＤＮＳＫＥＹ資源レコードで使われたアルゴリズム番号とまったく同じ
です。付録Ａ.１がアルゴリズム番号種別をリストアップします。
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.
委任署名資源レコードはそのＤＮＳＫＥＹ資源レコードのダイジェストを含
むことによってＤＮＳＫＥＹ資源レコードを指定します。ダイジェスト種別
フィールドはダイジェストを組み立てるために使われたアルゴリズムを識別
します。付録Ａ.２が可能なダイジェストアルゴリズム種別をリストアップ
します。
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.
委任署名レコードはそのＤＮＳＫＥＹ資源レコードのダイジェストを含むこ
とによってＤＮＳＫＥＹ資源レコードを指定します。
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.
ダイジェストは、ＤＮＳＫＥＹ資源レコードの完全指定所有者名の正規形式
とＤＮＳＫＥＹ資源データを連結し、ダイジェストアルゴリズムを適用する
ことによって計算されます。
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
"|" denotes concatenation
"|"は結合を示します
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
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.
ダイジェストの大きさはダイジェストアルゴリズムとＤＮＳＫＥＹ資源レコー
ドの大きさによって変化するかもしれません。この著作物時点で、唯一の定
義されたダイジェストアルゴリズムはＳＨＡ−1で、これは２０オクテットダ
イジェストを作り出します。
5.2. Processing of DS RRs When Validating Responses
5.2. 回答検証での委任署名資源レコード処理
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.
委任署名資源レコードはゾーン境界の向こう側に認証鎖をつなぎます、それ
で委任署名資源レコードは処理で十分な注意を必要とします。委任署名資源
レコードで指定されたＤＮＳＫＥＹ資源レコードはＤＮＳＳＥＣゾーンの鍵
に違いありません(MUST)。ＤＮＳＫＥＹ資源レコード旗はビット７が設定さ
れたフラグを持っていなくてはなりません(MUST)。もしＤＮＳＫＥＹフラグ
がＤＮＳＳＥＣゾーン鍵を示さないなら、委任署名資源レコード（とそれが
参照するＤＮＳＫＥＹ資源レコード）は承認プロセスで使われてはなりませ
ん(MUST NOT)。
5.3. The DS RR Presentation Format
5.3. 委任署名資源レコード表示フォーマット。
The presentation format of the RDATA portion is as follows:
資源データ部の表示フォーマットは次の通りです：
The Key Tag field MUST be represented as an unsigned decimal integer.
鍵タグフィールドは符号なしの１０進整数として描かれなくてはなりません
(MUST)。
The Algorithm field MUST be represented either as an unsigned decimal
integer or as an algorithm mnemonic specified in Appendix A.1.
アルゴリズムフィールドは符号なしの１０進整数か、アルゴリズムが付録
Ａ.１で指定した名前で表されなくてはなりません(MUST)。
The Digest Type field MUST be represented as an unsigned decimal
integer.
ダイジェスト種別フィールドは符号なしの１０進整数で描かれなくてはなり
ません(MUST)。
The Digest MUST be represented as a sequence of case-insensitive
hexadecimal digits. Whitespace is allowed within the hexadecimal
text.
ダイジェストは大文字小文字の違いを無視する１６進数列で描かれなくては
なりません(MUST)。空白スペースが１６進テキストの中で許されます。
5.4. DS RR Example
5.4. 委任署名資源レコードの例
The following example shows a DNSKEY RR and its corresponding 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 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.
最初の４つのテキストフィールドは名前とＴＴＬとクラスと資源レコード
種別（ＤＳ）を指定します。値60485 は対応する"dskey.example.com."
ＤＮＳＫＥＹ資源レコード の鍵タグで、値5はこの"dskey.example.com."
ＤＮＳＫＥＹ資源レコード で使われたアルゴリズムを示します。値1はダイ
ジェストを組み立てるために使われるアルゴリズムで、資源データテキスト
の残りが１６進のダイジェストです。
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.
この章は資源レコードとＤＮＳ名の正規順序と資源レコード集合の資源レコー
ドの正規順序のための正規形式を定義します。正規名前順序はＮＳＥＣ名前
鎖を作るのに必要です。正規資源レコード形式と資源レコード集合の中の正
規順序が資源レコード署名資源レコードを作って検証するために必要です。
6.1. Canonical DNS Name Order
6.1. 正規ＤＮＳ名前順序
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.
ＤＮＳセキュリティの目的で、所有者名は個別のラベルを、符号なしの左揃
えのオクテット列と取り扱うことで順序づけられています。ゼロ値オクテッ
トの前のオクテット種別を無視し、大文字のＵＳ−ＡＳＣＩＩ文字は小文字
のＵＳ−ＡＳＣＩＩ文字と扱います。
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.
ＤＮＳ名集合の正規順序を計算するために、最上位（最右）ラベルに従って
名前を並べ替えることから始めます。最上位ラベルが同一である名前では、
次の最上位ラベルによって並べ替え、以下同様です。
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.
例えば、次の名前は正規ＤＮＳ名の順序で並べ替えされています。最上位ラ
ベルは"example"です。このレベルにおいて、"example"で最初で、
"a.example"で終わる名前が次で、最後に"a.example"で終わる名前が来ます。
それぞれのラベルの名前は同じように分類されます。
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
\001.z.example
*.z.example
\200.z.example
6.2. Canonical RR Form
6.2. 正規資源レコード形式
For the purposes of DNS security, the canonical form of an RR is the
wire format of the RR where:
ＤＮＳセキュリティの目的で、資源レコードの正規形式は資源レコードのワ
イヤフォーマットです：
1. every domain name in the RR is fully expanded (no DNS name
compression) and fully qualified;
1. すべての資源レコードのドメイン名が完全に拡大され（ＤＮＳ名前圧縮
をしていない）、そして完全に指定されています；
2. all uppercase US-ASCII letters in the owner name of the RR are
replaced by the corresponding lowercase US-ASCII letters;
2. すべての資源レコードの所有者名の大文字のＵＳ−ＡＳＣＩＩ文字は、
対応する小文字で置き換えられます；
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. もし資源レコード種別が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であるなら、すべての資源データの中にあ
るＤＮＳ名の大文字のＵＳ−ＡＳＣＩＩ文字は、対応する小文字で置き
換えられます；
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. もし資源レコードの所有者名がワイルドカード名であるなら、所有者名
は "*"ラベル（ワイルドカード代用）を含めて、元の非拡張形式にしま
す；そして
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. 資源レコードのＴＴＬは、元の正式ゾーンの現われるか元の値か、カバー
する資源レコード署名資源レコードの元のＴＴＬフィールドに現われる
元の値を設定します。
6.3. Canonical RR Ordering within an RRset
6.3. 資源レコード集合の正規資源レコード順序
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.
ＤＮＳセキュリティの目的で、同じ所有者名とクラスと種類の資源レコード
は、それぞれの資源レコードの資源データ部の正規形式を、左揃えされた符
号なしのオクテット列として並べ替えます。
[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]が資源レコード集合が重複レコード（同じ所有者名とクラスと種別
と資源データの複数の資源レコード）を含むことを許されないことを明示し
ます。それ故に、もし実装が資源レコード集合を正規形にする際に重複資源
レコードを発見するなら、これをプロトコルエラーとして取り扱わなくては
なりません(MUST)。もし実行が強靭性の原則の精神でこのプロトコルエラー
を処理することに決めるなら（受け入を寛大にするなら）、資源レコード集
合の正規形式を計算する目的で、重複資源レコードを１つを残して他を削除
しなければなりません(MUST)。
7. IANA Considerations
7. ＩＡＮＡの考慮
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.
この文書は、この文書で使われたプロトコルパラメータのすべてがすでに前
の仕様書によって割り当てられたので、新しいＩＡＮＡの考慮を紹介しませ
ん。しかしながら、ＤＮＳＳＥＣの進展が長期で幾分複雑であったので、こ
の章はＩＡＮＡ登記所の現在の状態と、ＤＮＳＳＥＣに関連している（ある
いは関連していた）他のプロトコルパラメータを記述しようと試みます。
Please refer to [RFC4035] for additional IANA considerations.
どうか追加のＩＡＮＡ考慮として[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].
ＤＮＳ資源レコード種別：[RFC2535]がＳＩＧとＫＥＹとＮＸＴ資源レコード
に、それぞれ種別２４と２５と３０を割り当てました。[RFC3658]が委任
署名にＤＮＳ資源レコードタイプ４３を割り当てました。[RFC3755]が資
源レコード署名とＮＳＥＣとＤＮＳＫＥＹ資源レコードに、それぞれ種別
４６と４７と４８を割り当てました。[RFC3755]はまた種別３０（ＮＸＴ）
を時代遅れにし、種別２４（ＳＩＧ）と種別２５（ＫＥＹ）の使い方を、
[RFC2931]で記述される"SIG(0)"処理署名プロトコルと、[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.
ＤＮＳセキュリティアルゴリズム番号：[RFC2535]がＤＮＳＳＥＣ資源レコー
ドアルゴリズムフィールドの番号のためにＩＡＮＡ登記所を作り、値の１
から４と２５２から２５５を割り当てました。[RFC3110]が値５を割り当
てました。[RFC3755]がそれぞれの項目にＤＮＳセキュリティ拡張の使用
に関するフラグを含める様にこのレジストリを変更しました。それぞれの
アルゴリズム項目は、ゾーン署名か処理セキュリティか両方で使えるアル
ゴリズムに関係できます（[RFC2931]参照）。値６−２５１はＩＥＴＦ標
準行動による割当てで利用可能です（[RFC3755]）。この著作時点でのＤ
ＮＳＳＥＣのＤＮＳセキュリティアルゴリズム番号項目と状態の全リスト
は付録Ａを見てください。
[RFC3658] created an IANA registry for DNSSEC DS Digest Types and
assigned value 0 to reserved and value 1 to SHA-1.
[RFC3658]はＤＮＳＳＥＣ委任署名ダイジェスト種別のためにＩＡＮＡ登
記所を作り、そして値０を予約に、値１にＳＨＡ−１を割り当てました。
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]が鍵プロトコル値のためのＩＡＮＡ登記所を作り
ましたが、[RFC3445]が３以外の値を予約とし、このＩＡＮＡ登記所を閉
じました。登記所は閉じられたままで、そしてすべての鍵とＤＮＳＫＥ
Ｙレコードは３のプロトコルオクテット値を持つように要求されます。
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.
鍵とＤＮＳＫＥＹ資源レコードのフラグビット：[RFC3755]はＤＮＳＳＥＣ
の鍵とＤＮＳＫＥＹ資源レコードのフラグビットのＩＡＮＡ登記所を作
りました。初めに、この登記所はビット７（ゾーンビット）とビット
１５（セキュリティ入口点（ＳＥＰ）；[RFC3757]参照）フラグを割当て
ただけです。[RFC3755]で述べられるように、ビット０−６と８−１４は
ＩＥＴＦ標準化行動によって割当て利用可能です。
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.
この文書はＤＮＳセキュリティ拡張で使われた４つのＤＮＳ資源レコードの
フォーマットを記述し、そして公開鍵の鍵タグを計算するアルゴリズムを提
出します。下に記述された項目以外、資源レコード自身はセキュリティの考
慮を紹介しません。これらのレコードの使用と関係がある追加の保セキュリ
ティの考慮は[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.
委任署名レコードは暗号のダイジェストと鍵アルゴリズムタイプと鍵タグを
使うことによってＤＮＳＫＥＹ資源レコードを指し示します。委任署名レコー
ドは既存のＤＮＳＫＥＹ資源レコードを識別する事を意図しますが、攻撃者
がすべての委任署名フィールドと一致するＤＮＳＫＥＹを生成することは理
論的に可能です。一致するＤＮＳＫＥＹを生成する可能性は使用中のダイジェ
ストアルゴリズム種別に依存します。唯一の現在定義されたダイジェストア
ルゴリズムはＳＨＡ−１で、そして作業班はＳＨＡ−１を使えば、委任署名
レコードで与えられたアルゴリズムと鍵タグとダイジェストが一致する公開
鍵を生成するのは、このような攻撃が現時点で重大な脅威にはならないのに
十分なだけ、難しい問題と考えます。
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.
鍵タグは効率的にＤＮＳＫＥＹ資源レコードを効率的に探すために使われま
すが、一意に１つのＤＮＳＫＥＹ資源レコードを識別しません。２つの別の
ＤＮＳＫＥＹ資源レコードが同じ所有者名と同じアルゴリズムタイプと同じ
鍵タグを持つことは可能です。ＤＮＳＫＥＹ資源レコードを選ぶためにただ
鍵タグだけを使う実装はある状況で間違った公開鍵を選ぶかもしれません。
詳細は付録Ｂを見てください。
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].
付録Ａのアルゴリズムの表と付録Ｂの鍵タグ計算アルゴリズムは完全性のた
めにＲＳＡ／ＭＤ５アルゴリズムを含みますが、ＲＳＡ／ＭＤ５アルゴリズ
ムは[RFC3110]で説明したように、勧められません(NOT RECOMMENDED)。
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.
この文書はＤＮＳ拡張作業班と作業班メーリングリストのメンバーのインプッ
トと考えから作られました。編集者はセキュリティ拡張仕様書の修正の間に
彼らのコメントと提案に感謝します。ＤＮＳＳＥＣの今までの１０年の開発
期間に貢献した全員を明示的にリストアップすることは不可能であるでしょ
うが、[RFC4033]はこれらの文書についてコメントするのに十分親切であっ
た関係者のあるリストを含みます。
10. References
10. 参考文献
10.1. Normative References
10.1. 参照する参考文献
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
System (DNS)", RFC 2536, March 1999.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000.
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 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.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
10.2. Informative References
10.2. 有益な参考文献
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
Name System (DNS)", RFC 2537, March 1999.
[RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
RDATA Format", RFC 3845, August 2004.
Appendix A. DNSSEC Algorithm and Digest Types
付録Ａ． ＤＮＳＳＥＣアルゴリズムとダイジェストタイプ
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.
ＤＮＳセキュリティ拡張は基礎をなす暗号のアルゴリズムに依存しないよう
意図されます。ＤＮＳＫＥＹと資源レコード署名と委任署名の資源レコード
は資源レコードで使用中の暗号のアルゴリズムを識別するためにすべてＤＮ
ＳＳＥＣアルゴリズム番号を使います。委任署名資源レコードは委任署名レ
コードを組み立てるためのダイジェストアルゴリズムを識別するためにダイ
ジェストアルゴリズム番号を指定します。現在定義されたアルゴリズムとダ
イジェスト種別は下にリストアップされます。追加のアルゴリズムやダイジェ
スト種別は、暗号での進歩でそれらが正当化される時、追加できます。
A DNSSEC aware resolver or name server MUST implement all MANDATORY
algorithms.
ＤＮＳＳＥＣの認識があるリゾルバやネームサーバはすべての義務
(MANDATORY)アルゴリズムを実装しなくてはなりません(MUST)。
A.1. DNSSEC Algorithm Types
A.1. ＤＮＳＳＥＣアルゴリズム種別
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.
ＤＮＳＫＥＹと資源レコード署名と委任署名資源レコードは使われているセ
キュリティアルゴリズムを識別するために８ビットの番号を使います。これ
らの値は資源レコードと資源データの「アルゴリズム番号」フィールドに保
存されます。
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].
あるアルゴリズムがゾーン署名（ＤＮＳＳＥＣ）だけに有用で、あるものは
処理セキュリティメカニズム（ＳＩＧ（０）とＴＳＩＧ）だけに有用で、そ
してあるものは両方で有用です。ゾーン署名に有用なのはＤＮＳＫＥＹと資
源レコード署名と委任署名資源レコードに現われるかもしれません。処理セ
キュリティに有用のは、[RFC2931]で記述されるように、ＳＩＧ（０）と鍵資
源レコードで存在するでしょう。
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.
ＩＥＴＦ標準化行動によって割当可能
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.
アルゴリズム番号２５３が私的使用のために確保され、そして決して特定の
アルゴリズムに割り当てられないでしょう。ＤＮＳＫＥＹ資源レコードの公
開鍵エリアと資源レコード署名資源レコードの署名エリアはワイヤコードさ
れたドメイン名から始まり、圧縮されてはなりません。ドメイン名は使うべ
き私的アルゴリズムを示します、そして公開鍵エリアの残りがそのアルゴリ
ズムによって決定されます。エンティティは私的アルゴリズムの指定の制御
にだけドメイン名を使うべきです。
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.
アルゴリズム番号２５４が私的使用のために確保されて、決して特定のアル
ゴリズムに割り当てられないでしょう。ＤＮＳＫＥＹ資源レコードの中の公
開鍵エリアと資源レコード署名資源レコードの中の署名エリアは、符号なし
の長さバイトから始まり、その長さのＢＥＲでコードされたオブジェクト識
別子（ＩＳＯ ＯＩＤ）が続きます。ＯＩＤは使用中の私的アルゴリズムを示
します、そしてその区域の残りがそのアルゴリズムによって必要とされる何
かです。エンティティーは私的アルゴリズムの指名の制御にだけＯＩＤを使
うべきです。
A.2. DNSSEC Digest Types
A.2. ＤＮＳＳＥＣダイジェスト種別
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.
委任署名資源レコード種別の「ダイジェスト種別」フィールドは、資源レコー
ドで使われた暗号ダイジェストアルゴリズムを指定します。次の表は現在定
義されたダイジェストアルゴリズム種別をリストアップします。
VALUE Algorithm STATUS
値 アルゴリズム 状態
0 Reserved -
1 SHA-1 MANDATORY 必須実装
2-255 Unassigned -
Appendix B. Key Tag Calculation
付録Ｂ． 鍵タグ計算
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.
資源レコード署名と委任署名資源レコード種別の鍵タグフィールドは効率的
に公開鍵を選ぶメカニズムを供給します。たいていの場合、所有者名とアル
ゴリズムと鍵タグの組合せで効率的にＤＮＳＫＥＹレコードを識別すること
ができます。資源レコード署名と委任署名資源レコードの両方が対応するＤ
ＮＳＫＥＹレコードを持っています。資源レコード署名と委任署名レコード
の鍵タグフィールドは、複数のＤＮＳＫＥＹ資源レコードが存在する時、効
率的に対応するＤＮＳＫＥＹ資源レコードを選択するのに役立つために使う
ことができます。
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.
しかしながら、鍵タグが一意に識別するのではないことを指摘することは不
可欠です。２つの別のＤＮＳＫＥＹ資源レコードが同じ所有者名と同じアル
ゴリズムと同じ鍵タグを持つことは理論的に可能です。鍵タグは候補の鍵を
制限するために使われますが、一意にＤＮＳＫＥＹレコードを識別しません。
実装は鍵タグが一意にＤＮＳＫＥＹ資源レコードを識別すると想定してはな
りません(MUST NOT)。
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.
鍵タグはアルゴリズム１を除き全てＤＮＳＫＥＹアルゴリズム種別と同じで
す（アルゴリズム１の鍵タグの定義のために付録Ｂ.１を見てください）。鍵
タグアルゴリズムはＤＮＳＫＥＹ資源データのワイヤフォーマットを２オク
テットグループに分割して合計したものです。最初に、（ワイヤフォーマッ
トの）資源データを２オクテットの列と扱います。これらのグループは、桁
上がりビットを無視して、加算します。
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.
鍵タグアルゴリズムの実装の参照として、ＤＮＳＫＥＹ資源レコードの資源
データ部を入力とする、ＡＮＳＩのC関数を以下に示します。以下の参照コー
ドをそのまま使う必要はありませんが、しかし同じ入力に対する鍵タグの数
値は、参照実装が生成するものとまったく同じであるに違いありません(MUST)。
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.
鍵タグを計算するためのアルゴリズムが、多くの他のインターネット・プロ
トコルで使われるよく知られている１の補数の合計とほとんど同じであるこ
とを指摘してます。鍵タグは１の補数の合計ではなく、ここで記述されたア
ルゴリズムを使って計算されているに違いありません(MUST)。
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.
次のＡＮＳＩのＣ参照実装は鍵タグの値を計算します。この参照実装はアル
ゴリズム１以外すべてのアルゴリズム種別に当てはまります（付録Ｂ.１参
照）。入力はＤＮＳＫＥＹ資源レコードのの資源データ部のワイヤフォー
マットです。コードは、効率より、わかりやすさのために書かれます。
/*
* 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が少なくとも１６ビットであると想定します。
* 鍵タグの最初のオクテットは返された値の最上位８ビットです；
* 鍵タグの２番目のオクテットは返された値の最下位８ビットです。
*/
unsigned int
keytag (
unsigned char key[], /* the RDATA part of the DNSKEY RR */
unsigned int keysize /* the RDLENGTH */
)
{
unsigned long ac; /* assumed to be 32 bits or larger */
int i; /* loop index */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i & 1) ? key[i] : key[i] << 8;
ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}
B.1. Key Tag for Algorithm 1 (RSA/MD5)
B.1. アルゴリズム１（ＲＳＡ／ＭＤ５）のための鍵タグ
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).
アルゴリズム１のための鍵タグ（ＲＳＡ／ＭＤ５）は歴史的理由で他のアル
ゴリズムの鍵タグと違って定義されます。ＤＮＳＫＥＹ資源レコードのアル
ゴリズム１で、鍵タグは公開鍵モジュラスの下位２４ビットの上位１６ビッ
ト（換言すれば、公開鍵モジュラスの最後から４番目と３番目のオクテット）
と定義されます。
Please note that Algorithm 1 is NOT RECOMMENDED.
アルゴリズム１が推薦されていないことを指摘します。
Authors' Addresses
著者のアドレス
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
EMail: sra@isc.org
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
EMail: massey@cs.colostate.edu
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov
Full Copyright Statement
著作権表示全文
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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。