RFC3658 委任署名者（ＤＳ）資源レコード（ＲＲ）

この文書はRFC3658の日本語訳（和訳）です。この文書の翻訳内容の正確さは保障できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の配布は元のＲＦＣ同様に無制限です。

Network Working Group O. Gudmundsson
Request for Comments: 3658 December 2003
Updates: 3090, 3008, 2535, 1035
Category: Standards Track

Delegation Signer (DS) Resource Record (RR)
委任署名者（ＤＳ）資源レコード（ＲＲ）

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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。

Abstract
要約

The delegation signer (DS) resource record (RR) is inserted at a zone
cut (i.e., a delegation point) to indicate that the delegated zone is
digitally signed and that the delegated zone recognizes the indicated
key as a valid zone key for the delegated zone. The DS RR is a
modification to the DNS Security Extensions definition, motivated by
operational considerations. The intent is to use this resource
record as an explicit statement about the delegation, rather than
relying on inference.
委任署名者（ＤＳ）資源レコード（ＲＲ）は、委任されたゾーンがデジタル
で署名され、そして委任されたゾーンが委任されたゾーンに示された鍵を正
当なゾーン鍵と認知することを示すために、ゾーンカット（すなわち、委任
点）に差し込まれます。ＤＳ ＲＲはＤＮＳセキュリティ拡張の定義の、運用
上の考慮によって起きた、修正です。この資源レコードを使う意図は、推論
に頼るよりも、明白な宣言を用いる事です。

This document defines the DS RR, gives examples of how it is used and
describes the implications on resolvers. This change is not
backwards compatible with RFC 2535. This document updates RFC 1035,
RFC 2535, RFC 3008 and RFC 3090.
この文書はＤＳ ＲＲを定義し、これが使われる方法の例を与え、そしてリゾ
ルバでの意味を記述します。この変更はＲＦＣ２５３５と後方互換性があり
ません。この文書はＲＦＣ１０３５とＲＦＣ２５３５とＲＦＣ３００８と
ＲＦＣ３０９０を更新します。

Table of Contents
目次

1. Introduction
1. はじめに
1.2. Reserved Words
1.2. 予約語
2. Specification of the Delegation key Signer
2. 委任鍵署名の仕様
2.1. Delegation Signer Record Model
2.1. 委任署名者レコードモデル
2.2. Protocol Change
2.2. プロトコル変更
2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations
at Delegation Points
2.2.1. ＲＦＣ２５３５ ２.３.４章と３.４章：
委任点の特別な考慮
2.2.1.1. Special processing for DS queries
2.2.1.1. ＤＳ問合せの特別な処理
2.2.1.2. Special processing when child and an
ancestor share nameserver
2.2.1.2. 子と先祖がネームサーバを共有する
特別な処理
2.2.1.3. Modification on use of KEY RR in the
construction of Responses
2.2.1.3. 応答構築での鍵資源レコード使用の修正
2.2.2. Signer's Name (replaces RFC 3008 section 2.7)
2.2.2. 署名者名（ＲＦＣ３００８の２.７章の置き換え）
2.2.3. Changes to RFC 3090
2.2.3. ＲＦＣ３０９０に対する変更
2.2.3.1. RFC 3090: Updates to section 1:
Introduction
2.2.3.1. ＲＦＣ３０９０：１章：はじめに、
の更新
2.2.3.2. RFC 3090 section 2.1: Globally
Secured
2.2.3.2. ＲＦＣ３０９０の２.１章：
広域安全
2.2.3.3. RFC 3090 section 3: Experimental
Status.
2.2.3.3. ＲＦＣ３０９０の３章：実験的状態
2.2.4. NULL KEY elimination
2.2.4. 空鍵除去
2.3. Comments on Protocol Changes
2.3. プロトコル変更についてのコメント
2.4. Wire Format of the DS record
2.4. ＤＳレコードのフォーマット
2.4.1. Justifications for Fields
2.4.1. フィールドの正当化
2.5. Presentation Format of the DS Record
2.5. ＤＳレコードの表現形式
2.6. Transition Issues for Installed Base
2.6. 既存の移行問題
2.6.1. Backwards compatibility with RFC 2535 and
RFC 1035
2.6.1. ＲＦＣ２５３５とＲＦＣ１０３５との後方互換性
2.7. KEY and corresponding DS record example
2.7. 鍵と対応するＤＳレコード例
3. Resolver
3. リゾルバ
3.1. DS Example
3.1. ＤＳ例
3.2. Resolver Cost Estimates for DS Records
3.2. ＤＳレコードのためのリゾルバコスト見積り
4. Security Considerations
4. セキュリティの考察
5. IANA Considerations
5. ＩＡＮＡの考慮
6. Intellectual Property Statement
6. 知的所有権宣言
7. Acknowledgments
7. 謝辞
8. References
8. 参考文献
8.1. Normative References
8.1. 参照する参考文献

8.2. Informational References
8.2. 有益な参考文献

9. Author's Address
9. 著者のアドレス
10. Full Copyright Statement
10. 著作権表示全文

1. Introduction
1. はじめに

Familiarity with the DNS system [RFC1035], DNS security extensions
[RFC2535], and DNSSEC terminology [RFC3090] is important.
ＤＮＳシステム[RFC1035]とＤＮＳセキュリティ拡張[RFC2535]とＤＮＳＳＥ
Ｃ用語[RFC3090]の精通は重要です。

Experience shows that when the same data can reside in two
administratively different DNS zones, the data frequently gets out of
sync. The presence of an NS RRset in a zone anywhere other than at
the apex indicates a zone cut or delegation. The RDATA of the NS
RRset specifies the authoritative nameservers for the delegated or
"child" zone. Based on actual measurements, 10-30% of all
delegations on the Internet have differing NS RRsets at parent and
child. There are a number of reasons for this, including a lack of
communication between parent and child and bogus name servers being
listed to meet registry requirements.
経験的に、同じデータが２つの管理が異なるＤＮＳゾーンに存在する時、デー
タがしばしば同期しないことを示します。ゾーンの頂上以外にあるＮＳ資源
レコード集合はゾーンカットか委任を示します。ＮＳ資源レコード集合の資
源データは委任された人の正式ネームサーバや「子」ゾーンを指定します。
実際の測定によると、すべてのインターネット上の委任の１０～３０％で、
親と子が異なるＮＳ資源レコード集合を持ちます。親と子の連絡不足や、レ
ジストリ要求条件を満たすためにダミーのネームサーバを登録するなど、こ
れには様々な理由があります。

DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs
to have its KEY RRset signed by its parent to create a verifiable
chain of KEYs. There has been some debate on where the signed KEY
RRset should reside, whether at the child [RFC2535] or at the parent.
If the KEY RRset resides at the child, maintaining the signed KEY
RRset in the child requires frequent two-way communication between
the two parties. First, the child transmits the KEY RRset to the
parent and then the parent sends the signature(s) to the child.
Storing the KEY RRset at the parent was thought to simplify the
communication.
ＤＮＳＳＥＣ[RFC2535, RFC3008, RFC3090]は、鍵の証明可能な鎖を作るため
に、子供ゾーンが親によって署名された鍵資源レコード集合を持つ必要があ
ることを明示します。署名された鍵資源レコード集合が、子にあるべきか
[RFC2535]、親にあるべきか、の討論がありました。もし鍵資源レコード集合
が子にあるなら、子の署名された鍵資源レコード集合を維持するには、２者
間の頻繁な両方向の連絡を必要とします。最初に、子は親に鍵資源レコード
集合を渡し、次に親は子に署名を送ります。鍵資源レコード集合を親にしま
えば、連絡を単純化できると思われました。

DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
an unsecure child zone to indicate that the child is unsecure. A
NULL KEY record is a waste: an entire signed RRset is used to
communicate effectively one bit of information - that the child is
unsecure. Chasing down NULL KEY RRsets complicates the resolution
process in many cases, because nameservers for both parent and child
need to be queried for the KEY RRset if the child nameserver does not
return it. Storing the KEY RRset only in the parent zone simplifies
this and would allow the elimination of the NULL KEY RRsets entirely.
For large delegation zones, the cost of NULL keys is a significant
barrier to deployment.
ＤＮＳＳＥＣ[RFC2535]は安全でない子ゾーンが安全でない事を示すために親
が空の鍵レコードをしまっておくことを要求します。空の鍵レコードは無意
味です：全部の署名された資源レコード集合は、子が安全でないといｙ、１
ビット情報を伝えるために使われます。これは子が鍵資源レコード集合を返
さなければ、親と子の両方に鍵資源レコード集合の問合せが必要なので、下
方向きに空の鍵資源レコード集合を追うのは解決処理を複雑にします。親ゾー
ン地域でだ鍵資源レコード集合を保管すれば、これを単純化され、そして完
全に空の鍵資源レコード集合の除去を許すでしょう。大きい委任ゾーンで、
空の鍵のコストは重要な障壁です。

Prior to the restrictions imposed by RFC 3445 [RFC3445], another
implication of the DNSSEC key model is that the KEY record could be
used to store public keys for other protocols in addition to DNSSEC
keys. There are a number of potential problems with this, including:
ＲＦＣ３４４５[RFC3445]で課された制限の前に、ＤＮＳＳＥＣ鍵モデルは、
ＤＮＳＳＥＣ鍵以外のプロトコルの公開鍵を保存するために、鍵レコードが
が使えるとほのめかします。これは、下記を含む、多くの問題の可能性があ
ります：

1. The KEY RRset can become quite large if many applications and
protocols store their keys at the zone apex. Possible protocols
are IPSEC, HTTP, SMTP, SSH and others that use public key
cryptography.
1. もし多くのアプリケーションとプロトコルが鍵をゾーン頂上にしまうなら、
鍵資源レコード集合は非常に大きくなります。可能なプロトコルはＩＰｓ
ｅｃやＨＴＴＰやＳＭＴＰやＳＳＨやその他の公開鍵暗号を使うものです。

2. The KEY RRset may require frequent updates.
2. 鍵資源レコード集合は頻繁な更新を必要とするかもしれません。

3. The probability of compromised or lost keys, which trigger
emergency key roll-over procedures, increases.
3. 鍵が盗まれたか紛失したかで、緊急鍵交換手順が起こる可能性は増加しま
す。

4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
keys.
4. 親はＤＮＳＳＥＣゾーン鍵以外を含む鍵資源レコード集合の署名を拒否す
るかもしれません。

5. The parent may not meet the child's expectations of turnaround
time for resigning the KEY RRset.
5. 親は鍵資源レコード集合の再署名に対して、子の期待する応答時間を満た
さないかもしれません。

Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
これらの理由で、署名が親にあるのは、署名と鍵が子にあるよりよくありま
せん。

1.2. Reserved Words
1.2. 予約語

The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED",
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in BCP 14, RFC 2119 [RFC2119].
この文書のキーワード"MAY"と"MAY NOT"と"MUST"と"MUST NOT"と"REQUIRED"
と"RECOMMENDED"と"SHOULD"と"SHOULD NOT"ははＢＣＰ１４、ＲＦＣ２１１９
[RFC 2119]で記述されるように解釈されるはずです。

2. Specification of the Delegation key Signer
2. 委任鍵署名の仕様

This section defines the Delegation Signer (DS) RR type (type code
43) and the changes to DNS to accommodate it.
この章は委任署名者（ＤＳ）資源レコードタイプ（タイプコード４３）と、
これを受け入れるためのＤＮＳの変更を定義します。

2.1. Delegation Signer Record Model
2.1. 委任署名者レコードモデル

This document presents a replacement for the DNSSEC KEY record chain
of trust [RFC2535] that uses a new RR that resides only at the
parent. This record identifies the key(s) that the child uses to
self-sign its own KEY RRset.
この文書は親にだけ存在する新しい資源レコードを使うような、ＤＮＳ鍵レ
コードの信頼連鎖[RFC2535]の変更を示します。このレコードは子が自分の
鍵資源レコード集合に自分で署名するために使う鍵を示します。

Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
and Zone Signing Key (ZSK), there is no requirement that zone uses
two different keys for these roles. It is expected that many small
zones will only use one key, while larger zones will be more likely
to use multiple keys.
ＤＳには鍵署名鍵（ＫＳＫ）と、ゾーン署名鍵（ＺＳＫ）の、２つの鍵の役
割がありますが、ゾーンがこれらの役割のために２つの異なる鍵を使う必要
条件はありません。多くの小さいゾーンは１つの鍵だけを使うと思われ、他
方より大きいゾーンは多数の鍵を使う可能性が高いでしょう。

The chain of trust is now established by verifying the parent KEY
RRset, the DS RRset from the parent and the KEY RRset at the child.
This is cryptographically equivalent to using just KEY records.
信頼連鎖は、親の鍵資源レコード集を検証し、親からのＤＳ資源レコード集
合を検証し、子の鍵資源レコード集合を検証することで確立します。これは
暗号的に鍵レコードを使うことに等しいです。

Communication between the parent and child is greatly reduced, since
the child only needs to notify the parent about changes in keys that
sign its apex KEY RRset. The parent is ignorant of all other keys in
the child's apex KEY RRset. Furthermore, the child maintains full
control over the apex KEY RRset and its content. The child can
maintain any policies regarding its KEY usage for DNSSEC with minimal
impact on the parent. Thus, if the child wants to have frequent key
roll-over for its DNS zone keys, the parent does not need to be aware
of it. The child can use one key to sign only its apex KEY RRset and
a different key to sign the other RRsets in the zone.
子が頂上鍵資源レコード集合に署名する鍵の変更だけを親に通知するだけで
いいので、親と子の間の連絡は大きく減らされます。親は子の頂上鍵資源レ
コード集合以外の鍵は知りません。さらに、子は頂上鍵資源レコード集合と
その内容の完全な制御を維持します。子は、親への影響を最小にして、ＤＮ
ＳＳＥＣの鍵の使用法に関する任意のポリシを維持できます。それで、もし
子がＤＮＳゾーン鍵を頻繁に変えるのを望むなら、親はそれに気付く必要が
ありません。子は頂上鍵資源レコード集合の署名の１つの鍵だけを使い、ゾー
ンの他の資源レコード集合に他の鍵を使えます。

