Network Working Group S. Weiler
Request for Comments: 5074 SPARTA, Inc.
Category: Informational November 2007
Network Working Group S. Weiler
Request for Comments: 5074 SPARTA, Inc.
Category: Informational November 2007
DNSSEC Lookaside Validation (DLV)
DNSSEC后备验证（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安全（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
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]通过从信任锚点沿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].
[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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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，当验证器具有以下两种情况之一时，验证器可能期望区域是安全的：区域的预配置信任锚或区域父级中区域的已验证委派签名者（DS）记录（假定父级或另一祖先具有预配置的信任锚）。DLV添加了第三种机制：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可以以组织区域为目标，而DLV domain 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域包含一个或多个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以组织区域为目标，则可以在example.trustbroker.example.com上找到与区域example.org对应的任何DLV记录。对应于组织区域的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 domain bar.example.com以根区域为目标，那么可以在example.org.bar.example.com上找到对应于区域example.org的DLV记录。在org.bar.example.com上可以找到与组织区域相对应的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记录、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节所述，为了从积极的负缓存中获得全部好处，DLV域不应使用[RFC4470]中所述的最小覆盖NSEC记录，也不应使用[NSEC3]中所述的NSEC3记录。
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进行验证，验证器将查找适用于查询的（已验证的）DLV RRset，如下节所述，并将其当作DS RRset使用，以使用RFC 4035第5节中的正常过程验证答案。
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.
对于每个响应，验证程序都会尝试使用DLV域中的“最近封闭”DLV RRset进行验证，该DLV RRset是具有与查询匹配的最长名称的DLV RRset，或者可以是QNAME的祖先。例如，假设DLV域trustbroker.example.com以组织区域为目标，并且存在名为trustbroker.example.com（适用于组织）、example.trustbroker.example.com（适用于example.org）和sub.example.trustbroker.example.com（适用于sub.example.org）的DLV RRSET，验证器将使用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选择规则以及在此过程中考虑的几个备选方案的更详细讨论，请参见[INI1999-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，验证程序首先查找与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
在找到最接近的封闭DLV RRset或收到不存在适用DLV RRset的证明后，验证人必须使用RFC 4035第5节中的正常程序验证RRset或不存在证明。特别是，DLV域内的任何委托都需要
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的验证导致结果为假，则不得使用，且原始响应的验证结果也应为假。如果对DLV RRset的验证导致结果不安全（即，DLV记录位于DLV域的不安全部分），则不得使用它，并且原始响应的验证结果也应不安全。（事实上，发现标记为不安全的DLV域的一部分应该是非常奇怪的：只有当DLV域中存在委托并且该域的某些部分使用不同的加密签名算法时，才可能发生这种情况。）如果DLV RRset的验证导致安全签名的结果，然后，验证程序将该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记录所包含的任何名称进行查询。此外，回答客户端查询的验证器将在其缓存中有适用的已验证NSEC时合成否定答案，除非在传入查询上设置了CD位。
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记录的有序数据结构，以便有效地查找覆盖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 RRs时使用积极的否定缓存作为其内部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.
可以有多个DLV域以DNS层次结构的重叠部分为目标。例如，两个可能由不同方操作的DLV域可能以组织区域为目标，或者一个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.
如果验证器支持多个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记录，则使用阈值或评分系统（例如，“三取二最佳”）确定验证结果。
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 RRset查询时，应包括可能适用于查询的所有DLV RRset（特别是适用于QNAME及其任何祖先的所有DLV RRset）在回复的附加部分以及证明DLV域中不存在任何其他适用DLV记录的NSEC记录中。权威服务器只需要包括他们知道的DLV RRSET——子区域中的RRSET可以省略。
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 RRSET的任何数据，他们可能会缓存并使用它（假设它已验证），从而避免进一步往返到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域提供一个信任锚，并使用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也会导致更广泛的问题。通过检查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或DNSKEY来实施降级攻击。
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。需要特别注意的是，key tag字段用于帮助有效选择DNSKEY RR，但它不能唯一标识单个DNSKEY RR。两个不同的DNSKEY RRs可能具有相同的所有者名称、相同的算法类型和相同的密钥标记。在某些情况下，仅使用key标记选择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 40342005年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.和S.Weiler，“DNSSEC Lookaside Validation（DLV）DNS资源记录”，RFC 44312006年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 44702006年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为探索可能的验证器算法做出了重大贡献，这些算法导致了这种设计。有关这些探索的更多信息，请参见[1999-19]。
Johan Ihren and the editor share the blame for aggressive negative caching.
Johan 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.
感谢David B.Johnson和Marvin Sirbu对[INI1999-19]的患者回顾，这使得本规范更加完整。
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.
感谢Mark Andrews、Rob Austein、David Black、Stephane Bortzmeyer、Steve Crocker、Wes Hardaker、Alfred Hoenes、Russ Housley、Peter Koch、Olaf Kolkman、Juergen Quitek和Suzanne Woolf对本文件的宝贵评论。
Author's Address
作者地址
Samuel Weiler SPARTA, Inc. 7110 Samuel Morse Drive Columbia, Maryland 21046 US
美国马里兰州哥伦比亚市塞缪尔·莫尔斯大道7110号塞缪尔·韦勒斯巴达公司，邮编：21046
EMail: weiler@tislabs.com
EMail: weiler@tislabs.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.