[要約] RFC 5074は、DNSSEC Lookaside Validation（DLV）の仕様を定義しています。DLVは、DNSSECの信頼チェーンを構築するための補助的なメカニズムであり、信頼できるDLVレジストリを介して信頼できるキーを取得することが目的です。
Network Working Group S. Weiler
Request for Comments: 5074 SPARTA, Inc.
Category: Informational November 2007
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検証（DLV）は、DNS委任チェーンの外側にあるDNSセキュリティ（DNSSEC）トラストアンカーを公開するためのメカニズムです。これにより、リゾルバーの検証は、祖先が署名されていないか、子供向けの委任署名者（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
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]は、Trust Anchorから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.
現在の世界では、DNSルートと多くの主要なトップレベルドメインが署名されていないため、検証型のリゾルバー（「検証剤」）が多くのDNSSECに署名したゾーンを検証する唯一の方法は、事前に設定された信頼できるトラストアンカーのかなりのコレクションを維持することです。各DNSSECを有するバリデーターに複数の事前設定された信頼を維持することは、重要な管理上の課題を提示します。
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にトラストアンカーを公開する方法について説明します。
Some design trade-offs leading to the mechanism presented here are described in [INI1999-19].
ここで提示されるメカニズムにつながるいくつかの設計トレードオフは、[INI199-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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
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検証により、「DLVドメイン」と呼ばれるドメインのセットが、自分の子供ではないゾーンの安全なエントリポイントを公開できます。
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を使用すると、バリッターは、バリッターが2つのことのいずれかを持っている場合、ゾーンが安全であることを期待する場合があります。親または別の祖先）。DLVは、3番目のメカニズムを追加します。DLVドメインの検証済みエントリ（DLVドメインの事前に構成された信頼アンカーを推定）。DLVドメインにゾーン用のDLV RRSetが含まれている場合はいつでも、バリデーターは、指定されたゾーンに署名されることを期待する場合があります。ゾーンにDLV RRSetがないことは、必ずしもゾーンが安全でないと予想されることを意味するわけではありません。バリーターにゾーンを保護する必要があると信じる別の理由がある場合、そのゾーンのデータの検証はまだ試みる必要があります。
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 Domain 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 Domain TrustBroker.example.comがORGゾーンをターゲットにすると仮定すると、ゾーンexample.orgに対応するDLVレコードはexample.trustbroker.example.comにあります。ORGゾーンに対応するDLVレコードは、TrustBroker.example.comの頂点にあります。
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に対応するDLVレコードはexample.org.bar.example.comで見つけることができます。ORGゾーンに対応するDLVレコードは、org.bar.example.comで見つけることができ、ルートゾーン自体に対応するDLVレコードは、bar.example.comの頂点にあります。
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レコード以外のデータ、そのデータ、Apex 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]で説明されているように、DLVドメインは最小限のNSECレコードを使用してはなりません。
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非）トラストアンカーを使用して最初に検証を試みる必要があります。検証が成功した場合（安全な結果で）、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ドメインのターゲット以下のすべての応答を検証しようと試みる必要があります。
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.
DLVを使用して検証を行うには、次のセクションで説明されているように、VALIDATORはクエリに適用される（検証済みの）DLV RRSetを探し、DS rRSetであるかのように使用して、セクション5の通常の手順を使用して回答を検証するかのように使用します。RFC 4035。
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ドメインの「最も近い囲い」DLV RRSetを使用して検証を試みます。DLVドメインは、クエリに一致する最長の名前を持つDLV RRSetであるか、QNameの祖先である可能性があります。たとえば、DLV Domain TrustBroker.example.comがORGゾーンをターゲットにしていると仮定し、TrustBroker.example.com（ORGに該当）という名前のdlv rrsetsが存在します。sub.example.trustbroker.example.com（sub.example.orgに該当する）、バリデーターはsub.example.trustbroker.example.com dlv rrsetを使用して、sub.example.orgのクエリへの応答を検証します。
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選択ルールは、他の選択ルールよりもクエリ負荷が高くなりますが、実装できるセキュリティポリシーに関してはいくつかの利点があります。このDLV選択ルールのより詳細な議論と、途中で考慮されたいくつかの選択肢は、[INI199-19]に記載されています。
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以外の）信頼アンカーを使用して最初に検証を試みる必要があります。検証が成功した場合（安全な結果で）、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ドメインの頂点ではない場合、有効化者は主要なラベルを名前から削除し、再び試します。このプロセスは、DLV RRSETが見つかるまで繰り返されます。または、QNAMEに適用されるDLV RRSetを囲むことがないことが証明されます。すべての場合において、バリデーターは、クエリを発行する前に、目的の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 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.
最も近い囲いDLV RRSETを見つけたか、該当するDLV RRSETが存在しないという証明を受け取った場合、VALIDATORはRFC 4035のセクション5の通常の手順を使用してRRSETまたは非存在証明を検証する必要があります。通常のDNSSEC検証が適用されています。DLV RRSETの検証が偽の結果につながる場合、それを使用する必要はなく、元の応答の検証結果も偽物でなければなりません。DLV RRSTの検証が不安定な結果につながる場合（つまり、DLVレコードがDLVドメインの無担保部分にある）、使用してはならず、元の応答の検証結果も安全である必要があります。（実際、不安とマークされたDLVドメインの一部を見つけることは非常に奇妙なはずです。これは、DLVドメイン内に代表団があり、そのドメインの一部が異なる暗号化署名アルゴリズムを使用している場合にのみ発生する可能性があります。）DLV RRSETのSECUREの結果につながると、VALIDATORはDLV RRSETを該当するゾーンのDS RRSETであるかのように扱い、RFC 4035のセクション5で説明した手順を使用して検証を試みます。
In the interest of limiting complexity, validators SHOULD NOT attempt to use DLV to validate data from another DLV domain.
複雑さを制限するために、バリデーターはDLVを使用して別のDLVドメインからのデータを検証しようとしないでください。
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バリデーターが積極的なネガティブキャッシュを実装する必要があります。
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).
以前は、キャッシュされた負の応答はQNAME、QCLASS、QTYPE、およびCDビットの設定によってインデックス付けされており（RFC 4035、セクション4.7を参照）、インデックスキーに一致するクエリのみがキャッシュから回答されます。積極的なネガティブキャッシュを使用して、バリーターは、クエリを送信する前に回答がキャッシュにあるかどうかを確認することに加えて、キャッシュされた検証済みの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.
積極的なネガティブキャッシュを使用して、バリデーターは、キャッシュされた検証済みのNSECレコードでカバーされている名前のクエリを作成しません。さらに、クライアントからのクエリに応答するバリデーターは、CDビットが着信クエリに設定されていない限り、キャッシュに適用可能な検証済みのNSECがある場合は否定的な答えを統合します。
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.
積極的なネガティブキャッシングの実装は、NSECレコードを効率的に見つけるために、VALIBARTARがNSECレコードの順序付けられたデータ構造を構築する必要があることを示唆しています。このデータ構造には、DLVドメインのNSECレコードのみを含める必要があります。
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バリデーターの実装は、挿入への挿入に対する否定的な回答を合成しないことに注意してください。内部DLV検証の一部としてDLV RRSを調べるときにのみ積極的なネガティブキャッシュを使用します。
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ゾーンをターゲットにするか、1つのDLVドメインがルートをターゲットにしている間、別のDLVドメインがORGをターゲットにする場合があります。
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.
バリデーターが複数のDLVドメインをサポートしている場合、オーバーラップの場合の優先順位の選択は実装に任され、ユーザーの構成オプションとして公開する必要があります（各ドメイン内のDLVレコードの選択と比較して、どの優先事項であるかこのドキュメントで明確に指定されています）。非常に単純なデフォルトとして、バリデーターは最も特定の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レコードが見つからない場合、答えは安全でないと扱われます。
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.
上記のリストは確実に完全ではなく、これらのケースの異なる優先順位ルールと構成オプションを検証者が持つことができます。[INI1999-19]は、同じDLVドメイン内の複数のDLVレコードから選択するためのさまざまなポリシーについて説明します。その議論は、どのDLVドメインを使用するかという問題にも適用される可能性があり、複数のDLVドメインをサポートするバリデーターの実装者にとって興味深いものである可能性があります。
This section documents an optimization to further reduce query load on DLV servers and improve validator response time.
このセクションでは、DLVサーバーのクエリ負荷をさらに削減し、バリデーター応答時間を改善するための最適化を文書化します。
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 RRSTのクエリを処理する場合、応答の追加セクションとNSEC Recordsの追加セクションで、クエリ（具体的にはQNAMEおよびその祖先に適用可能なすべてのDLV RRSets）に適用可能なすべてのDLV RRSetsを含める必要があります。DLVドメイン内の他の適用されるDLVレコードの存在しないことを証明します。権威あるサーバーには、認識しているDLV rrsetのみが含まれている必要があります。サブゾーンの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.
バリデーターは、最初にDLV RRSETを囲む最も近い囲いを求めています。ゾーン内の他のDLV rrsetsに関するデータを受け取った場合、キャッシュして使用することができます（検証すると仮定して）。したがって、DLVドメインの信頼できるサーバーへのさらなるラウンドトリップを回避できます。
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.
バリデーターは、DLVレコードが正常に認証されていない限り、DLVレコードを使用してはなりません。通常、バリデーターは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.
積極的なネガティブキャッシングにより、バリッターがキャッシュする前に、入ってくるNSECレコードの基本的な検証を行う必要性が高まります。特に、NSECレコードの「次の名前」フィールドは、NSECを生成（および署名）したゾーン内にある必要があります。それ以外の場合、悪意のあるゾーンオペレーターは、ゾーンから祖先ゾーンに到達するNSECを生成し、ルートゾーンにまで登場し、そのNSECを使用して、NSECの名前の後に並べ替える名前を押し出すことができます。これらのオーバーリーチNSECと呼びます。より潜在的に、攻撃者は、署名されたワイルドカードレコードと組み合わせてオーバーリーチNSECを使用して、実際のデータの代わりに署名された肯定的な答えを置き換えることができます。このチェックは新しい要件ではありません。これらの攻撃は、積極的なネガティブキャッシュがなくてもリスクです。ただし、積極的なネガティブキャッシングにより、チェックがより重要になります。積極的なネガティブキャッシングの前に、NSECは特定のクエリに関連するメタデータとしてのみキャッシュされました。壊れたゾーン署名ツールまたはいくつかの誤解に起因するオーバーリーチNSECは、以前に特別に作成されたクエリのキャッシュによってのみ使用されます。攻撃者が積極的に提供するNSECのオーバーリーチのみが不正行為を引き起こす可能性があります。積極的なネガティブキャッシュを使用すると、NSECを超えていると、アクティブな攻撃者がいなくても、より広範な問題を引き起こす可能性があります。この脅威は、NSECの境界をチェックすることで簡単に軽減できます。
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.
リマインダーとして、バリデーターは、通常のDNSSEC階層であろうとDLVを介して、検証を行うためのトリガーとして、RRSIGまたはAPEX DNSKEY RRSetの単なる存在を使用してはなりません。それ以外の場合、攻撃者は、それらのRRSIGまたは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.
RFC 4034のセクション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のセキュリティへの影響についての詳細については、RFCS 4033、4034、および4035を参照してください。
DLV makes use of the DLV resource record (RR type 32769) previously assigned in [RFC4431].
DLVは、[RFC4431]で以前に割り当てられたDLVリソースレコード（RRタイプ32769）を使用しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[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.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル変更」、RFC 4035、2005年3月。
[RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside Validation (DLV) DNS Resource Record", RFC 4431, February 2006.
[RFC4431] Andrews、M。and S. Weiler、「DNSSEC Lookaside Validation（DLV）DNS Resource Record」、RFC 4431、2006年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] Weiler、S。、「署名されたルートなしでDNSSECの展開」、テクニカルレポート1999-19、情報ネットワーキング研究所、カーネギーメロン大学、2004年4月。
[NSEC3] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNSSEC Hashed Authenticated Denial of Existence", Work in Progress, July 2007.
[NSEC3] Laurie、B.、Sisson、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] Weiler、S。およびJ. Ihren、「NSECレコードとDNSSECオンライン署名を最小限に抑える」、RFC 4470、2006年4月。
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].
Johan Ihren、Paul Vixie、およびSuzanne Woolfは、このデザインにつながった可能性のあるバリデーターアルゴリズムの調査に大きく貢献しました。これらの探索の詳細については、[INI199-19]に記録されています。
Johan Ihren and the editor share the blame for aggressive negative caching.
ヨハン・イーレンと編集者は、積極的なネガティブキャッシングの責任を共有しています。
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]の患者レビューをしてくれたDavid B. JohnsonとMarvin Sirbuに感謝します。
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.
マーク・アンドリュース、ロブ・アウスタイン、デビッド・ブラッカ、ステフェーン・ボルツマイヤー、スティーブ・クロッカー、ウェス・ハーデイカー、アルフレッド・ホーネス、ラス・ヒューズリー、ピーター・コッホ、オラフ・コルクマン、ジュエルゲン・キッテク、およびスザンヌ・ウルフのこの文書への貴重なコメントをありがとう。
Author's Address
著者の連絡先
Samuel Weiler SPARTA, Inc. 7110 Samuel Morse Drive Columbia, Maryland 21046 US
Samuel Weiler Sparta、Inc。7110 Samuel Morse Drive Columbia、Maryland 21046 US
EMail: weiler@tislabs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。