This model fits well with a slow roll out of DNSSEC and the islands
of security model. In this model, someone who trusts "good.example."
can preconfigure a key from "good.example." as a trusted key, and
from then on trusts any data signed by that key or that has a chain
of trust to that key. If "example." starts advertising DS records,
"good.example." does not have to change operations by suspending
self-signing. DS records can be used in configuration files to
identify trusted keys instead of KEY records. Another significant
advantage is that the amount of information stored in large
delegation zones is reduced: rather than the NULL KEY record at every
unsecure delegation demanded by RFC 2535, only secure delegations
require additional information in the form of a signed DS RRset.
このモデルはＤＮＳＳＥＣのゆっくりした変更と、セキュリティモデルの孤
島に、合います。このモデルは、"good.example."を信頼する誰でも
"good.example."からの鍵を信頼できる鍵と事前設定でき、それからこの鍵や
この鍵の信頼連鎖のある鍵で署名された任意のデータを信頼できます。もし
"example."がＤＳレコードを広告し始めたら、"good.example."は自己署名を
をしばらくしないで、オペレーションを変えなくてもよい。ＤＳレコードは
鍵レコードの代わりに信頼できる鍵を識別するために設定ファイルで使われ
ることができます。もう１つの重要な利点は、大きい委任ゾーンで保管する
情報量が減らされることです：安全でない委任に、ＲＦＣ２５３５の要求す
る空鍵レコードを置くのではなく、安全な委任にだけ署名されたＤＳ資源レ
コード集合の追加を必要とします。

The main disadvantage of this approach is that verifying a zone's KEY
RRset requires two signature verification operations instead of the
one in RFC 2535 chain of trust. There is no impact on the number of
signatures verified for other types of RRsets.
この方法の主な欠点はゾーン鍵資源レコード集合を実証するのに、ＲＦＣ２
５３５の信頼連鎖の代わりに、２つの署名検証演算を必要とすることです。
他のタイプの資源レコード集合の検証のための署名の数に影響がありません。

2.2. Protocol Change
2.2. プロトコル変更

All DNS servers and resolvers that support DS MUST support the OK bit
[RFC3225] and a larger message size [RFC3226]. In order for a
delegation to be considered secure the delegation MUST contain a DS
RRset. If a query contains the OK bit, a nameserver returning a
referral for the delegation MUST include the following RRsets in the
authority section in this order:
ＤＳをサポートするすべてのＤＮＳサーバとリゾルバはＯＫビット[RFC3225]
と大きいメッセージサイズ[RFC3226]をサポートしなくてはなりません(MUST)。
委任が安全と思われるために、委任はＤＳ資源レコード集合を含んでいなく
てはなりません(MUST)。もし問合せがＯＫビットを含んでいるなら、委任の
参照を返すネームサーバが以下の順序で権威部に次の資源レコード集合を含
めなくてはなりません(MUST)：

If DS RRset is present:
もしＤＳ資源レコード集合が存在しているなら：
parent's copy of child's NS RRset
親の持つ、子のＮＳ資源レコード集合のコピー
DS and SIG(DS)
ＤＳと署名（ＤＳ）

If no DS RRset is present:
もしＤＳ資源レコード集合が存在していないなら：
parent's copy of child's NS RRset
親の持つ、子のＮＳ資源レコード集合のコピー
parent's zone NXT and SIG(NXT)
親ゾーンのＮＸＴと署名（ＮＸＴ）

This increases the size of referral messages, possibly causing some
or all glue to be omitted. If the DS or NXT RRsets with signatures
do not fit in the DNS message, the TC bit MUST be set. Additional
section processing is not changed.
これは、一部や全てのグルーを削除しても、照会メッセージの大きさを増や
します。もし署名を持つＤＳやＮＸＴ資源レコード集合がＤＮＳメッセージ
入りきらないなら、ＴＣビットを設定しなければなりません(MUST)。追加部
処理が変わりません。

A DS RRset accompanying a NS RRset indicates that the child zone is
secure. If a NS RRset exists without a DS RRset, the child zone is
unsecure (from the parents point of view). DS RRsets MUST NOT appear
at non-delegation points or at a zone's apex.
ＮＳ資源レコード集合に付くＤＳ資源レコード集合は子ゾーンがが安全であ
ることを示します。もしＮＳ資源レコード集合がＤＳ資源レコード集合なし
で存在するなら、子ゾーンは（親から見て）安全ではありません。ＤＳ資源
レコード集合は非委任点やゾーンの頂上に現われてはなりません(MUST NOT)。

Section 2.2.1 defines special considerations related to authoritative
nameservers responding to DS queries and replaces RFC 2535 sections
2.3.4 and 3.4. Section 2.2.2 replaces RFC 3008 section 2.7, and
section 2.2.3 updates RFC 3090.
２.２.１章はＤＳ問合せに応答する正式ネームサーバと関係する特別な考慮
を示し、ＲＦＣ２５３５の２.３.４章と３.４章を置き換えます。２.２.２章
はＲＦＣ３００８の２.７章を置き換え、２.２.３章がＲＦＣ３０９０を更新
します。

2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation
Points
2.2.1. ＲＦＣ２５３５ ２.３.４章と３.４章：委任点の特別な考慮

DNS security views each zone as a unit of data completely under the
control of the zone owner with each entry (RRset) signed by a special
private key held by the zone manager. But the DNS protocol views the
leaf nodes in a zone that are also the apex nodes of a child zone
(i.e., delegation points) as "really" belonging to the child zone.
The corresponding domain names appear in two master files and might
have RRsets signed by both the parent and child zones' keys. A
retrieval could get a mixture of these RRsets and SIGs, especially
since one nameserver could be serving both the zone above and below a
delegation point [RFC2181].
ＤＮＳセキュリティは、ゾーン所有者の制御下のゾーンをデータ完全性の単
位と考えます、そしてゾーン管理者が保持する特別な秘密鍵で各項目（資源
レコード集合）に署名します。けれどもＤＮＳプロトコルは、子の頂上ノー
ドであるゾーンの末端ノード（つまり委任点）を、「本当」は子に属すると
考えます。２つのマスターファイルに現われる対応するドメイン名は、親と
子の両方のゾーン鍵で署名された資源レコード集合を持つかもしれません。
検索の結果、特に１つのネームサーバが委任点の上と下の両方を扱う場合、
両方の資源レコード集合や署名の混合が起きるかも知れません[RFC2181]。

Each DS RRset stored in the parent zone MUST be signed by at least
one of the parent zone's private keys. The parent zone MUST NOT
contain a KEY RRset at any delegation point. Delegations in the
parent MAY contain only the following RR types: NS, DS, NXT and SIG.
The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
case: it will always appear differently and authoritatively in both
the parent and child zones, if both are secure.
親ゾーンの各ＤＳ資源レコード集合は、親ゾーンの秘密鍵の少なくとも１つ
で署名されなくてはなりません(MUST)。親ゾーンは委任点に鍵資源レコード
集合を含んでいてはなりません(MUST NOT)。親の委任は次の資源レコードタ
イプだけを含むかもしれません(MAY)：ＮＳ、ＤＳ、ＮＸＴ、ＳＩＧ。ＮＳ
資源レコード集合は署名されてはなりません(MUST NOT)。ＮＸＴ資源レコー
ド集合は特殊事例です：これは親と子の両方が安全であれば、両方で常に異
なり、両方で正しいでしょう。

A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
verifying the DS RRset from the parent, a resolver MAY trust any KEY
identified in the DS RRset as a valid signer of the child's apex KEY
RRset. Resolvers configured to trust one of the keys signing the KEY
RRset MAY now treat any data signed by the zone keys in the KEY RRset
as secure. In all other cases, resolvers MUST consider the zone
unsecure.
安全なゾーンは頂上に自己署名した鍵資源レコード集合を含まなければなり
ません(MUST)。親からのＤＳ資源レコード集合を検証すると、リゾルバはＤ
Ｓ資源集合内の鍵を、子ゾーンの頂上の資源レコード集合に署名を検証する
正しい鍵と、信頼してもよいです(MAY)。鍵資源レコード集合で署名された
鍵の１つを信頼すると設定されたリゾルバは、安全な鍵資源レコード集合の
ゾーン鍵で署名された任意の鍵を信頼するかもしれません(MAY)。他場合、
リゾルバはゾーンを安全でないと考えなければなりません(MUST)。

