RFC5074 日本語訳

Network Working Group                                          S. Weiler
Request for Comments: 5074                                  SPARTA, Inc.
Category: Informational                                    November 2007

コメントを求めるワーキンググループS.ウィーラー要求をネットワークでつないでください: 5074年のスパルタInc.カテゴリ: 情報の2007年11月

                   DNSSEC Lookaside Validation (DLV)

DNSSEC Lookaside合法化(DLV)

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNS
   Security (DNSSEC) trust anchors outside of the DNS delegation chain.
   It allows validating resolvers to validate DNSSEC-signed data from
   zones whose ancestors either aren't signed or don't publish
   Delegation Signer (DS) records for their children.

DNSSEC Lookaside Validation(DLV)は、DNS代表団チェーンの外でDNS Security(DNSSEC)信用アンカーを発行するためのメカニズムです。 それで、先祖がサインされないか、または彼らの子供のためにDelegation Signer(DS)記録を発表しないゾーンからのDNSSECによってサインされたデータを有効にするためにレゾルバを有効にします。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  DLV Domains . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Overview of Validator Behavior  . . . . . . . . . . . . . . . . 3
   5.  Details of Validator Behavior . . . . . . . . . . . . . . . . . 4
   6.  Aggressive Negative Caching . . . . . . . . . . . . . . . . . . 5
     6.1.  Implementation Notes  . . . . . . . . . . . . . . . . . . . 5
   7.  Overlapping DLV Domains . . . . . . . . . . . . . . . . . . . . 6
   8.  Optimization  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     11.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     11.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . .10

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 構造. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 DLVドメイン. . . . . . . . . . . . . . . . . . . . . . . . . . 3 4。 Validatorの振舞い. . . . . . . . . . . . . . . . 3 5の概観。 Validatorの振舞い. . . . . . . . . . . . . . . . . 4 6の詳細。 攻撃的な否定的キャッシュ. . . . . . . . . . . . . . . . . . 5 6.1。 実現注意. . . . . . . . . . . . . . . . . . . 5 7。 DLVドメイン. . . . . . . . . . . . . . . . . . . . 6 8を重ね合わせます。 最適化. . . . . . . . . . . . . . . . . . . . . . . . . 7 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 7 10。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 8 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 8 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 9付録A.承認.10………………

Weiler                       Informational                      [Page 1]

RFC 5074                          DLV                      November 2007

[1ページ]RFC5074DLV2007年11月の情報のウィーラー

1.  Introduction

1. 序論

   DNSSEC [RFC4033] [RFC4034] [RFC4035] authenticates DNS data by
   building public-key signature chains along the DNS delegation chain
   from a trust anchor.

DNSSEC[RFC4033][RFC4034][RFC4035]は、DNS代表団チェーンに沿って信用アンカーから公開カギ署名チェーンを組立てることによって、DNSデータを認証します。

   In the present world, with the DNS root and many key top level
   domains unsigned, the only way for a validating resolver
   ("validator") to validate the many DNSSEC-signed zones is to maintain
   a sizable collection of preconfigured trust anchors.  Maintaining
   multiple preconfigured trust anchors in each DNSSEC-aware validator
   presents a significant management challenge.

現世では、多くのDNSSECによってサインされたゾーンを有効にする有効にしているレゾルバ("validator")のための唯一の方法はあらかじめ設定された信用アンカーのかなり大きい収集を維持するDNS根と多くの主要なトップ・レベル・ドメインが無記名であることの、ことです。 それぞれのDNSSEC意識しているvalidatorの複数のあらかじめ設定された信用アンカーを維持すると、重要な管理挑戦は提示されます。

   This document describes a way to publish trust anchors in the DNS
   outside of the normal delegation chain, as a way to easily configure
   many validators within an organization or to "outsource" trust anchor
   management.

このドキュメントは正常な代表団チェーンの外でDNSで信用アンカーを発行する方法を述べます、容易に組織の中の多くのvalidatorsを構成するか、または信用アンカー管理を「社外調達する」方法として。

   Some design trade-offs leading to the mechanism presented here are
   described in [INI1999-19].

ここに提示されたメカニズムにつながるいくつかのデザイントレードオフが[INI1999-19]で説明されます。

   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 RFC 2119 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  Architecture

2. 構造

   DNSSEC Lookaside Validation allows a set of domains, called "DLV
   domains", to publish secure entry points for zones that are not their
   own children.

