Network Working Group H. Eland
Request for Comments: 4986 Afilias Limited
Category: Informational R. Mundy
SPARTA, Inc.
S. Crocker
Shinkuro Inc.
S. Krishnaswamy
SPARTA, Inc.
August 2007
Network Working Group H. Eland
Request for Comments: 4986 Afilias Limited
Category: Informational R. Mundy
SPARTA, Inc.
S. Crocker
Shinkuro Inc.
S. Krishnaswamy
SPARTA, Inc.
August 2007
Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover
与DNS安全（DNSSEC）信任锚滚动相关的要求
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
摘要
Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers.
每个DNS安全感知解析程序必须至少有一个信任锚点，用作验证来自DNS签名区域的响应的基础。出于各种原因，大多数DNS安全感知解析程序都需要有多个信任锚。对于某些操作，手动监视和更新信任锚可能是可行的，但许多操作将需要自动方法来更新其安全感知解析器中的信任锚。本文档确定了安全感知DNS解析程序的自动DNS信任锚点翻转解决方案必须满足的要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. No Known Intellectual Property Encumbrance . . . . . . . . 6
5.3. General Applicability . . . . . . . . . . . . . . . . . . . 7
5.4. Support Private Networks . . . . . . . . . . . . . . . . . 7
5.5. Detection of Stale Trust Anchors . . . . . . . . . . . . . 7
5.6. Manual Operations Permitted . . . . . . . . . . . . . . . . 7
5.7. Planned and Unplanned Rollovers . . . . . . . . . . . . . . 7
5.8. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 8
5.9. High Availability . . . . . . . . . . . . . . . . . . . . . 8
5.10. New RR Types . . . . . . . . . . . . . . . . . . . . . . . 8
5.11. Support for Trust Anchor Maintenance Operations . . . . . . 8
5.12. Recovery from Compromise . . . . . . . . . . . . . . . . . 8
5.13. Non-Degrading Trust . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. No Known Intellectual Property Encumbrance . . . . . . . . 6
5.3. General Applicability . . . . . . . . . . . . . . . . . . . 7
5.4. Support Private Networks . . . . . . . . . . . . . . . . . 7
5.5. Detection of Stale Trust Anchors . . . . . . . . . . . . . 7
5.6. Manual Operations Permitted . . . . . . . . . . . . . . . . 7
5.7. Planned and Unplanned Rollovers . . . . . . . . . . . . . . 7
5.8. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 8
5.9. High Availability . . . . . . . . . . . . . . . . . . . . . 8
5.10. New RR Types . . . . . . . . . . . . . . . . . . . . . . . 8
5.11. Support for Trust Anchor Maintenance Operations . . . . . . 8
5.12. Recovery from Compromise . . . . . . . . . . . . . . . . . 8
5.13. Non-Degrading Trust . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
The Domain Name System Security Extensions (DNSSEC), as described in [2], [3], and [4], define new records and protocol modifications to DNS that permit security-aware resolvers to validate DNS Resource Records (RRs) from one or more Trust Anchors held by such security-aware resolvers.
如[2]、[3]和[4]所述，域名系统安全扩展（DNSSEC）定义了DNS的新记录和协议修改，允许安全感知解析程序从此类安全感知解析程序持有的一个或多个信任锚验证DNS资源记录（RRs）。
Security-aware resolvers will have to initially obtain their Trust Anchors in a trustworthy manner to ensure the Trust Anchors are correct and valid. There are a number of ways that this initial step can be accomplished; however, details of this step are beyond the scope of this document. Once an operator has obtained Trust Anchors, initially entering the Trust Anchors into their security-aware resolvers will in many instances be a manual operation.
具有安全意识的解析程序必须首先以可信的方式获取其信任锚，以确保信任锚是正确和有效的。有许多方法可以完成这一初始步骤；但是，此步骤的详细信息超出了本文档的范围。一旦操作员获得信任锚，在许多情况下，最初将信任锚输入其安全感知解析器将是手动操作。
For some operational environments, manual management of Trust Anchors might be a viable approach. However, many operational environments will require a more automated, specification-based method for updating and managing Trust Anchors. This document provides a list of requirements that can be used to measure the effectiveness of any proposed automated Trust Anchor rollover mechanism in a consistent manner.
对于某些操作环境，手动管理信任锚可能是一种可行的方法。然而，许多操作环境将需要更自动化、基于规范的方法来更新和管理信任锚。本文档提供了一个需求列表，可用于以一致的方式衡量任何建议的自动信任锚滚动机制的有效性。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The use of RFC 2119 words in the requirements is intended to unambiguously describe a requirement. If a tradeoff is to be made between conflicting requirements when choosing a solution, the requirement with MUST language will have higher preference than requirements with SHOULD, MAY, or RECOMMENDED language. It is understood that a tradeoff may need to be made between requirements that both contain RFC 2119 language.
在需求中使用RFC 2119词语旨在明确描述需求。如果在选择解决方案时要在冲突的需求之间进行权衡，那么使用“必须”语言的需求将比使用“应该”、“可能”或“建议”语言的需求具有更高的优先级。可以理解的是，可能需要在两者都包含RFC 2119语言的需求之间进行权衡。
DNS resolvers need to have one or more starting points to use in obtaining DNS answers. The starting points for stub resolvers are normally the IP addresses for one or more recursive name servers. The starting points for recursive name servers are normally IP addresses for DNS Root name servers. Similarly, security-aware resolvers must have one or more starting points to use for building the authenticated chain to validate a signed DNS response. Instead of IP addresses, DNSSEC requires that each resolver trust one or more
DNS解析程序需要有一个或多个起点才能用于获取DNS答案。存根解析器的起点通常是一个或多个递归名称服务器的IP地址。递归名称服务器的起点通常是DNS根名称服务器的IP地址。类似地，具有安全意识的解析程序必须有一个或多个起点，用于构建经过身份验证的链以验证签名的DNS响应。DNSSEC要求每个解析器信任一个或多个IP地址，而不是IP地址
DNSKEY RRs or DS RRs as their starting point. Each of these starting points is called a Trust Anchor.
DNSKEY RRs或DS RRs作为其起点。这些起点中的每一个都称为信任锚。
It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors when they are created by the signed zone operator nor are they Trust Anchors because the records are published in the signed zone. A DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a security-aware resolver determines that the public key or hash will be used as a Trust Anchor. Thus, the signed zone operator that created and/or published these RRs may not know if any of the DNSKEY RRs or DS RRs associated with their zone are being used as Trust Anchors by security-aware resolvers. The obvious exceptions are the DNSKEY RRs for the Root Zone, which will be used as Trust Anchors by many security-aware resolvers. For various reasons, DNSKEY RRs or DS RRs from zones other than Root can be used by operators of security-aware resolvers as Trust Anchors. It follows that responsibility lies with the operator of the security-aware resolver to ensure that the DNSKEY and/or DS RRs they have chosen to use as Trust Anchors are valid at the time they are used by the security-aware resolver as the starting point for building the authentication chain to validate a signed DNS response.
应该注意的是，当DNSKEY RRs和DS RRs由签名区域操作员创建时，它们不是信任锚，也不是信任锚，因为记录是在签名区域中发布的。当安全感知解析器的操作员确定公钥或哈希将用作信任锚时，DNSKEY RR或DS RR将成为信任锚。因此，创建和/或发布这些RRs的签名区域操作员可能不知道是否有任何与其区域相关联的DNSKEY RRs或DS RRs被安全感知解析程序用作信任锚。明显的例外是根区域的DNSKEY RRs，它将被许多具有安全意识的解析程序用作信任锚。出于各种原因，具有安全意识的解析程序的操作员可以使用来自根以外区域的DNSKEY RRs或DS RRs作为信任锚。因此，安全感知解析程序的操作员有责任确保他们选择用作信任锚的DNSKEY和/或DS RRs在安全感知解析程序将其用作构建认证链以验证签名DNS响应的起点时有效。
When operators of security-aware resolvers choose one or more Trust Anchors, they must also determine the method(s) they will use to ensure that they are using valid RRs and that they are able to determine when RRs being used as Trust Anchors should be replaced or removed. Early adopters of DNS signed zones have published information about the processes and methods they will use when their DNSKEY and/or DS RRs change so that operators of security-aware resolvers can manually change the Trust Anchors at the appropriate time. This manual approach will not scale and, therefore, drives the need for an automated specification-based approach for rollover of Trust Anchors for security-aware resolvers.
当安全感知解析程序的操作员选择一个或多个信任锚时，他们还必须确定将使用的方法，以确保他们使用的是有效的RRs，并且能够确定何时应更换或删除用作信任锚的RRs。DNS签名区域的早期采用者已发布了有关其DNSKEY和/或DS RRs更改时将使用的流程和方法的信息，以便安全感知解析程序的操作员可以在适当的时间手动更改信任锚。这种手动方法不会扩展，因此，需要一种基于规范的自动化方法来实现安全感知解析器的信任锚的滚动。
This document uses the definitions contained in RFC 4033, section 2, plus the following additional definitions:
本文件使用RFC 4033第2节中包含的定义，以及以下附加定义：
Trust Anchor: From RFC 4033, "A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response." Additionally, a DNSKEY RR or DS RR is associated with precisely one point in the DNS hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY be associated with each DNS zone and MAY be held by any number of security-aware resolvers. Security-aware resolvers MAY have Trust Anchors from multiple DNS zones. Those responsible for the
信任锚点：来自RFC 4033，“DNSKEY RR的配置DNSKEY RR或DS RR哈希。验证安全感知解析程序使用此公钥或哈希作为构建签名DNS响应的身份验证链的起点。”此外，DNSKEY RR或DS RR与DNS层次结构中的一个点精确关联，即。，一个DNS区域。多个信任锚可与每个DNS区域相关联，并可由任意数量的安全感知解析器持有。安全感知解析程序可能具有来自多个DNS区域的信任锚。负责
operation of security-aware resolvers are responsible for determining the set of RRs that will be used as Trust Anchors by that resolver.
安全感知解析程序的操作负责确定将由该解析程序用作信任锚的RRs集。
Initial Trust Relationship: Operators of security-aware resolvers must ensure that they initially obtain any Trust Anchors in a trustworthy manner. For example, the correctness of the Root Zone DNSKEY RR(s) could be verified by comparing what the operator believes to be the Root Trust Anchor(s) with several 'well-known' sources such as the IANA web site, the DNS published Root Zone and the publication of the public key in well-known hard-copy forms. For other Trust Anchors, the operator must ensure the accuracy and validity of the DNSKEY and/or DS RRs before designating them Trust Anchors. This might be accomplished through a combination of technical, procedural, and contractual relationships, or use other existing trust relationships outside the current DNS protocol.
初始信任关系：安全感知解析程序的操作员必须确保他们最初以可信的方式获得任何信任锚。例如，可以通过将运营商认为是根信任锚的内容与几个“已知”来源进行比较来验证根区域DNSKEY RR的正确性，如IANA网站、DNS发布的根区域和以已知硬拷贝形式发布的公钥。对于其他信任锚，运营商必须确保DNSKEY和/或DS RRs的准确性和有效性，然后再指定他们信任锚。这可以通过技术、程序和合同关系的组合来实现，或者使用当前DNS协议之外的其他现有信任关系。
Trust Anchor Distribution: The method or methods used to convey the DNSKEY and/or DS RR(s) between the signed zone operator and the security-aware resolver operator. The method or methods MUST be deemed sufficiently trustworthy by the operator of the security-aware resolver to ensure source authenticity and integrity of the new RRs to maintain the Initial Trust Relationship required to designate those RRs as Trust Anchors.
信任锚分布：用于在签名区域操作符和安全感知解析器操作符之间传递DNSKEY和/或DS RR的一种或多种方法。安全感知解析器的操作员必须认为该方法足够可信，以确保新RRs的源真实性和完整性，以维持将这些RRs指定为信任锚所需的初始信任关系。
Trust Anchor Maintenance: Any change in a validating security-aware resolver to add a new Trust Anchor, delete an existing Trust Anchor, or replace an existing Trust Anchor with another. This change might be accomplished manually or in some automated manner. Those responsible for the operation of the security-aware resolver are responsible for establishing policies and procedures to ensure that a sufficient Initial Trust Relationship is in place before adding Trust Anchors for a particular DNS zone to their security-aware resolver configuration.
信任锚维护：验证安全感知解析程序中的任何更改，以添加新的信任锚、删除现有的信任锚或用其他信任锚替换现有的信任锚。此更改可以手动或以某种自动方式完成。负责安全感知解析程序操作的人员负责建立策略和程序，以确保在将特定DNS区域的信任锚添加到其安全感知解析程序配置之前，有足够的初始信任关系。
Trust Anchor Revocation and Removal: The invalidation of a particular Trust Anchor that results when the operator of the signed zone revokes or removes a DNSKEY RR or DS RR that is being used as a Trust Anchor by any security-aware resolver. It is possible that a zone administrator may invalidate more than one RR at one point in time; therefore, it MUST be clear to both the zone administrator and the security-aware resolver the exact RR(s) that have been revoked or removed so the proper Trust Anchor or Trust Anchors are removed.
信任锚撤销和删除：当签名区域的操作员撤销或删除任何安全感知解析程序用作信任锚的DNSKEY RR或DS RR时，特定信任锚的无效。区域管理员可能会在一个时间点使多个RR失效；因此，区域管理员和安全感知解析程序必须清楚已撤销或删除的确切RR，以便删除适当的信任锚。
Trust Anchor Rollover: The method or methods necessary for the secure replacement of one or multiple Trust Anchors held by security-aware resolvers. Trust Anchor Rollover should be considered a subset of Trust Anchor Maintenance.
信任锚滚动：安全替换安全感知解析程序持有的一个或多个信任锚所需的一种或多种方法。信任锚滚动应视为信任锚维护的一个子集。
Normal or Pre-Scheduled Trust Anchor Rollover: The operator of a DNSSEC signed zone has issued a new DNSKEY and/or DS RR(s) as a part of an operational routine.
正常或预先安排的信任锚滚动：DNSSEC签名区域的操作员已发布新的DNSKEY和/或DS RR，作为操作例行程序的一部分。
Emergency or Non-Scheduled Trust Anchor Rollover: The operator of a signed zone has issued a new DNSKEY and/or DS RR(s) as part of an exceptional event.
紧急或非计划信托锚翻滚：作为例外事件的一部分，已签署区域的运营商已发布新的DNSKEY和/或DS RR。
Emergency Trust Anchor Revocation: The operator of a signed zone wishes to indicate that the current DNSKEY and/or DS RR(s) are no longer valid as part of an exceptional event.
紧急信任锚撤销：已签名区域的操作员希望表明当前DNSKEY和/或DS RR不再作为异常事件的一部分有效。
Following are the requirements for DNSSEC automated specification-based Trust Anchor Rollover:
以下是DNSSEC基于自动规范的信任锚滚动的要求：
The automated Trust Anchor Rollover solution MUST be capable of scaling to Internet-wide usage. The probable largest number of instances of security-aware resolvers needing to rollover a Trust Anchor will be those that use the public key(s) for the Root Zone as Trust Anchor(s). This number could be extremely large if a number of applications have embedded security-aware resolvers.
自动信任锚滚动解决方案必须能够扩展到Internet范围的使用。需要翻转信任锚点的安全感知解析程序的实例可能最多，这些实例将使用根区域的公钥作为信任锚点。如果许多应用程序都具有嵌入式安全感知解析器，那么这个数字可能会非常大。
The automated Trust Anchor Rollover solution MUST be able to support Trust Anchors for multiple zones and multiple Trust Anchors for each DNS zone. The number of Trust Anchors that might be configured into any one validating security-aware resolver is not known with certainty at this time; in most cases it will be less than 20 but it may even be as high as one thousand.
自动信任锚滚动解决方案必须能够支持多个区域的信任锚，以及每个DNS区域的多个信任锚。此时无法确定可配置到任何一个验证安全感知解析器中的信任锚的数量；在大多数情况下，它将少于20，但它甚至可能高达1000。
Because trust anchor rollover is likely to be "mandatory-to-implement", section 8 of [5] requires that the technical solution chosen must not be known to be encumbered or must be available under royalty-free terms.
由于信托锚延期很可能是“强制实施的”，因此[5]第8节要求所选择的技术解决方案不得被设押或必须在免版税条款下可用。
For this purpose, "royalty-free" is defined as follows: worldwide, irrevocable, perpetual right to use, without fee, in commerce or otherwise, where "use" includes descriptions of algorithms,
为此，“免版税”的定义如下：“使用”包括对算法的描述，在全球范围内，不可撤销的、永久的、免费的、在商业或其他领域使用的权利，
distribution and/or use of hardware implementations, distribution and/or use of software systems in source and/or binary form, in all DNS or DNSSEC applications including registry, registrar, domain name service including authority, recursion, caching, forwarding, stub resolver, or similar.
在所有DNS或DNSSEC应用程序中分发和/或使用硬件实现，分发和/或使用源代码和/或二进制形式的软件系统，包括注册表、注册器、域名服务（包括授权）、递归、缓存、转发、存根解析程序或类似程序。
In summary, no implementor, distributor, or operator of the technology chosen for trust anchor management shall be expected or required to pay any fee to any IPR holder for the right to implement, distribute, or operate a system which includes the chosen mandatory-to-implement solution.
总之，对于任何知识产权持有人实施、分销或运营包含所选强制实施解决方案的系统的权利，预计或要求信托锚管理技术的实施者、分销商或运营商向任何知识产权持有人支付任何费用。
The solution MUST provide the capability to maintain Trust Anchors in security-aware resolvers for any and all DNS zones.
该解决方案必须能够在任何和所有DNS区域的安全感知解析程序中维护信任锚。
The solution MUST support private networks with their own DNS hierarchy.
解决方案必须支持具有自己DNS层次结构的专用网络。
The Trust Anchor Rollover solution MUST allow a validating security-aware resolver to be able to detect if the DNSKEY and/or DS RR(s) can no longer be updated given the current set of actual trust-anchors. In these cases, the resolver should inform the operator of the need to reestablish initial trust.
信任锚点翻转解决方案必须允许验证安全感知解析程序能够检测到，鉴于当前的一组实际信任锚点，DNSKEY和/或DS RR是否无法再更新。在这些情况下，解析程序应通知操作员需要重新建立初始信任。
The operator of a security-aware resolver may choose manual or automated rollover, but the rollover protocol must allow the implementation to support both automated and manual Trust Anchor Maintenance operations. Implementation of the rollover protocol is likely to be mandatory, but that's out of scope for this requirements document.
安全感知解析器的操作员可以选择手动或自动滚动，但滚动协议必须允许实现支持自动和手动信任锚维护操作。滚动协议的实现可能是强制性的，但这超出了本需求文档的范围。
The solution MUST permit both planned (pre-scheduled) and unplanned (non-scheduled) rollover of Trust Anchors. Support for providing an Initial Trust Relationship is OPTIONAL.
该解决方案必须允许计划内（预先计划）和计划外（非计划）的信任锚转移。支持提供初始信任关系是可选的。
Resource Records used as Trust Anchors SHOULD be able to be distributed to security-aware resolvers in a timely manner.
用作信任锚的资源记录应能够及时分发给具有安全意识的解析程序。
Security-aware resolvers need to acquire new and remove revoked DNSKEY and/or DS RRs that are being used as Trust Anchors for a zone such that no old RR is used as a Trust Anchor for long after the zone issues new or revokes existing RRs.
具有安全意识的解析程序需要获取新的并删除已撤销的DNSKEY和/或DS RRs，这些已撤销的DNSKEY和/或DS RRs正被用作区域的信任锚点，以便在区域发布新的或撤销现有RRs后很长时间内没有旧的RR被用作信任锚点。
Information about the zone administrator's view of the state of Resource Records used as Trust Anchors SHOULD be available in a trustworthy manner at all times to security-aware resolvers. Information about Resource Records that a zone administrator has invalidated and that are known to be used as Trust Anchors should be available in a trustworthy manner for a reasonable length of time.
有关区域管理员对用作信任锚的资源记录状态的视图的信息应始终以可靠的方式提供给具有安全意识的解析程序。有关区域管理员已失效且已知用作信任锚的资源记录的信息应以可信的方式在合理的时间长度内可用。
If a Trust Anchor Rollover solution requires new RR types or protocol modifications, this should be considered in the evaluation of solutions. The working group needs to determine whether such changes are a good thing or a bad thing or something else.
如果信任锚滚动更新解决方案需要新的RR类型或协议修改，则在评估解决方案时应考虑这一点。工作组需要确定这些变化是好事还是坏事或其他事情。
The Trust Anchor Rollover solution MUST support operations that allow a validating security-aware resolver to add a new Trust Anchor, delete an existing Trust Anchor, or replace an existing Trust Anchor with another.
信任锚点翻转解决方案必须支持允许验证安全感知解析程序添加新信任锚点、删除现有信任锚点或用其他信任锚点替换现有信任锚点的操作。
The Trust Anchor Rollover solution MUST allow a security-aware resolver to be able to recover from the compromise of any of its configured Trust Anchors for a zone so long as at least one other key, which is known to have not been compromised, is configured as a Trust Anchor for that same zone at that resolver.
信任锚点翻转解决方案必须允许安全感知解析程序能够从其为某个区域配置的任何信任锚点的泄露中恢复，只要至少有一个已知未泄露的其他密钥在该解析程序处配置为该区域的信任锚点。
The Trust Anchor Rollover solution MUST provide sufficient means to ensure authenticity and integrity so that the existing trust relation does not degrade by performing the rollover.
信任锚滚动更新解决方案必须提供足够的方法来确保真实性和完整性，以便现有的信任关系不会因执行滚动更新而降级。
This document defines overall requirements for an automated specification-based Trust Anchor Rollover solution for security-aware resolvers but specifically does not define the security mechanisms needed to meet these requirements.
本文档定义了用于安全感知解析器的基于自动化规范的信任锚滚动解决方案的总体要求，但没有明确定义满足这些要求所需的安全机制。
This document reflects the majority opinion of the DNSEXT Working Group members on the topic of requirements related to DNSSEC trust anchor rollover. The contributions made by various members of the working group to improve the readability and style of this document are graciously acknowledged.
本文件反映了DNSEXT工作组成员对DNSSEC信托锚延期相关要求的多数意见。感谢工作组各成员为改进本文件的可读性和风格所作的贡献。
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[2] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[3] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[4] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[5] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3979, March 2005.
[5] Bradner，S.，“IETF技术中的知识产权”，RFC 3979，2005年3月。
Authors' Addresses
作者地址
Howard Eland Afilias Limited 300 Welsh Road Building 3, Suite 105 Horsham, PA 19044 USA
霍华德·伊兰·阿菲利亚斯有限公司美国宾夕法尼亚州霍舍姆威尔士路300号3号楼105室，邮编：19044
EMail: heland@afilias.info
EMail: heland@afilias.info
Russ Mundy SPARTA, Inc. 7110 Samuel Morse Dr. Columbia, MD 21046 USA
Russ Mundy SPARTA，Inc.7110美国马里兰州哥伦比亚塞缪尔·莫尔斯博士21046
EMail: mundy@sparta.com
EMail: mundy@sparta.com
Steve Crocker Shinkuro Inc. 1025 Vermont Ave, Suite 820 Washington, DC 20005 USA
Steve Crocker Shinkuro Inc.美国华盛顿特区佛蒙特大道1025号820室，邮编：20005
EMail: steve@shinkuro.com
EMail: steve@shinkuro.com
Suresh Krishnaswamy SPARTA, Inc. 7110 Samuel Morse Dr. Columbia, MD 21046 USA
Suresh Krishnaswamy SPARTA，Inc.7110 Samuel Morse哥伦比亚博士，美国马里兰州21046
EMail: suresh@sparta.com
EMail: suresh@sparta.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.