An authoritative nameserver queried for type DS MUST return the DS
RRset in the answer section.
ＤＳを問合された正式ネームサーバは解答部にＤＳ資源レコード集合を返さ
なければなりません(MUST)。

2.2.1.1. Special processing for DS queries
2.2.1.1. ＤＳ問合せの特別な処理

When a nameserver is authoritative for the parent zone at a
delegation point and receives a query for the DS record at that name,
it MUST answer based on data in the parent zone, return DS or
negative answer. This is true whether or not it is also
authoritative for the child zone.
ネームサーバが委任点での親ゾーンの権威で、その名前のＤＳレコード問合
せを受け取る時、親ゾーンデータに基づいて応答し、ＤＳか否定応答を返さ
なくてはなりません(MUST)。これは、子ゾーンの権威であるか否かにかかわ
らず、真です。

When the nameserver is authoritative for the child zone at a
delegation point but not the parent zone, there is no natural
response, since the child zone is not authoritative for the DS record
at the zone's apex. As these queries are only expected to originate
from recursive nameservers which are not DS-aware, the authoritative
nameserver MUST answer with:
ネームサーバが委任点の子ゾーンの権威で親ゾーンの権威でないなら、ゾー
ンの頂上のDSレコードは子ゾーンが権威でないので、自然な回答がありませ
ん。これらの問合せはＤＳを理解していない再帰ネームサーバから生成され
たと予想されるので、権威ネームサーバが以下の応答をしなければなりませ
ん(MUST)：

RCODE: NOERROR
AA bit: set
Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]

That is, it answers as if it is authoritative and the DS record does
not exist. DS-aware recursive nameservers will query the parent zone
at delegation points, so will not be affected by this.
すなわち、自分が権威でＤＳレコードが存在しないかのように応答します。
ＤＳ対応再帰ネームサーバは委任点の親ゾーンに問合せるので、この影響は
ないでしょう。

A nameserver authoritative for only the child zone, that is also a
caching server MAY (if the RD bit is set in the query) perform
recursion to find the DS record at the delegation point, or MAY
return the DS record from its cache. In this case, the AA bit MUST
NOT be set in the response.
子ゾーンだけの権威ネームサーバで、同時にキャッシュサーバであるならば
（もし問合せのＲＤビットが設定されていれば）委任点のＤＳレコードを探
すために再帰を行うかもしれません(MAY)、あるいはキャッシュキャッシュ
からＤＳレコードを返してもよいです(MAY)。この場合、ＡＡビットは応答
で設定してはなりません(MUST NOT)。

2.2.1.2. Special processing when child and an ancestor share
nameserver
2.2.1.2. 子と先祖がネームサーバを共有する特別な処理

Special rules are needed to permit DS RR aware nameservers to
gracefully interact with older caches which otherwise might falsely
label a nameserver as lame because of the placement of the DS RR set.
ＤＳ資源レコード集合の配置のために間違ってネームサーバに不完全のレッ
テルを貼られないために、ＤＳ資源レコード対応ネームサーバが古いキャッ
シュと優雅に相互作用する特別な規則が必要です。このような状態は、ネー
ムサーバがゾーンとその祖父の両方で権威であるが、親の権威でない時に生
ずるかもしれません。

Such a situation might arise when a nameserver is authoritative for
both a zone and it's grandparent, but not the parent. This sounds
like an obscure example, but it is very real. The root zone is
currently served on 13 machines, and "root-servers.net." is served on
4 of the 13, but "net." is severed on different nameservers.
これはわかりにくい例に聞こえますが、非常に実際的です。ルートゾーンは
現在１３のマシン上で動き、１３のうち４つは"root-servers.net."を提供し
ますが、"net."は異なるネームサーバ上に切断されています。

When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the
response MUST be determined from reading these rules in order:
ネームサーバが(<QNAME>, DS, <QCLASS>)の問合せを受信する時、下記の規則
を順に行うことで、応答を決定しなければなりません(MUST)：

1) If the nameserver is authoritative for the zone that holds the DS
RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
zone), the response contains the DS RR set as an authoritative
answer.
1) もしネームサーバがＤＳ資源レコード集合を持つゾーンの権威なら（すな
わち、<QNAME>を委任したゾーン、別名「親」ゾーン）、応答は正式な答え
としてＤＳ資源レコード集合を含んでいます。

2) If the nameserver is offering recursive service and the RD bit is
set in the query, the nameserver performs the query itself
(according to the rules for resolvers described below) and returns
its findings.
2) もしネームサーバが再帰サービスを提供し、問合せのＲＤビットが設定さ
れてるなら、ネームサーバは（下記のリゾルバの規則によって）自分自身
で問合せて、調査結果を返します。

3) If the nameserver is authoritative for the zone that holds the
<QNAME>'s SOA RR set, the response is an authoritative negative
answer as described in 2.2.1.1.
3) もしネームサーバが<QNAME>のＳＯＡ資源レコード集合を持つゾーンの権
威なら、応答は２.２.１.１章で記述されるように、正式な否定応答です。

4) If the nameserver is authoritative for a zone or zones above the
QNAME, a referral to the most enclosing (deepest match) zone's
servers is made.
4) もしネームサーバがQNAMEの上のゾーンの権威なら、最も囲まれた（最深
一致）ゾーンのサーバへの照会が作られます。

5) If the nameserver is not authoritative for any part of the QNAME,
a response indicating a lame nameserver for QNAME is given.
5) もしネームサーバがQNAMEのその部分でも権威ではないなら、QNAMEのネー
ムサーバでないことを示す回答が与えられます。

Using these rules will require some special processing on the part of
a DS RR aware resolver. To illustrate this, an example is used.
これらの規則を使うことはＤＳ資源レコード対応リゾルバへ特別な処理を要
求するでしょう。これを示すために例を使います。

Assuming a nameserver is authoritative for roots.example.net. and for
the root zone but not the intervening two zones (or the intervening
two label deep zone). Assume that QNAME=roots.example.net.,
QTYPE=DS, and QCLASS=IN.
ネームサーバをroots.example.netとルートゾーンの権威で、間の２つのゾー
ン（あるいは間の２つのラベルのゾーン）の権威ではない、と仮定します。
QNAME=roots.example.net、QTYPE=DS、QCLASS=INと仮定します。

The resolver will issue this request (assuming no cached data)
expecting a referral to a nameserver for .net. Instead, rule number
3 above applies and a negative answer is returned by the nameserver.
The reaction by the resolver is not to accept this answer as final,
as it can determine from the SOA RR in the negative answer the
context within which the nameserver has answered.
リゾルバは.netのネームサーバの参照を期待してこの要求を発行するでしょ
う（キャッシュデータなしを仮定）。代わりに、上記規則３番が適用され、
否定応答がネームサーバから返されます。否定応答のＳＯＡ資源レコードか
らネームサーバが何に答えたか決定できるので、リゾルバは応答が最終応答
でないと認識できるはずです。