DNSSEC Lookaside Validationは、それら自身の子供でないゾーンに安全なエントリー・ポイントを発行するために「DLVドメイン」と呼ばれる1セットのドメインを許容します。

   With DNSSEC, validators may expect a zone to be secure when
   validators have one of two things: a preconfigured trust anchor for
   the zone or a validated Delegation Signer (DS) record for the zone in
   the zone's parent (which presumes a preconfigured trust anchor for
   the parent or another ancestor).  DLV adds a third mechanism: a
   validated entry in a DLV domain (which presumes a preconfigured trust
   anchor for the DLV domain).  Whenever a DLV domain contains a DLV
   RRset for a zone, a validator may expect the named zone to be signed.
   Absence of a DLV RRset for a zone does not necessarily mean that the
   zone should be expected to be insecure; if the validator has another
   reason to believe the zone should be secured, validation of that
   zone's data should still be attempted.

DNSSECと共に、validatorsは、validatorsに2つのものの1つがあるとき、ゾーンが安全であると予想するかもしれません: ゾーンの親(親か別の先祖のためにあらかじめ設定された信用アンカーを推定する)でのゾーンへのあらかじめ設定された信用アンカーかゾーンのための有効にされたDelegation Signer(DS)記録。 DLVは3番目のメカニズムを加えます: DLVドメイン(あらかじめ設定された信用アンカーをDLVドメインに推定する)の有効にされたエントリー。 DLVドメインがゾーンへのDLV RRsetを含んでいるときはいつも、validatorは、命名されたゾーンがサインされると予想するかもしれません。 ゾーンへのDLV RRsetの不在は、必ずゾーンが不安定であると予想されるべきであることを意味するというわけではありません。 validatorにゾーンが保証されるべきであると信じる別の理由があるなら、そのゾーンのデータの合法化はまだ試みられているべきです。

Weiler                       Informational                      [Page 2]

RFC 5074                          DLV                      November 2007

[2ページ]RFC5074DLV2007年11月の情報のウィーラー

3.  DLV Domains

3. DLVドメイン

   A DLV domain includes trust statements about descendants of a single
   zone, called the 'target' zone.  For example, the DLV domain
   trustbroker.example.com could target the org zone and the DLV domain
   bar.example.com could target the root.

DLVドメインは'目標'ゾーンと呼ばれるただ一つのゾーンの子孫に関する信用声明を含んでいます。 例えば、DLVドメインtrustbroker.example.comはorgゾーンを狙うことができました、そして、DLVドメインbar.example.comは根を狙うことができました。

   A DLV domain contains one or more DLV records [RFC4431] for each of
   the target's descendant zones that have registered security
   information with it.  For a given zone, the corresponding name in the
   DLV domain is formed by replacing the target zone name with the DLV
   domain name.

DLVドメインはセキュリティ情報をそれに登録したそれぞれの目標の下降のゾーンのための1つ以上のDLV記録[RFC4431]を含んでいます。 与えられたゾーンにおいて、DLVドメインの対応する名前は、ターゲットゾーン名をDLVドメイン名に取り替えることによって、形成されます。

   For example, assuming the DLV domain trustbroker.example.com targets
   the org zone, any DLV records corresponding to the zone example.org
   can be found at example.trustbroker.example.com.  DLV records
   corresponding to the org zone can be found at the apex of
   trustbroker.example.com.

例えば、DLVドメインtrustbroker.example.com目標がorgゾーンであると仮定する場合、example.trustbroker.example.comでゾーンexample.orgに対応するどんなDLV記録も見つけることができます。 trustbroker.example.comの頂点でorgゾーンに対応するDLV記録を見つけることができます。

   As another example, assuming the DLV domain bar.example.com targets
   the root zone, DLV records corresponding to the zone example.org can
   be found at example.org.bar.example.com.  DLV records corresponding
   to the org zone can be found at org.bar.example.com, and DLV records
   corresponding to the root zone itself can be found at the apex of
   bar.example.com.

別の例として、DLVドメインbar.example.com目標がルートゾーンであると仮定する場合、example.org.bar.example.comでゾーンexample.orgに対応するDLV記録を見つけることができます。 org.bar.example.comでorgゾーンに対応するDLV記録を見つけることができます、そして、bar.example.comの頂点でルートゾーン自体に対応するDLV記録を見つけることができます。

   A DLV domain need not contain data other than DLV records,
   appropriate DNSSEC records validating that data, the apex NS and SOA
   records, and, optionally, delegations.  In most cases, the operator
   of a DLV domain will probably not want to include any other RR types
   in the DLV domain.

DLVドメインはDLV記録、そのデータを有効にする適切なDNSSEC記録、頂点NS、SOA記録、および任意に代表団以外のデータを含む必要はありません。 多くの場合、DLVドメインのオペレータはたぶんDLVドメインにいかなる他のRRタイプも含みたくならないでしょう。

   To gain full benefit from aggressive negative caching, described in
   Section 6, a DLV domain SHOULD NOT use minimally-covering NSEC
   records, as described in [RFC4470], and it SHOULD NOT use NSEC3
   records, as described in [NSEC3].

