Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 7344 Google
Category: Informational O. Gudmundsson
ISSN: 2070-1721 OGUD Consulting
G. Barwood
September 2014
Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 7344 Google
Category: Informational O. Gudmundsson
ISSN: 2070-1721 OGUD Consulting
G. Barwood
September 2014
Automating DNSSEC Delegation Trust Maintenance
自动化DNSSEC委托信任维护
Abstract
摘要
This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.
本文档描述了一种允许DNS操作员使用DNS作为通信通道更轻松地更新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/rfc7344.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7344.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DNS Delegations . . . . . . . . . . . . . . . . . . . . . 5
2.2. Relationship between Parent and Child DNS Operators . . . 5
2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6
2.2.2. DNSSEC Key Change Process . . . . . . . . . . . . . . 7
3. CDS (Child DS) and CDNSKEY (Child DNSKEY) Record Definitions 7
3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 8
3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8
4. Automating DS Maintenance with CDS/CDNSKEY Records . . . . . 8
4.1. CDS and CDNSKEY Processing Rules . . . . . . . . . . . . 9
5. CDS/CDNSKEY Publication . . . . . . . . . . . . . . . . . . . 9
6. Parent-Side CDS/CDNSKEY Consumption . . . . . . . . . . . . . 9
6.1. Detecting a Changed CDS/CDNSKEY . . . . . . . . . . . . . 10
6.1.1. CDS/CDNSKEY Polling . . . . . . . . . . . . . . . . . 10
6.1.2. Polling Triggers . . . . . . . . . . . . . . . . . . 11
6.2. Using the New CDS/CDNSKEY Records . . . . . . . . . . . . 11
6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. RRR Background . . . . . . . . . . . . . . . . . . . 17
Appendix B. CDS Key Rollover Example . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DNS Delegations . . . . . . . . . . . . . . . . . . . . . 5
2.2. Relationship between Parent and Child DNS Operators . . . 5
2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6
2.2.2. DNSSEC Key Change Process . . . . . . . . . . . . . . 7
3. CDS (Child DS) and CDNSKEY (Child DNSKEY) Record Definitions 7
3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 8
3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8
4. Automating DS Maintenance with CDS/CDNSKEY Records . . . . . 8
4.1. CDS and CDNSKEY Processing Rules . . . . . . . . . . . . 9
5. CDS/CDNSKEY Publication . . . . . . . . . . . . . . . . . . . 9
6. Parent-Side CDS/CDNSKEY Consumption . . . . . . . . . . . . . 9
6.1. Detecting a Changed CDS/CDNSKEY . . . . . . . . . . . . . 10
6.1.1. CDS/CDNSKEY Polling . . . . . . . . . . . . . . . . . 10
6.1.2. Polling Triggers . . . . . . . . . . . . . . . . . . 11
6.2. Using the New CDS/CDNSKEY Records . . . . . . . . . . . . 11
6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. RRR Background . . . . . . . . . . . . . . . . . . . 17
Appendix B. CDS Key Rollover Example . . . . . . . . . . . . . . 17
The first time a DNS Operator signs a zone, they need to communicate the keying material to their Parent through some out-of-band method to complete the chain of trust. Depending on the desires of the Parent, the Child might send their DNSKEY record, a DS record, or both.
DNS运营商第一次签署区域时，他们需要通过一些带外方法将密钥材料传达给其父代，以完成信任链。根据家长的意愿，孩子可能会发送他们的DNSKEY记录、DS记录或两者。
Each time the Child changes the key that is represented in the Parent, the updated and/or deleted key information has to be communicated to the Parent and published in the Parent's zone. How this information is sent to the Parent depends on the relationship the Child has with the Parent. In many cases this is a manual process -- and not an easy one. For each key change, there may be up to two interactions with the Parent. Any manual process is susceptible to mistakes and/or errors. In addition, due to the annoyance factor of the process, Operators may avoid changing keys or skip needed steps to publish the new DS at the Parent.
每次子项更改父项中表示的密钥时，必须将更新和/或删除的密钥信息传达给父项并在父项的区域中发布。如何将此信息发送给家长取决于孩子与家长之间的关系。在许多情况下，这是一个手动过程——而不是一个简单的过程。对于每个关键更改，最多可能有两个与父级的交互。任何手动过程都容易出现错误和/或错误。此外，由于过程中的烦恼因素，操作员可能会避免更改键或跳过在父级发布新DS所需的步骤。
DNSSEC provides data integrity to information published in DNS; thus, DNS publication can be used to automate maintenance of delegation information. This document describes a method to automate publication of subsequent DS records after the initial one has been published.
DNSSEC为DNS中发布的信息提供数据完整性；因此，DNS发布可用于自动维护委派信息。本文档描述了在初始DS记录发布后自动发布后续DS记录的方法。
Readers are expected to be familiar with DNSSEC, including [RFC4033], [RFC4034], [RFC4035], [RFC5011], and [RFC6781].
读者应熟悉DNSSEC，包括[RFC4033]、[RFC4034]、[RFC4035]、[RFC5011]和[RFC6781]。
This document outlines a technique in which the Parent periodically (or upon request) polls its signed Children and automatically publishes new DS records. To a large extent, the procedures this document follows are as described in [RFC6781], Section 4.1.2.
本文档概述了一种技术，其中父级定期（或根据请求）轮询其已签名的子级，并自动发布新的DS记录。在很大程度上，本文件遵循的程序如[RFC6781]第4.1.2节所述。
This technique is designed to be friendly both to fully automated tools and humans. Fully automated tools can perform all the actions needed without human intervention and thus can monitor when it is safe to move to the next step.
这项技术被设计为对全自动工具和人类都友好。全自动工具可以执行所有需要的操作，无需人工干预，因此可以监控何时可以安全地进入下一步。
The solution described in this document only allows transferring information about DNSSEC keys (DS and DNSKEY) from the Child to the Parental Agent. It lists exactly what the Parent should publish and allows for publication of standby keys. A different protocol, [CPSYNC-DNS], can be used to maintain other important delegation information, such as NS and glue records. These two protocols have been kept as separate solutions because the problems are fundamentally different and a combined solution is overly complex.
本文档中描述的解决方案仅允许将有关DNSSEC密钥（DS和DNSKEY）的信息从孩子传输到家长代理。它准确地列出了父级应该发布的内容，并允许发布备用密钥。不同的协议[CPSYNC-DNS]可用于维护其他重要的委派信息，如NS和glue记录。这两个协议一直保持为单独的解决方案，因为问题根本不同，并且组合解决方案过于复杂。
This document describes a method for automating maintenance of the delegation trust information and proposes a polled/periodic trigger for simplicity. Some users may prefer a different trigger, for example, a button on a web page, a REST interface, or a DNS NOTIFY. These alternate additional triggers are not discussed in this document.
本文档描述了一种自动维护委托信任信息的方法，并为简单起见，提出了轮询/定期触发器。一些用户可能更喜欢不同的触发器，例如，网页上的按钮、REST接口或DNS通知。本文档中未讨论这些备用附加触发器。
This proposal does not include all operations needed for the maintenance of DNSSEC key material, specifically the initial introduction or complete removal of all keys. Because of this, alternate communications mechanisms must always exist, potentially introducing more complexity.
本建议书不包括维护DNSSEC钥匙材料所需的所有操作，特别是首次引入或完全拆除所有钥匙。因此，必须始终存在备用通信机制，这可能会带来更大的复杂性。
The terminology we use is defined in this section. The highlighted roles are as follows:
本节定义了我们使用的术语。突出显示的角色如下：
o Child: The entity on record that has the delegation of the domain from the Parent.
o 子项：记录中的实体，该实体具有来自父项的域委派。
o Parent: The domain in which the Child is registered.
o 父级：子级在其中注册的域。
o Child DNS Operator: The entity that maintains and publishes the zone information for the Child DNS.
o 子DNS操作员：维护和发布子DNS区域信息的实体。
o Parental Agent: The entity that the Child has a relationship with to change its delegation information.
o 家长代理：与孩子有关系以更改其委派信息的实体。
o Provisioning System: A system that the Operator of the master DNS server operates to maintain the information published in the DNS. This includes the systems that sign the DNS data.
o 供应系统：主DNS服务器的操作员操作以维护DNS中发布的信息的系统。这包括对DNS数据进行签名的系统。
o CDS/CDNSKEY: This notation refers to CDS and/or CDNSKEY, i.e., one or both.
o CDS/CDNSKEY：此符号表示CDS和/或CDNSKEY，即一个或两个。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
DNS operation consists of delegations of authority. For each delegation, there are (most of the time) two parties: the Parent and the Child.
DNS操作由授权组成。对于每个代表团，有（大多数情况下）两方：家长和孩子。
The Parent publishes information about the delegations to the Child; for the name servers, it publishes an NS [RFC1035] Resource Record Set (RRset) that lists a hint for name servers that are authoritative for the Child. The Child also publishes an NS RRset, and this set is the authoritative list of name servers to the Child zone.
家长向孩子发布有关委托的信息；对于名称服务器，它发布一个NS[RFC1035]资源记录集（RRset），其中列出了对子服务器具有权威性的名称服务器的提示。子级还发布NS RRset，该集合是子区域的名称服务器的权威列表。
The second RRset the Parent sometimes publishes is the DS [RFC4034] set. The DS RRset provides information about the DNSKEY(s) that the Child has told the Parent it will use to sign its DNSKEY RRset. In DNSSEC, a trust relationship between zones is provided by the following chain:
父级有时发布的第二个RRset是DS[RFC4034]集。DS RRset提供有关DNSKEY的信息，该子项已告知父项它将使用该DNSKEY RRset对其进行签名。在DNSSEC中，区域之间的信任关系由以下链提供：
Parent DNSKEY --> DS --> Child DNSKEY.
父DNSKEY-->DS-->子DNSKEY。
A prior proposal [AUTO-CPSYNC] suggested that the Child send an "update" to the Parent via a mechanism similar to DNS UPDATE. The main issue became: how does the Child find the actual Parental Agent/ server to send the update to? While that could have been solved via technical means, it failed to reach consensus. There is also a similar proposal in [PARENT-ZONES].
先前的一项建议[AUTO-CPSYNC]建议子系统通过类似于DNS更新的机制向父系统发送“更新”。主要问题是：孩子如何找到要向其发送更新的实际家长代理/服务器？虽然这可以通过技术手段解决，但未能达成共识。[PARENT-ZONES]中也有类似的提议。
As the DS record can only be present at the Parent [RFC4034], some other method is needed to automate which DNSKEYs are picked to be represented in the Parent zone's DS records. One possibility is to use flags in the DNSKEY record. If the Secure Entry Point (SEP) bit is set, this indicates that the DNSKEY is intended for use as a secure entry point. This DNSKEY signs the DNSKEY RRset, and the Parental Agent can calculate DS records based on that. But this fails to meet some operating needs, including the Child having no influence on what DS digest algorithms are used and DS records that can only be published for keys that are in the DNSKEY RRset; thus, this technique would not be compatible with Double-DS rollover [RFC6781].
由于DS记录只能出现在父区[RFC4034]中，因此需要其他一些方法来自动选择要在父区DS记录中表示的DNSKEY。一种可能是在DNSKEY记录中使用标志。如果设置了安全入口点（SEP）位，则表示DNSKEY拟用作安全入口点。此DNSKEY对DNSKEY RRset进行签名，并且父代理可以基于此计算DS记录。但这无法满足某些操作需要，包括子代对使用的DS摘要算法没有影响，以及只能为DNSKEY RRset中的密钥发布DS记录；因此，该技术与双DS翻转[RFC6781]不兼容。
In practical application, there are many different relationships between the Parent and Child DNS Operators. The type of relationship affects how the Child DNS Operator communicates with the Parent.
在实际应用中，父DNS操作符和子DNS操作符之间存在许多不同的关系。关系类型影响子DNS操作员与父DNS操作员的通信方式。
This section will highlight some of the different situations but is by no means a complete list.
本节将重点介绍一些不同的情况，但绝不是一个完整的列表。
Different communication paths:
不同的通信路径：
o Direct/API: The Child can change the delegation information via automated/scripted means. The Extensible Provisioning Protocol (EPP) [RFC5730], used by many Top-Level Domains (TLDs), is an example of this. Other examples are web-based programmatic interfaces that Registrars make available to their Resellers.
o Direct/API：孩子可以通过自动化/脚本化的方式更改委派信息。许多顶级域（TLD）使用的可扩展资源调配协议（EPP）[RFC5730]就是一个例子。其他示例是注册商向其经销商提供的基于web的编程接口。
o User Interface: The Child uses a web site set up by the Parental Agent for updating delegation information.
o 用户界面：孩子使用家长代理设置的网站更新委派信息。
o Indirect: The communication has to be transmitted via an out-of-band mechanism between two parties, such as by email or telephone. This is common when the Child DNS Operator is neither the Child itself nor the Registrar for the domain, but a third party.
o 间接：通信必须通过双方之间的带外机制进行传输，如电子邮件或电话。当子DNS运营商既不是子DNS运营商本身，也不是域的注册商，而是第三方时，这种情况很常见。
o Multi-step Combinations: The information flows through an intermediary. It is possible, but unlikely, that all the steps are automated via APIs and there are no humans involved.
o 多步骤组合：信息通过中介流动。有可能，但不太可能，所有的步骤都是通过API自动化的，并且没有人参与。
A domain name holder (Child) may operate its own DNS servers or outsource the operation. While we use the word "Parent" as singular, a Parent can consist of a single entity or a composite of many discrete parts that have rules and roles. We refer to the entity that the Child corresponds with as the Parent.
域名持有人（子）可以运营自己的DNS服务器或外包运营。虽然我们使用“父级”一词作为单数，但父级可以由单个实体或具有规则和角色的许多离散部分组成。我们将子实体对应的实体称为父实体。
An organization (such as an enterprise) may delegate parts of its name-space to be operated by a group that is not the same as that which operates the organization's DNS servers. In some of these cases, the flow of information is handled either in an ad hoc manner or via some corporate mechanism; this can range from email to a fully automated operation.
组织（如企业）可以将其名称空间的一部分委托给与运营该组织的DNS服务器不同的组来运营。在某些情况下，信息流要么以特殊方式处理，要么通过某种公司机制处理；这可以从电子邮件到全自动操作。
This document is aimed at the cases in which there is a separation between the Child and Parent.
本文件针对的是子女与父母分离的情况。
A further complication is when the Child DNS Operator is not the Child. There are two common cases of this:
另一个复杂情况是，子DNS操作员不是子DNS操作员。这种情况有两种常见情况：
a) The Parental Agent (e.g., Registrar) handles the DNS operation.
a) 父代理（例如，注册器）处理DNS操作。
b) A third party takes care of the DNS operation.
b) 第三方负责DNS操作。
If the Parental Agent is the DNS Operator, life is much easier; the Parental Agent can inject any delegation changes directly into the Parent's provisioning system. The techniques described below are not needed in the case when the Parental Agent is the DNS Operator.
如果家长代理是DNS运营商，生活会轻松得多；家长代理可以将任何委派更改直接注入家长的供应系统。当父代理是DNS操作员时，不需要以下描述的技术。
In the case of a third-party DNS Operator, the Child either needs to relay changes in DNS delegation or give the Child DNS Operator access to its delegation/registration account.
如果是第三方DNS运营商，则子DNS运营商需要转发DNS委派中的更改，或授予子DNS运营商访问其委派/注册帐户的权限。
Some Parents want the Child to express their DNSKEYs in the form of DS records, while others want to receive the DNSKEY records and calculate the DS records themselves. There is no consensus on which method is better; both have good reasons to exist. This solution is DS vs. DNSKEY agnostic and allows operation with either.
一些家长希望孩子以DS记录的形式表达他们的DNSKEY，而另一些家长希望接收DNSKEY记录并自己计算DS记录。对于哪种方法更好没有共识；两者都有存在的理由。此解决方案是DS vs.DNSKEY不可知的，允许使用其中一种进行操作。
After a Child DNS Operator first signs the zone, there is a need to interact with the Parent, for example, via a delegation account interface to upload or paste in the zone's DS information. This action of logging in through the delegation account user interface authenticates that the user is authorized to change delegation information for the Child published in the Parent zone. In the case where the Child DNS Operator does not have access to the registration account, the Child needs to perform the action.
在子DNS运营商首次签署区域后，需要与父DNS运营商进行交互，例如，通过委派帐户界面上传或粘贴区域的DS信息。通过委派帐户用户界面登录的此操作验证用户有权更改父区域中发布的子项的委派信息。如果子DNS操作员无权访问注册帐户，则子DNS操作员需要执行该操作。
At a later date, the Child DNS Operator may want to publish a new DS record in the Parent, either because they are changing keys or because they want to publish a standby key. This involves performing the same process as before. Furthermore, when this is a manual process with cut and paste, operational mistakes will happen -- or worse, the update action will not be performed at all.
稍后，子DNS运营商可能希望在父级中发布新的DS记录，因为他们正在更改密钥或希望发布备用密钥。这包括执行与以前相同的过程。此外，当这是一个带有剪切和粘贴的手动过程时，会发生操作错误——或者更糟的是，根本不会执行更新操作。
The Child DNS Operator may also introduce new keys and can do so when old keys exist and can be used. The Child may also remove old keys, but this document does not support removing all keys. This is to avoid making signed zones unsigned. The Child may not enroll the initial key or introduce a new key when there are no old keys that can be used (without some additional out-of-band validation of the keys) because there is no way to validate the information.
子DNS运营商还可以引入新密钥，并且可以在旧密钥存在且可以使用时引入新密钥。子项也可以删除旧密钥，但本文档不支持删除所有密钥。这是为了避免使已签名区域未签名。如果没有可以使用的旧密钥（无需对密钥进行额外的带外验证），则孩子可能不会注册初始密钥或引入新密钥，因为无法验证信息。
This document specifies two new DNS resource records, CDS and CDNSKEY. These records are used to convey, from one zone to its Parent, the desired contents of the zone's DS resource record set residing in the Parent zone.
本文档指定了两个新的DNS资源记录：CD和CDNSKEY。这些记录用于将驻留在父分区中的分区DS资源记录集的所需内容从一个分区传送到其父分区。
The CDS and CDNSKEY resource records are published in the Child zone and give the Child control of what is published for it in the parental zone. The Child can publish these manually, or they can be automatically maintained by DNS provisioning tools. The CDS/CDNSKEY RRset expresses what the Child would like the DS RRset to look like after the change; it is a "replace" operation, and it is up to the software that consumes the records to translate that into the appropriate add/delete operations in the provisioning systems (and in the case of CDNSKEY, to generate the DS from the DNSKEY). If neither CDS nor CDNSKEY RRset is present in the Child, this means that no change is needed.
CD和CDNSKEY资源记录在子区域中发布，并使子区域可以控制在父区域中为其发布的内容。子级可以手动发布这些内容，也可以通过DNS配置工具自动维护这些内容。CDS/CDNSKEY RRset表示更改后孩子希望DS RRset的外观；这是一种“替换”操作，由使用记录的软件在供应系统中将其转换为适当的添加/删除操作（对于CDNSKEY，则由DNSKEY生成DS）。如果子级中既不存在CD也不存在CDNSKEY RRset，这意味着不需要更改。
The wire and presentation format of the Child DS (CDS) resource record is identical to the DS record [RFC4034]. IANA has allocated RR code 59 for the CDS resource record via Expert Review [DNS-TRANSPORT]. The CDS RR uses the same registries as DS for its fields.
子DS（CD）资源记录的连线和表示格式与DS记录[RFC4034]相同。IANA已通过专家评审[DNS-TRANSPORT]为CDS资源记录分配RR代码59。CDS RR对其字段使用与DS相同的注册表。
No special processing is performed by authoritative servers or by resolvers, when serving or resolving. For all practical purposes, CDS is a regular RR type.
服务或解析时，权威服务器或解析程序不执行特殊处理。就所有实际用途而言，CDS是常规RR类型。
The wire and presentation format of the CDNSKEY ("Child DNSKEY") resource record is identical to the DNSKEY record. IANA has allocated RR code 60 for the CDNSKEY resource record via Expert Review. The CDNSKEY RR uses the same registries as DNSKEY for its fields.
CDNSKEY（“子DNSKEY”）资源记录的连线和表示格式与DNSKEY记录相同。IANA已通过专家评审为CDNSKEY资源记录分配RR代码60。CDNSKEY RR对其字段使用与DNSKEY相同的注册表。
No special processing is performed by authoritative servers or by resolvers, when serving or resolving. For all practical purposes, CDNSKEY is a regular RR type.
服务或解析时，权威服务器或解析程序不执行特殊处理。出于所有实际目的，CDNSKEY是一种常规RR类型。
CDS/CDNSKEY resource records are intended to be "consumed" by delegation trust maintainers. The use of CDS/CDNSKEY is OPTIONAL.
CDS/CDNSKEY资源记录旨在由委托信任维护者“使用”。CD/CDNSKEY的使用是可选的。
If the Child publishes either the CDS or the CDNSKEY resource record, it SHOULD publish both. If the Child knows which the Parent consumes, it MAY choose to only publish that record type (for example, some Children wish the Parent to publish a DS, but they wish to keep the DNSKEY "hidden" until needed). If the Child publishes both, the two RRsets MUST match in content.
如果子级发布CD或CDNSKEY资源记录，则应同时发布两者。如果子项知道父项使用哪种记录，则可以选择仅发布该记录类型（例如，一些子项希望父项发布DS，但希望在需要时将DNSKEY保持“隐藏”）。如果子级同时发布这两个RRSET，则两个RRSET的内容必须匹配。
If there is neither CDS nor CDNSKEY RRset in the Child, this signals that no change should be made to the current DS set. This means that, once the Child and Parent are in sync, the Child DNS Operator MAY remove all CDS and CDNSKEY resource records from the zone. The Child DNS Operator may choose to do this to decrease the size of the zone or to decrease the workload for the Parent (if the Parent receives no CDS/CDNSKEY records, it can go back to sleep). If it does receive a CDS or CDNSKEY RRset, it needs to check them against what is currently published (see Section 5).
如果子系统中既没有CD也没有CDNSKEY RRset，则表示不应更改当前DS集合。这意味着，一旦子级和父级同步，子DNS操作员可以从区域中删除所有CD和CDNSKEY资源记录。子DNS操作员可以选择这样做以减小区域的大小或减少父级的工作负载（如果父级未收到CD/CDNSKEY记录，则可以返回睡眠）。如果收到CD或CDNSKEY RRset，则需要对照当前发布的内容进行检查（参见第5节）。
The following acceptance rules are placed on the CDS and CDNSKEY resource records as follows:
以下验收规则放置在CD和CDNSKEY资源记录上，如下所示：
o Location: MUST be at the Child zone apex.
o 位置：必须位于子区域顶点。
o Signer: MUST be signed with a key that is represented in both the current DNSKEY and DS RRsets, unless the Parent uses the CDS or CDNSKEY RRset for initial enrollment; in that case, the Parent validates the CDS/CDNSKEY through some other means (see Section 6.1 and the Security Considerations).
o 签名者：必须使用当前DNSKEY和DS RRset中表示的密钥进行签名，除非父级使用CDS或CDNSKEY RRset进行初始注册；在这种情况下，家长通过其他方式验证CDS/CDNSKEY（参见第6.1节和安全注意事项）。
o Continuity: MUST NOT break the current delegation if applied to DS RRset.
o 连续性：如果应用于DS RRset，则不得中断当前委派。
If any these conditions fail, the CDS or CDNSKEY resource record MUST be ignored, and this error SHOULD be logged.
如果这些条件失败，则必须忽略CDS或CDNSKEY资源记录，并记录此错误。
The Child DNS Operator publishes CDS/CDNSKEY RRset(s). In order to be valid, the CDS/CDNSKEY RRset(s) MUST be compliant with the rules in Section 4.1. When the Parent DS is in sync with the CDS/CDNSKEY RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s); the Child can determine if this is the case by querying for DS records in the Parent.
子DNS运营商发布CD/CDNSKEY RRset。为了有效，CDS/CDNSKEY RRset必须符合第4.1节中的规则。当父DS与CDS/CDNSKEY RRset同步时，子DNS操作员可以删除CDS/CDNSKEY RRset；子级可以通过查询父级中的DS记录来确定是否存在这种情况。
The CDS/CDNSKEY RRset(s) SHOULD be used by the Parental Agent to update the DS RRset in the Parent zone. The Parental Agent for this uses a tool that understands the CDS/CDNSKEY signing rules in Section 4.1, so it might not be able to use a standard validator.
家长代理应使用CDS/CDNSKEY RRset更新家长区域中的DS RRset。为此，家长代理使用的工具了解第4.1节中的CDS/CDNSKEY签名规则，因此可能无法使用标准验证器。
The Parent MUST choose to use either CDNSKEY or CDS resource records as its default updating mechanism. The Parent MAY only accept either CDNSKEY or CDS, but it MAY also accept both so it can use the other in the absence of the default updating mechanism; it MUST NOT expect there to be both.
父级必须选择使用CDNSKEY或CDS资源记录作为其默认更新机制。父级可以只接受CDNSKEY或CDS，但也可以同时接受两者，以便在没有默认更新机制的情况下使用另一个；不能期望两者兼而有之。
How the Parental Agent gets the CDS/CDNSKEY RRset may differ. Below are two examples of how this can take place.
家长代理获取CD/CDNSKEY RRset的方式可能有所不同。下面是如何实现这一点的两个示例。
Polling: The Parental Agent operates a tool that periodically checks each of the Children that has a DS record to see if there is a CDS or CDNSKEY RRset.
轮询：家长代理操作一个工具，定期检查每个具有DS记录的孩子，以查看是否存在CD或CDNSKEY RRset。
Pushing: The delegation user interface has a button {Fetch DS} that, when pushed, performs the CDS/CDNSKEY processing. If the Parent zone does not contain DS for this delegation, then the "push" SHOULD be ignored. If the Parental Agent displays the contents of the CDS/CDNSKEY to the user and gets confirmation that this represents their key, the Parental Agent MAY use this for initial enrollment (when the Parent zone does not contain the DS for this delegation).
按下：委派用户界面有一个按钮{Fetch DS}，按下该按钮时，执行CDS/CDNSKEY处理。如果父区域不包含此委派的DS，则应忽略“推送”。如果家长代理向用户显示CD/CDNSKEY的内容，并确认这代表了他们的密钥，家长代理可以将其用于初始注册（当家长区域不包含此委派的DS时）。
In either case, the Parental Agent MAY apply additional rules that defer the acceptance of a CDS/CDNSKEY change. These rules may include a condition that the CDS/CDNSKEY remains in place and valid for some time period before it is accepted. It may be appropriate in the "Pushing" case to assume that the Child is ready and thus accept changes without delay.
在任何一种情况下，家长代理都可以应用延迟接受CDS/CDNSKEY更改的附加规则。这些规则可能包括一个条件，即CDS/CDN密钥在被接受之前保持在原位并有效一段时间。在“推动”的情况下，假设孩子已经准备好，因此毫不拖延地接受改变可能是合适的。
This is the only defined use of CDS/CDNSKEY resource records in this document. There are limits to the scalability of polling techniques; thus, some other mechanism is likely to be specified later that addresses CDS/CDNSKEY resource record usage in the situation where polling runs into scaling issues. Having said that, polling will work in many important cases such as enterprises, universities, and smaller TLDs. In many regulatory environments, the Registry is prohibited from talking to the Registrant. In most of these cases, the Registrant has a business relationship with the Registrar, so the Registrar can offer this as a service.
这是本文档中定义的CD/CDNSKEY资源记录的唯一用途。轮询技术的可扩展性存在限制；因此，稍后可能会指定一些其他机制来解决轮询遇到缩放问题时的CDS/CDNSKEY资源记录使用问题。话虽如此，投票将在许多重要案例中发挥作用，如企业、大学和小型TLD。在许多监管环境中，注册处被禁止与注册人交谈。在大多数情况下，注册人与注册人有业务关系，因此注册人可以将此作为一项服务提供。
If the CDS/CDNSKEY RRset(s) do not exist, the Parental Agent MUST take no action. Specifically, it MUST NOT delete or alter the existing DS RRset.
如果CDS/CDNSKEY RRset不存在，则家长代理不得采取任何操作。具体而言，它不得删除或更改现有DS RRset。
It is assumed that other mechanisms will be implemented to trigger the Parent to look for an updated CDS/CDNSKEY RRset. As the CDS/ CDNSKEY resource records are validated with DNSSEC, these mechanisms can be unauthenticated. As an example, a Child could telephone its Parent and request that it process the new CDS or CDNSKEY resource records, or an unauthenticated POST could be made to a web server (with rate-limiting).
假设将实现其他机制，以触发父级查找更新的CDS/CDNSKEY RRset。由于CDS/CDNSKEY资源记录通过DNSSEC验证，因此这些机制可能未经验证。例如，孩子可以打电话给父母，要求其处理新的CD或CDNSKEY资源记录，或者向web服务器发送未经验证的帖子（有速率限制）。
Other documents can specify the trigger conditions.
其他文档可以指定触发条件。
Regardless of how the Parental Agent detected changes to a CDS/ CDNSKEY RRset, the Parental Agent SHOULD use a DNSSEC validator to obtain a validated CDS/CDNSKEY RRset from the Child zone. A NOT RECOMMENDED exception to this is if the Parent performs some additional validation on the data to confirm that it is the "correct" key.
无论家长代理如何检测到CD/CDNSKEY RRset的更改，家长代理都应使用DNSSEC验证程序从子区域获取已验证的CD/CDNSKEY RRset。不推荐的例外情况是，如果父级对数据执行一些额外的验证，以确认它是“正确”的键。
The Parental Agent MUST ensure that previous versions of the CDS/ CDNSKEY RRset do not overwrite more recent versions. This MAY be accomplished by checking that the signature inception in the Resource Record Signature (RRSIG) for CDS/CDNSKEY RRset is later and/or that the serial number on the Child's Start of Authority (SOA) is greater. This may require the Parental Agent to maintain some state information.
家长代理必须确保以前版本的CD/CDNSKEY RRset不会覆盖较新版本。这可以通过检查CDS/CDNSKEY RRset的资源记录签名（RRSIG）中的签名起始时间是否较晚和/或子级权限起始（SOA）上的序列号是否更大来实现。这可能需要家长代理维护一些状态信息。
The Parental Agent MAY take extra security measures. For example, to mitigate the possibility that a Child's Key Signing Key (KSK) has been compromised, the Parental Agent may inform (by email or other methods) the Child DNS Operator of the change. However, the precise out-of-band measures that a Parent zone takes are outside the scope of this document.
母公司代理可以采取额外的安全措施。例如，为了降低孩子的密钥签名密钥（KSK）被泄露的可能性，家长代理可以（通过电子邮件或其他方法）通知孩子DNS操作员该更改。但是，父区域采取的精确带外测量不在本文档的范围内。
Once the Parental Agent has obtained a valid CDS/CDNSKEY RRset it MUST check the publication rules from Section 4.1. In particular, the Parental Agent MUST check the Continuity rule and do its best not to invalidate the Child zone. Once checked, if the information in the CDS/CDNSKEY and DS differ, it may apply the changes to the Parent zone. If the Parent consumes CDNSKEY, the Parent should calculate the DS before doing this comparison.
一旦家长代理获得有效的CDS/CDNSKEY RRset，则必须检查第4.1节中的发布规则。特别是，家长代理必须检查连续性规则，并尽最大努力不使子区域无效。选中后，如果CD/CDNSKEY和DS中的信息不同，则可能会将更改应用于父区域。如果父级使用CDNSKEY，则在进行此比较之前，父级应计算DS。
There are cases where the Parent wants to calculate the DS record due to policy reasons. In this case, the Child publishes CDNSKEY records, and the Parent calculates the DS records on behalf of the Children.
在某些情况下，由于策略原因，父级希望计算DS记录。在这种情况下，子级发布CDNSKEY记录，父级代表子级计算DS记录。
When a Parent operates in "calculate DS" mode, it can operate in one of two sub-modes:
当父级在“计算DS”模式下运行时，它可以在两个子模式之一下运行：
full: The Parent only publishes DS records it calculates from DNSKEY records.
完整：父级仅发布其根据DNSKEY记录计算的DS记录。
augment: The Parent will make sure there are DS records for the digest algorithm(s) it requires(s).
扩充：父级将确保它所需的摘要算法有DS记录。
In the case where the Parent fetches the CDNSKEY RRset and calculates the DS, the resulting DS can differ from the CDS published by the Child. It is expected that the differences are only due to the different set of digest algorithms used.
在父级获取CDNSKEY RRset并计算DS的情况下，生成的DS可能不同于子级发布的CD。预计这些差异只是由于使用了不同的摘要算法。
IANA has assigned RR Type code 59 for the CDS resource record. This was done for a draft version whose content was later incorporated into this document [DNS-TRANSPORT]. This document is the reference for CDS RRtype.
IANA已为CDS资源记录分配了RR类型代码59。这是针对一个草案版本完成的，其内容后来被纳入本文档[DNS-TRANSPORT]。本文档是CDS RRtype的参考。
IANA has assigned an RR Type for the CDNSKEY as described below:
IANA已为CDNSKEY分配了RR类型，如下所述：
Type: CDNSKEY
类型：CDNSKEY
Value: 60
价值：60
Meaning: DNSKEY(s) the Child wants reflected in DS
意思：DNSKEY（s）孩子希望在DS中得到反映
Reference: This document
参考：本文件
All of the information handled or transmitted by this protocol is public information published in the DNS.
此协议处理或传输的所有信息都是在DNS中发布的公共信息。
This work is for the normal case; when things go wrong there is only so much that automation can fix.
这是正常情况下的工作；当事情出了差错时，自动化所能解决的问题就那么多了。
If the Child breaks DNSSEC validation by removing all the DNSKEYs that are represented in the DS set, its only repair actions are to contact the Parent or restore the DNSKEYs in the DS set.
如果子级通过删除DS集中表示的所有DNSKEY而中断DNSSEC验证，则其唯一修复操作是联系父级或恢复DS集中的DNSKEY。
In the event of a compromise of the server or system generating signatures for a zone, an attacker might be able to generate and publish new CDS/CDNSKEY resource records. The modified CDS/CDNSKEY records will be picked up by this technique and may allow the attacker to extend the effective time of his attack. If there is a delay in accepting changes to DS, as in [RFC5011], then the attacker needs to hope his activity is not detected before the DS in the Parent is changed. If this type of change takes place, the Child needs to contact the Parent (possibly via a Registrar web interface) and remove any compromised DS keys.
如果生成区域签名的服务器或系统受损，攻击者可能会生成并发布新的CD/CDNSKEY资源记录。修改后的CDS/CDNSKEY记录将通过此技术拾取，并可能允许攻击者延长其攻击的有效时间。如果在接受对DS的更改时出现延迟，如[RFC5011]中所述，则攻击者需要希望在更改父项中的DS之前未检测到其活动。如果发生这种类型的更改，孩子需要联系家长（可能通过注册器web界面）并删除任何受损的DS密钥。
A compromise of the account with the Parent (e.g., Registrar) will not be mitigated by this technique, as the "new Registrant" can delete or modify the DS records at will.
由于“新注册人”可以随意删除或修改DS记录，因此这种技术不会减轻与母公司（如注册人）之间的账户泄露。
While it may be tempting, the techniques specified in this document SHOULD NOT be used for initial enrollment of keys since there is no way to ensure that the initial key is the correct one. If it is used, strict rules for inclusion of keys -- such as hold-down times, challenge data inclusion, or similar -- MUST be used along with some kind of challenge mechanism. A Child cannot use this mechanism to go from signed to unsigned (publishing an empty CDS/CDNSKEY RRset means no change should be made in the Parent).
虽然这可能很诱人，但本文档中指定的技术不应用于密钥的初始注册，因为无法确保初始密钥是正确的。如果使用它，则必须在使用某种质询机制的同时使用严格的键包含规则，如按住时间、质询数据包含或类似规则。子级不能使用此机制从已签名变为未签名（发布空CD/CDNSKEY RRset意味着不应在父级中进行更改）。
The CDS RR type should allow for enhanced security by simplifying the process. Since key change is automated, updating a DS RRset by other means may be regarded as unusual and subject to extra security checks.
CDS RR类型应通过简化流程来增强安全性。由于密钥更改是自动进行的，因此通过其他方式更新DS RRset可能会被视为异常情况，并需要进行额外的安全检查。
As this introduces a new mechanism to update information in the Parent, it MUST be clear who is fetching the records and creating the appropriate records in the Parent zone. Specifically, some operations may use mechanisms other than what is described here. For example, a Registrar may assume that it is maintaining the DNSSEC key information in the Registry and may have this cached. If the Registry is fetching the CDS/CDNSKEY RRset, then the Registry and Registrar may have different views of the DNSSEC key material; the
由于这引入了一种新的机制来更新父区域中的信息，因此必须明确谁在获取记录并在父区域中创建适当的记录。具体地说，一些操作可能使用本文所述以外的机制。例如，注册器可能假设它正在注册表中维护DNSSEC密钥信息，并可能将其缓存。如果注册表正在获取CDS/CDNSKEY RRset，则注册表和注册器可能对DNSSEC密钥材料有不同的看法；这个
result of such a situation is unclear. Therefore, this mechanism SHOULD NOT be used to bypass intermediaries that might cache information and, because of that, get the wrong state.
这种情况的结果尚不清楚。因此，不应使用此机制绕过可能缓存信息并因此获得错误状态的中介。
If there is a failure in applying changes in the Child zone to all DNS servers listed in either Parent or Child NS set, it is possible that the Parental Agent may get confused either because it gets different answers on different checks or CDS RR validation fails. In the worst case, the Parental Agent performs an action reversing a prior action after the Child signing system decides to take the next step in the key change process, resulting in a broken delegation.
如果无法将子区域中的更改应用于父或子NS集中列出的所有DNS服务器，则父代理可能会感到困惑，因为它在不同的检查中得到不同的答案，或者CDS RR验证失败。在最坏的情况下，在子签名系统决定在密钥更改过程中采取下一步后，家长代理将执行一个操作，以反转先前的操作，从而导致委派中断。
DNS is a loosely coherent distributed database with local caching; therefore, it is important to allow old information to expire from caches before deleting DS or DNSKEY records. Similarly, it is important to allow new records to propagate through the DNS before use (see [RFC6781]).
DNS是具有本地缓存的松散一致的分布式数据库；因此，在删除DS或DNSKEY记录之前，允许旧信息从缓存中过期非常重要。同样，在使用前允许新记录通过DNS传播也很重要（请参见[RFC6781]）。
It is common practice for users to outsource their DNS hosting to a third-party DNS provider. In order for that provider to be able to maintain the DNSSEC information, some users give the provider their Registrar login credentials (which obviously has negative security implications). Deploying the solution described in this document allows third-party DNS providers to maintain the DNSSEC information without Registrants giving their Registrar credentials, thereby improving security.
用户通常将其DNS主机外包给第三方DNS提供商。为了让提供商能够维护DNSSEC信息，一些用户向提供商提供了他们的注册登录凭据（这显然会带来负面的安全影响）。部署本文档中描述的解决方案允许第三方DNS提供商维护DNSSEC信息，而无需注册人提供其注册人凭据，从而提高安全性。
By automating the maintenance of the DNSSEC key information (and removing humans from the process), we expect to decrease the number of DNSSEC related outages, which should increase DNSSEC deployment.
通过自动维护DNSSEC关键信息（并将人员从流程中移除），我们希望减少与DNSSEC相关的停机次数，这将增加DNSSEC部署。
We would like to thank a large number of folk, including Mark Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian Dickson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu, Matt Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul Wouters, John Dickinson, Timothe Litt, and Edward Lewis.
我们要感谢很多人，包括马克·安德鲁斯、乔·艾布利、雅普·阿克赫斯、罗伊·阿伦兹、道格·巴顿、布赖恩·迪克森、保罗·埃伯斯曼、托尼·芬奇、吉姆·高尔文、保罗·霍夫曼、萨米尔·侯赛因、塔图亚·金梅、奥拉夫·科尔曼、斯蒂芬·拉格霍姆、板球刘、马特·拉森、马可·桑兹、安托因·维舒伦、苏珊·伍尔夫、保罗·沃特斯、，约翰·迪金森、蒂莫西·利特和爱德华·刘易斯。
Special thanks to Wes Hardaker for contributing significant text and creating the complementary (CSYNC) solution, and to Patrik Faltstrom, Paul Hoffman, Matthijs Mekking, Mukund Sivaraman, and Jeremy C. Reed for text and in-depth review. Brian Carpenter provided a good Gen-ART review.
特别感谢Wes Hardaker提供了重要文本并创建了补充（CSYNC）解决方案，感谢Patrik Faltstrom、Paul Hoffman、Matthijs Mekking、Mukund Sivaraman和Jeremy C.Reed提供文本和深入审查。布赖恩·卡彭特（Brian Carpenter）提供了一篇优秀的艺术评论。
There were a number of other folk with whom we discussed this document; apologies for not remembering everyone.
我们还与其他一些人讨论了这份文件；为没有记住每个人而道歉。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[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月。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, September 2007.
[RFC5011]StJohns，M.“DNS安全（DNSSEC）信任锚的自动更新”，STD 74，RFC 50111907年9月。
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, December 2012.
[RFC6781]Kolkman，O.，Mekking，W.和R.Gieben，“DNSSEC操作规程，第2版”，RFC 6781，2012年12月。
[AUTO-CPSYNC] Mekking, W., "Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE", Work in Progress, December 2010.
[AUTO-CPSYNC]Mekking，W.，“使用DNS更新的自动（DNSSEC）子-父同步”，正在进行的工作，2010年12月。
[CPSYNC-DNS] Hardaker, W., "Child To Parent Synchronization in DNS", Work in Progress, July 2014.
[CPSYNC-DNS]Hardaker，W.，“DNS中的子到父同步”，正在进行的工作，2014年7月。
[DNS-TRANSPORT] Barwood, G., "DNS Transport", Work in Progress, June 2011.
[DNS-TRANSPORT]Barwood，G.，“DNS传输”，正在进行的工作，2011年6月。
[PARENT-ZONES] Andrews, M., "Updating Parent Zones", Work in Progress, November 2013.
[PARENT-ZONES]Andrews，M.，“更新父区”，正在进行的工作，2013年11月。
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009.
[RFC5730]Hollenbeck，S.，“可扩展资源调配协议（EPP）”，STD 69，RFC 5730，2009年8月。
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, May 2010.
[RFC5910]Gould，J.和S.Hollenbeck，“可扩展资源调配协议（EPP）的域名系统（DNS）安全扩展映射”，RFC 59102010年5月。
RRR is our shorthand for the Registry/Registrar/Registrant model of Parent-Child relationships.
RRR是我们亲子关系的注册人/注册人/注册人模型的缩写。
In the RRR world, the different parties are frequently from different organizations. In the single enterprise world, there are also organizational, geographical, and cultural separations that affect how information flows from a Child to the Parent.
在RRR领域，不同的当事人通常来自不同的组织。在单一企业世界中，也存在组织、地理和文化上的差异，这些差异会影响信息从子企业流向父企业的方式。
Due to the complexity of the different roles and interconnections, automation of delegation information has not yet occurred. There have been proposals to automate this, in order to improve the reliability of the DNS. These proposals have not gained enough traction to become standards.
由于不同角色和互连的复杂性，授权信息的自动化尚未实现。为了提高DNS的可靠性，已经有人提议将其自动化。这些提案没有获得足够的吸引力，无法成为标准。
For example, in many of the TLD cases, there is the RRR model (Registry/Registrar/Registrant). The Registry operates DNS for the TLD, and the Registrars accept registrations and place information into the Registry's database. The Registrant only communicates with the Registrar; frequently, the Registry is not allowed to communicate with the Registrant. In that case, as far as the Registrant is concerned, the Registrar is the same entity as the Parent.
例如，在许多TLD案例中，存在RRR模型（注册/注册/注册人）。注册中心运行TLD的DNS，注册中心接受注册并将信息放入注册中心的数据库中。注册人仅与注册人沟通；通常，登记处不允许与登记人沟通。在这种情况下，就注册人而言，注册人与母公司是同一实体。
In many RRR cases, the Registrar and Registry communicate via EPP [RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number of Country Code TLDs (ccTLDs), there are other mechanisms in use as well as EPP, but in general, there seems to be a movement towards EPP usage when DNSSEC is enabled in the TLD.
在许多RRR情况下，注册机构和注册机构通过EPP[RFC5730]进行通信，并使用EPP DNSSEC扩展[RFC5910]。在许多国家/地区代码TLD（CCTLD）中，除了EPP之外，还有其他机制在使用，但一般来说，当TLD中启用DNSSEC时，似乎有一种使用EPP的趋势。
This section shows an example on how CDS is used when performing a KSK rollover. This example will demonstrate the Double-DS rollover method from Section 4.1.2 of [RFC6781]. Other rollovers using CDNSKEY and double KSK are left as an exercise to the reader. The table below does not reflect the Zone Signing Keys (ZSKs) as they do not matter during KSK rollovers. The wait steps highlight what RRset needs to expire from caches before progressing to the next step.
本节显示了执行KSK滚动时如何使用CD的示例。本示例将演示[RFC6781]第4.1.2节中的双DS翻转方法。其他使用CDNSKEY和double-KSK的滚动将留给读者作为练习。下表未反映区域签名密钥（ZSK），因为它们在KSK滚动期间并不重要。等待步骤突出显示了RRset在进入下一步之前需要从缓存中过期的内容。
+------+---------------+---------+---------+--------------+---------+
| Step | State | Parent | Child | DNSKEY and | Child |
| | | DS | KSK | CDS signer | CDS |
+------+---------------+---------+---------+--------------+---------+
| | Beginning | A | A | A | |
| 1 | Add CDS | A | A | A | AB |
| Wait | for DS change | A | A | A | AB |
| 2 | Updated DS | AB | A | A | AB |
| Wait | > DS TTL | AB | A | A | AB |
| 3 | Actual | AB | B | B | AB |
| | Rollover | | | | |
| Wait | > DNSKEY TTL | AB | B | B | AB |
| 4 | Child Cleanup | AB | B | B | B |
| 5 | Parent cleans | B | B | B | B |
| 6 | Optional CDS | B | B | B | |
| | delete | | | | |
+------+---------------+---------+---------+--------------+---------+
+------+---------------+---------+---------+--------------+---------+
| Step | State | Parent | Child | DNSKEY and | Child |
| | | DS | KSK | CDS signer | CDS |
+------+---------------+---------+---------+--------------+---------+
| | Beginning | A | A | A | |
| 1 | Add CDS | A | A | A | AB |
| Wait | for DS change | A | A | A | AB |
| 2 | Updated DS | AB | A | A | AB |
| Wait | > DS TTL | AB | A | A | AB |
| 3 | Actual | AB | B | B | AB |
| | Rollover | | | | |
| Wait | > DNSKEY TTL | AB | B | B | AB |
| 4 | Child Cleanup | AB | B | B | B |
| 5 | Parent cleans | B | B | B | B |
| 6 | Optional CDS | B | B | B | |
| | delete | | | | |
+------+---------------+---------+---------+--------------+---------+
Table 1: States
表1：国家
Authors' Addresses
作者地址
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US
沃伦·库马里谷歌1600圆形剧场公园道山景，加利福尼亚州94043美国
EMail: warren@kumari.net
EMail: warren@kumari.net
Olafur Gudmundsson OGUD Consulting 3821 Village Park Dr. Chevy Chase, MD 20815 US
Olafur Gudmundsson OGUD Consulting 3821乡村公园Chevy Chase博士，美国马里兰州20815
EMail: ogud@ogud.com
EMail: ogud@ogud.com
George Barwood 33 Sandpiper Close Gloucester GL2 4LZ United Kingdom
George Barwood 33矶鹞Close Gloucester GL2 4LZ英国
EMail: george.barwood@blueyonder.co.uk
EMail: george.barwood@blueyonder.co.uk