A solution would be to instruct the resolver to hunt for the
authoritative zone of the data in a brute force manner.
解決策はがリゾルバが力づくでデータの正式ゾーンを探すように指示するこ
とでしょう。

This can be accomplished by taking the owner name of the returned SOA
RR and striping off enough left-hand labels until a successful NS
response is obtained. A successful response here means that the
answer has NS records in it. (Entertaining the possibility that a
cut point can be two labels down in a zone.)
これは返されたＳＯＡの所有者名を取り出し、ＮＳ問合せが成功するまで、
左のラベルを取り去っていくことで達成されます。問合せの成功は応答にＮ
Ｓレコードあることです。（ゾーンカットされた場所が２枚のラベルである
可能性があります。）

Returning to the example, the response will include a negative answer
with either the SOA RR for "roots.example.net." or "example.net."
depending on whether roots.example.net is a delegated domain. In
either case, removing the left most label of the SOA owner name will
lead to the location of the desired data.
例では、応答は、roots.example.netが委任点かどうかにより、
"roots.example.net."か"example.net."の、ＳＯＡ資源レコードを含む否定
応答です。その場合でも、ＳＯＡ所有者名の最左ラベルを除去すれば望まし
いデータの場所に導かれるでしょう。

2.2.1.3. Modification on use of KEY RR in the construction of Responses
2.2.1.3. 応答構築での鍵資源レコード使用の修正

This section updates RFC 2535 section 3.5 by replacing it with the
following:
この章はＲＦＣ２５３５の３.５章を、下記に変更することで、更新します：

A query for KEY RR MUST NOT trigger any additional section
processing. Security aware resolvers will include corresponding SIG
records in the answer section.
鍵資源レコードの問合せ追加部処理を引き起こしてはなりません(MUST NOT)。
セキュリティの認識のあるリゾルバは解答部に対応する署名レコードを含め
るでしょう。

KEY records SHOULD NOT be added to the additional records section in
response to any query.
問合せの応答で、鍵レコードを追加レコード部に加えるべきではありません
(SHOUKD NOT)。

RFC 2535 specified that KEY records be added to the additional
section when SOA or NS records were included in an answer. This was
done to reduce round trips (in the case of SOA) and to force out NULL
KEYs (in the NS case). As this document obsoletes NULL keys, there
is no need for the inclusion of KEYs with NSs. Furthermore, as SOAs
are included in the authority section of negative answers, including
the KEYs each time will cause redundant transfers of KEYs.
ＲＦＣ２５３５は、ＳＯＡかＮＳレコードが応答に含められた時、鍵レコー
ドを追加章に加えると明示しました。これは（ＳＯＡの場合）往復回数を減
らして、そして（ＮＳの場合）空鍵をなくすためにされました。この文書が
空鍵を時代遅れにするから、ＮＳと同時に鍵を送る必要がありません。さら
に、ＳＯＡが否定応答の権威部に含められるから、毎回鍵を含める事は、鍵
の重複転送を起こすでしょう。

RFC 2535 section 3.5 also included a rule for adding the KEY RRset to
the response for a query for A and AAAA types. As Restrict KEY
[RFC3445] eliminated use of KEY RR by all applications, this rule is
no longer needed.
ＲＦＣ２５３５の３.５章はＡとＡＡＡＡタイプの問合せの応答に鍵資源レコー
ド集合を加える規則を含みました。鍵の制限[RFC3445]は、アプリケーション
の鍵資源レコードの使用を排除したので、この規則はもう必要ありません。

2.2.2. Signer's Name (replaces RFC 3008 section 2.7)
2.2.2. 署名者名（ＲＦＣ３００８の２.７章の置き換え）

The signer's name field of a SIG RR MUST contain the name of the zone
to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is
to be considered material. This document defines a standard policy
for DNSSEC validation; local policy MAY override the standard policy.
署名資源レコードの署名者名フィールドはデータと署名が属するゾーンの名
前を含んでいなくてはなりません(MUST)。署名者名と鍵タグとアルゴリズム
の組合せは、もし署名が材料と思われるなら、ゾーン鍵を識別しなくてはな
りません(MUST)。この文書はＤＮＳＳＥＣ検証の標準ポリシを定義します；
ローカルポリシが標準ポリシより優先するかもしれません(MAY)。

There are no restrictions on the signer field of a SIG(0) record. The
combination of signer's name, key tag, and algorithm MUST identify a
key if this SIG(0) is to be processed.
ＳＩＧ（０）レコードの署名者フィールドの制限がありません。署名者名と
鍵タグとアルゴリズムの組合せは、もしこのＳＩＧ（０）が処理されるなら、
鍵を識別しなくてはなりません。

2.2.3. Changes to RFC 3090
2.2.3. ＲＦＣ３０９０に対する変更

A number of sections in RFC 3090 need to be updated to reflect the DS
record.
ＲＦＣ３０９０の多くの章がＤＳレコードを反映して更新され必要があります。

2.2.3.1. RFC 3090: Updates to section 1: Introduction
2.2.3.1. ＲＦＣ３０９０：１章：はじめに、の更新

Most of the text is still relevant but the words "NULL key" are to be
replaced with "missing DS RRset". In section 1.3, the last three
paragraphs discuss the confusion in sections of RFC 2535 that are
replaced in section 2.2.1 above. Therefore, these paragraphs are now
obsolete.
テキストの大部分はまだ適切ですが、「空鍵」は「ＤＳ資源レコード集合な
し」で置き換えられるはずです。１.３章の最後の３段落の議論は、ＲＦＣ
２５３５の上記２.２.１章で置換えた内容と混乱を論じます。それで、これ
らの段落は時代遅れです。

2.2.3.2. RFC 3090 section 2.1: Globally Secured
2.2.3.2. ＲＦＣ３０９０の２.１章：広域安全

Rule 2.1.b is replaced by the following rule:
規則２.１.ｂが次の規則に置換えられます：

2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
private key whose public counterpart MUST appear in a zone signing
KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
implement algorithm. This KEY RR MUST be identified by a DS RR in a
signed DS RRset in the parent zone.
2.1.b. ゾーンの頂上の鍵資源レコード集合は、ゾーンの頂上が所有者であり
必須実装アルゴリズムが指定されたゾーン署名鍵資源レコード(2.a)が、対応
する公開鍵である秘密鍵で、自己署名されなければなりません(MUST)。この
鍵資源レコードは親ゾーンの署名されたＤＳ資源レコード集合のＤＳ資源レ
コードで識別されなくてはなりません(MUST)。

If a zone cannot get its parent to advertise a DS record for it, the
child zone cannot be considered globally secured. The only exception
to this is the root zone, for which there is no parent zone.
もしゾーンが親にＤＳレコードの広告をさせることができないなら、子ゾー
ンは世界的規模で安全に保たれているとは考えられません。唯一のこの例外
は親ゾーンがないルートゾーンです。

2.2.3.3. RFC 3090 section 3: Experimental Status.
2.2.3.3. ＲＦＣ３０９０の３章：実験的状態

The only difference between experimental status and globally secured
is the missing DS RRset in the parent zone. All locally secured
zones are experimental.
実験的状態と世界的規模での安全の唯一の差は、親ゾーンのＤＳ資源レコー
ド集合の欠如です。すべてのローカルに安全なゾーンは実験的です。

2.2.4. NULL KEY elimination
2.2.4. 空鍵除去