セクション6、[RFC4470]で説明されるようにNSEC記録を最少量でカバーするDLVドメインSHOULD NOT使用、およびそれで説明された攻撃的な否定的キャッシュから完全給付を獲得するのに、SHOULD NOTはNSEC3記録を使用します、[NSEC3]で説明されるように。

4.  Overview of Validator Behavior

4. Validatorの振舞いの概観

   To minimize the load on the DLV domain's authoritative servers as
   well as query response time, a validator SHOULD first attempt
   validation using any applicable (non-DLV) trust anchors.  If the
   validation succeeds (with a result of Secure), DLV processing need
   not occur.

DLVドメインの正式のサーバで負荷を最小にして、応答時間について質問するために、どんな適切な(非DLVの)信用も使用するvalidator SHOULD最初の試み合法化は投錨されます。 合法化が成功するなら(Secureの結果で)、DLV処理は起こる必要はありません。

   When configured with a trust anchor for a DLV domain, a validator
   SHOULD attempt to validate all responses at and below the target of
   that DLV domain.

信用アンカーにDLVドメインに構成されると、目標におけるそのDLVドメインの目標の下におけるすべての応答を有効にするためにvalidator SHOULD試みます。

Weiler                       Informational                      [Page 3]

RFC 5074                          DLV                      November 2007

[3ページ]RFC5074DLV2007年11月の情報のウィーラー

   To do validation using DLV, a validator looks for a (validated) DLV
   RRset applicable to the query, as described in the following section,
   and uses it as though it were a DS RRset to validate the answer using
   the normal procedures in Section 5 of RFC 4035.

validatorは、DLVを使用することで合法化するのに、以下のセクションで説明されるように質問に適切な(有効にされます)DLV RRsetを探して、まるでそれがRFC4035のセクション5の正常な手順を用いることで答えを有効にするDS RRsetであるかのようにそれを使用します。

   For each response, the validator attempts validation using the
   "closest enclosing" DLV RRset in the DLV domain, which is the DLV
   RRset with the longest name that matches the query or could be an
   ancestor of the QNAME.  For example, assuming the DLV domain
   trustbroker.example.com targets the org zone, and there exist DLV
   RRsets named trustbroker.example.com (applicable to org),
   example.trustbroker.example.com (applicable to example.org), and
   sub.example.trustbroker.example.com (applicable to sub.example.org),
   a validator would use the sub.example.trustbroker.example.com DLV
   RRset for validating responses to a query for sub.example.org.

各応答のために、validatorは、DLVドメイン(質問に合っているか、QNAMEの先祖であるかもしれない最も長い名前があるDLV RRsetである)で「最も近い同封」DLV RRsetを使用することで合法化を試みます。 例えば、DLVドメインtrustbroker.example.comがorgゾーンを狙って、trustbroker.example.comというDLV RRsets(orgに適切な)、example.trustbroker.example.com(example.orgに適切な)、およびsub.example.trustbroker.example.com(sub.example.orgに適切な)が存在すると仮定する場合、validatorは、sub.example.orgのために質問への応答を有効にするのにsub.example.trustbroker.example.com DLV RRsetを使用するでしょう。

   The choice of which DLV record(s) to use has a significant impact on
   the query load seen at DLV domains' authoritative servers.  The
   particular DLV selection rule described in this document results in a
   higher query load than some other selection rules, but it has some
   advantages in terms of the security policies that it can implement.
   More detailed discussion of this DLV selection rule as well as
   several alternatives that were considered along the way can be found
   in [INI1999-19].

選択はどのDLV記録を使用するかをDLVドメインの正式のサーバで見られた質問負荷に重要な影響を与えます。 特定のDLV選択規則は本書ではある他の選択規則より高い質問負荷における結果について説明しましたが、それには、いくつかの利点が実行できる安全保障政策であります。 [INI1999-19]で道に沿って考えられたいくつかの選択肢と同様にこのDLV選択規則の、より詳細な議論を見つけることができます。

5.  Details of Validator Behavior

5. Validatorの振舞いの詳細

   As above, to minimize the load on the DLV domain's authoritative
   servers as well as query response time, a validator SHOULD first
   attempt validation using any applicable (non-DLV) trust anchors.  If
   the validation succeeds (with a result of Secure), DLV processing
   need not occur.

