Internet Engineering Task Force (IETF) O. Gudmundsson
Request for Comments: 8078 CloudFlare
Updates: 7344 P. Wouters
Category: Standards Track Red Hat
ISSN: 2070-1721 March 2017
Internet Engineering Task Force (IETF) O. Gudmundsson
Request for Comments: 8078 CloudFlare
Updates: 7344 P. Wouters
Category: Standards Track Red Hat
ISSN: 2070-1721 March 2017
Managing DS Records from the Parent via CDS/CDNSKEY
通过CD/CDNSKEY管理来自父级的DS记录
Abstract
摘要
RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.
RFC 7344指定如何在父级和子级之间的频带内的密钥滚动期间维护DNS信任。本文件将RFC 7344从信息性提升到标准轨道。它还添加了用于初始信任设置和删除安全入口点的方法。
Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.
更改域的DNSSEC状态可能是一个涉及多个不相关方的复杂问题。其中一些参与方，例如DNS运营商，甚至可能不为所有相关组织所知。无法通过带内信令禁用DNSSEC被视为阻碍某些DNSSEC大规模采用的问题或责任。本文件增加了这些DNSSEC状态变化的带内信令方法。
This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).
本文档描述了简化新安全入口点（DS记录）初始验收部署的合理策略。
It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.
操作员最好在域的转移或移动上进行协作。最好的方法是执行密钥签名密钥（KSK）加区域签名密钥（ZSK）滚动。如果不可能，可以使用本文档中描述的使用无符号中间状态的方法在双方之间移动域。这会使域暂时未签名，并且容易受到DNS欺骗的攻击，但由于DS和DNSKEY记录不匹配，因此与验证失败相比，这是首选的方法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8078.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8078.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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. Introducing a DS Record . . . . . . . . . . . . . . . . . 3
1.2. Removing a DS Record . . . . . . . . . . . . . . . . . . 4
1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. The Three Uses of CDS . . . . . . . . . . . . . . . . . . . . 5
2.1. The Meaning of the CDS RRset . . . . . . . . . . . . . . 5
3. Enabling DNSSEC via CDS/CDNSKEY . . . . . . . . . . . . . . . 6
3.1. Accept Policy via Authenticated Channel . . . . . . . . . 6
3.2. Accept with Extra Checks . . . . . . . . . . . . . . . . 6
3.3. Accept after Delay . . . . . . . . . . . . . . . . . . . 7
3.4. Accept with Challenge . . . . . . . . . . . . . . . . . . 7
3.5. Accept from Inception . . . . . . . . . . . . . . . . . . 7
4. DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Promoting RFC 7344 to Standards Track . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introducing a DS Record . . . . . . . . . . . . . . . . . 3
1.2. Removing a DS Record . . . . . . . . . . . . . . . . . . 4
1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. The Three Uses of CDS . . . . . . . . . . . . . . . . . . . . 5
2.1. The Meaning of the CDS RRset . . . . . . . . . . . . . . 5
3. Enabling DNSSEC via CDS/CDNSKEY . . . . . . . . . . . . . . . 6
3.1. Accept Policy via Authenticated Channel . . . . . . . . . 6
3.2. Accept with Extra Checks . . . . . . . . . . . . . . . . 6
3.3. Accept after Delay . . . . . . . . . . . . . . . . . . . 7
3.4. Accept with Challenge . . . . . . . . . . . . . . . . . . 7
3.5. Accept from Inception . . . . . . . . . . . . . . . . . . 7
4. DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Promoting RFC 7344 to Standards Track . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
CDS (Child DS) and CDNSKEY (Child DNSKEY) [RFC7344] records are used to signal changes in secure entry points. This is one method to maintain delegations that can be used when the DNS operator has no other way to inform the parent that changes are needed. This document elevates [RFC7344] from Informational to Standards Track.
CDS（子DS）和CDNSKEY（子DNSKEY）[RFC7344]记录用于表示安全入口点的更改。这是一种维护委托的方法，当DNS操作员没有其他方法通知父级需要更改时，可以使用这种方法。本文件将[RFC7344]从信息性提升到标准轨道。
In addition, [RFC7344] lacks two different options for full automated operation to be possible. It does not define a method for the initial trust establishment, leaving it open to each parent to come up with an acceptance policy. Additionally, [RFC7344] does not provide a "delete" signal for the child to inform the parent that the DNSSEC security for its domain must be removed.
此外，[RFC7344]缺少两种不同的选项，无法实现全自动操作。它没有定义初始信任建立的方法，让每个家长都可以制定接受策略。此外，[RFC7344]不为子级提供“删除”信号，以通知父级必须删除其域的DNSSEC安全性。
Automated insertion of DS records has been limited for many zones by the requirement that all changes pass through a "Registry" of the child zone's parent. This has significantly hindered deployment of DNSSEC at a large scale for DNS hosters, as the child zone owner is often not aware or able to update DNS records such as the DS record.
由于要求所有更改都通过子区域父级的“注册表”，许多区域的DS记录的自动插入受到限制。这严重阻碍了DNS主机大规模部署DNSSEC，因为子区域所有者通常不知道或无法更新DNS记录，如DS记录。
This document describes a few possible methods for the parent to accept a request by the child to add a DS record to its zone. These methods have different security properties that address different deployment scenarios, all resulting in an automated method of trust introduction.
本文档介绍了几种可能的方法，让父级可以接受子级向其区域添加DS记录的请求。这些方法具有不同的安全属性，可以解决不同的部署场景，所有这些都导致了一种自动引入信任的方法。
This document introduces the delete option for both CDS and CDNSKEY, allowing a child to signal to the parent to turn off DNSSEC. When a domain is moved from one DNS operator to another, sometimes it is necessary to turn off DNSSEC to facilitate the change of DNS operator. Common scenarios include:
本文档介绍了CD和CDNSKEY的删除选项，允许子项向父项发出关闭DNSSEC的信号。当域从一个DNS运营商移动到另一个DNS运营商时，有时需要关闭DNSSEC以便于更改DNS运营商。常见情况包括：
1. Alternative to doing a proper DNSSEC algorithm rollover due to operational limitations such as software limitations.
1. 由于操作限制（如软件限制），进行适当的DNSSEC算法翻转的替代方法。
2. Moving from a DNSSEC operator to a non-DNSSEC-capable operator.
2. 从DNSSEC操作员转移到不具备DNSSEC能力的操作员。
3. Moving to an operator that cannot or does not want to do a proper DNSSEC rollover.
3. 移动到无法或不希望进行正确DNSSEC翻转的操作员。
4. When moving between two DNS operators that use disjoint sets of algorithms to sign the zone, an algorithm rollover cannot be performed.
4. 在使用不相交的算法集对区域进行签名的两个DNS运营商之间移动时，无法执行算法滚动。
5. The domain holder no longer wants DNSSEC enabled.
5. 域持有者不再希望启用DNSSEC。
The lack of a "remove my DNSSEC" option is cited as a reason why some operators cannot deploy DNSSEC, as this is seen as an operational risk.
缺少“删除我的DNSSEC”选项是一些运营商无法部署DNSSEC的原因，因为这被视为运营风险。
Turning off DNSSEC reduces the security of the domain and thus should only be done carefully, and that decision should be fully under the child domain's control.
关闭DNSSEC会降低域的安全性，因此只能小心地执行，并且该决定应完全在子域的控制下。
Signaling can happen via CDS or CDNSKEY records. The only differences between the two records are how information is represented and who calculates the DS digest. For clarity, this document uses the term "CDS" to mean "either CDS or CDNSKEY".
可以通过CD或CDNSKEY记录发送信号。这两个记录之间的唯一区别是信息的表示方式以及谁计算DS摘要。为清楚起见，本文件使用术语“CDS”表示“CDS或CDNSKEY”。
When this document uses the word "parent", it implies an entity that is authorized to insert DS records into the parent zone on behalf of the child domain. Which entity this exactly is does not matter. It
当本文档使用“父级”一词时，它意味着一个被授权代表子域将DS记录插入父区域的实体。这到底是哪个实体并不重要。信息技术
could be the Registrar or Reseller that the child domain was purchased from. It could be the Registry that the domain is registered in when allowed. Or it could be some other entity.
可以是购买子域的注册商或经销商。在允许的情况下，它可以是注册域的注册表。也可能是其他实体。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In general, there are three operations that a domain wants to instruct its parent to perform:
通常，域要指示其父域执行三个操作：
1. Enable DNSSEC validation, i.e., place an initial DS Resource Record Set (RRset) in the parent.
1. 启用DNSSEC验证，即在父级中放置初始DS资源记录集（RRset）。
2. Roll over the KSK. This means updating the DS records in the parent to reflect the new set of KSKs at the child. This could be an ADD operation, a DELETE operation on one or more records while keeping at least one DS RR, or a full REPLACE operation.
2. 滚过KSK。这意味着更新父级中的DS记录以反映子级的新KSK集。这可能是一个添加操作、一个或多个记录上的删除操作，同时保留至少一个DS RR，或者是完全替换操作。
3. Turn off DNSSEC validation, i.e., delete all the DS records.
3. 关闭DNSSEC验证，即删除所有DS记录。
KSK rollover is covered in [RFC7344]. It is considered the safest use case of a CDS/CDNSKEY record as it makes no change to the trust relationship between parent and child. Introduction and removal of DS records are defined in this document. As these CDS/CDNSKEY use cases create or end the trust relationship between the parent and child, these use cases should be carefully implemented and monitored.
[RFC7344]中介绍了KSK展期。它被认为是CDS/CDNSKEY记录最安全的用例，因为它不会改变父项和子项之间的信任关系。DS记录的引入和删除在本文件中有定义。当这些CDS/CDN关键用例创建或终止父级和子级之间的信任关系时，应仔细实施和监控这些用例。
The semantic meaning of publishing a CDS RRset is interpreted to mean:
发布CDS RRset的语义含义解释为：
Publishing a CDS or CDNSKEY record signals to the parent that the child desires that the corresponding DS records be synchronized. Every parent or parental agent should have an acceptance policy of these records for the three different use cases involved: Initial DS publication, Key rollover, and Returning to Insecure.
发布CD或CDNSKEY记录向父级发出信号，表示子级希望同步相应的DS记录。对于涉及的三种不同用例，每个家长或家长代理都应该有一个接受这些记录的策略：初始DS发布、密钥滚动和返回不安全状态。
In short, the CDS RRset is an instruction to the parent to modify the DS RRset if the CDS and DS Resets differ.
简而言之，CDS RRset是一条指令，用于在CDS和DS重置不同时向父级发出修改DS RRset的指令。
The acceptance policy for CDS in the rollover case is "seeing" according to [RFC7344]. The acceptance policy in the Delete case is seeing a (validly signed) CDS RRset with the delete operation specified in this document.
根据[RFC7344]，展期情况下的CDS接受政策为“看见”。删除案例中的接受策略正在使用本文档中指定的删除操作查看（有效签名）CDS RRset。
There are number of different models for managing initial trust, but in the general case, the child wants to enable global validation. As long as the child is insecure, DNS answers can be forged. The goal is to promote the child from insecure to secure as soon as reasonably possible by the parent. This means that the period from the child's publication of CDS/CDNSKEY RRset to the parent publishing the synchronized DS RRset should be as short as possible.
有许多不同的模型用于管理初始信任，但在一般情况下，子级希望启用全局验证。只要孩子不安全，DNS答案就可以伪造。目标是让父母尽可能快地让孩子从不安全状态过渡到安全状态。这意味着，从子级发布CD/CDNSKEY RRset到父级发布同步DS RRset的时间段应尽可能短。
One important use case is how a third-party DNS operator can upload its DNSSEC information to the parent, so the parent can publish a DS record for the child. In this case, there is a possibility of setting up some kind of authentication mechanism and submission mechanism that is outside the scope of this document.
一个重要的用例是第三方DNS运营商如何将其DNSSEC信息上载到父级，以便父级可以为子级发布DS记录。在这种情况下，有可能建立某种身份验证机制和提交机制，这超出了本文件的范围。
Below are some policies that parents can use. These policies assume that the notifications can be verified or authenticated.
以下是家长可以使用的一些政策。这些策略假定可以验证或验证通知。
In this case, the parent is notified via authenticated channel UI/API that a CDS/CDNSKEY RRset exists. In the case of a CDS RRset, the parent retrieves the CDS RRset and inserts the corresponding DS RRset as requested. In the case of CDNSKEY, the parent retrieves the CDNSKEY RRset and calculates the DS record(s). Parents may limit the DS record type based on local policy. Parents SHOULD NOT refuse CDS/ CDNSKEY updates that do not (yet) have a matching DNSKEY in the child zone. This will allow the child to pre-publish a spare (and potentially offline) DNSKEY.
在这种情况下，通过已验证的通道UI/API通知父级存在CDS/CDNSKEY RRset。对于CDS RRset，父级检索CDS RRset并根据请求插入相应的DS RRset。对于CDNSKEY，父级检索CDNSKEY RRset并计算DS记录。家长可以根据本地策略限制DS记录类型。家长不应拒绝（尚未）在子区域中没有匹配DNSKEY的CD/CDNSKEY更新。这将允许孩子预发布备用（可能脱机）DNSKEY。
In this case, the parent checks that the source of the notification is allowed to request the DS insertion. The checks could include whether this is a trusted entity, whether the nameservers correspond to the requester, whether there have been any changes in registration in the last few days, etc. The parent can also send a notification requesting a confirmation, for example, by sending email to the registrant requesting a confirmation. The end result is that the CDS RRset is accepted at the end of the checks or when the out-of-band confirmation is received. Any extra checks should have proper rate limiting in place to prevent abuse.
在这种情况下，父级检查是否允许通知源请求DS插入。检查可能包括这是否是一个受信任的实体，名称服务器是否对应于请求者，在过去几天中注册是否有任何更改，等等。家长还可以发送通知请求确认，例如，通过向请求确认的注册人发送电子邮件。最终结果是在检查结束时或收到带外确认时接受CDS RRset。任何额外的检查都应该有适当的利率限制，以防止滥用。
In this case, if the parent deems the request valid, it starts monitoring the CDS RRset at the child nameservers over a period of time to make sure nothing changes. After some time or after a number of checks, preferably from different vantage points in the network, the parent accepts the CDS RRset as a valid signal to update its DS RRset for this child.
在这种情况下，如果父级认为请求有效，它将在一段时间内开始监视子名称服务器上的CDS RRset，以确保没有任何更改。在一段时间之后或在若干次检查之后，优选地从网络中的不同有利位置，父节点接受CDS RRset作为有效信号，以更新该子节点的DS RRset。
In this case, the parent instructs the requester to insert some record into the child domain to prove it has the ability to do so (i.e., it is the operator of the zone). This method imposes a new task on the parent to monitor the child zone to see if the challenge has been added to the zone. The parent should verify that the challenge is published by all the child's nameservers and should test for this challenge from various diverse network locations to increase the security of this method as much as possible.
在这种情况下，父域指示请求者在子域中插入一些记录，以证明它有能力这样做（即，它是区域的操作员）。此方法对父区域强制执行一项新任务，以监视子区域，查看是否已将质询添加到该区域。父级应验证质询是否由所有子级的名称服务器发布，并应测试来自不同网络位置的质询，以尽可能提高此方法的安全性。
If a parent is adding a new child domain that is not currently delegated at all, it could use the child CDS/CDNSKEY RRset to immediately publish a DS RRset along with the new NS RRset. This would ensure that the new child domain is never active in an insecure state.
如果父级正在添加当前根本未委派的新子域，则可以使用子CDS/CDNSKEY RRset立即发布DS RRset以及新的NS RRset。这将确保新子域永远不会在不安全状态下处于活动状态。
This document defines the previously reserved DNS Security Algorithm Number of value 0 in the context of CDS and CDNSKEY records to mean that the entire DS RRset at the parent must be removed. The value 0 remains reserved for the DS and DNSKEY records.
本文档在CDS和CDNSKEY记录的上下文中定义了值为0的先前保留的DNS安全算法编号，这意味着必须删除父级上的整个DS RRset。值0保留给DS和DNSKEY记录。
No DNSSEC validator can treat algorithm 0 as a valid signature algorithm. If a validator sees a DNSKEY or DS record with this algorithm value, it must treat it as unknown. Accordingly, the zone is treated as unsigned unless there are other algorithms present. In general, the value 0 should never be used in the context of DNSKEY and DS records.
没有DNSSEC验证器可以将算法0视为有效的签名算法。如果验证器看到具有此算法值的DNSKEY或DS记录，则必须将其视为未知。因此，除非存在其他算法，否则区域将被视为无符号。通常，值0不应在DNSKEY和DS记录的上下文中使用。
The CERT record [RFC4398] defines the value 0 similarly to mean the algorithm in the CERT record is not defined in DNSSEC.
证书记录[RFC4398]定义了值0，类似于表示DNSSEC中未定义证书记录中的算法。
The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below.
CDS或CDNSKEY RRset的内容必须包含一个RR，并且只能包含如下所示的确切字段。
CDS 0 0 0 0
CD 0 0 0 0
CDNSKEY 0 3 0 0
CDNSKEY 0 3 0 0
The keying material payload is represented by a single 0. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed.
键控材料有效载荷由单个0表示。此记录的签名方式与常规CD/CDNSKEY RRSET的签名方式相同。
Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 0" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2.
严格地说，CDS记录可以是“CDS X 0 X 0”，因为只有DNSKEY算法才是删除操作的信号，但为了清楚起见，强制使用“0 0”表示法——这不是DS摘要算法0的定义。相同的参数适用于“CDNSKEY 0 3 0 0”；第二个字段中的值3由[RFC4034]第2.1.2节规定。
Once the parent has verified the CDS/CDNSKEY RRset and it has passed other acceptance tests, the parent MUST remove the DS RRset. After waiting a sufficient amount of time -- depending on the parental TTLs -- the child can start the process of turning off DNSSEC.
一旦母公司验证了CDS/CDNSKEY RRset并通过了其他验收测试，母公司必须移除DS RRset。等待足够长的时间后（取决于家长TTL），孩子可以开始关闭DNSSEC的过程。
Turning off DNSSEC reduces the security of the domain and thus should only be done as a last resort in preventing DNSSEC validation errors due to mismatched DS and DNSKEY records.
关闭DNSSEC会降低域的安全性，因此只能作为防止由于DS和DNSKEY记录不匹配而导致DNSSEC验证错误的最后手段。
Users should keep in mind that re-establishing trust in delegation can be hard and takes time. Before deciding to complete the rollover via an unsigned state, all other options should be considered first.
用户应该记住，在委派中重新建立信任可能很困难，而且需要时间。在决定通过未签名状态完成滚动之前，应首先考虑所有其他选项。
A parent SHOULD ensure that when it is allowing a child to become securely delegated, it has a reasonable assurance that the CDS/ CDNSKEY RRset used to bootstrap the security is visible from a geographically and topologically diverse view. It SHOULD also ensure that the zone validates correctly if the parent publishes the DS record. A parent zone might also consider sending an email to its contact addresses to give the child zone a warning that security will be enabled after a certain amount of wait time -- thus allowing a child administrator to cancel the request.
家长应确保在允许孩子安全地被委派时，能够合理地保证用于引导安全性的CDS/CDNSKEY RRset可以从地理和拓扑上的不同角度看到。如果父级发布DS记录，还应确保区域正确验证。父区域也可能考虑向其联系人地址发送电子邮件，以给子区域一个警告，即在一定的等待时间之后启用安全性，从而允许子管理员取消请求。
This document describes a few possible acceptance criteria for the initial trust establishment. Due to a large variety of legal frameworks surrounding parent domains (Top-Level Domain (TLDs) in particular), this document cannot give a definitive list of valid acceptance criteria. Parental zones should look at the listed
本文件描述了初始信托建立的一些可能的接受标准。由于围绕父域（特别是顶级域（TLD））的各种法律框架，本文档无法给出有效验收标准的最终列表。家长区应查看列出的
methods and pick the most secure method possible within their legal and technical scenario, possibly further securing the acceptance criteria, as long as the deployed method still enables a fully automated method for non-direct parties such as third-party DNS hosters.
方法，并在其法律和技术场景中选择最安全的方法，可能进一步确保验收标准的安全，只要部署的方法仍然能够为非直接方（如第三方DNS主机）启用完全自动化的方法。
IANA has assigned entry number 0 in the "DNS Security Algorithm Numbers" registry as follows:
IANA在“DNS安全算法编号”注册表中分配了条目编号0，如下所示：
+--------+--------------+----------+----------+---------+-----------+
| Number | Description | Mnemonic | Zone | Trans. | Reference |
| | | | Signing | Sec. | |
+--------+--------------+----------+----------+---------+-----------+
| 0 | Delete DS | DELETE | N | N | [RFC4034] |
| | | | | | [RFC4398] |
| | | | | | [RFC8078] |
+--------+--------------+----------+----------+---------+-----------+
+--------+--------------+----------+----------+---------+-----------+
| Number | Description | Mnemonic | Zone | Trans. | Reference |
| | | | Signing | Sec. | |
+--------+--------------+----------+----------+---------+-----------+
| 0 | Delete DS | DELETE | N | N | [RFC4034] |
| | | | | | [RFC4398] |
| | | | | | [RFC8078] |
+--------+--------------+----------+----------+---------+-----------+
Experience has shown that CDS and CDNSKEY are useful in the deployment of DNSSEC. [RFC7344] was published as Informational; this document elevates RFC 7344 to Standards Track.
经验表明，CDS和CDNSKEY在DNSSEC的部署中非常有用。[RFC7344]作为信息发布；本文件将RFC 7344提升至标准轨道。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<http://www.rfc-editor.org/info/rfc4034>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, <http://www.rfc-editor.org/info/rfc7344>.
[RFC7344]Kumari，W.，Gudmundsson，O.，和G.Barwood，“自动化DNSSEC委托信托维护”，RFC 7344，DOI 10.17487/RFC73442014年9月<http://www.rfc-editor.org/info/rfc7344>.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, <http://www.rfc-editor.org/info/rfc4398>.
[RFC4398]Josefsson，S.，“在域名系统（DNS）中存储证书”，RFC 4398，DOI 10.17487/RFC4398，2006年3月<http://www.rfc-editor.org/info/rfc4398>.
Acknowledgments
致谢
We thank a number of people that have provided feedback and useful comments including Bob Harold, John Levine, Dan York, Shane Kerr, Jacques Latour, and especially Matthijs Mekking.
我们感谢许多提供反馈和有用意见的人，包括鲍勃·哈罗德、约翰·莱文、丹·约克、谢恩·克尔、雅克·拉图尔，特别是马蒂斯·梅金。
Authors' Addresses
作者地址
Olafur Gudmundsson CloudFlare
Olafur Gudmundsson云耀斑
Email: olafur+ietf@cloudflare.com
Email: olafur+ietf@cloudflare.com
Paul Wouters Red Hat
保罗·沃特斯红帽
Email: pwouters@redhat.com
Email: pwouters@redhat.com