RFC 3445 section 3 eliminates the top two bits in the flags field of
KEY RR. These two bits were used to indicate NULL KEY or NO KEY. RFC
3090 defines that zone as either secure or not and these rules
eliminate the need to put NULL keys in the zone apex to indicate that
the zone is not secured for a algorithm. Along with this document,
these other two eliminate all uses for the NULL KEY. This document
obsoletes NULL KEY.
ＲＦＣ３４４５の３章は鍵資源レコードのフラグフィールドの上位２ビット
を削除します。これらの２ビットは空鍵あるいは鍵なしを示すために使われ
ました。ＲＦＣ３０９０はゾーンが安全かどうかと、そのアルゴリズムでゾー
ンが安全でない事を示す空鍵をゾーン頂上に置く必要性の排除の規則を定義
します。この文書で、他の２つは、空鍵のすべての使用を排除します。この
文書は空鍵を時代遅れにします。

2.3. Comments on Protocol Changes
2.3. プロトコル変更についてのコメント

Over the years, there have been various discussions surrounding the
DNS delegation model, declaring it to be broken because there is no
good way to assert if a delegation exists. In the RFC 2535 version
of DNSSEC, the presence of the NS bit in the NXT bit map proves there
is a delegation at this name. Something more explicit is required
and the DS record addresses this need for secure delegations.
数年間、代表団が存在すると断言する何の役にも立たない方法があるから、
ＤＮＳ委任モデルが壊れているという、種々な論議がありました。ＤＮＳＳ
ＥＣのＲＦＣ２５３５バージョンで、ＮＸＴビットマップのＮＳビットはこ
の名前の委任がいることを証明します。より明示的な何かが必要とされ、そ
してＤＳレコードはこの安全な委任の必要性を扱います。

The DS record is a major change to DNS: it is the first resource
record that can appear only on the upper side of a delegation.
Adding it will cause interoperability problems and requires a flag
day for DNSSEC. Many old nameservers and resolvers MUST be upgraded
to take advantage of DS. Some old nameservers will be able to be
authoritative for zones with DS records but will not add the NXT or
DS records to the authority section. The same is true for caching
nameservers; in fact, some might even refuse to pass on the DS or NXT
records.
ＤＳレコードはＤＮＳに対する主要な変更です：これは委任の上側にだけ現
われることができる最初の資源レコードです。これを加えることは互換性問
題を起こすだろうから、ＤＮＳＳＥＣのために１つのフラグを必要とします。
多くの古いネームサーバとリゾルバがＤＳを利用するために更新されなくて
はなりません(MUST)。ある古いネームサーバがＤＳレコードのゾーンの権威
であることが可能でしょうが、権威部にＮＸＴやＤＳレコードを加えないで
しょう。同じ事はキャッシュネームサーバでも本当です；実際、いくつかは
ＤＳやＮＸＴレコードを渡すことを拒否するかもしれません。

2.4. Wire Format of the DS record
2.4. ＤＳレコードのフォーマット

The DS (type=43) record contains these fields: key tag, algorithm,
digest type, and the digest of a public key KEY record that is
allowed and/or used to sign the child's apex KEY RRset. Other keys
MAY sign the child's apex KEY RRset.
ＤＳ（タイプ＝４３）レコードは次のフィールドを含みます：鍵タグ、アル
ゴリズム、要約種別、子の頂上の鍵資源レコード集合に署名する公開鍵レコー
ドの要約。他の鍵が子の頂上鍵資源レコード集合に署名するかもしれません
(MAY)。

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 (length depends on type) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (SHA-1 digest is 20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The key tag is calculated as specified in RFC 2535. Algorithm MUST
be allowed to sign DNS data. The digest type is an identifier for
the digest algorithm used. The digest is calculated over the
canonical name of the delegated domain name followed by the whole
RDATA of the KEY record (all four fields).
鍵タグはＲＦＣ２５３５で指定されるように計算されています。アルゴリズ
ムがＤＮＳデータに署名するために割り当てられなくてはなりません(MUST)。
要約種別は使われた要約アルゴリズムの識別子です。要約は、委任されたド
メイン名の正規化名と鍵レコードの全資源データ（全ての４フィールド）上
で計算されます。

digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)

KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key

Digest type value 0 is reserved, value 1 is SHA-1, and reserving
other types requires IETF standards action. For interoperability
reasons, keeping number of digest algorithms low is strongly
RECOMMENDED. The only reason to reserve additional digest types is
to increase security.
要約種別値の０は予約です、値１はSHA-1で、他の種別の予約はＩＥＴＦ標準
行動を必要とします。互換性のために、要約アルゴリズムの数を少なくして
おくことが強く推薦されています。追加の要約種別を予約するべき唯一の理
由はセキュリティの強化です。

DS records MUST point to zone KEY records that are allowed to
authenticate DNS data. The indicated KEY records protocol field MUST
be set to 3; flag field bit 7 MUST be set to 1. The value of other
flag bits is not significant for the purposes of this document.
ＤＳレコードは、ＤＮＳデータを認証することを許されるゾーン鍵レコード
を示さなくてはなりません(MUST)。示された鍵レコードプロトコルフィール
ドは３が設定されてなくてはなりません(MUST)；フラグフィールドビット７
が１に設定されなくてはなりません(MUST)。他のフラグビットの値はこの文
書の目的では重要ではありません。

The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
of key size. New digest types probably will have larger digests.
タイプ１（SHA-1）のＤＳ資源データのサイズは、鍵のサイズにかかわらず、
２４バイトです。新しい要約種別が恐らくより大きい要約を持つでしょう。

2.4.1. Justifications for Fields
2.4.1. フィールドの正当化

The algorithm and key tag fields are present to allow resolvers to
quickly identify the candidate KEY records to examine. SHA-1 is a
strong cryptographic checksum: it is computationally infeasible for
an attacker to generate a KEY record that has the same SHA-1 digest.
Combining the name of the key and the key rdata as input to the
digest provides stronger assurance of the binding. Having the key
tag in the DS record adds greater assurance than the SHA-1 digest
alone, as there are now two different mapping functions.
アルゴリズムと鍵タグフィールドはリゾルバが検証の候補の鍵レコードをす
ばやく認識するために存在しています。SHA-1強い暗号のチェックサムです：
これは攻撃者が同じSHA-1要約を持つ鍵レコードを生成するのを計算量的に実
行不可能にします。要約への入力として鍵名と鍵資源データを組合わせるこ
とは結合により強い保障を供給します。ＤＳレコードで鍵タグを持つことは、
２つの異なる対応関数があるので、SHA-1要約だけより大きい保障を加えます。

This format allows concise representation of the keys that the child
will use, thus keeping down the size of the answer for the
delegation, reducing the probability of DNS message overflow. The
SHA-1 hash is strong enough to uniquely identify the key and is
similar to the PGP key footprint. The digest type field is present
for possible future expansion.
このフォーマットは子の使うであろう鍵の簡潔な表現を許し、それで委任の
応答の大きさを減らし、ＤＮＳメッセージがあふれる可能性を減らします。
SHA-1ハッシュは一意に鍵を識別するのに十分協力で、ＰＧＰ鍵跡に類似し
ています。要約種別フィールドは将来の拡張の可能性のために存在していま
す。

The DS record is well suited to listing trusted keys for islands of
security in configuration files.
ＤＳレコードは設定ファイルで信頼できる鍵をリストアップするセキュリティ
の孤島で適切です。

2.5. Presentation Format of the DS Record
2.5. ＤＳレコードの表現形式