同じくらい上では、DLVドメインの正式のサーバで負荷を最小にして、応答時間について質問するために、どんな適切な(非DLVの)信用も使用するvalidator SHOULD最初の試み合法化が投錨されます。 合法化が成功するなら(Secureの結果で)、DLV処理は起こる必要はありません。

   To find the closest enclosing DLV RRset for a given query, the
   validator starts by looking for a DLV RRset corresponding to the
   QNAME.  If it doesn't find a DLV RRset for that name (as confirmed by
   the presence of a validated NSEC record) and that name is not the
   apex of the DLV domain, the validator removes the leading label from
   the name and tries again.  This process is repeated until a DLV RRset
   is found or it is proved that there is no enclosing DLV RRset
   applicable to the QNAME.  In all cases, a validator SHOULD check its
   cache for the desired DLV RRset before issuing a query.  Section 8
   discusses a slight optimization to this strategy.

最も近くで与えられた質問に関して同封がDLV RRsetであることがわかるために、validatorはQNAMEに対応するDLV RRsetを探すことによって、始動します。 その名前に関してDLV RRsetを見つけないで(有効にされたNSEC記録の存在によって確認されるように)、またその名前がDLVドメインの頂点でないなら、validatorは名前から主なラベルを取り除いて、再試行します。 DLV RRsetが見つけられるか、またはQNAMEに適切なDLV RRsetを同封してはいけないと立証されるまで、この過程は繰り返されます。 質問を発行する前に、全部で、ケース、validator SHOULDは必要なDLV RRsetがないかどうかキャッシュをチェックします。 セクション8はこの戦略にわずかな最適化について論じます。

   Having found the closest enclosing DLV RRset or received proof that
   no applicable DLV RRset exists, the validator MUST validate the RRset
   or non-existence proof using the normal procedures in Section 5 of
   RFC 4035.  In particular, any delegations within the DLV domain need

最も近くで同封がDLV RRsetであることがわかるか、またはどんな適切なDLV RRsetも存在していないという証拠を受けたので、RFC4035のセクション5の正常な手順を用いて、validatorはRRsetか非存在証拠を有効にしなければなりません。 特にDLVドメインの必要性の中のどんな代表団

Weiler                       Informational                      [Page 4]

RFC 5074                          DLV                      November 2007

[4ページ]RFC5074DLV2007年11月の情報のウィーラー

   to be followed, with normal DNSSEC validation applied.  If validation
   of the DLV RRset leads to a result of Bogus, then it MUST NOT be used
   and the validation result for the original response SHOULD be Bogus,
   also.  If validation of the DLV RRset leads to a result of Insecure
   (i.e., the DLV record is in an unsecured portion of the DLV domain),
   then it MUST NOT be used and the validation result for the original
   response SHOULD be Insecure, also.  (It should be very odd, indeed,
   to find part of a DLV domain marked as Insecure: this is likely to
   happen only when there are delegations within the DLV domain and some
   portions of that domain use different cryptographic signing
   algorithms.)  If the validation of the DLV RRset leads to a result of
   Secure, the validator then treats that DLV RRset as though it were a
   DS RRset for the applicable zone and attempts validation using the
   procedures described in Section 5 of RFC 4035.

正常なDNSSECと共に続かれるように、合法化は申し込まれました。 DLV RRsetの合法化がBogusの結果につながるなら、それを使用してはいけません、そして、合法化は結果として生じます。また、オリジナルの応答SHOULDのための、Bogusになってください。 DLV RRsetの合法化がInsecureの結果につながるなら(すなわち、DLV記録がDLVドメインの非安全にされた部分にあります)、それを使用してはいけません、そして、合法化は結果として生じます。また、オリジナルの応答SHOULDのための、Insecureになってください。 (本当に、Insecureとして示されるDLVドメインの一部を見つけるのは非常に変であるべきです: DLVドメインの中に代表団があるときだけ、これは起こりそうであって、そのドメインの数個の部分が異なった暗号の調印アルゴリズムを使用します。) DLV RRsetの合法化がSecureの結果につながるなら、validatorは、次に、まるでそれが適切なゾーンへのDS RRsetであるかのようにそのDLV RRsetを扱って、RFC4035のセクション5で説明された手順を用いることで合法化を試みます。

   In the interest of limiting complexity, validators SHOULD NOT attempt
   to use DLV to validate data from another DLV domain.

複雑さを制限することのために、validators SHOULDは、別のDLVドメインからのデータを有効にするのにDLVを使用するのを試みません。

6.  Aggressive Negative Caching

6. 攻撃的な否定的キャッシュ

   To minimize load on authoritative servers for DLV domains,
   particularly those with few entries, DLV validators SHOULD implement
   aggressive negative caching, as defined in this section.

