Internet Engineering Task Force (IETF) F. Ljunggren
Request for Comments: 6841 Kirei AB
Category: Informational AM. Eklund Lowinder
ISSN: 2070-1721 .SE
T. Okubo
ICANN
January 2013
Internet Engineering Task Force (IETF) F. Ljunggren
Request for Comments: 6841 Kirei AB
Category: Informational AM. Eklund Lowinder
ISSN: 2070-1721 .SE
T. Okubo
ICANN
January 2013
A Framework for DNSSEC Policies and DNSSEC Practice Statements
DNSSEC政策框架和DNSSEC实践声明
Abstract
摘要
This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.
本文档提供了一个框架，以帮助DNS安全扩展（DNSSEC）策略和DNSSEC实践声明的编写者，例如顶级和二级的域管理员和区域操作员，他们正在管理和操作实施了安全扩展的DNS区域。
In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement.
特别是，该框架提供了应考虑纳入DNSSEC政策定义和实践声明的全面主题列表。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6841.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6841.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. DNSSEC Policy . . . . . . . . . . . . . . . . . . . . . . 6
3.2. DNSSEC Practice Statement . . . . . . . . . . . . . . . . 7
3.3. Relationship between DNSSEC Policy and Practice
Statement . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Set of Provisions . . . . . . . . . . . . . . . . . . . . 9
4. Contents of a Set of Provisions . . . . . . . . . . . . . . . 10
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Publication and Repositories . . . . . . . . . . . . . . . 11
4.3. Operational Requirements . . . . . . . . . . . . . . . . . 12
4.4. Facility, Management, and Operational Controls . . . . . . 13
4.5. Technical Security Controls . . . . . . . . . . . . . . . 17
4.6. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 20
4.7. Compliance Audit . . . . . . . . . . . . . . . . . . . . . 22
4.8. Legal Matters . . . . . . . . . . . . . . . . . . . . . . 23
5. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. DNSSEC Policy . . . . . . . . . . . . . . . . . . . . . . 6
3.2. DNSSEC Practice Statement . . . . . . . . . . . . . . . . 7
3.3. Relationship between DNSSEC Policy and Practice
Statement . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Set of Provisions . . . . . . . . . . . . . . . . . . . . 9
4. Contents of a Set of Provisions . . . . . . . . . . . . . . . 10
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Publication and Repositories . . . . . . . . . . . . . . . 11
4.3. Operational Requirements . . . . . . . . . . . . . . . . . 12
4.4. Facility, Management, and Operational Controls . . . . . . 13
4.5. Technical Security Controls . . . . . . . . . . . . . . . 17
4.6. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 20
4.7. Compliance Audit . . . . . . . . . . . . . . . . . . . . . 22
4.8. Legal Matters . . . . . . . . . . . . . . . . . . . . . . 23
5. Outline of a Set of Provisions . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 26
The Domain Name System (DNS) was not originally designed with strong security mechanisms to provide integrity and authenticity of its data. Over the years, a number of vulnerabilities have been discovered that threaten the reliability and trustworthiness of the system.
域名系统（DNS）最初并没有设计强大的安全机制来提供其数据的完整性和真实性。多年来，发现了许多威胁系统可靠性和可信度的漏洞。
The Domain Name System Security Extensions (DNSSEC, [RFC4033], [RFC4034], [RFC4035]) address these vulnerabilities by using public key cryptography to add data origin authentication, data integrity verification, and authenticated denial-of-existence capabilities to the DNS. In short, DNSSEC provides a way for software to verify the origin of DNS data and validate that it has not been modified in transit or by intermediaries.
域名系统安全扩展（DNSSEC、[RFC4033]、[RFC4034]、[RFC4035]）通过使用公钥加密向DNS添加数据源身份验证、数据完整性验证和身份验证的拒绝存在功能来解决这些漏洞。简言之，DNSSEC为软件提供了一种方法来验证DNS数据的来源，并验证数据是否在传输过程中或中介机构未对其进行修改。
To provide a means for stakeholders to evaluate the strength and security of the DNSSEC chain of trust, an entity operating a DNSSEC-enabled zone may publish a DNSSEC Practice Statement (DPS), comprising statements describing critical security controls and procedures relevant for scrutinizing the trustworthiness of the system. The DPS may also identify any of the DNSSEC Policies (DPs) it supports, explaining how it meets their requirements.
为向利益相关者提供评估DNSSEC信任链强度和安全性的手段，经营DNSSEC启用区域的实体可发布DNSSEC实践声明（DPS），其中包括描述关键安全控制和与审查系统可信度相关的程序的声明。DPS还可以确定其支持的任何DNSSEC政策（DPS），解释其如何满足其要求。
The DP and DPS are not primarily aimed at users who rely on signed responses from the DNS ("relying parties"); instead, their audience is other stakeholders of the DNS infrastructure, a group that may include bodies such as regulatory authorities.
DP和DPS主要不是针对依赖DNS签名响应的用户（“依赖方”）；相反，他们的受众是DNS基础设施的其他利益相关者，这一群体可能包括监管机构等机构。
Even though this document is heavily inspired by the "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" [RFC3647], with large parts being drawn from that document, the properties and structure of the DNSSEC trust model are fundamentally different from those of the X.509 Public Key Infrastructure (PKI).
尽管本文档深受“Internet X.509公钥基础设施证书政策和认证实践框架”[RFC3647]的启发，其中大部分内容来自该文档，但DNSSEC信任模型的属性和结构与X.509公钥基础设施的属性和结构有根本不同（公钥基础设施）。
The purpose of this document is twofold. Firstly, the document explains the concepts of a DNSSEC Policy (DP) and of a DNSSEC Practice Statement (DPS), and it describes the relationship between the two. Secondly, it presents a framework to encourage and assist writers of Policies and Practice Statements in creating consistent and comparable documents. In particular, the framework identifies the elements that should be considered in formulating a DP or a DPS.
本文件的目的有两个。首先，本文件解释了DNSSEC政策（DP）和DNSSEC实践声明（DPS）的概念，并描述了两者之间的关系。其次，它提出了一个框架，鼓励和协助政策和实践声明的作者创建一致和可比的文件。特别是，该框架确定了制定DP或DPS时应考虑的要素。
It does not, however, define a particular Policy or Practice Statement, nor does it seek to provide legal advice or recommendations as to the contents.
然而，它没有定义特定的政策或实践声明，也没有寻求就内容提供法律意见或建议。
The scope of this document is limited to discussion of the topics that can be covered in a DP or a DPS, but it does not go into the specific details that could possibly be included in either a DP or a DPS. In particular, this document describes the types of information that should be considered for inclusion in them.
本文件的范围仅限于讨论DP或DPS中可能包含的主题，但不涉及DP或DPS中可能包含的具体细节。特别是，本文件描述了应考虑纳入其中的信息类型。
This framework should be viewed and used as a checklist of factors that ought be taken into consideration prior to deploying DNSSEC, and as an outline to create an operational practices disclosure document. As such, it focuses on the topics affected by the introduction of DNSSEC into a zone. Other aspects, such as the operations of name servers and registry systems, are considered out of scope. The framework is primarily aimed at Top-Level Domain (TLD) managers and organizations providing registry services, but it may be used by high-value domain holders and so serve as a checklist for DNSSEC readiness at a high level.
应将该框架视为部署DNSSEC之前应考虑的因素清单，并将其用作创建运营实践披露文件的大纲。因此，它关注的主题是将DNSSEC引入区域所影响的主题。其他方面，例如名称服务器和注册表系统的操作，被认为超出了范围。该框架主要针对顶级域（TLD）管理者和提供注册服务的组织，但也可供高价值域持有者使用，因此可作为DNSSEC高级别准备情况的检查表。
This document assumes that the reader is familiar with the general concepts of DNS, DNSSEC, and PKI.
本文档假设读者熟悉DNS、DNSSEC和PKI的一般概念。
This document makes use of the following defined terms:
本文件使用了以下定义的术语：
Audit logs: Control evidence information to prove the integrity of processes. This may be generated by DNS and DNSSEC-related systems, supplied by the surrounding facility, or obtained from manually generated, non-electronic documentation. Audit logs will be examined by the internal and/or external auditors.
审核日志：控制证据信息，以证明流程的完整性。这可能由DNS和DNSSEC相关系统生成，由周围设施提供，或从手动生成的非电子文档中获取。内部和/或外部审计师将检查审计日志。
Activation data: Data values, other than keys, required to operate the cryptographic modules used to protect the keys from unauthorized use.
激活数据：操作加密模块所需的数据值（密钥除外），用于保护密钥不被未授权使用。
Chain of trust: A hierarchical structure of trust consisting of DNS keys, signatures, and delegation signer records that, when validated in a series, can provide proof of authenticity of the last element in the chain, providing that the first element is trusted. Usually, the first element is a trust anchor.
信任链：信任的层次结构，由DNS密钥、签名和委托签名者记录组成，当在一系列中进行验证时，可以提供链中最后一个元素的真实性证明，前提是第一个元素是可信的。通常，第一个元素是信任锚。
Compromise (key compromise): Key compromise is a situation where the private component of a signing key is lost, stolen, exposed, modified, or used in an unauthorized manner. More strictly, even a suspicion that one of these has occurred will be enough to be considered as key compromise.
泄露（密钥泄露）：密钥泄露是指签名密钥的私有组件丢失、被盗、暴露、修改或以未经授权的方式使用的情况。更严格地说，即使怀疑其中一个已经发生，也足以被视为关键的妥协。
DNS: The Domain Name System (DNS) is a hierarchical global naming catalog for computers, services, or any resource connected to the Internet.
DNS：域名系统（DNS）是计算机、服务或连接到Internet的任何资源的分层全局命名目录。
DNS zone: A portion of the global Domain Name System (DNS) namespace for which administrative responsibility has been delegated.
DNS区域：全局域名系统（DNS）命名空间的一部分，已为其委派管理责任。
DNSSEC: DNS Security Extensions (DNSSEC) is a set of IETF specifications [RFC4033] [RFC4034] [RFC4035] that uses public key cryptography to add data origin authentication, data integrity verification, and authenticated denial of existence capabilities to DNS.
DNSSEC:DNS安全扩展（DNSSEC）是一组IETF规范[RFC4033][RFC4034][RFC4035]，它使用公钥加密技术向DNS添加数据源身份验证、数据完整性验证和经身份验证的拒绝存在功能。
DNSSEC Policy: A DNSSEC Policy (DP) sets forth the security requirements and standards to be implemented for a DNSSEC-signed zone.
DNSSEC政策：DNSSEC政策（DP）规定了DNSSEC签署区域的安全要求和标准。
DNSSEC Practice Statement: A DNSSEC Practice Statement (DPS) is a practices disclosure document that may support and be a supplemental document to the DNSSEC Policy (if such exists), and it states how the management of a given zone implements procedures and controls at a high level.
DNSSEC实践声明：DNSSEC实践声明（DPS）是一份实践披露文件，可能支持DNSSEC政策并作为其补充文件（如有），它说明了给定区域的管理层如何在高水平上实施程序和控制。
Key rollover: An operational process to change one of the DNSSEC keys used for signing a zone via distribution of public keys in a trusted manner.
密钥滚动：通过以可信方式分发公钥来更改用于对区域进行签名的DNSSEC密钥之一的操作过程。
Multi-person control: A security concept to distribute the authority of an operation over multiple persons, to mitigate threats caused by a single authorized individual. For example, a key recovery function may require some number of authorized individuals (m) out of the (n) to whom a portion of the recovery key was distributed, to combine their key fragments, before key recovery can occur.
多人控制：一种安全概念，用于将操作权限分配给多人，以减轻单个授权人员造成的威胁。例如，在可以进行密钥恢复之前，密钥恢复功能可能需要（n）个被分发了部分恢复密钥的授权个人（m）中的一些人组合他们的密钥片段。
PKI: Public Key Infrastructure (PKI) is a concept that makes use of asymmetric cryptography to provide a system with integrity, authentication, and confidentiality and to do it via distribution of public keys in a trusted manner.
PKI：公钥基础设施（Public Key Infrastructure，PKI）是一个概念，它利用非对称加密技术为系统提供完整性、身份验证和机密性，并通过以可信方式分发公钥来实现。
Policy authority: The body responsible for setting and administering a DNSSEC Policy and for determining whether a DPS is suitable for that Policy.
政策机构：负责制定和管理DNSSEC政策以及确定DPS是否适合该政策的机构。
Relying party: An entity that relies on a signed response from the DNS.
依赖方：依赖于来自DNS的签名响应的实体。
Repository: A location on the Internet to store DP, DPS, trust anchors, and other related information that should be kept public.
存储库：Internet上存储DP、DPS、信任锚和其他应公开的相关信息的位置。
Security posture: A security posture is an indicator of how secure an entity is and how secure the entity should be. It is the result of an adequate threat model and risk assessment.
安全态势：安全态势是实体安全程度和实体应安全程度的指标。这是充分的威胁模型和风险评估的结果。
Separation of duties: A security concept that limits the influence of a single person by segregating roles and responsibilities.
职责分离：通过分离角色和责任限制单个人员影响的安全概念。
Signing key: Private component of an asymmetric key pair that is used for signing of resource records within the zone. Note that the other component, called public key, is used for signature validation.
签名密钥：非对称密钥对的私有组件，用于对区域内的资源记录进行签名。请注意，另一个名为公钥的组件用于签名验证。
TLD: A Top-Level Domain (TLD) is one of the domains at the highest level below the root in the hierarchy of the DNS.
顶级域（TLD）：顶级域（TLD）是DNS层次结构中根目录下最高级别的域之一。
Trust anchor: Public portion of a key pair that is the authoritative entity used to authenticate the first element in a chain of trust.
信任锚：密钥对的公共部分，是用于验证信任链中第一个元素的权威实体。
This section describes the concepts of a DNSSEC Policy and of a DNSSEC Practice Statement. Other related concepts are described as well.
本节介绍DNSSEC政策和DNSSEC实践声明的概念。还描述了其他相关概念。
A DNSSEC Policy (DP) sets forth requirements that are appropriate for a specified level of assurance. For example, a DP may encompass all topics of this framework, each with a certain set of security requirements, possibly grouped according to impact. The progression from medium to high levels of assurance would correspond to increasing security requirements and corresponding increasing levels of assurance.
DNSSEC政策（DP）规定了适用于特定保证水平的要求。例如，DP可能包含此框架的所有主题，每个主题都有一组特定的安全需求，可能根据影响进行分组。从中等水平到高水平的保证将对应不断增加的安全要求和相应不断增加的保证水平。
A DP also constitutes a basis for an audit, accreditation, or another assessment of an entity. Each entity can be assessed against one or more DPs that it claims to implement.
DP还构成对实体进行审计、认证或其他评估的基础。每个实体可以根据其声称实施的一个或多个DPs进行评估。
Most zone managers using DNSSEC will not have the need to create a thorough and detailed statement of practices. For example, a registrant may be the sole relying party of its own zone and would already be aware of the nature and trustworthiness of its services. In other cases, a zone manager may provide registration services with only a very low level of assurances where the domain names being secured may pose only marginal risks if compromised. Publishing a DPS is most relevant for entities operating a zone that contains a significant number of delegations to other entities.
大多数使用DNSSEC的区域经理不需要创建一份全面、详细的实践声明。例如，注册人可能是其所在区域的唯一依赖方，并且已经知道其服务的性质和可靠性。在其他情况下，区域管理人可能只提供极低级别的注册服务，其中被保护的域名如果受到损害，可能只会带来边际风险。发布DPS与经营区域的实体最相关，该区域包含大量其他实体的授权。
A DNSSEC Practice Statement (DPS) should contain information that is relevant to the stakeholders of the relevant zone(s). Since these generally include the Internet community, it should not contain such information that could be considered to be sensitive details of an entity's operations.
DNSSEC实践声明（DPS）应包含与相关区域利益相关者相关的信息。由于这些信息通常包括互联网社区，因此不应包含可能被视为实体运营的敏感细节的信息。
A DNSSEC Practice Statement may identify a supported DP, which may subsequently be used by a relying party to evaluate the trustworthiness of any digital signatures verified using the public key of that entity.
DNSSEC实践声明可确定支持的DP，依赖方随后可使用该DP评估使用该实体公钥验证的任何数字签名的可信度。
A DNSSEC Policy and a DNSSEC Practice Statement address the same set of topics of interest to the stakeholders in terms of the level of confidence ascribed to the security posture of a zone. The primary difference is in the focus of their provisions. A Policy sets forth the requirements and standards to be implemented for a DNSSEC-signed zone, and may be used to communicate requirements that must be met by complying parties; as such, it may also be used to determine or establish equivalency between policies associated with different zones. A Practice Statement, by contrast, describes how a zone operator (and possibly other participants in the management of a given zone) implements procedures and controls to meet the requirements of applicable Policies. In other words, the Policy says what needs to be done, and the Practice Statement says what is being done.
DNSSEC政策和DNSSEC实践声明针对利益相关者感兴趣的同一组主题，涉及区域安全态势的信心水平。主要区别在于其规定的重点。政策规定了DNSSEC签署区域的要求和标准，并可用于传达合规方必须满足的要求；因此，它还可用于确定或建立与不同分区关联的策略之间的等效性。相反，实践陈述描述了区域运营商（可能还有特定区域管理的其他参与者）如何实施程序和控制，以满足适用政策的要求。换句话说，政策说明了需要做什么，实践声明说明了正在做什么。
An additional difference between a Policy and a Practice Statement relates to the scope of coverage of the two kinds of documents, in terms of its applicability. A Policy may apply to multiple
保险单和业务说明之间的另一个区别在于两类文件的适用范围。一个策略可以应用于多个
organizations or multiple zones. By contrast, a Practice Statement would usually apply only to a single zone operator or a single organization, since it describes the actual controls in place that meet the requirements of applicable Policy.
组织或多个区域。相比之下，实践声明通常仅适用于单个区域运营商或单个组织，因为它描述了符合适用政策要求的实际控制措施。
For example, a TLD manager or regulatory authority may define requirements in a Policy for the operation of one or more zones. The Policy will be a broad statement of the general requirements for managing the zone. A zone operator may be required to write its own Practice Statement to support the Policy, explaining how it meets the requirements of the Policy. Alternatively, a zone operator that is also the manager of that zone, and not governed by any external Policy, may still choose to disclose operational practices by publishing a DPS. The zone operator might do so to provide transparency and to gain community trust in its operations.
例如，TLD经理或监管机构可在一项政策中定义一个或多个区域的运营要求。该政策将是对管理该区域的一般要求的概括说明。区域运营商可能需要编写自己的实践声明以支持政策，解释其如何满足政策要求。或者，同时也是该区域经理且不受任何外部政策管辖的区域运营商仍可选择通过发布DPS来披露运营实践。区域运营商可以这样做，以提供透明度，并获得社区对其运营的信任。
A Policy and a Practice Statement also differ in the level of detail each expresses: although there may be variations, a Practice Statement will provide a description of procedures and controls and so will usually be more detailed than a Policy, which provides general principles.
政策和实践声明在各自表达的详细程度上也有所不同：虽然可能存在差异，但实践声明将提供程序和控制的描述，因此通常比提供一般原则的政策更详细。
The main differences between a Policy and Practice Statement can be summarized as follows:
政策和实践声明之间的主要区别可总结如下：
(a) Operation of a DNS zone with DNSSEC may be governed by a Policy that establishes requirements stating what the entity operating that zone must do. An entity can use a Practice Statement to disclose how it meets the requirements of a Policy or how it has implemented critical processes and controls, absent a controlling Policy.
(a) 使用DNSSEC操作DNS区域可能受一项政策的管理，该政策规定了说明操作该区域的实体必须执行的操作的要求。实体可以使用实践声明来披露其如何满足政策要求，或在没有控制政策的情况下如何实施关键流程和控制。
(b) A Policy may serve the purpose of establishing a common basis of trusted operation throughout a set of zones in the DNS hierarchy. By contrast, a Practice Statement is a statement of a single zone operator or organization.
(b) 策略可用于在DNS层次结构中的一组区域中建立可信操作的公共基础。相反，实践陈述是单个区域运营商或组织的陈述。
(c) A Practice Statement is generally more detailed than a Policy and specifies how the zone operator or organization implements critical processes and controls, and how the entity meets any requirements specified in the one or more Policies under which it operates DNSSEC.
(c) 实践声明通常比政策更详细，并规定了区域运营商或组织如何实施关键流程和控制，以及实体如何满足其运营DNSSEC的一个或多个政策中规定的任何要求。
A set of provisions is a collection of Policy requirements or Practice Statements, which may employ the approach described in this framework by covering the topics appearing in Section 5 below. The topics are described in detail in Section 4.
一套规定是政策要求或实践声明的集合，可采用本框架中描述的方法，涵盖下文第5节中出现的主题。第4节详细介绍了这些主题。
A Policy can be expressed as a single set of provisions. A Practice Statement can also be expressed as a single set of provisions with each component addressing the requirements of one or more Policies. Alternatively, it could be a set of provisions that do not reference any particular policy but instead describe a set of self-imposed controls to the stakeholders. For example, a Practice Statement could be expressed as a combination of the following:
一项政策可以表示为一套规定。实践声明也可以表示为一组单独的规定，每个组成部分满足一个或多个政策的要求。或者，它可以是一套不引用任何特定政策的规定，而是向利益相关者描述一套自我施加的控制。例如，实践陈述可以表示为以下内容的组合：
(a) a list of Policies supported by the DPS;
(a) DPS支持的政策列表；
(b) for each Policy in (a), a set of provisions that contains statements addressing the requirements by filling in details not stipulated in that policy or expressly left to the discretion of the implementer. Such statements serve to show how this particular Practice Statement implements the requirements of the particular Policy; or
(b) 对于（a）中的每项政策，一组规定包含通过填写该政策中未规定或明确由实施者自行决定的细节来解决要求的声明。此类声明用于说明该特定实践声明如何实现特定政策的要求；或
(c) a set of provisions that contains statements regarding the DNSSEC operations practices, independent of any Policy.
(c) 包含DNSSEC运营实践相关声明的一套规定，独立于任何政策。
The statements provided in (b) may augment or refine the stipulations of an applicable Policy, but generally they must not conflict with the stipulations. In certain cases, however, a Policy authority may permit exceptions because certain compensating controls of the entity disclosed in its Practice Statement allow it to provide a level of assurance equivalent to full compliance with the policy.
（b）中提供的声明可以补充或完善适用政策的规定，但通常不得与规定相冲突。然而，在某些情况下，保单管理局可能允许例外，因为在其业务声明中披露的实体的某些补偿控制允许其提供相当于完全遵守保单的保证水平。
The framework outlines the contents of a set of provisions, in terms of eight primary components, as follows:
该框架从以下八个主要部分概述了一套条款的内容：
1. Introduction
1. 介绍
2. Publication and Repositories
2. 出版物和储存库
3. Operational Requirements
3. 操作要求
4. Facility, Management, and Operational Controls
4. 设施、管理和运营控制
5. Technical Security Controls
5. 技术安全控制
6. Zone Signing
6. 区域标志
7. Compliance Audit
7. 合规审计
8. Legal Matters
8. 法律事项
This framework can be used by Policy authorities to write DNSSEC Policies and by zone operators to write a DNSSEC Practice Statements. Having a set of documents with the same structure facilitates comparisons with the corresponding documents of other zones.
政策机构可以使用此框架编写DNSSEC政策，区域操作员可以使用此框架编写DNSSEC实践声明。拥有一组具有相同结构的文档有助于与其他区域的相应文档进行比较。
This section describes the contents of a set of provisions. Refer to Section 5 for the complete outline.
本节介绍了一套规定的内容。有关完整的大纲，请参阅第5节。
Drafters of DPSs conforming to this framework are permitted to add additional levels of subcomponents below those described here to meet specific needs. All components listed in Section 5 should be present, but drafters may leave components empty, only stating "no stipulation", if so required.
符合本框架的DPS起草人可在此处描述的子组件下方添加额外级别的子组件，以满足特定需求。第5节中列出的所有组件均应存在，但起草人可将组件留空，仅在需要时说明“无规定”。
This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the document (either Policy or Practice Statement) is targeted.
本部分确定并介绍了一套规定，并指出了文件（政策或实践声明）所针对的实体和应用的类型。
This subcomponent provides a general introduction to the document. It can also be used to provide a description of entities to which the Policy or Practice Statement applies.
此子组件提供了对文档的一般介绍。它还可用于提供政策或实践声明适用的实体的描述。
This subcomponent provides any applicable names or other identifiers of the document.
此子组件提供文档的任何适用名称或其他标识符。
This subcomponent identifies the stakeholders along with their expected roles and responsibilities. These include (but are not limited to) an entity signing the zone, entities relying on the signed zone, other entities that have operational dependency on the signed zone, and an entity that entrusted the zone signing.
该子部分确定了利益相关者及其预期角色和责任。这些包括（但不限于）签署区域的实体、依赖于签署区域的实体、对签署区域具有运营依赖性的其他实体以及委托签署区域的实体。
This subcomponent contains the contact details of the organization responsible for managing the DP/DPS, as well as the specification change procedures. These procedures may include the description of the notification mechanisms used to provide advance notice of amendments that are deemed to materially affect the assurance provided by the entity and how/when such amendments will be communicated to the stakeholders.
本子部分包含负责管理DP/DPS的组织的联系方式以及规范变更程序。这些程序可能包括对被视为对实体提供的保证产生重大影响的修正案提前通知所使用的通知机制的描述，以及如何/何时将此类修正案传达给利益相关者。
If a Policy authority is responsible for determining whether a DPS is suitable for the Policy, this subcomponent may include the name and contact information of the entity in charge of making such a determination. In this case, the subcomponent also includes the procedures by which this determination is made.
如果政策主管机构负责确定DPS是否适用于该政策，则该子组件可包括负责进行该确定的实体的名称和联系信息。在这种情况下，子组件还包括进行该确定的程序。
The component describes the requirements for an entity to publish information regarding its practices, public keys, the current status of such keys together with details relating to the repositories in which the information is held. This may include the responsibilities of publishing the DPS and of identifying documents that are not made publicly available owing to their sensitive nature, e.g., security controls, clearance procedures, or business information.
该组件描述了实体发布有关其实践、公钥、此类密钥的当前状态以及与保存信息的存储库相关的详细信息的要求。这可能包括发布DPS的责任，以及识别由于敏感性质而未公开的文件的责任，例如安全控制、许可程序或业务信息。
This subcomponent describes the repository mechanisms used for making information available to the stakeholders, and may include:
此子组件描述了用于向利益相关者提供信息的存储库机制，可能包括：
o The locations of the repositories and the means by which they may be accessed;
o 存储库的位置以及访问存储库的方式；
o An identification of the entity or entities that operate repositories, such as a zone operator or a TLD manager;
o 操作存储库的一个或多个实体的标识，如区域运营商或TLD管理者；
o Access control on published information objects; and
o 对已发布信息对象的访问控制；和
o Any notification services that may be subscribed to by the stakeholders.
o 利益相关者可能订阅的任何通知服务。
This subcomponent contains information relating to the publication of public keys:
此子组件包含与公钥发布相关的信息：
o Whether the public keys are included in a key hierarchy, published as trust anchors, or both;
o 公钥是否包括在密钥层次结构中，是否作为信任锚发布，或者两者都包括；
o The data formats and methods available to validate the authenticity of public keys;
o 可用于验证公钥真实性的数据格式和方法；
o The frequency and timing of publishing new information (principally, as advance notice for stakeholders relying on the public keys).
o 发布新信息的频率和时间（主要是作为依赖公钥的利益相关者的提前通知）。
This component describes the operational requirements when operating a DNSSEC-signed zone.
本部分描述了操作DNSSEC签名区域时的操作要求。
This subcomponent describes the overall policy of child zone naming, if any.
此子组件描述子区域命名的总体策略（如果有）。
This subcomponent describes how the child zone manager has initially been identified, and how any subsequent change request is authenticated as originating from the manager or their authorized representative.
本子组件描述了子区域经理最初是如何识别的，以及任何后续变更请求是如何验证为来自经理或其授权代表的。
This subcomponent describes the process of establishing the chain-of-trust to the child zone by incorporating delegation signer (DS) record(s) into the zone.
此子组件描述了通过将委托签名者（DS）记录合并到子区域来建立信任链的过程。
This subcomponent describes whether and, if so, under what circumstances the child zone manager is required to provide proof of the possession of the private component of any current or subsequent child zone signing key corresponding to a DS record they wish to incorporate into the parent zone.
此子组件描述了是否以及在何种情况下，子区域经理需要提供证据，证明其拥有任何当前或后续子区域签名密钥的私有组件，该密钥对应于其希望并入父区域的DS记录。
This subcomponent will explain how, when, and under what circumstances the DS records may be removed from the zone.
此子组件将解释如何、何时以及在何种情况下从区域中删除DS记录。
This component describes non-technical security controls (i.e., physical, procedural, and personnel) in use by the entity to securely perform the DNSSEC related functions. Such controls include physical access, key management, disaster recovery, auditing, and archiving.
本部分描述了实体为安全执行DNSSEC相关功能而使用的非技术性安全控制（即物理、程序和人员）。此类控制包括物理访问、密钥管理、灾难恢复、审核和归档。
These non-technical security controls are critical for trusting the DNSSEC signatures, since lack of security may compromise DNSSEC operations. For example, it could result in the creation of signatures with erroneous information or in the compromise of the signing key.
这些非技术性安全控制对于信任DNSSEC签名至关重要，因为缺乏安全性可能会危及DNSSEC操作。例如，它可能导致创建具有错误信息的签名，或导致签名密钥泄露。
Within each subcomponent, separate consideration will usually need to be given to each entity type.
在每个子组件中，通常需要单独考虑每个实体类型。
In this subcomponent, the physical controls on the facility housing the entity systems are described. Topics addressed may include:
在本子部分中，描述了实体系统所在设施的物理控制。讨论的主题可能包括：
o Site location and construction, such as requirements for multiple tiers of physical barriers, construction requirements for high-security areas, etc. It may also describe the use of locked rooms, cages, safes, cabinets, etc.;
o 现场位置和施工，如多层物理屏障的要求、高安全区域的施工要求等。还可说明上锁房间、笼子、保险箱、橱柜等的使用。；
o Physical access, i.e., mechanisms to control access from one area of the facility to another or additional controls for reaching into higher tiers, such as dual-access control and two-factor authentication;
o 物理访问，即控制从设施的一个区域到另一个区域的访问的机制，或用于进入更高层的附加控制，例如双重访问控制和双因素认证；
o Power and air conditioning;
o 电力和空调；
o Water exposures;
o 水暴露；
o Fire prevention and protection;
o 防火和保护；
o Media storage, e.g., requiring the storage of backup media in a separate location that is physically secure and protected from fire, smoke, particle, and water damage;
o 介质存储，例如，要求将备份介质存储在物理安全的单独位置，防止火灾、烟雾、颗粒物和水损坏；
o Waste disposal; and
o 废物处理；和
o Off-site backup.
o 异地备份。
In this subcomponent, requirements for recognizing trusted roles are described, together with a description of the responsibilities of each role. Examples of trusted roles include system administrators, security officers, crypto officers, and system auditors.
在此子组件中，描述了识别受信任角色的要求，以及每个角色的职责描述。受信任角色的示例包括系统管理员、安全官员、加密官员和系统审计员。
For each task identified, the number of individuals required to perform the task (m of n rule, if applicable) should be stated for each role. Identification and authentication requirements for each role may also be defined.
对于确定的每项任务，应说明每个角色执行任务所需的人员数量（m/n规则，如适用）。还可以定义每个角色的标识和身份验证要求。
This subcomponent also includes the separation of duties in terms of the roles that cannot be performed by the same individuals.
该子部分还包括职责分离，即不能由同一个人履行的职责。
This subcomponent addresses the following:
此子组件涉及以下内容：
o Qualifications, experience, and clearances that personnel must have as a condition of filling trusted roles or other important roles. Examples include credentials, job experiences, and official government clearances;
o 作为填补受信任角色或其他重要角色的条件，人员必须具备的资格、经验和许可。例如证书、工作经验和官方政府许可证；
o Background checks and clearance procedures that are required in connection with the hiring of personnel filling trusted roles or other important roles. Such roles may require a check of their criminal records, financial records, references, and any additional clearances required for the position in question;
o 雇佣担任受信任角色或其他重要角色的人员所需的背景调查和批准程序。此类职位可能需要检查其犯罪记录、财务记录、参考资料以及相关职位所需的任何额外许可；
o Training requirements and training procedures for each role following the hiring of personnel;
o 雇佣人员后每个角色的培训要求和培训程序；
o Any retraining period and retraining procedures for each role after completion of initial training;
o 完成初始培训后，每个角色的任何再培训期和再培训程序；
o Frequency and sequence for job rotation among various roles;
o 不同角色之间工作轮换的频率和顺序；
o Sanctions against personnel for unauthorized actions, such as unauthorized use of authority or unauthorized use of the entity systems;
o 对未经授权行为的人员的制裁，如未经授权使用权限或未经授权使用实体系统；
o Controls on personnel that are contractors rather than employees of the entity; examples include:
o 对作为承包商而非实体员工的人员的控制；例子包括：
* Bonding requirements on contract personnel;
* 对合同人员的担保要求；
* Contractual requirements including indemnification for damages due to the actions of the contractor personnel;
* 合同要求，包括因承包商人员的行为造成的损害赔偿；
* Auditing and monitoring of contractor personnel; and
* 承包商人员的审计和监督；和
* Other controls on contracting personnel.
* 对订约人员的其他控制。
o Documentation to be supplied to personnel during initial training, retraining, or otherwise.
o 在初始培训、再培训或其他过程中向人员提供的文件。
This subcomponent is used to describe event logging and audit systems, implemented for the purpose of maintaining an audit trail and to provide evidence of process integrity. Elements include the following:
此子组件用于描述事件日志记录和审计系统，用于维护审计跟踪和提供过程完整性证据。内容包括：
o Types of events recorded, such as records of key rollover and other key management operations, the personnel assigned to various roles, attempts to access the system, and requests made to the system;
o 记录的事件类型，例如密钥翻转和其他密钥管理操作的记录、分配给不同角色的人员、尝试访问系统的情况以及向系统发出的请求；
o Frequency with which audit logs are processed or archived, e.g., weekly following an alarm or anomalous event or whenever the audit log size reaches a particular size;
o 处理或归档审计日志的频率，例如，在警报或异常事件发生后每周或审计日志大小达到特定大小时；
o Period for which audit logs are kept;
o 保存审核日志的期限；
o Protection of audit logs:
o 审计日志的保护：
* Who can view audit logs, for example, only the audit administrator;
* 谁可以查看审核日志，例如，只有审核管理员；
* Protection against modification of audit logs, for instance, a requirement that no one may modify or delete the audit records or that only an audit administrator may delete an audit file as part of audit file rotation; and
* 防止修改审计日志，例如，要求任何人不得修改或删除审计记录，或者只有审计管理员可以删除审计文件，作为审计文件轮换的一部分；和
* Protection against deletion of audit logs.
* 防止删除审核日志。
o Audit log backup procedures;
o 审核日志备份程序；
o Whether the audit log collection function is internal or external to the system;
o 审计日志收集功能是系统内部的还是外部的；
o Whether the subject who caused an audit event to occur is notified of the audit action; and
o 是否将审计行动通知导致审计事件发生的主体；和
o Vulnerability assessments, for example, where audit data is run through a tool that identifies potential attempts to breach the security of the system.
o 例如，漏洞评估，其中审计数据通过一个工具运行，该工具可识别破坏系统安全性的潜在企图。
This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following may need to be addressed separately:
本子部分描述了发生危害或灾难时与通知和恢复程序相关的要求。以下各项可能需要单独解决：
o Identification or listing of the applicable incident and compromise reporting and handling procedures, which may include the investigation of measures to prevent the event from reoccurring.
o 确定或列出适用的事件和危害报告和处理程序，其中可能包括调查防止事件再次发生的措施。
o The recovery procedures used if computing resources, software, and/or data are corrupted or suspected to have been corrupted. These procedures describe how, and under what circumstances, operations of the system are to be suspended; how and when normal operations are resumed; how the stakeholders are to be informed; and how to assess the damage and carry out the root cause analysis.
o 如果计算资源、软件和/或数据已损坏或怀疑已损坏，则使用的恢复过程。这些程序描述了如何以及在什么情况下暂停系统的运行；恢复正常运行的方式和时间；如何告知利益相关者；以及如何评估损害并进行根本原因分析。
o The recovery procedures used if any keys are compromised. These procedures describe how a secure environment is re-established, how the keys are rolled over, how a new trust anchor is provided to the community (if applicable), and how new zone information is published.
o 如果任何密钥被泄露，则使用恢复程序。这些过程描述了如何重新建立安全环境、如何滚动密钥、如何向社区提供新的信任锚（如果适用）以及如何发布新的区域信息。
o The entity's capabilities to ensure business continuity following a natural or other disaster. Such capabilities may include the availability of a disaster recovery site at which operations may be recovered. They may also include procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is re-established, either at the original site or at a disaster recovery site, for example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.
o 实体在自然灾害或其他灾害后确保业务连续性的能力。此类功能可能包括可恢复操作的灾难恢复站点的可用性。它们还可能包括在自然灾害或其他灾害发生后以及重建安全环境之前，在原始现场或灾难恢复现场保护其设施的程序，例如，防止敏感材料从地震受损现场被盗的程序。
This subcomponent describes requirements relating to procedures for termination of a contract with an entity, termination notification, and transition of responsibilities to another entity. The purpose may be to ensure that the transition process will be transparent to the stakeholders, and it will not affect the services.
本子部分描述了与实体终止合同、终止通知以及向另一实体移交责任的程序相关的要求。其目的可能是确保过渡过程对利益相关者透明，并且不会影响服务。
This component is used to define the security measures taken to protect the cryptographic keys and activation data (e.g., PINs, passwords, or manually held key shares) relevant to DNSSEC operations. Secure key management is critical to ensure that all secret and private keys and activation data are protected and used only by authorized personnel.
此组件用于定义为保护与DNSSEC操作相关的加密密钥和激活数据（例如PIN、密码或手动持有的密钥共享）而采取的安全措施。安全密钥管理对于确保所有密钥和私钥以及激活数据都受到保护，并且仅由授权人员使用至关重要。
Also described here are other technical security controls used to perform the functions of key generation, authentication, registration, auditing, and archiving. Technical controls include life cycle security controls, software development environment security, and operational security controls.
这里还描述了用于执行密钥生成、身份验证、注册、审核和归档功能的其他技术安全控制。技术控制包括生命周期安全控制、软件开发环境安全控制和操作安全控制。
If applicable, other technical security controls on repositories, authoritative name servers, or other participants may also be documented here.
如果适用，还可以在此处记录存储库、权威名称服务器或其他参与者的其他技术安全控制。
Key pair generation and installation need to be considered, which may involve answering the following questions:
需要考虑密钥对的生成和安装，这可能涉及回答以下问题：
1. Who generates the zone's public/private key pairs? How is the key generation performed? Is the key generation performed by hardware or software?
1. 谁生成区域的公钥/私钥对？密钥生成是如何执行的？密钥生成是由硬件还是软件执行的？
2. How is the private key installed in all parts of the key management system?
2. 如何在密钥管理系统的所有部分安装私钥？
3. How are the zone's public keys provided securely to the parent zone and potential relying parties?
3. 区域的公钥如何安全地提供给父区域和潜在依赖方？
4. Who generates the public key parameters. Is the quality of the parameters checked during key generation?
4. 谁生成公钥参数。在密钥生成过程中是否检查了参数的质量？
5. For what purposes may the keys be used, and/or for what purposes should usage of the key be restricted?
5. 钥匙可用于什么目的，和/或应限制钥匙的使用用于什么目的？
4.5.2. Private Key Protection and Cryptographic Module Engineering Controls
4.5.2. 私钥保护和加密模块工程控制
Requirements for private key protection and cryptographic modules need to be considered for key generation and creation of signatures. The following questions may need to be answered:
密钥生成和签名创建需要考虑私钥保护和加密模块的要求。可能需要回答以下问题：
1. What standards, if any, are required for the cryptographic module used to generate the keys? A cryptographic module can be composed of hardware, software, firmware, or any combination of them. For example, are the zone's signatures required to be generated using modules compliant with the US FIPS 140-2 [FIPS-140-2] standard? If so, what is the required FIPS 140-2 level of the module? Are there any other engineering or other controls relating to a cryptographic module, such as the identification of the cryptographic module boundary, input/ output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests?
1. 用于生成密钥的加密模块需要什么标准（如果有）？加密模块可以由硬件、软件、固件或它们的任意组合组成。例如，是否需要使用符合美国FIPS 140-2[FIPS-140-2]标准的模块生成区域签名？如果是，模块所需的FIPS 140-2级别是什么？是否存在与加密模块相关的任何其他工程或其他控制，如加密模块边界的标识、输入/输出、角色和服务、有限状态机、物理安全性、软件安全性、操作系统安全性、算法符合性、电磁兼容性和自检？
2. Is the private key under m of n multi-person control? If yes, provide m and n (two-person control is a special case of m of n, where m = 2 and n >= 2).
2. 私钥是否在m/n多人控制下？如果是，则提供m和n（两人控制是n中的m的特例，其中m=2和n>=2）。
3. Is the private key escrowed? If so, who is the escrow agent, in what form is the key escrowed (e.g., plaintext, encrypted, split key), and what are the security controls on the escrow system?
3. 私钥是否托管？如果是，谁是托管代理，以何种形式托管密钥（例如，明文、加密、拆分密钥），托管系统的安全控制措施是什么？
4. Is the private key backed up? If so, who is the backup agent, in what form is the key backed up (e.g., plaintext, encrypted, split key), and what are the security controls on the backup system?
4. 私钥是否已备份？如果是，谁是备份代理，以何种形式备份密钥（例如，明文、加密、拆分密钥），以及备份系统上的安全控制措施是什么？
5. Is the private key archived? If so, who is the archival agent, in what form is the key archived (e.g. plaintext, encrypted, split key), and what are the security controls on the archival system?
5. 私钥是否已存档？如果是，谁是存档代理，密钥以何种形式存档（例如，明文、加密、拆分密钥），以及存档系统上的安全控制措施是什么？
6. Under what circumstances, if any, can a private key be transferred into or from a cryptographic module? Who is permitted to perform such a transfer operation? In what form is the private key during the transfer (e.g., plaintext, encrypted, or split key)?
6. 在什么情况下（如果有的话），可以将私钥传输到加密模块或从加密模块传输私钥？允许谁执行此类转移操作？在传输过程中，私钥的形式是什么（例如，明文、加密或分割密钥）？
7. How is the private key stored in the module (e.g., plaintext, encrypted, or split key)?
7. 私钥如何存储在模块中（例如，明文、加密或分割密钥）？
8. Who can activate (use) the private key? What actions must be performed to activate the private key (e.g., login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key active for an indefinite period, active for one time, or active for a defined time period?
8. 谁可以激活（使用）私钥？激活私钥必须执行哪些操作（例如登录、通电、电源PIN、插入令牌/密钥、自动等）？一旦钥匙被激活，钥匙是无限期激活、一次激活还是在规定的时间段内激活？
9. Who can deactivate the private key and how? Examples of methods of deactivating private keys include logging out, turning the power off, removing the token/key, automatic deactivation, and time expiration.
9. 谁可以停用私钥？如何停用？停用私钥的方法的示例包括注销、关闭电源、移除令牌/密钥、自动停用和过期。
10. Who can destroy the private key and how? Examples of methods of destroying private keys include token surrender, token destruction, and zeroizing the key.
10. 谁可以销毁私钥？如何销毁？销毁私钥的方法示例包括令牌放弃、令牌销毁和密钥归零。
Other aspects of key management need to be considered for the zone operator and other participants. For each of these types of entities, the following questions may need to be answered:
区域运营商和其他参与者需要考虑密钥管理的其他方面。对于每种类型的实体，可能需要回答以下问题：
1. What are the life cycle states for the management of any signing keys?
1. 管理任何签名密钥的生命周期状态是什么？
2. What is the operational period of these keys? What are the usage periods or active lifetimes for the pairs?
2. 这些钥匙的使用期限是多久？配对的使用周期或有效寿命是多少？
Activation data refers to data values other than whole private keys that are required to operate private keys or cryptographic modules containing private keys, such as a PIN, passphrase, or portions of a private key used in a key-splitting scheme. Protection of activation data prevents unauthorized use of the private key and potentially needs to be considered for the zone operator and other participants. Such a consideration may need to address the entire life cycle of the activation data from generation through archival and destruction. For each of the entity types, all of the questions listed in Sections 4.5.1 through 4.5.3 potentially need to be answered with respect to activation data rather than with respect to keys.
激活数据是指操作私钥或包含私钥的加密模块（如PIN、密码短语或密钥分割方案中使用的私钥部分）所需的除整个私钥以外的数据值。对激活数据的保护可防止私钥的未经授权使用，区域操作员和其他参与者可能需要考虑这一点。这种考虑可能需要解决激活数据从生成到存档和销毁的整个生命周期。对于每种实体类型，第4.5.1节至第4.5.3节中列出的所有问题都可能需要回答与激活数据有关的问题，而不是与密钥有关的问题。
This subcomponent is used to describe computer security controls such as:
此子组件用于描述计算机安全控制，例如：
1. use of the trusted computing base concept or equivalent;
1. 使用可信计算基础概念或同等概念；
2. discretionary access control, labels, mandatory access controls;
2. 自主访问控制、标签、强制访问控制；
3. object reuse;
3. 对象重用；
4. auditing;
4. 审计
5. identification and authentication;
5. 识别和认证；
6. trusted path; and
6. 可信路径；和
7. security testing.
7. 安全测试。
This subcomponent may also address requirements for product assurance, product evaluation analysis, testing, profiling, product certification, and/or product accreditation.
该子组件还可以满足产品保证、产品评估分析、测试、分析、产品认证和/或产品认证的要求。
This subcomponent addresses network security related controls, including firewalls, routers, and remote access.
此子组件处理与网络安全相关的控制，包括防火墙、路由器和远程访问。
This subcomponent addresses requirements or practices relating to the use of timestamps on various data. It may also discuss whether or not the timestamping application must use a trusted time source.
本子组件阐述了与在各种数据上使用时间戳相关的要求或实践。它还可能讨论时间戳应用程序是否必须使用受信任的时间源。
This subcomponent addresses system development controls and security management controls.
此子组件涉及系统开发控制和安全管理控制。
System development controls include development environment security, development personnel security, configuration management security during product maintenance, software engineering practices, software development methodology, modularity, layering, use of fail-safe design and implementation techniques (e.g., defensive programming), and development facility security.
系统开发控制包括开发环境安全、开发人员安全、产品维护期间的配置管理安全、软件工程实践、软件开发方法、模块化、分层、故障安全设计和实施技术的使用（例如，防御性编程），和发展设施安全。
Security management controls include execution of tools and procedures to ensure that the operational systems and networks adhere to configured security. These tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation.
安全管理控制包括执行工具和程序，以确保操作系统和网络遵守配置的安全。这些工具和程序包括检查安全软件、固件和硬件的完整性，以确保其正确运行。
This component covers all aspects of zone signing, including the cryptographic specification surrounding the signing keys, signing scheme, and methodology for key rollover and the actual zone signing. Child zones and other relying parties may depend on the information in this section to understand the expected data in the signed zone
此组件涵盖区域签名的所有方面，包括围绕签名密钥的加密规范、签名方案以及密钥翻转和实际区域签名的方法。子区域和其他依赖方可能依赖本节中的信息来了解签名区域中的预期数据
and determine their own behavior. In addition, this section will be used to state the compliance to the cryptographic and operational requirements pertaining to zone signing, if any.
并决定自己的行为。此外，本节将用于说明是否符合与区域签名相关的加密和操作要求（如有）。
This subcomponent describes the key generation algorithm, the key types used for signing the key set and zone data, and key lengths used to create the keys. It should also cover how changes to these key lengths, key types, and algorithms may be performed.
此子组件描述密钥生成算法、用于签名密钥集和区域数据的密钥类型以及用于创建密钥的密钥长度。它还应包括如何对这些密钥长度、密钥类型和算法进行更改。
Authenticated denial of existence refers to the usage of NSEC [RFC4034], NSEC3 [RFC5155], or any other mechanism defined in the future that is used to authenticate the denial of existence of resource records. This subcomponent describes what mechanisms are used, any parameters associated with that mechanism, and how these mechanisms and parameters may be changed.
已验证的拒绝存在是指使用NSEC[RFC4034]、NSEC3[RFC5155]或将来定义的用于验证资源记录拒绝存在的任何其他机制。此子组件描述了使用的机制、与该机制相关的任何参数，以及如何更改这些机制和参数。
This subcomponent is used to describe the signing method and algorithms used for the zone signing.
此子组件用于描述用于区域签名的签名方法和算法。
This subcomponent explains the key rollover scheme for each key type.
此子组件解释了每种密钥类型的密钥翻转方案。
This subcomponent describes the life cycle of the Resource Record Signature (RRSIG) record.
此子组件描述资源记录签名（RRSIG）记录的生命周期。
This subsection addresses the controls around the verification of the resource records in order to validate and authenticate the data to be signed. This may include a separate key set verification process if using a split key signing scheme.
本小节介绍了围绕验证资源记录的控制，以验证和验证要签名的数据。如果使用分割密钥签名方案，这可能包括单独的密钥集验证过程。
This subcomponent specifies the resource records' time-to-live (TTL) for all types relevant to DNSSEC, as well as any global parameters that affect the caching mechanisms of the resolvers.
此子组件指定与DNSSEC相关的所有类型的资源记录的生存时间（TTL），以及影响冲突解决程序缓存机制的任何全局参数。
To prove the compliance with a Policy or the statements in the Practice Statement, a compliance audit can be conducted. This component describes how the audit is to be conducted at the zone operator and, possibly, at other involved entities.
为了证明符合政策或实践声明中的声明，可以进行合规审计。本部分描述了如何在区域运营商以及可能在其他相关实体进行审计。
This subcomponent describes the frequency of the compliance audit.
本子部分描述了合规性审核的频率。
This subcomponent addresses what qualifications are required of the auditor. For instance, it may be that an auditor must belong to a specific association or that they have certain certifications.
本子部分说明了审计师所需的资格。例如，一名审计员必须属于某个特定的协会，或者他们拥有某些证书。
This subcomponent is used to clarify the relationship between the auditor and the entity being audited. This becomes important if there are any requirements or guidelines for the selection of the auditor.
本子部分用于澄清审计师与被审计实体之间的关系。如果对审计师的选择有任何要求或指南，这一点就变得非常重要。
Topics covered by audit depends on the scope of the audit. Since the DNSSEC Policy and Practice Statement is the document to be audited against, it is ideal to set the scope of the audit to the scope of the DP/DPS. However, the scope may be narrowed down or expanded as needed, for example, if there are not enough resources to conduct a full audit or if some portion is under development and not ready for the audit.
审计涉及的主题取决于审计的范围。由于DNSSEC政策和实践声明是要审计的文件，因此最好将审计范围设置为DP/DPS的范围。但是，如果没有足够的资源进行全面审计，或者某一部分正在开发中，尚未准备好进行审计，则可根据需要缩小或扩大范围。
This subcomponent specifies the action taken in order to correct any discrepancy that has a security impact. This could be the remediation process for the audit findings or any other action to correct any discrepancy with the DNSSEC Policy or Practice Statement.
此子组件指定为纠正任何具有安全影响的差异而采取的操作。这可能是审计发现的补救过程，也可能是纠正与DNSSEC政策或实践声明不一致的任何其他行动。
This subcomponent specifies how the results of the audit are communicated to the stakeholders.
本子部分规定了如何将审计结果传达给利益相关者。
The introduction of DNSSEC into a zone may have legal implications. Consequently, it may be appropriate to declare the legal status of the binding embodied in the DNSSEC digital signatures and to clarify on any limitations of liability asserted by the registry manager.
将DNSSEC引入区域可能会产生法律影响。因此，可能需要声明DNSSEC数字签名中包含的约束的法律地位，并澄清注册管理人主张的任何责任限制。
In most cases, the DPS is not a contract or part of a contract; instead, it is laid out so that its terms and conditions are applied to the parties by separate documents, such as registrar or registrant agreements. In other cases, its contents may form part of a legal contract between parties (either directly or via other agreements). In this case, legal expertise should be consulted when drawing up sections of the document that may have contractual implications.
在大多数情况下，DPS不是合同或合同的一部分；相反，其条款和条件通过单独的文件（如注册人或注册人协议）适用于双方。在其他情况下，其内容可能构成双方之间法律合同的一部分（直接或通过其他协议）。在这种情况下，在起草可能涉及合同的文件章节时，应咨询法律专家。
At a minimum, the Legal Matters section should indicate under what jurisdiction the registry is operated and provide references to any associated agreements that are in force. It may also be appropriate to inform of any identified implications on the protection of personally identifiable private information.
法律事项一节至少应说明登记处在哪个司法管辖区内运作，并提供有效的任何相关协议的参考资料。还可以告知任何已确定的对保护个人可识别私人信息的影响。
This section contains a recommended outline for a set of provisions, intended to serve as a checklist or a standard template for use by DP or DPS writers. Such a common outline will facilitate:
本节包含一套条款的建议大纲，旨在作为DP或DPS编写者使用的检查表或标准模板。这种共同大纲将有助于：
(a) Comparison of a DPS with a DP to ensure that the DPS faithfully implements the policy.
(a) 将DPS与DP进行比较，以确保DPS忠实地执行策略。
(b) Comparison of two DPSs.
(b) 两个DPS的比较。
Section 4 of this document is structured so that it provides guidance for each corresponding component and subcomponent of the outline.
本文件第4节的结构旨在为大纲的每个相应部分和子部分提供指导。
1. INTRODUCTION 1.1. Overview 1.2. Document name and identification 1.3. Community and applicability 1.4. Specification administration 1.4.1. Specification administration organization 1.4.2. Contact information 1.4.3. Specification change procedures 2. PUBLICATION AND REPOSITORIES 2.1. Repositories 2.2. Publication of public keys 3. OPERATIONAL REQUIREMENTS 3.1. Meaning of domain names
1. 导言1.1。概述1.2。文件名称和标识1.3。社区和适用性1.4。规范管理1.4.1。规范管理组织1.4.2。联系信息1.4.3。规范变更程序2。出版物和存储库2.1。存储库2.2。公开密钥的发布3。操作要求3.1。域名的含义
3.2. Identification and authentication of child zone manager 3.3. Registration of delegation signer (DS) resource records 3.4. Method to prove possession of private key 3.5. Removal of DS resource records 3.5.1. Who can request removal 3.5.2. Procedure for removal request 3.5.3. Emergency removal request 4. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS 4.1. Physical controls 4.1.1. Site location and construction 4.1.2. Physical access 4.1.3. Power and air conditioning 4.1.4. Water exposures 4.1.5. Fire prevention and protection 4.1.6. Media storage 4.1.7. Waste disposal 4.1.8. Off-site backup 4.2. Procedural controls 4.2.1. Trusted roles 4.2.2. Number of persons required per task 4.2.3. Identification and authentication for each role 4.2.4. Tasks requiring separation of duties 4.3. Personnel controls 4.3.1. Qualifications, experience, and clearance requirements 4.3.2. Background check procedures 4.3.3. Training requirements 4.3.4. Job rotation frequency and sequence 4.3.5. Sanctions for unauthorized actions 4.3.6. Contracting personnel requirements 4.3.7. Documentation supplied to personnel 4.4. Audit logging procedures 4.4.1. Types of events recorded 4.4.2. Frequency of processing log 4.4.3. Retention period for audit log information 4.4.4. Protection of audit log 4.4.5. Audit log backup procedures 4.4.6. Audit collection system 4.4.7. Vulnerability assessments 4.5. Compromise and disaster recovery 4.5.1. Incident and compromise handling procedures 4.5.2. Corrupted computing resources, software, and/or data 4.5.3. Entity private key compromise procedures 4.5.4. Business continuity and IT disaster recovery capabilities 4.6. Entity termination
3.2. 子区域管理器的识别和认证3.3。授权签署人（DS）资源记录的注册3.4。证明拥有私钥的方法3.5。删除DS资源记录3.5.1。谁可以要求删除3.5.2。拆除程序要求3.5.3。紧急撤离请求4。设施、管理和运营控制4.1。物理控制4.1.1。现场位置和施工4.1.2。物理访问4.1.3。电力和空调4.1.4。水暴露4.1.5。防火和保护4.1.6。媒体存储4.1.7。废物处理4.1.8。场外备份4.2。程序控制4.2.1。受信任的角色4.2.2。任务4.2.3要求的人数。每个角色的标识和身份验证4.2.4。需要职责分离的任务4.3。人员控制4.3.1。资格、经验和许可要求4.3.2。背景检查程序4.3.3。培训要求4.3.4。工作轮换频率和顺序4.3.5。对未经授权行为的制裁4.3.6。合同人员要求4.3.7。提供给人员的文件4.4。审计记录程序4.4.1。4.4.2记录的事件类型。处理日志4.4.3的频率。审核日志信息的保留期4.4.4。保护审计日志4.4.5。审核日志备份程序4.4.6。审计收集系统4.4.7。脆弱性评估4.5。妥协和灾难恢复4.5.1。事件和危害处理程序4.5.2。损坏的计算资源、软件和/或数据4.5.3。实体私钥泄露程序4.5.4。业务连续性和IT灾难恢复能力4.6。实体终止
5. TECHNICAL SECURITY CONTROLS 5.1. Key pair generation and installation 5.1.1. Key pair generation 5.1.2. Public key delivery 5.1.3. Public key parameters generation and quality checking 5.1.4. Key usage purposes 5.2. Private key protection and cryptographic module engineering controls 5.2.1. Cryptographic module standards and controls 5.2.2. Private key (m-of-n) multi-person control 5.2.3. Private key escrow 5.2.4. Private key backup 5.2.5. Private key storage on cryptographic module 5.2.6. Private key archival 5.2.7. Private key transfer into or from a cryptographic module 5.2.8. Method of activating private key 5.2.9. Method of deactivating private key 5.2.10. Method of destroying private key 5.3. Other aspects of key pair management 5.4. Activation data 5.4.1. Activation data generation and installation 5.4.2. Activation data protection 5.4.3. Other aspects of activation data 5.5. Computer security controls 5.6. Network security controls 5.7. Timestamping 5.8. Life cycle technical controls 6. ZONE SIGNING 6.1. Key lengths, key types, and algorithms 6.2. Authenticated denial of existence 6.3. Signature format 6.4. Key rollover 6.5. Signature lifetime and re-signing frequency 6.6. Verification of resource records 6.7. Resource records time-to-live 7. COMPLIANCE AUDIT 7.1. Frequency of entity compliance audit 7.2. Identity/qualifications of auditor 7.3. Auditor's relationship to audited party 7.4. Topics covered by audit 7.5. Actions taken as a result of deficiency 7.6. Communication of results 8. LEGAL MATTERS
5. 技术安全控制5.1。密钥对生成和安装5.1.1。密钥对生成5.1.2。公开密钥交付5.1.3。公钥参数生成和质量检查5.1.4。主要用途5.2。私钥保护和加密模块工程控制5.2.1。加密模块标准和控制5.2.2。私钥（m-of-n）多人控制5.2.3。私钥托管5.2.4。私钥备份5.2.5。加密模块5.2.6上的私钥存储。私钥存档5.2.7。加密模块5.2.8中的私钥传输。激活私钥的方法5.2.9。禁用私钥的方法5.2.10。销毁私钥的方法5.3。密钥对管理的其他方面5.4。激活数据5.4.1。激活数据生成和安装5.4.2。激活数据保护5.4.3。激活数据的其他方面5.5。计算机安全控制5.6。网络安全控制5.7。时间戳5.8。生命周期技术控制6。区域标志6.1。密钥长度、密钥类型和算法6.2。经认证的拒绝存在6.3。签名格式6.4。键滚动6.5。签名寿命和重新签名频率6.6。核实资源记录6.7。资源记录生存时间7。合规审计7.1。实体合规审计频率7.2。审计员的身份/资格7.3。审计师与被审计方的关系7.4。审计7.5涵盖的主题。因缺陷7.6而采取的措施。交流结果8。法律事项
The sensitivity of the information protected by DNSSEC at different tiers in the DNS tree varies significantly. In addition, there are no restrictions as to what types of information (i.e., DNS records) that can be protected using DNSSEC. Each relying party must evaluate its own environment and the chain of trust originating from a trust anchor, the associated threats and vulnerabilities, to determine the level of risk it is willing to accept when relying on DNSSEC-protected objects.
在DNS树的不同层上，DNSSEC保护的信息的敏感度差别很大。此外，对于使用DNSSEC可以保护哪些类型的信息（即DNS记录），没有任何限制。每个依赖方必须评估其自身环境和源自信任锚的信任链、相关威胁和漏洞，以确定其在依赖DNSSEC保护对象时愿意接受的风险水平。
This document is inspired by RFC 3647 and its predecessor (RFC 2527), and the authors acknowledge the work in the development of these documents.
本文件受RFC 3647及其前身（RFC 2527）的启发，作者对这些文件的开发工作表示认可。
In addition, the authors would like to acknowledge the contributions made by Richard Lamb, Jakob Schlyter, and Stephen Morris.
此外，作者还要感谢Richard Lamb、Jakob Schlyter和Stephen Morris所做的贡献。
[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月。
[FIPS-140-2] NIST, "Security Requirements for Cryptographic Modules", June 2005, <http://csrc.nist.gov/ publications/fips/fips140-2/fips1402.pdf>.
[FIPS-140-2]NIST，“加密模块的安全要求”，2005年6月<http://csrc.nist.gov/ 出版物/fips/fips140-2/fips1402.pdf>。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[RFC3647]Chokhani，S.，Ford，W.，Sabett，R.，Merrill，C.，和S.Wu，“互联网X.509公钥基础设施证书政策和认证实践框架”，RFC 3647，2003年11月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
Authors' Addresses
作者地址
Fredrik Ljunggren Kirei AB P.O. Box 53204 Goteborg SE-400 16 Sweden
Fredrik Ljunggren Kirei AB邮政信箱53204哥德堡SE-400 16瑞典
EMail: fredrik@kirei.se
EMail: fredrik@kirei.se
Anne-Marie Eklund Lowinder .SE (The Internet Infrastructure Foundation) P.O. Box 7399 Stockholm SE-103 91 Sweden
Anne-Marie Eklund Lowinder.SE（互联网基础设施基金会）邮政信箱7399斯德哥尔摩SE-103 91瑞典
EMail: amel@iis.se
EMail: amel@iis.se
Tomofumi Okubo Internet Corporation For Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Ray, CA 90292 USA
美国加利福尼亚州Marina del Ray 330号金钟大道4676号，大久保智文互联网公司，邮编90292
EMail: tomofumi.okubo@icann.org
EMail: tomofumi.okubo@icann.org