The presentation format of the DS record consists of three numbers
(key tag, algorithm, and digest type) followed by the digest itself
presented in hex:
ＤＳレコードの表現形式は３つの数字（鍵タグ、アルゴリズム、要約種別）
と１６進数表記の要約からなります：

example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890

2.6. Transition Issues for Installed Base
2.6. 既存の移行問題

No backwards compatibility with RFC 2535 is provided.
ＲＦＣ２５３５との後方互換性が供給されません。

RFC 2535-compliant resolvers will assume that all DS-secured
delegations are locally secure. This is bad, but the DNSEXT Working
Group has determined that rather than dealing with both RFC 2535-
secured zones and DS-secured zones, a rapid adoption of DS is
preferable. Thus, the only option for early adopters is to upgrade
to DS as soon as possible.
ＲＦＣ２５３５対応リゾルバはすべてのＤＳで安全にされた委任をローカル
に安全と想定するでしょう。これは良くありませんが、ＤＮＳＥＸＴ作業班
ははＲＦＣ２５３５で安全に保たれたゾーンとＤＳで安全に保たれたゾーン
の両方を扱うより、ＤＳの速い採用が望ましいと決定しました。それで、唯
一の素早い採用のための選択は、できるだけ早くＤＳに格上げすることです。

2.6.1. Backwards compatibility with RFC 2535 and RFC 1035
2.6.1. ＲＦＣ２５３５とＲＦＣ１０３５との後方互換性

This section documents how a resolver determines the type of
delegation.
この章はどのようにリゾルバが委任タイプを決定するかを文書化します。

RFC 1035 delegation (in parent) has:
ＲＦＣ１０３５委任（親で）は以下を持ちます：

RFC 1035 NS

RFC 2535 adds the following two cases:
ＲＦＣ２５３５は以下の２つの場合を追加します：

Secure RFC 2535: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT
Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
NXT bit map contains: NS SIG KEY NXT
KEY must be a NULL key.

DNSSEC with DS has the following two states:
ＤＳのＤＮＳＳＥＣは以下の２つの状態を持ちます：

Secure DS: NS + DS + SIG(DS)
NXT bit map contains: NS SIG NXT DS
Unsecure DS: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT

It is difficult for a resolver to determine if a delegation is secure
RFC 2535 or unsecure DS. This could be overcome by adding a flag to
the NXT bit map, but only upgraded resolvers would understand this
flag, anyway. Having both parent and child signatures for a KEY
RRset might allow old resolvers to accept a zone as secure, but the
cost of doing this for a long time is much higher than just
prohibiting RFC 2535-style signatures at child zone apexes and
forcing rapid deployment of DS-enabled nameservers and resolvers.
リゾルバはが委任が安全なＲＦＣ２５３５なのか、安全でないＤＳなのか決
定することは難しいです。これはＮＸＴビットマップにフラグを加えること
で克服できます、しかし更新されたリゾルバだけがこのフラグを理解するで
しょう。鍵資源レコード集合で親と子の両方の署名を持つことは、古いリゾ
ルバはゾーンを安全と認識するのを許すかもしれませんが、長期間これをす
るコストは子ゾーンの頂上でＲＦＣ２５３５スタイルの署名を禁止し、ＤＳ
使用が可能なネームサーバとリゾルバの速い配置を強制するよりずっと高価
です。

RFC 2535 and DS can, in theory, be deployed in parallel, but this
would require resolvers to deal with RFC 2535 configurations forever.
This document obsoletes the NULL KEY in parent zones, which is a
difficult enough change that to cause a flag day.
ＲＦＣ２５３５とＤＳは、理論上、並列に配置できますが、これはリゾルバ
が永久にＲＦＣ２５３５形式を扱うように要求するでしょう。この文書は親
ゾーンの空鍵を時代遅れにし、そしてこれは十分難しい変更です。

2.7. KEY and corresponding DS record example
2.7. 鍵と対応するＤＳレコード例

This is an example of a KEY record and the corresponding DS record.
これは鍵レコードと対応するＤＳレコードの例です。

dskey.example. KEY 256 3 1 (
AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
) ; key id = 28668
DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE

3. Resolver
3. リゾルバ

3.1. DS Example
3.1. ＤＳ例

To create a chain of trust, a resolver goes from trusted KEY to DS to
KEY.
信頼連鎖を作るために、リゾルバは信頼できる鍵からＤＳ鍵へ進みます。

Assume the key for domain "example." is trusted. Zone "example."
contains at least the following records:
"example."ドメインの鍵は信頼できると仮定します。ゾーン"example."は
少なくとも以下のレコードを持ちます：
example. SOA <soa stuff>
example. NS ns.example.
example. KEY <stuff>
example. NXT secure.example. NS SOA KEY SIG NXT
example. SIG(SOA)
example. SIG(NS)
example. SIG(NXT)
example. SIG(KEY)
secure.example. NS ns1.secure.example.
secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo>
secure.example. NXT unsecure.example. NS SIG NXT DS
secure.example. SIG(NXT)
secure.example. SIG(DS)
unsecure.example NS ns1.unsecure.example.
unsecure.example. NXT example. NS SIG NXT
unsecure.example. SIG(NXT)

In zone "secure.example." following records exist:
ゾーン"secure.example."は以下のレコードを含みます：
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
secure.example. KEY <tag=12345 alg=3>
secure.example. KEY <tag=54321 alg=5>
secure.example. NXT <nxt stuff>
secure.example. SIG(KEY) <key-tag=12345 alg=3>
secure.example. SIG(SOA) <key-tag=54321 alg=5>
secure.example. SIG(NS) <key-tag=54321 alg=5>
secure.example. SIG(NXT) <key-tag=54321 alg=5>

In this example, the private key for "example." signs the DS record
for "secure.example.", making that a secure delegation. The DS
record states which key is expected to sign the KEY RRset at
"secure.example.". Here "secure.example." signs its KEY RRset with
the KEY identified in the DS RRset, thus the KEY RRset is validated
and trusted.
この例で"example."の秘密鍵で"secure.example."に署名し、これを安全な
委任にします。ＤＳレコードは"secure.example."の鍵資源レコード集合に
署名することを期待される鍵を示します。ここで"secure.example."はＤＳ
資源レコード集合で指定される鍵で鍵集合に署名します、それで鍵資源レ
コード集合は検証され信頼できます。

This example has only one DS record for the child, but parents MUST
allow multiple DS records to facilitate key roll-over and multiple
KEY algorithms.
この例は子のために１つだけのＤＳレコードを持っていますが、親が鍵変
更と複数鍵アルゴリズムを容易にするため、多数のＤＳレコードを許さな
くてはなりません(MUST)。

The resolver determines the security status of "unsecure.example." by
examining the parent zone's NXT record for this name. The absence of
the DS bit indicates an unsecure delegation. Note the NXT record
SHOULD only be examined after verifying the corresponding signature.
リゾルバは親ゾーンのこの名前のＮＸＴレコードを調べることで
"unsecure.example."セキュリティ状態を決定します。ＤＳビットの欠如は
安全でない委任を示します。ＮＸＴレコードは対応する署名を検証した後で
だけ調べられるべきことに注意してください(SHOULD)。

3.2. Resolver Cost Estimates for DS Records
3.2. ＤＳレコードのためのリゾルバコスト見積り