DLVドメイン、特にわずかなエントリーがあるそれらのために正式のサーバで負荷を最小にするために、DLV validators SHOULDは攻撃的な否定的キャッシュを実行します、このセクションで定義されるように。

   Previously, cached negative responses were indexed by QNAME, QCLASS,
   QTYPE, and the setting of the CD bit (see RFC 4035, Section 4.7), and
   only queries matching the index key would be answered from the cache.
   With aggressive negative caching, the validator, in addition to
   checking to see if the answer is in its cache before sending a query,
   checks to see whether any cached and validated NSEC record denies the
   existence of the sought record(s).

以前、キャッシュされた否定応答はCDビットのQNAME、QCLASS、QTYPE、および設定によって索引をつけられました、そして、(RFC4035を見てください、セクション4.7)インデックスキーに合っている質問だけがキャッシュから答えられるでしょう。 攻撃的な否定的キャッシュに、質問を送る前に、キャッシュで答えがあるかを確認するためにチェックすることに加えて、validatorは、何かキャッシュされて有効にされたNSEC記録が探された記録の存在を否定するかどうかを見るために問い合わせます。

   Using aggressive negative caching, a validator will not make queries
   for any name covered by a cached and validated NSEC record.
   Furthermore, a validator answering queries from clients will
   synthesize a negative answer whenever it has an applicable validated
   NSEC in its cache unless the CD bit was set on the incoming query.

攻撃的な否定的キャッシュを使用して、validatorはキャッシュされて有効にされたNSEC記録でどんな名前のための質問もカバーさせないでしょう。 その上、CDビットが入って来る質問に設定されなかったならキャッシュで適切な有効にされたNSECを持っているときはいつも、クライアントから質問に答えるvalidatorは否定的な返答を統合するでしょう。

6.1.  Implementation Notes

6.1. 実現注意

   Implementing aggressive negative caching suggests that a validator
   will need to build an ordered data structure of NSEC records in order
   to efficiently find covering NSEC records.  Only NSEC records from
   DLV domains need to be included in this data structure.

攻撃的な否定的キャッシュを実行するのは、validatorが、効率的に覆いNSEC記録を見つけるためにNSEC記録の規則正しいデータ構造を築き上げる必要であるのを示します。 DLVドメインからのNSEC記録だけが、このデータ構造に含まれる必要があります。

Weiler                       Informational                      [Page 5]

RFC 5074                          DLV                      November 2007

[5ページ]RFC5074DLV2007年11月の情報のウィーラー

   Also note that some DLV validator implementations do not synthesize
   negative answers to insert into outgoing responses -- they only use
   aggressive negative caching when looking up DLV RRs as part of their
   internal DLV validation.

また、いくつかのDLV validator実現が外向的な応答に挿入する否定的な返答を統合しないことに注意してください--彼らの内部のDLV合法化の一部としてDLV RRsを見上げるときだけ、それらは攻撃的な否定的キャッシュを使用します。

7.  Overlapping DLV Domains

7. DLVドメインを重ね合わせます。

   It is possible to have multiple DLV domains targeting overlapping
   portions of the DNS hierarchy.  For example, two DLV domains, perhaps
   operated by different parties, might target the org zone, or one DLV
   domain might target the root while another targets org.

DNS階層構造の重なっている部分を狙う複数のDLVドメインを持っているのは可能です。 例えば、2つの恐らく異なったパーティーによって運用されたDLVドメインがorgゾーンを狙うかもしれませんか、または別のものがorgを狙っている間、1つのDLVドメインが根を狙うかもしれません。

   If a validator supports multiple DLV domains, the choice of
   precedence in case of overlap is left up to the implementation and
   SHOULD be exposed as a configuration option to the user (as compared
   to the choice of DLV records within each domain, a precedence for
   which is clearly specified in this document).  As a very simple
   default, a validator could give precedence to the most specific DLV
   domain.

validatorが複数のDLVドメインを支持するなら、露出されていて、オーバラップの場合の先行の選択はユーザへの設定オプションとして実現とSHOULDに任せられます(どれが明確に本書では指定されるかために各ドメイン、先行の中でDLV記録の選択と比べて)。 非常に簡単なデフォルトとして、validatorは最も特定のDLVドメインに優先権を与えることができました。

   Some other reasonable options include:

ある他の正当な選択は:

   1.  Searching all applicable DLV domains until an applicable DLV
       record is found that results in a successful validation of the
       response.  In the case where no applicable DLV record is found in
       any DLV domain, the answer will be treated as Unsecure.