From a RFC 2535 recursive resolver point of view, for each delegation
followed to chase down an answer, one KEY RRset has to be verified.
Additional RRsets might also need to be verified based on local
policy (e.g., the contents of the NS RRset). Once the resolver gets
to the appropriate delegation, validating the answer might require
verifying one or more signatures. A simple A record lookup requires
at least N delegations to be verified and one RRset. For a DS-
enabled recursive resolver, the cost is 2N+1. For an MX record,
where the target of the MX record is in the same zone as the MX
record, the costs are N+2 and 2N+2, for RFC 2535 and DS,
respectively. In the case of a negative answer, the same ratios hold
true.
ＲＦＣ２５３５の再帰リゾルバの見地から、それぞれ委任に従って下へ答え
を求めるために、１つの鍵資源レコード集合が検証されなければなりません。
追加の資源レコード集合が同じくローカルポリシに基づいて検証される必要
があるかもしれません（例えば、ＮＳ資源レコード集合の中身）。リゾルバ
が適切な委任に到達すると、応答の検証は１つ以上の署名検証を必要とする
かもしれません。単純なレコード検索は少なくとも検証すべきＮ個の委任と、
１つの資源レコード集合を必要とします。ＤＳ対応の再帰リゾルバで、コス
トは２Ｎ＋１です。ＭＸレコードで、ＭＸレコードの目標がＭＸレコードと
同じゾーンにあるとき、コストはＲＦＣ２５３５でＮ＋２で、ＤＳで２Ｎ＋
２です。否定的応答でも、比率は同じです。

The recursive resolver has to do an extra query to get the DS record,
which will increase the overall cost of resolving this question, but
it will never be worse than chasing down NULL KEY records from the
parent in RFC 2535 DNSSEC.
再帰リゾルバはＤＳレコードを得るのに追加の問合せが必要で、これはこの
質問の全体コストを増やしますが、ＲＦＣ２５３５のＤＮＳＳＥＣの親での
空鍵のキャッシュより悪くはないでしょう。

DS adds processing overhead on resolvers and increases the size of
delegation answers, but much less than storing signatures in the
parent zone.
ＤＳはリゾルバ上の処理を増やし、委任応答の大きさを増やしますが、署名
を親ゾーンにしまうより少ないです。

4. Security Considerations
4. セキュリティの考察

This document proposes a change to the validation chain of KEY
records in DNSSEC. The change is not believed to reduce security in
the overall system. In RFC 2535 DNSSEC, the child zone has to
communicate keys to its parent and prudent parents will require some
authentication with that transaction. The modified protocol will
require the same authentication, but allows the child to exert more
local control over its own KEY RRset.
この文書はＤＮＳＳＥＣの鍵レコードの検証連鎖に対する変更を提案します。
変更は全体的なシステムの安全性を減らさないと信じられています。ＲＦＣ
２５３５ＤＮＳＳＥＣで、子ゾーンは親に鍵を伝達しなければならず、そし
て慎重な親がその処理で何かの認証を必要とするでしょう。修正されたプロ
トコルは同じ認証を必要とするでしょうが、子が自分自身の鍵資源レコード
集合のよりローカルな制御を許します。

There is a remote possibility that an attacker could generate a valid
KEY that matches all the DS fields, of a specific DS set, and thus
forge data from the child. This possibility is considered
impractical, as on average more than
攻撃者が、特定のＤＳ集合のすべてのＤＳフィールドと一致する正当な鍵を
生成し、それで子からデータを作り出すことができるうかすかなの可能性が
あります。この可能性は、一致した鍵を見つけるのに、平均して

2 ^ (160 - <Number of keys in DS set>)

keys would have to be generated before a match would be found.
以上の鍵がを生成しなければならないので、非実用的と思われます。

An attacker that wants to match any DS record will have to generate
on average at least 2^80 keys.
ＤＳレコードと一致する鍵を望む攻撃者が平均して少なくとも２^８０の鍵
を生成しなければならないでしょう。

The DS record represents a change to the DNSSEC protocol and there is
an installed base of implementations, as well as textbooks on how to
set up secure delegations. Implementations that do not understand
the DS record will not be able to follow the KEY to DS to KEY chain
and will consider all zones secured that way as unsecure.
ＤＳレコードはＤＮＳＳＥＣプロトコルに対する変更を表し、そして既にイ
ンストールされている実装があり、そして安全な委任を作る方法の教科書が
あります。ＤＳレコードを理解しない実装が鍵ＤＳ鍵の連鎖に対応可能では
ないでしょう、そしてすべての安全なソーンを安全でないと考えるでしょう。

5. IANA Considerations
5. ＩＡＮＡの考慮

IANA has allocated an RR type code for DS from the standard RR type
space (type 43).
ＩＡＮＡは標準資源レコード種別空間からＤＳに資源レコード種別コードを
割り当てました（タイプ４３）。

IANA has established a new registry for the DS RR type for digest
algorithms. Defined types are:
ＩＡＮＡはＤＳ資源レコードタイプの概要アルゴリズムのために新しい登記
所を設立しました。定義されたタイプが以下です：。

0 is Reserved,
０が予約です、
1 is SHA-1.
１はSHA-1です。

Adding new reservations requires IETF standards action.
新しい予約を加えるのはＩＥＴＦ標準行動を必要とします。

6. Intellectual Property Statement
6. 知的所有権宣言

The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
この文書に記述された実装や技術に関して主張される知的財産や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する調査をしたとは述べません。ＩＥＴＦ標準手続きと標準関連文書で
の権利に関しての手順の情報はＢＣＰ１１を見てください。出版に利用する
権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書
の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの
結果はＩＥＴＦ事務局で得られます。

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかＩＥＴＦ専務に情報を伝えてください。

7. Acknowledgments
7. 謝辞

Over the last few years a number of people have contributed ideas
that are captured in this document. The core idea of using one key
to sign only the KEY RRset comes from discussions with Bill Manning
and Perry Metzger on how to put in a single root key in all
resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie,
Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt
Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker,
Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
Andrews, Harald Alvestrand, and others have provided useful comments.
これまでの数年にわたって多くの人々がこの文書で取り込まれる考えを提供
しました。ただ鍵資源レコード集合だけに署名する１つの鍵を使うことの核
心的考えは、すべてのリゾルバにひとつのルート鍵を渡す方法についてのBill
ManningとPerry Metzgerとの論議に由来します。Alexis YushinとBrian
WellingtonとSam WeilerとPaul VixieとJakob SchlyterとScott RoseとEdward
LewisとLars-Johan LimanとMatt LarsonとMark KostersとDan MasseyとOlaf
KolmanとPhillip Hallam-BakerとMiek GiebenとHavard EidnesとDonald
Eastlake 3rd.とRandy BushとDavid BlackaとSteve BellovinとRob Austein
とDerek AtkinsとRoy ArendsとMark AndrewsとHarald Alvestrandと他の人
たちは有用なコメントを供給しました。

8. References
8. 参考文献

8.1. Normative References
8.1. 参照する参考文献

[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

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

[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.

[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.

[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.

[RFC3445] Massey, D. and S. Rose, "Limiting the scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.

8.2. Informational References
8.2. 有益な参考文献

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.

[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.

9. Author's Address
9. 著者のアドレス

Olafur Gudmundsson
3821 Village Park Drive
Chevy Chase, MD, 20815

EMail: ds-rfc@ogud.com

10. Full Copyright Statement
10. 著作権表示全文

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。

Acknowledgement
謝辞

Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。

Japanese translation by Ishida So