1. それが適用されるDLV記録に見つけられるまですべての適切なDLVドメインを捜すと、応答のうまくいっている合法化はもたらされます。 どんな適用されるDLV記録もどんなDLVドメインでも見つけられない場合では、答えはUnsecureとして扱われるでしょう。

   2.  Applying some sort of precedence to the DLV domains based on
       their perceived trustworthiness.

2. それらが知覚された信頼できることに基づくDLVドメインにある種の先行を適用します。

   3.  Searching all applicable DLV domains for applicable DLV records
       and using only the most specific of those DLV records.

3. 適用されるDLV記録のためにすべての適切なDLVドメインを捜して、最も特定のそれらだけを使用して、DLVは記録します。

   4.  If multiple DLV domains provide applicable DLV records, use a
       threshold or scoring system (e.g., "best 2 out of 3") to
       determine the validation result.

4. 複数のDLVドメインが適用されるDLV記録を提供するなら、敷居か採点法を使用してください。(例えば、「3インチで最も良い2) 合法化を決定するのは結果として生じます」。

   The above list is surely not complete, and it's possible for
   validators to have different precedence rules and configuration
   options for these cases.  [INI1999-19] discusses different policies
   for selecting from multiple DLV records within the same DLV domain.
   That discussion may also be applicable to the question of which DLV
   domain to use and may be of interest to implementers of validators
   that support multiple DLV domains.

上記のリストは確実に完全ではありません、そして、validatorsにはこれらのケースのための異なった先行規則と設定オプションがあるのは、可能です。 [INI1999-19]は同じDLVドメインの中で複数のDLV記録から選び抜くための異なった方針について議論します。 その議論は、また、どのDLVドメインを使用したらよいかに関する質問に適切であるかもしれなく、複数のDLVドメインを支持するvalidatorsのimplementersに興味があるかもしれません。

Weiler                       Informational                      [Page 6]

RFC 5074                          DLV                      November 2007

[6ページ]RFC5074DLV2007年11月の情報のウィーラー

8.  Optimization

8. 最適化

   This section documents an optimization to further reduce query load
   on DLV servers and improve validator response time.

このセクションは、DLVサーバで質問負荷をさらに減少させて、validator応答時間を改良するために最適化を記録します。

   Authoritative servers, when processing a query for a DLV RRset,
   SHOULD include all DLV RRsets potentially applicable to a query
   (specifically, all DLV RRsets applicable to the QNAME and any of its
   ancestors) in the Additional section of the response as well as NSEC
   records proving the non-existence of any other applicable DLV records
   in the DLV domain.  Authoritative servers need only include DLV
   RRsets they're aware of -- RRsets in sub-zones may be omitted.

正式のサーバ、DLV RRsetのために質問を処理するとき、SHOULDはDLVドメインのいかなる他の適用されるDLV記録の非存在も立証するNSEC記録と同様に応答のAdditional部で潜在的に質問(明確に先祖のすべてのQNAMEに適切なDLV RRsetsとどれか)に適切なすべてのDLV RRsetsを含んでいます。 正式のサーバは彼らが意識しているDLV RRsetsを含むだけでよいです--サブゾーンのRRsetsは省略されるかもしれません。

   Validators still seek out of the closest enclosing DLV RRset first.
   If they receive any data about other DLV RRsets in the zone, they MAY
   cache and use it (assuming that it validates), thus avoiding further
   round-trips to the DLV domain's authoritative servers.

Validatorsは、最初にDLV RRsetを同封しながら、最も近くからまだ探しています。 ゾーンに何か他のDLV RRsetsに関するデータを受け取るなら、彼らは、それ(それを仮定しますそれが有効にする)をキャッシュして、使用するかもしれません、その結果、DLVドメインの正式のサーバとしてさらなる周遊旅行を避けます。

9.  Security Considerations

9. セキュリティ問題

   Validators MUST NOT use a DLV record unless it has been successfully
   authenticated.  Normally, validators will have a trust anchor for the
   DLV domain and use DNSSEC to validate the data in it.

それが首尾よく認証されていない場合、ValidatorsはDLV記録を使用してはいけません。 通常、validatorsは、DLVドメインへの信用アンカーがいて、それのデータを有効にするのにDNSSECを使用するでしょう。

   Aggressive negative caching increases the need for validators to do
   some basic validation of incoming NSEC records before caching them.
   In particular, the 'next name' field in the NSEC record MUST be
   within the zone that generated (and signed) the NSEC.  Otherwise, a
   malicious zone operator could generate an NSEC that reaches out of
   its zone -- into its ancestor zones, even up into the root zone --
   and use that NSEC to spoof away any name that sorts after the name of
   the NSEC.  We call these overreaching NSECs.  More insidiously, an
   attacker could use an overreaching NSEC in combination with a signed
   wildcard record to substitute a signed positive answer in place of
   the real data.  This checking is not a new requirement -- these
   attacks are a risk even without aggressive negative caching.
   However, aggressive negative caching makes the checking more
   important.  Before aggressive negative caching, NSECs were cached
   only as metadata associated with a particular query.  An overreaching
   NSEC that resulted from a broken zone signing tool or some
   misconfiguration would only be used by a cache for those queries that
   it had specifically made before.  Only an overreaching NSEC actively
   served by an attacker could cause misbehavior.  With aggressive
   negative caching, an overreaching NSEC can cause broader problems
   even in the absence of an active attacker.  This threat can be easily
   mitigated by checking the bounds on the NSEC.

攻撃的な否定的キャッシュはそれらをキャッシュする前にvalidatorsが入って来るNSEC記録の何らかの基本的な合法化をする必要性を増加させます。 NSECを発生させた(そして、サインされます)ゾーンの中に特に、NSEC記録の分野という'次の名前'があるに違いありません。 さもなければ、悪意があるゾーンのオペレータは、先祖ゾーンと、ルートゾーンの中へのゾーンからさえ達するNSECを発生させて、遠くでそれがNSECという名前の後に分類するどんな名前もだますのにそのNSECを使用できました。 私たちは、これらをNSECsに広がると呼びます。 より狡猾に、攻撃者は、サインされたワイルドカード記録と組み合わせて本当のデータに代わってサインされた積極的な答えを代入するのに広がりNSECを使用できました。 この照合は新しい要件ではありません--これらの攻撃は攻撃的な否定的キャッシュがなければリスクです。 しかしながら、攻撃的な否定的キャッシュで、照合は、より重要になります。 攻撃的な否定的キャッシュの前に、NSECsは単に特定の質問に関連しているメタデータとしてキャッシュされました。 壊れているゾーン調印ツールから生じた広がりNSECかいくらかのmisconfigurationがそれが以前明確にしたことがあったそれらの質問にキャッシュによって使用されるだけでしょう。 攻撃者によって活発に勤められた広がりNSECだけが不正行為を引き起こす場合がありました。 攻撃的な否定的キャッシュで、広がりNSECは活発な攻撃者がないときでさえより広い問題を引き起こす場合があります。 NSECの上の領域をチェックすることによって、容易にこの脅威を緩和できます。

Weiler                       Informational                      [Page 7]

RFC 5074                          DLV                      November 2007

[7ページ]RFC5074DLV2007年11月の情報のウィーラー

   As a reminder, validators MUST NOT use the mere presence of an RRSIG
   or apex DNSKEY RRset as a trigger for doing validation, whether
   through the normal DNSSEC hierarchy or DLV.  Otherwise, an attacker
   might perpetrate a downgrade attack by stripping off those RRSIGs or
   DNSKEYs.

思い出させるものとして、validatorsはRRSIG、正常なDNSSEC階層構造を通してか否かに関係なく、合法化するための引き金としての頂点DNSKEY RRsetまたはDLVの単なる存在を使用してはいけません。 さもなければ、攻撃者は、それらのRRSIGsかDNSKEYsを全部はぎ取ることによって、ダウングレード攻撃を犯すかもしれません。

   Section 8 of RFC 4034 describes security considerations specific to
   the DS RR.  Those considerations are equally applicable to DLV RRs.
   Of particular note, the key tag field is used to help select DNSKEY
   RRs efficiently, but it does not uniquely identify a single DNSKEY
   RR.  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.

RFC4034のセクション8はDS RRに特定のセキュリティ問題について説明します。 それらの問題は等しくDLV RRsに適切です。 特定の注意では、キー・タグ分野は効率的にDNSKEY RRsを選択するのを助けるのに使用されますが、それは唯一独身のDNSKEY RRを特定しません。 2異なったDNSKEY RRsには同じ所有者名、同じアルゴリズムタイプ、および同じキー・タグがあるのは、可能です。 DNSKEY RRを選択するのにキー・タグだけを使用する実現はいくつかの事情の間違った公開鍵を選択するかもしれません。

   For further discussion of the security implications of DNSSEC, see
   RFCs 4033, 4034, and 4035.

DNSSECのセキュリティ含意のさらなる議論に関しては、RFCs4033、4034、および4035を見てください。

10.  IANA Considerations

10. IANA問題

   DLV makes use of the DLV resource record (RR type 32769) previously
   assigned in [RFC4431].

DLVは以前に[RFC4431]で割り当てられたDLVリソース記録(RRは32769をタイプする)を利用します。

11.  References

11. 参照

11.1.  Normative References

11.1. 引用規格

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC4033]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
                 Rose, "DNS Security Introduction and Requirements",
                 RFC 4033, March 2005.

[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。

   [RFC4034]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
                 Rose, "Resource Records for the DNS Security
                 Extensions", RFC 4034, March 2005.

[RFC4034] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。

   [RFC4035]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
                 Rose, "Protocol Modifications for the DNS Security
                 Extensions", RFC 4035, March 2005.

[RFC4035]Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。

   [RFC4431]     Andrews, M. and S. Weiler, "The DNSSEC Lookaside
                 Validation (DLV) DNS Resource Record", RFC 4431,
                 February 2006.

[RFC4431] アンドリュースとM.とS.ウィーラー、「DNSSEC Lookaside合法化(DLV)DNSリソース記録」、RFC4431、2006年2月。

Weiler                       Informational                      [Page 8]

RFC 5074                          DLV                      November 2007

[8ページ]RFC5074DLV2007年11月の情報のウィーラー

11.2.  Informative References

11.2. 有益な参照

   [INI1999-19]  Weiler, S., "Deploying DNSSEC Without a Signed Root",
                 Technical Report 1999-19, Information Networking
                 Institute, Carnegie Mellon University, April 2004.

[INI1999-19]ウィーラー、「サインされた根なしでDNSSECを配備すること」での技術報告書1999-19、情報ネットワーク化が設けるS.、カーネギーメロン大学、2004年4月。

   [NSEC3]       Laurie, B., Sisson, G., Arends, R., and D. Blacka,
                 "DNSSEC Hashed Authenticated Denial of Existence", Work
                 in Progress, July 2007.

[NSEC3]ローリー、B.、シスン、G.、Arends、R.、D.Blacka、「DNSSECは存在の認証された否定を論じ尽くしたこと」が進行中(2007年7月)で働いています。

   [RFC4470]     Weiler, S. and J. Ihren, "Minimally Covering NSEC
                 Records and DNSSEC On-line Signing", RFC 4470,
                 April 2006.

[RFC4470] ウィーラーとS.とJ.Ihren、「nsec記録とDNSSECのオンライン調印を最少量で含んでいます」、RFC4470、2006年4月。

Weiler                       Informational                      [Page 9]

RFC 5074                          DLV                      November 2007

[9ページ]RFC5074DLV2007年11月の情報のウィーラー

Appendix A.  Acknowledgments

付録A.承認

   Johan Ihren, Paul Vixie, and Suzanne Woolf contributed significantly
   to the exploration of possible validator algorithms that led to this
   design.  More about those explorations is documented in [INI1999-19].

ジョハンIhren、ポールVixie、およびスザンヌ・ウルフはこのデザインにつながった可能なvalidatorアルゴリズムの探検にかなり貢献しました。 それらの探検に関する以上は[INI1999-19]に記録されます。

   Johan Ihren and the editor share the blame for aggressive negative
   caching.

ジョハンIhrenとエディタは攻撃的な否定的キャッシュのための非難を共有します。

   Thanks to David B. Johnson and Marvin Sirbu for their patient review
   of [INI1999-19] which led to this specification being far more
   complete.

彼らのこのはるかに完全な仕様に通じた[INI1999-19]の我慢強いレビューをデヴィッド・B.ジョンソンとマーヴィン・シルブをありがとうございます。

   Thanks to Mark Andrews, Rob Austein, David Blacka, Stephane
   Bortzmeyer, Steve Crocker, Wes Hardaker, Alfred Hoenes, Russ Housley,
   Peter Koch, Olaf Kolkman, Juergen Quittek, and Suzanne Woolf for
   their valuable comments on this document.

このドキュメントの彼らの貴重なコメントをマーク・アンドリュース、ロブAustein、デヴィッドBlacka、ステファーヌBortzmeyer、スティーブ・クロッカー、ウェスHardaker、アルフレッドHoenes、ラスHousley、ピーター・コッホ、オラフKolkman、ユルゲンQuittek、およびスザンヌ・ウルフをありがとうございます。

Author's Address

作者のアドレス

   Samuel Weiler
   SPARTA, Inc.
   7110 Samuel Morse Drive
   Columbia, Maryland  21046
   US

サミュエルウィーラースパルタInc.7110サミュエル・モースDriveメリーランド21046コロンビア(米国)

   EMail: weiler@tislabs.com

メール: weiler@tislabs.com

Weiler                       Informational                     [Page 10]

RFC 5074                          DLV                      November 2007

[10ページ]RFC5074DLV2007年11月の情報のウィーラー

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Weiler                       Informational                     [Page 11]

ウィーラーInformationalです。[11ページ]