Internet Engineering Task Force (IETF) J. Gould
Request for Comments: 5910 S. Hollenbeck
Obsoletes: 4310 VeriSign, Inc.
Category: Standards Track May 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Gould
Request for Comments: 5910 S. Hollenbeck
Obsoletes: 4310 VeriSign, Inc.
Category: Standards Track May 2010
ISSN: 2070-1721
Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
可扩展配置协议（EPP）的域名系统（DNS）安全扩展映射
Abstract
摘要
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310.
本文档描述了可扩展资源调配协议（EPP）扩展映射，用于为存储在共享中央存储库中的域名提供和管理域名系统安全性（DNSSEC）扩展。在XML中指定，此映射扩展了EPP域名映射，以提供提供DNS安全扩展所需的其他功能。本文件淘汰了RFC 4310。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc5910.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5910.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Migrating from RFC 4310 . . . . . . . . . . . . . . . . . . . 4
3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Delegation Signer Information . . . . . . . . . . . . . . 5
3.1.1. Public Key Information . . . . . . . . . . . . . . . . 5
3.2. Booleans . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Maximum Signature Lifetime . . . . . . . . . . . . . . . . 5
4. DS Data Interface and Key Data Interface . . . . . . . . . . . 6
4.1. DS Data Interface . . . . . . . . . . . . . . . . . . . . 7
4.2. Key Data Interface . . . . . . . . . . . . . . . . . . . . 7
4.3. Example DS Data Interface and Key Data Interface . . . . . 8
5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9
5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9
5.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 9
5.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 9
5.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . . 13
5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 14
5.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 14
5.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 17
5.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 18
5.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 18
5.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 18
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Internationalization Considerations . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Changes from RFC 4310 . . . . . . . . . . . . . . . . 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Migrating from RFC 4310 . . . . . . . . . . . . . . . . . . . 4
3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Delegation Signer Information . . . . . . . . . . . . . . 5
3.1.1. Public Key Information . . . . . . . . . . . . . . . . 5
3.2. Booleans . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Maximum Signature Lifetime . . . . . . . . . . . . . . . . 5
4. DS Data Interface and Key Data Interface . . . . . . . . . . . 6
4.1. DS Data Interface . . . . . . . . . . . . . . . . . . . . 7
4.2. Key Data Interface . . . . . . . . . . . . . . . . . . . . 7
4.3. Example DS Data Interface and Key Data Interface . . . . . 8
5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9
5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9
5.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 9
5.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 9
5.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . . 13
5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 14
5.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 14
5.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 17
5.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 18
5.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 18
5.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 18
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Internationalization Considerations . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Changes from RFC 4310 . . . . . . . . . . . . . . . . 33
This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730 [RFC5730]. This mapping, an extension of the domain name mapping described in RFC 5731 [RFC5731], is specified using the Extensible Markup Language (XML) 1.0 [W3C.REC-xml-20001006] and XML Schema notation ([W3C.REC-xmlschema-1-20010502] [W3C.REC-xmlschema-2-20010502]).
本文档描述了RFC 5730[RFC5730]中描述的可扩展资源调配协议（EPP）1.0版的扩展映射。此映射是RFC 5731[RFC5731]中描述的域名映射的扩展，使用可扩展标记语言（XML）1.0[W3C.REC-XML-20001006]和XML模式符号（[W3C.REC-xmlschema-1-20010502][W3C.REC-xmlschema-2-20010502]）指定。
The EPP core protocol specification [RFC5730] provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in this document. Familiarity with the Domain Name System (DNS) described in RFC 1034 [RFC1034] and RFC 1035 [RFC1035] and with DNS security extensions described in RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035] is required to understand the DNS security concepts described in this document.
EPP核心协议规范[RFC5730]提供了EPP命令和响应结构的完整描述。要理解本文档中描述的映射，必须彻底理解基本协议规范。需要熟悉RFC 1034[RFC1034]和RFC 1035[RFC1035]中描述的域名系统（DNS）以及RFC 4033[RFC4033]、RFC 4034[RFC4034]和RFC 4035[RFC4035]中描述的DNS安全扩展，才能理解本文档中描述的DNS安全概念。
The EPP mapping described in this document specifies a mechanism for the provisioning and management of DNS security extensions in a shared central repository. Information exchanged via this mapping can be extracted from the repository and used to publish DNSSEC Delegation Signer (DS) resource records (RRs) as described in RFC 4034 [RFC4034].
本文档中描述的EPP映射指定了在共享中央存储库中提供和管理DNS安全扩展的机制。通过此映射交换的信息可以从存储库中提取，并用于发布DNSSEC委派签名者（DS）资源记录（RRs），如RFC 4034[RFC4034]中所述。
This document obsoletes RFC 4310 [RFC4310]; thus, secDNS-1.1 as defined in this document deprecates secDNS-1.0 [RFC4310]. The motivation behind obsoleting RFC 4310 [RFC4310] includes:
本文件淘汰了RFC 4310[RFC4310]；因此，本文件中定义的secDNS-1.1不推荐使用secDNS-1.0[RFC4310]。淘汰RFC 4310[RFC4310]的动机包括：
- Addressing the issue with removing DS data based on the non-unique <secDNS:keyTag> element. The client should explicitly specify the DS data to be removed, by using all four <secDNS:dsData> elements that are guaranteed to be unique.
- 通过基于非唯一的<secDNS:keyTag>元素删除DS数据来解决此问题。客户端应使用保证唯一的所有四个<secDNS:dsData>元素明确指定要删除的DS数据。
- Adding the ability to add and remove <secDNS:dsData> elements in a single command. This makes it consistent with RFC 5731 [RFC5731].
- 添加在单个命令中添加和删除<secDNS:dsData>元素的功能。这使其与RFC 5731[RFC5731]一致。
- Clarifying and correcting the usage of the <secDNS:chg> element. RFC 4310 [RFC4310] defined the <secDNS:chg> element as a replacement for the DS data. This is inconsistent with RFC 5731 [RFC5731], where a <domain:chg> element is used to change the values of the domain attributes.
- 澄清并更正<secDNS:chg>元素的用法。RFC 4310[RFC4310]将<secDNS:chg>元素定义为DS数据的替换。这与RFC 5731[RFC5731]不一致，RFC 5731[RFC5731]使用<domain:chg>元素更改域属性的值。
- Adding support for the Key Data Interface described in Section 4.2 for "thick" DNSSEC servers that accept only key data and generate the associated DS data.
- 添加对第4.2节中描述的“厚”DNSSEC服务器的关键数据接口的支持，该服务器仅接受关键数据并生成相关DS数据。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
In examples, "C:" represents lines sent by a protocol client, and "S:" represents lines returned by a protocol server. "////" is used to note element values that have been shortened to better fit page boundaries. Indentation and white space in examples is provided only to illustrate element relationships and is not a mandatory feature of this protocol.
在示例中，“C:”表示协议客户端发送的行，“S:”表示协议服务器返回的行。“///”用于记录缩短以更好地适应页面边界的元素值。示例中的缩进和空白仅用于说明元素关系，不是本协议的强制性功能。
XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.
XML区分大小写。除非另有说明，否则本文档中提供的XML规范和示例必须以所提供的字符大小写进行解释，以便开发一致的实现。
secDNS-1.0 is used as an abbreviation for urn:ietf:params:xml:ns:secDNS-1.0, and secDNS-1.1 is used as an abbreviation for urn:ietf:params:xml:ns:secDNS-1.1.
secDNS-1.0用作urn:ietf:params:xml:ns:secDNS-1.0的缩写，secDNS-1.1用作urn:ietf:params:xml:ns:secDNS-1.1的缩写。
This section includes implementation recommendations for clients and servers to use in migrating from secDNS-1.0 [RFC4310] to secDNS-1.1.
本节包括从secDNS-1.0[RFC4310]迁移到secDNS-1.1时使用的客户端和服务器的实施建议。
As this document deprecates RFC 4310 [RFC4310], if a server announces support for both secDNS-1.0 [RFC4310] and secDNS-1.1 in the EPP greeting, clients supporting both versions SHOULD prefer secDNS-1.1.
由于本文档不推荐RFC 4310[RFC4310]，如果服务器在EPP问候语中宣布支持secDNS-1.0[RFC4310]和secDNS-1.1，则支持这两个版本的客户端应首选secDNS-1.1。
A server SHOULD do the following to help clients migrate from secDNS-1.0 [RFC4310] to secDNS-1.1 as defined in this document.
服务器应执行以下操作，以帮助客户端从本文档中定义的secDNS-1.0[RFC4310]迁移到secDNS-1.1。
1. A server migrating from secDNS-1.0 [RFC4310] to secDNS-1.1 SHOULD support both versions (i.e., secDNS-1.0 and secDNS-1.1) for a reasonable migration period.
1. 从secDNS-1.0[RFC4310]迁移到secDNS-1.1的服务器应在合理的迁移期内支持两个版本（即secDNS-1.0和secDNS-1.1）。
2. The version of the <secDNS:infData> element to be returned by the server in the response to a <domain:info> response SHOULD depend on the <extURI> elements (indicating the secDNS extension) the client included in the EPP <login> command using the following mapping:
2. 服务器在对<domain:info>响应的响应中返回的<secDNS:infData>元素的版本应取决于使用以下映射的EPP<login>命令中包含的<extURI>元素（指示secDNS扩展名）：
- Return version secDNS-1.1 of the <secDNS:infData> element if urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> element in the EPP <login> command, independent of whether
- 如果urn:ietf:params:xml:ns:secDNS-1.1作为<extURI>元素包含在EPP<login>命令中，则返回<secDNS:infData>元素的secDNS-1.1版本，与是否
urn:ietf:params:xml:ns:secDNS-1.0 is also included as an <extURI> element in the EPP <login> command.
urn:ietf:params:xml:ns:secDNS-1.0也作为一个<extURI>元素包含在EPP<login>命令中。
- Return version secDNS-1.0 of the <secDNS:infData> element if urn:ietf:params:xml:ns:secDNS-1.0 but not urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> element in the EPP <login> command.
- 如果urn:ietf:params:xml:ns:secDNS-1.0而不是urn:ietf:params:xml:ns:secDNS-1.1作为EPP<login>命令中的<extURI>元素包含，则返回<secDNS:infData>元素的secDNS-1.0版本。
- Don't return the <secDNS:infData> element if neither urn:ietf:params:xml:ns:secDNS-1.0 nor urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> element in the EPP <login> command.
- 如果urn:ietf:params:xml:ns:secDNS-1.0或urn:ietf:params:xml:ns:secDNS-1.1都未作为EPP<login>命令中的<extURI>元素包含，则不要返回<secDNS:infData>元素。
This extension adds additional elements to the EPP domain name mapping [RFC5731]. Only those new elements are described here.
此扩展将向EPP域名映射[RFC5731]添加其他元素。这里只描述这些新元素。
Delegation Signer (DS) information is published by a DNS server to indicate that a child zone is digitally signed and that the parent zone recognizes the indicated key as a valid zone key for the child zone. A DS resource record (RR) contains four fields: a key tag field, a key algorithm number octet, an octet identifying a digest algorithm, and a digest field. See RFC 4034 [RFC4034] for specific field formats.
DNS服务器发布委派签名者（DS）信息，以指示子区域已进行数字签名，并且父区域将指示的密钥识别为子区域的有效区域密钥。DS资源记录（RR）包含四个字段：密钥标记字段、密钥算法编号八位组、标识摘要算法的八位组和摘要字段。具体字段格式见RFC 4034[RFC4034]。
Public key information provided by a client maps to the DNSKEY RR presentation field formats described in Section 2.2 of RFC 4034 [RFC4034]. A DNSKEY RR contains four fields: flags, a protocol octet, an algorithm number octet, and a public key.
客户提供的公钥信息映射到RFC 4034[RFC4034]第2.2节中描述的DNSKEY RR表示字段格式。DNSKEY RR包含四个字段：标志、协议八位字节、算法编号八位字节和公钥。
Boolean values MUST be represented in the XML Schema format described in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502].
布尔值必须以W3C XML模式建议[W3C.REC-xmlschema-2-20010502]第2部分中描述的XML模式格式表示。
Maximum signature lifetime (maxSigLife) is an OPTIONAL child preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire. The maxSigLife value applies to the RRSIG resource
最大签名生存期（maxSigLife）是一个可选的子项首选项，表示生成签名后，当父项对子项提供的DS信息的签名过期时的秒数。maxSigLife值应用于RRSIG资源
record (RR) over the DS RRset. See Section 3 of RFC 4034 [RFC4034] for information on the RRSIG resource record (RR).
通过DS RRset记录（RR）。有关RRSIG资源记录（RR）的信息，请参阅RFC 4034[RFC4034]第3节。
The maximum signature lifetime is represented using the <secDNS: maxSigLife> element. The maxSigLife value MUST be represented in seconds, using an extended XML Schema "int" format. The base "int" format, which allows negative numbers, is described in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502]. This format is further restricted to enforce a minimum value of 1.
最大签名生存期使用<secDNS:maxSigLife>元素表示。maxSigLife值必须使用扩展XML模式“int”格式以秒为单位表示。W3C XML模式建议[W3C.REC-xmlschema-2-20010502]的第2部分描述了允许负数的基本“int”格式。此格式进一步限制为强制执行最小值1。
If maxSigLife is not provided by the client, or if the server does not support the client-specified maxSigLife value, the default signature expiration policy of the server operator (as determined using an out-of-band mechanism) applies.
如果客户端未提供maxSigLife，或者服务器不支持客户端指定的maxSigLife值，则服务器操作员的默认签名过期策略（使用带外机制确定）适用。
This document describes operational scenarios in which a client can create, add, and remove Delegation Signer (DS) information or key data information for a domain name. There are two different forms of interfaces that a server can support. The first is called the "DS Data Interface", where the client is responsible for the creation of the DS information and is required to pass DS information when performing adds and removes. The server is required to pass DS information for <domain:info> responses. The second is the "Key Data Interface," where the client is responsible for passing the key data information when performing adds and removes. The server is responsible for passing key data information for <domain:info> responses.
本文档描述了客户端可以创建、添加和删除域名的委派签名者（DS）信息或关键数据信息的操作场景。服务器可以支持两种不同形式的接口。第一种称为“DS数据接口”，其中客户机负责创建DS信息，并在执行添加和删除时传递DS信息。服务器需要为<domain:info>响应传递DS信息。第二个是“关键数据接口”，客户机负责在执行添加和删除时传递关键数据信息。服务器负责传递<domain:info>响应的关键数据信息。
The server MUST support one form of interface within a single command or response, where <secDNS:dsData> and <secDNS:keyData> MUST NOT be mixed, except for when <secDNS:keyData> is a child element of <secDNS:dsData> for server validation. The server MUST support the use of only one form of interface across all <secDNS:create>, <secDNS:update>, and <secDNS:infData> elements, except during a transition period, during which the server MAY support both. For instance, during a transition period, the server MAY support either the DS Data Interface or the Key Data Interface on a per-domain basis and allow the client to migrate to the target interface. The client can replace the interface used by utilizing the <secDNS:rem><secDNS: all>true</secDNS:all></secDNS:rem> element to remove all data of the old interface, and by utilizing the <secDNS:add> to add data using the new interface (<secDNS:dsData> for the DS Data Interface and <secDNS:keyData> for the Key Data Interface). The server MUST return an EPP error result code of 2306 if the server receives a command using an unsupported interface.
服务器必须在单个命令或响应中支持一种形式的接口，其中<secDNS:dsData>和<secDNS:keyData>不得混合，除非<secDNS:keyData>是用于服务器验证的<secDNS:dsData>的子元素。服务器必须只支持在所有<secDNS:create>、<secDNS:update>和<secDNS:infData>元素中使用一种形式的接口，过渡期除外，在此期间，服务器可能同时支持这两种接口。例如，在过渡期内，服务器可以基于每个域支持DS数据接口或关键数据接口，并允许客户端迁移到目标接口。客户端可以使用<secDNS:rem><secDNS:all>true</secDNS:all></secDNS:rem>元素删除旧接口的所有数据，并使用<secDNS:add>使用新接口添加数据（DS数据接口为<secDNS:dsData>，密钥数据接口为<secDNS:keyData>）。如果服务器使用不受支持的接口接收到命令，则服务器必须返回EPP错误结果代码2306。
The DS Data Interface relies on the use of the <secDNS:dsData> element for creates, adds, removes, and <domain:info> responses. The key data associated with the DS information MAY be provided by the client, but the server is not obligated to use the key data. The server operator MAY also issue out-of-band DNS queries to retrieve the key data from the registered domain's apex in order to evaluate the received DS information. It is RECOMMENDED that the child zone operator have this key data online in the DNS tree to allow the parent zone administrator to validate the data as necessary. The key data SHOULD have the Secure Entry Point (SEP) bit set as described in RFC 3757 [RFC3757] and RFC 4034 [RFC4034].
DS数据接口依赖于使用<secDNS:dsData>元素来创建、添加、删除和<domain:info>响应。与DS信息相关联的密钥数据可以由客户端提供，但是服务器没有义务使用密钥数据。服务器运营商还可以发出带外DNS查询以从注册域的apex检索密钥数据，以便评估接收到的DS信息。建议子区域操作员在DNS树中联机此密钥数据，以允许父区域管理员根据需要验证数据。密钥数据应按照RFC 3757[RFC3757]和RFC 4034[RFC4034]中的说明设置安全入口点（SEP）位。
The <secDNS:dsData> element contains the following child elements:
<secDNS:dsData>元素包含以下子元素：
- A <secDNS:keyTag> element that contains a key tag value as described in Section 5.1.1 of RFC 4034 [RFC4034]. The <secDNS: keyTag> element is represented as an unsignedShort [W3C.REC-xmlschema-2-20010502].
- 包含RFC 4034[RFC4034]第5.1.1节所述密钥标签值的<secDNS:keyTag>元素。<secDNS:keyTag>元素表示为一个unsignedShort[W3C.REC-xmlschema-2-20010502]。
- A <secDNS:alg> element that contains an algorithm value as described in Section 5.1.2 of RFC 4034 [RFC4034].
- 包含RFC 4034[RFC4034]第5.1.2节所述算法值的<secDNS:alg>元素。
- A <secDNS:digestType> element that contains a digest type value as described in Section 5.1.3 of RFC 4034 [RFC4034].
- 包含RFC 4034[RFC4034]第5.1.3节所述摘要类型值的<secDNS:digestType>元素。
- A <secDNS:digest> element that contains a digest value as described in Section 5.1.4 of RFC 4034 [RFC4034]. The <secDNS: digest> element is represented as a hexBinary [W3C.REC-xmlschema-2-20010502].
- 包含RFC 4034[RFC4034]第5.1.4节所述摘要值的<secDNS:digest>元素。<secDNS:digest>元素表示为十六进制二进制[W3C.REC-xmlschema-2-20010502]。
- An OPTIONAL <secDNS:keyData> element that describes the key data used as input in the DS hash calculation for use in server validation. The <secDNS:keyData> element contains the child elements defined in Section 4.2.
- 一个可选的<secDNS:keyData>元素，描述在服务器验证中用作DS哈希计算输入的密钥数据。<secDNS:keyData>元素包含第4.2节中定义的子元素。
The Key Data Interface relies on the use of the <secDNS:keyData> element for creates, adds, removes, and <domain:info> responses. The DS information is not provided by the client but is generated by the server. The attributes used for DS generation are based on server policy, where only key data is passed between the client and the server.
密钥数据接口依赖于使用<secDNS:keyData>元素来创建、添加、删除和<domain:info>响应。DS信息不是由客户端提供的，而是由服务器生成的。用于生成DS的属性基于服务器策略，其中客户端和服务器之间只传递关键数据。
The <secDNS:keyData> element contains the following child elements:
<secDNS:keyData>元素包含以下子元素：
- A <secDNS:flags> element that contains a flags field value as described in Section 2.1.1 of RFC 4034 [RFC4034].
- 包含RFC 4034[RFC4034]第2.1.1节所述标志字段值的<secDNS:flags>元素。
- A <secDNS:protocol> element that contains a protocol field value as described in Section 2.1.2 of RFC 4034 [RFC4034].
- 包含协议字段值的<secDNS:protocol>元素，如RFC 4034[RFC4034]第2.1.2节所述。
- A <secDNS:alg> element that contains an algorithm number field value as described in Section 2.1.3 of RFC 4034 [RFC4034].
- 包含RFC 4034[RFC4034]第2.1.3节所述算法编号字段值的<secDNS:alg>元素。
- A <secDNS:pubKey> element that contains an encoded public key field value as described in Section 2.1.4 of RFC 4034 [RFC4034]. The <secDNS:pubKey> element is represented as a base64Binary [W3C.REC-xmlschema-2-20010502] with a minimum length of 1.
- 一个<secDNS:pubKey>元素，包含RFC 4034[RFC4034]第2.1.4节所述的编码公钥字段值。<secDNS:pubKey>元素表示为base64二进制[W3C.REC-xmlschema-2-20010502]，最小长度为1。
Example use of the secDNS-1.1 DS Data Interface for a create:
secDNS-1.1 DS数据接口用于创建的示例：
<secDNS:dsData>
<secDNS:keyTag>12345</secDNS:keyTag>
<secDNS:alg>3</secDNS:alg>
<secDNS:digestType>1</secDNS:digestType>
<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
</secDNS:dsData>
<secDNS:dsData>
<secDNS:keyTag>12345</secDNS:keyTag>
<secDNS:alg>3</secDNS:alg>
<secDNS:digestType>1</secDNS:digestType>
<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
</secDNS:dsData>
Example use of secDNS-1.1 DS Data Interface with option key data for a create:
secDNS-1.1 DS数据接口与选项密钥数据的示例，用于创建：
<secDNS:dsData>
<secDNS:keyTag>12345</secDNS:keyTag>
<secDNS:alg>3</secDNS:alg>
<secDNS:digestType>1</secDNS:digestType>
<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
<secDNS:keyData>
<secDNS:flags>257</secDNS:flags>
<secDNS:protocol>3</secDNS:protocol>
<secDNS:alg>1</secDNS:alg>
<secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
</secDNS:keyData>
</secDNS:dsData>
<secDNS:dsData>
<secDNS:keyTag>12345</secDNS:keyTag>
<secDNS:alg>3</secDNS:alg>
<secDNS:digestType>1</secDNS:digestType>
<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
<secDNS:keyData>
<secDNS:flags>257</secDNS:flags>
<secDNS:protocol>3</secDNS:protocol>
<secDNS:alg>1</secDNS:alg>
<secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
</secDNS:keyData>
</secDNS:dsData>
Example use of the secDNS-1.1 Key Data Interface for a create:
secDNS-1.1密钥数据接口用于创建的示例：
<secDNS:keyData>
<secDNS:flags>257</secDNS:flags>
<secDNS:protocol>3</secDNS:protocol>
<secDNS:alg>1</secDNS:alg>
<secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
</secDNS:keyData>
<secDNS:keyData>
<secDNS:flags>257</secDNS:flags>
<secDNS:protocol>3</secDNS:protocol>
<secDNS:alg>1</secDNS:alg>
<secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
</secDNS:keyData>
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mappings described here are specifically for use in provisioning and managing DNS security extensions via EPP.
EPP语法和语义的详细描述可在EPP核心协议规范[RFC5730]中找到。这里描述的命令映射专门用于通过EPP配置和管理DNS安全扩展。
EPP provides three commands to retrieve object information: <check> to determine if an object is known to the server, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.
EPP提供了三个命令来检索对象信息：<check>来确定服务器是否知道对象，<info>来检索与对象相关的详细信息，<transfer>来检索对象传输状态信息。
This extension does not add any elements to the EPP <check> command or <check> response described in the EPP domain mapping [RFC5731].
此扩展不向EPP域映射[RFC5731]中描述的EPP<check>命令或<check>响应添加任何元素。
This extension does not add any elements to the EPP <info> command described in the EPP domain mapping [RFC5731]. However, additional elements are defined for the <info> response.
此扩展不向EPP域映射[RFC5731]中描述的EPP<info>命令添加任何元素。但是，为<info>响应定义了其他元素。
When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in the EPP domain mapping [RFC5731]. In addition, the EPP <extension> element SHOULD contain a child <secDNS:infData> element that identifies the extension namespace if the domain object has data associated with this extension and based on server policy. The <secDNS:infData> element contains the following child elements:
成功处理<info>命令后，EPP<resData>元素必须包含EPP域映射[RFC5731]中所述的子元素。此外，EPP<extension>元素应该包含一个子<secDNS:infData>元素，如果域对象具有与此扩展关联的数据并且基于服务器策略，则该元素将标识扩展命名空间。<secDNS:infData>元素包含以下子元素：
- An OPTIONAL <secDNS:maxSigLife> element that indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire. maxSigLife is described in Section 3.3.
- 一个可选的<secDNS:maxSigLife>元素，指示孩子在签名生成后的秒数上的首选项，当孩子提供的DS信息上的父签名过期时。maxSigLife在第3.3节中描述。
- One or more <secDNS:dsData> elements or <secDNS:keyData> elements, but not both, as defined in Section 4. The <secDNS:dsData> elements describe the Delegation Signer (DS) data provided by the client for the domain. The <secDNS:keyData> elements describe the key data provided by the client for the domain. Child elements of the <secDNS:dsData> element are described in Section 4.1. Child elements of the <secDNS:keyData> element are described in Section 4.2.
- 一个或多个<secDNS:dsData>元素或<secDNS:keyData>元素，但不是两个，如第4节所定义。<secDNS:dsData>元素描述客户端为域提供的委托签名者（DS）数据。<secDNS:keyData>元素描述客户端为域提供的密钥数据。第4.1节描述了<secDNS:dsData>元素的子元素。第4.2节描述了<secDNS:keyData>元素的子元素。
Example <info> Response for a Secure Delegation Using the DS Data Interface:
使用DS数据接口的安全委派的<info>响应示例：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns2.example.com</domain:hostObj>
S: </domain:ns>
S: <domain:host>ns1.example.com</domain:host>
S: <domain:host>ns2.example.com</domain:host>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:upID>ClientX</domain:upID>
S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <secDNS:infData
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns2.example.com</domain:hostObj>
S: </domain:ns>
S: <domain:host>ns1.example.com</domain:host>
S: <domain:host>ns2.example.com</domain:host>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:upID>ClientX</domain:upID>
S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <secDNS:infData
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
S: <secDNS:dsData>
S: <secDNS:keyTag>12345</secDNS:keyTag>
S: <secDNS:alg>3</secDNS:alg>
S: <secDNS:digestType>1</secDNS:digestType>
S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
S: </secDNS:dsData>
S: </secDNS:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
S: <secDNS:dsData>
S: <secDNS:keyTag>12345</secDNS:keyTag>
S: <secDNS:alg>3</secDNS:alg>
S: <secDNS:digestType>1</secDNS:digestType>
S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
S: </secDNS:dsData>
S: </secDNS:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Example <info> Response for a Secure Delegation Using the DS Data Interface with OPTIONAL Key Data:
示例<info>使用DS数据接口和可选密钥数据的安全委派响应：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns2.example.com</domain:hostObj>
S: </domain:ns>
S: <domain:host>ns1.example.com</domain:host>
S: <domain:host>ns2.example.com</domain:host>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:upID>ClientX</domain:upID>
S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns2.example.com</domain:hostObj>
S: </domain:ns>
S: <domain:host>ns1.example.com</domain:host>
S: <domain:host>ns2.example.com</domain:host>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:upID>ClientX</domain:upID>
S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <secDNS:infData
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
S: <secDNS:maxSigLife>604800</secDNS:maxSigLife>
S: <secDNS:dsData>
S: <secDNS:keyTag>12345</secDNS:keyTag>
S: <secDNS:alg>3</secDNS:alg>
S: <secDNS:digestType>1</secDNS:digestType>
S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
S: <secDNS:keyData>
S: <secDNS:flags>257</secDNS:flags>
S: <secDNS:protocol>3</secDNS:protocol>
S: <secDNS:alg>1</secDNS:alg>
S: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
S: </secDNS:keyData>
S: </secDNS:dsData>
S: </secDNS:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <secDNS:infData
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
S: <secDNS:maxSigLife>604800</secDNS:maxSigLife>
S: <secDNS:dsData>
S: <secDNS:keyTag>12345</secDNS:keyTag>
S: <secDNS:alg>3</secDNS:alg>
S: <secDNS:digestType>1</secDNS:digestType>
S: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
S: <secDNS:keyData>
S: <secDNS:flags>257</secDNS:flags>
S: <secDNS:protocol>3</secDNS:protocol>
S: <secDNS:alg>1</secDNS:alg>
S: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
S: </secDNS:keyData>
S: </secDNS:dsData>
S: </secDNS:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Example <info> Response for a Secure Delegation Using the Key Data Interface:
使用密钥数据接口的安全委派响应示例：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns2.example.com</domain:hostObj>
S: </domain:ns>
S: <domain:host>ns1.example.com</domain:host>
S: <domain:host>ns2.example.com</domain:host>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:upID>ClientX</domain:upID>
S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <secDNS:infData
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
S: <secDNS:keyData>
S: <secDNS:flags>257</secDNS:flags>
S: <secDNS:protocol>3</secDNS:protocol>
S: <secDNS:alg>1</secDNS:alg>
S: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
S: </secDNS:keyData>
S: </secDNS:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns2.example.com</domain:hostObj>
S: </domain:ns>
S: <domain:host>ns1.example.com</domain:host>
S: <domain:host>ns2.example.com</domain:host>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:upID>ClientX</domain:upID>
S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <secDNS:infData
S: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
S: <secDNS:keyData>
S: <secDNS:flags>257</secDNS:flags>
S: <secDNS:protocol>3</secDNS:protocol>
S: <secDNS:alg>1</secDNS:alg>
S: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
S: </secDNS:keyData>
S: </secDNS:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if an <info> command cannot be processed for any reason.
如果由于任何原因无法处理<info>命令，则必须返回EPP错误响应。
This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [RFC5731].
此扩展不向EPP域映射[RFC5731]中描述的EPP<transfer>命令或<transfer>响应添加任何元素。
EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object.
EPP提供了五个转换对象的命令：<create>创建对象实例，<delete>删除对象实例，<renew>延长对象有效期，<transfer>管理对象更改，以及<update>更改与对象关联的信息。
This extension defines additional elements for the EPP <create> command described in the EPP domain mapping [RFC5731]. No additional elements are defined for the EPP <create> response.
此扩展为EPP域映射[RFC5731]中描述的EPP<create>命令定义了其他元素。没有为EPP<create>响应定义其他元素。
The EPP <create> command provides a transform operation that allows a client to create a domain object. In addition to the EPP command elements described in the EPP domain mapping [RFC5731], the command MUST contain an <extension> element, and the <extension> element MUST contain a child <secDNS:create> element that identifies the extension namespace if the client wants to associate data defined in this extension to the domain object. The <secDNS:create> element contains the following child elements:
EPP<create>命令提供一个转换操作，允许客户端创建域对象。除了EPP域映射[RFC5731]中描述的EPP命令元素外，该命令还必须包含<extension>元素，<extension>元素必须包含一个子<secDNS:create>元素，如果客户端希望将此扩展中定义的数据与域对象相关联，该子元素将标识扩展命名空间。<secDNS:create>元素包含以下子元素：
- An OPTIONAL <secDNS:maxSigLife> element that indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire. maxSigLife is described in Section 3.3. If the server does not support the <secDNS:maxSigLife> element, a 2102 error MUST be returned.
- 一个可选的<secDNS:maxSigLife>元素，指示孩子在签名生成后的秒数上的首选项，当孩子提供的DS信息上的父签名过期时。maxSigLife在第3.3节中描述。如果服务器不支持<secDNS:maxSigLife>元素，则必须返回2102错误。
- Zero or more <secDNS:dsData> elements or <secDNS:keyData> elements, but not both, as defined in Section 4. Child elements of the <secDNS:dsData> element are described in Section 4.1. Child elements of the <secDNS:keyData> element are described in Section 4.2.
- 零个或多个<secDNS:dsData>元素或<secDNS:keyData>元素，但不是两个，如第4节所定义。第4.1节描述了<secDNS:dsData>元素的子元素。第4.2节描述了<secDNS:keyData>元素的子元素。
Example <create> Command for a Secure Delegation Using the DS Data Interface:
使用DS数据接口的安全委派的<create>命令示例：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <create>
C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: <domain:period unit="y">2</domain:period>
C: <domain:ns>
C: <domain:hostObj>ns1.example.com</domain:hostObj>
C: <domain:hostObj>ns2.example.com</domain:hostObj>
C: </domain:ns>
C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="admin">sh8013</domain:contact>
C: <domain:contact type="tech">sh8013</domain:contact>
C: <domain:authInfo>
C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <secDNS:create
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:maxSigLife>604800</secDNS:maxSigLife>
C: <secDNS:dsData>
C: <secDNS:keyTag>12345</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <create>
C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: <domain:period unit="y">2</domain:period>
C: <domain:ns>
C: <domain:hostObj>ns1.example.com</domain:hostObj>
C: <domain:hostObj>ns2.example.com</domain:hostObj>
C: </domain:ns>
C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="admin">sh8013</domain:contact>
C: <domain:contact type="tech">sh8013</domain:contact>
C: <domain:authInfo>
C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <secDNS:create
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:maxSigLife>604800</secDNS:maxSigLife>
C: <secDNS:dsData>
C: <secDNS:keyTag>12345</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <create> Command for a Secure Delegation Using the DS Data Interface with OPTIONAL Key Data:
使用DS数据接口和可选密钥数据的安全委派的<create>命令示例：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <create>
C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: <domain:period unit="y">2</domain:period>
C: <domain:ns>
C: <domain:hostObj>ns1.example.com</domain:hostObj>
C: <domain:hostObj>ns2.example.com</domain:hostObj>
C: </domain:ns>
C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="admin">sh8013</domain:contact>
C: <domain:contact type="tech">sh8013</domain:contact>
C: <domain:authInfo>
C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <secDNS:create
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:maxSigLife>604800</secDNS:maxSigLife>
C: <secDNS:dsData>
C: <secDNS:keyTag>12345</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
C: <secDNS:keyData>
C: <secDNS:flags>257</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>1</secDNS:alg>
C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
C: </secDNS:keyData>
C: </secDNS:dsData>
C: </secDNS:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <create>
C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: <domain:period unit="y">2</domain:period>
C: <domain:ns>
C: <domain:hostObj>ns1.example.com</domain:hostObj>
C: <domain:hostObj>ns2.example.com</domain:hostObj>
C: </domain:ns>
C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="admin">sh8013</domain:contact>
C: <domain:contact type="tech">sh8013</domain:contact>
C: <domain:authInfo>
C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <secDNS:create
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:maxSigLife>604800</secDNS:maxSigLife>
C: <secDNS:dsData>
C: <secDNS:keyTag>12345</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
C: <secDNS:keyData>
C: <secDNS:flags>257</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>1</secDNS:alg>
C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
C: </secDNS:keyData>
C: </secDNS:dsData>
C: </secDNS:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <create> Command for a Secure Delegation Using the Key Data Interface:
使用密钥数据接口的安全委派的<create>命令示例：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <create>
C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: <domain:period unit="y">2</domain:period>
C: <domain:ns>
C: <domain:hostObj>ns1.example.com</domain:hostObj>
C: <domain:hostObj>ns2.example.com</domain:hostObj>
C: </domain:ns>
C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="admin">sh8013</domain:contact>
C: <domain:contact type="tech">sh8013</domain:contact>
C: <domain:authInfo>
C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <secDNS:create
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:keyData>
C: <secDNS:flags>257</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>1</secDNS:alg>
C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
C: </secDNS:keyData>
C: </secDNS:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <create>
C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: <domain:period unit="y">2</domain:period>
C: <domain:ns>
C: <domain:hostObj>ns1.example.com</domain:hostObj>
C: <domain:hostObj>ns2.example.com</domain:hostObj>
C: </domain:ns>
C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="admin">sh8013</domain:contact>
C: <domain:contact type="tech">sh8013</domain:contact>
C: <domain:authInfo>
C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <secDNS:create
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:keyData>
C: <secDNS:flags>257</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>1</secDNS:alg>
C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
C: </secDNS:keyData>
C: </secDNS:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <create> command has been processed successfully, the EPP response is as described in the EPP domain mapping [RFC5731].
成功处理<create>命令后，EPP响应如EPP域映射[RFC5731]中所述。
This extension does not add any elements to the EPP <delete> command or <delete> response described in the EPP domain mapping [RFC5731].
此扩展不向EPP域映射[RFC5731]中描述的EPP<delete>命令或<delete>响应添加任何元素。
This extension does not add any elements to the EPP <renew> command or <renew> response described in the EPP domain mapping [RFC5731].
此扩展不向EPP域映射[RFC5731]中描述的EPP<renew>命令或<renew>响应添加任何元素。
This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [RFC5731].
此扩展不向EPP域映射[RFC5731]中描述的EPP<transfer>命令或<transfer>响应添加任何元素。
This extension defines additional elements for the EPP <update> command described in the EPP domain mapping [RFC5731]. No additional elements are defined for the EPP <update> response.
此扩展为EPP域映射[RFC5731]中描述的EPP<update>命令定义了其他元素。没有为EPP<update>响应定义其他元素。
The EPP <update> command provides a transform operation that allows a client to modify the attributes of a domain object. In addition to the EPP command elements described in the EPP domain mapping, the command MUST contain an <extension> element, and the <extension> element MUST contain a child <secDNS:update> element that identifies the extension namespace if the client wants to update the domain object with data defined in this extension. The <secDNS:update> element contains a <secDNS:add> element to add security information to a delegation, a <secDNS:rem> element to remove security information from a delegation, or a <secDNS:chg> element to change existing security information. At least one <secDNS:add>, <secDNS: rem>, or <secDNS:chg> element MUST be provided. The order of the <secDNS:rem> and <secDNS:add> elements is significant, where the server MUST first remove the existing elements prior to adding the new elements.
EPP<update>命令提供转换操作，允许客户端修改域对象的属性。除了EPP域映射中描述的EPP command元素外，该命令还必须包含<extension>元素，<extension>元素必须包含一个子<secDNS:update>元素，如果客户端希望使用此扩展中定义的数据更新域对象，该子元素将标识扩展命名空间。<secDNS:update>元素包含用于向委派添加安全信息的<secDNS:add>元素，用于从委派中删除安全信息的<secDNS:rem>元素，或用于更改现有安全信息的<secDNS:chg>元素。必须至少提供一个<secDNS:add>、<secDNS:rem>或<secDNS:chg>元素。<secDNS:rem>和<secDNS:add>元素的顺序很重要，其中服务器必须在添加新元素之前先删除现有元素。
The <secDNS:update> element also contains an OPTIONAL "urgent" attribute that a client can use to ask the server operator to complete and implement the update request with high priority. This attribute accepts boolean values as described in Section 3.2; the default value is boolean false. "High priority" is relative to standard server operator policies that are determined using an out-of-band mechanism. A server MUST return an EPP error result code of 2102 if the "urgent" attribute is specified with a value of boolean true and the server does not support it. A server MUST return an EPP error result code of 2306 if the server supports the "urgent" attribute and an urgent update (noted with an "urgent" attribute value of boolean true) cannot be completed with high priority.
<secDNS:update>元素还包含一个可选的“紧急”属性，客户端可以使用该属性请求服务器操作员以高优先级完成并实现更新请求。该属性接受第3.2节所述的布尔值；默认值为布尔值false。“高优先级”是相对于使用带外机制确定的标准服务器操作员策略而言的。如果“紧急”属性的值为布尔真且服务器不支持，则服务器必须返回EPP错误结果代码2102。如果服务器支持“紧急”属性，并且无法以高优先级完成紧急更新（用布尔值true表示为“紧急”属性值），则服务器必须返回EPP错误结果代码2306。
The <secDNS:update> element contains the following child elements:
<secDNS:update>元素包含以下子元素：
- An OPTIONAL <secDNS:rem> element that contains a <secDNS:all> element, or one or more <secDNS:dsData> or <secDNS:keyData> elements that are used to remove security data from a delegation.
- 可选的<secDNS:rem>元素，包含<secDNS:all>元素，或一个或多个<secDNS:dsData>或<secDNS:keyData>元素，用于从委派中删除安全数据。
The <secDNS:all> element is used to remove all DS and key data with a value of boolean true. A value of boolean false will do nothing. Removing all DS information can remove the ability of the parent to secure the delegation to the child zone.
<secDNS:all>元素用于删除布尔值为true的所有DS和密钥数据。布尔值false将不起任何作用。删除所有DS信息可能会使父级无法保护对子区域的委派。
The <secDNS:dsData> element is part of the DS Data Interface and is used to uniquely define the DS record to be removed, by using all four elements -- <secDNS:keyTag>, <secDNS:alg>, <secDNS: digestType>, and <secDNS:digest> -- that are guaranteed to be unique.
<secDNS:dsData>元素是DS数据接口的一部分，用于通过使用保证唯一的所有四个元素--<secDNS:keyTag>、<secDNS:alg>、<secDNS:digestType>和<secDNS:digest>，唯一地定义要删除的DS记录。
The <secDNS:keyData> element is part of the Key Data Interface and is used to uniquely define the key data to be removed, by using all four elements -- <secDNS:flags>, <secDNS:protocol>, <secDNS: alg>, and <secDNS:pubKey> -- that are guaranteed to be unique. There can be more than one DS record created for each key, so removing a key could remove more than one DS record.
<secDNS:keyData>元素是密钥数据接口的一部分，用于通过使用保证唯一的所有四个元素--<secDNS:flags>、<secDNS:protocol>、<secDNS:alg>和<secDNS:pubKey>，唯一地定义要删除的密钥数据。可以为每个键创建多个DS记录，因此删除一个键可以删除多个DS记录。
- An OPTIONAL <secDNS:add> element that is used to add security information to an existing set. The <secDNS:add> element MUST contain one or more <secDNS:dsData> or <secDNS:keyData> elements. Child elements of the <secDNS:dsData> element are described in Section 4.1. Child elements of the <secDNS:keyData> element are described in Section 4.2.
- 可选的<secDNS:add>元素，用于将安全信息添加到现有集合。<secDNS:add>元素必须包含一个或多个<secDNS:dsData>或<secDNS:keyData>元素。第4.1节描述了<secDNS:dsData>元素的子元素。第4.2节描述了<secDNS:keyData>元素的子元素。
- An OPTIONAL <secDNS:chg> element that contains security information to be changed. A <secDNS:chg> element contains the following child elements:
- 包含要更改的安全信息的可选<secDNS:chg>元素。<secDNS:chg>元素包含以下子元素：
- An OPTIONAL <secDNS:maxSigLife> element that indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire. maxSigLife is described in Section 3.3. If the server does not support the <secDNS: maxSigLife> element, a 2102 error MUST be returned.
- 一个可选的<secDNS:maxSigLife>元素，指示孩子在签名生成后的秒数上的首选项，当孩子提供的DS信息上的父签名过期时。maxSigLife在第3.3节中描述。如果服务器不支持<secDNS:maxSigLife>元素，则必须返回2102错误。
Example <update> Command, Adding and Removing DS Data Using the DS Data Interface:
示例<update>命令，使用DS数据接口添加和删除DS数据：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:dsData>
C: <secDNS:keyTag>12345</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>38EC35D5B3A34B33C99B</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:rem>
C: <secDNS:add>
C: <secDNS:dsData>
C: <secDNS:keyTag>12346</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:add>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:dsData>
C: <secDNS:keyTag>12345</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>38EC35D5B3A34B33C99B</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:rem>
C: <secDNS:add>
C: <secDNS:dsData>
C: <secDNS:keyTag>12346</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:add>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> Command, Updating the maxSigLife:
示例<update>命令，更新maxSigLife：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:chg>
C: <secDNS:maxSigLife>605900</secDNS:maxSigLife>
C: </secDNS:chg>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:chg>
C: <secDNS:maxSigLife>605900</secDNS:maxSigLife>
C: </secDNS:chg>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> Command, Adding and Removing Key Data Using the Key Data Interface, and Setting maxSigLife:
示例<update>命令，使用密钥数据界面添加和删除密钥数据，并设置maxSigLife：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:keyData>
C: <secDNS:flags>257</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>1</secDNS:alg>
C: <secDNS:pubKey>AQPJ////4QQQ</secDNS:pubKey>
C: </secDNS:keyData>
C: </secDNS:rem>
C: <secDNS:add>
C: <secDNS:keyData>
C: <secDNS:flags>257</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>1</secDNS:alg>
C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
C: </secDNS:keyData>
C: </secDNS:add>
C: <secDNS:chg>
C: <secDNS:maxSigLife>605900</secDNS:maxSigLife>
C: </secDNS:chg>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:keyData>
C: <secDNS:flags>257</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>1</secDNS:alg>
C: <secDNS:pubKey>AQPJ////4QQQ</secDNS:pubKey>
C: </secDNS:keyData>
C: </secDNS:rem>
C: <secDNS:add>
C: <secDNS:keyData>
C: <secDNS:flags>257</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>1</secDNS:alg>
C: <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
C: </secDNS:keyData>
C: </secDNS:add>
C: <secDNS:chg>
C: <secDNS:maxSigLife>605900</secDNS:maxSigLife>
C: </secDNS:chg>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> Command, Removing DS Data with <secDNS:dsData> Using the DS Data Interface:
示例<update>命令，使用DS数据接口通过<secDNS:dsData>删除DS数据：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:dsData>
C: <secDNS:keyTag>12346</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:rem>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:dsData>
C: <secDNS:keyTag>12346</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:rem>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> Command, Removing all DS and Key Data Using <secDNS:rem> with <secDNS:all>:
示例<update>命令，使用<secDNS:rem>和<secDNS:all>删除所有DS和密钥数据：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update urgent="true"
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0">
C: <secDNS:rem>
C: <secDNS:all>true</secDNS:all>
C: </secDNS:rem>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update urgent="true"
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0">
C: <secDNS:rem>
C: <secDNS:all>true</secDNS:all>
C: </secDNS:rem>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example Urgent <update> Command, Replacing all DS Data Using the DS Data Interface:
示例紧急<update>命令，使用DS数据接口替换所有DS数据：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update urgent="true"
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:all>true</secDNS:all>
C: </secDNS:rem>
C: <secDNS:add>
C: <secDNS:dsData>
C: <secDNS:keyTag>12346</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:add>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <secDNS:update urgent="true"
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:all>true</secDNS:all>
C: </secDNS:rem>
C: <secDNS:add>
C: <secDNS:dsData>
C: <secDNS:keyTag>12346</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:add>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an extended <update> command has been processed successfully, the EPP response is as described in the EPP domain mapping [RFC5731].
成功处理扩展的<update>命令后，EPP响应如EPP域映射[RFC5731]中所述。
An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.
EPP对象映射是用XML模式表示法指定的。这里给出的形式语法是对象映射的完整模式表示，适合于自动验证EPP XML实例。开始和结束标记不是模式的一部分；它们用于记录模式的开始和结束，以便进行URI注册。
Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2010 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
在满足以下条件的情况下，允许以源代码和二进制格式重新分发和使用，无论是否修改：
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- 源代码的重新分发必须保留上述版权声明、此条件列表和以下免责声明。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- 以二进制形式重新分发时，必须在分发时提供的文档和/或其他材料中复制上述版权声明、本条件列表和以下免责声明。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
本软件由版权所有者和贡献者“按原样”提供，不承担任何明示或暗示的担保，包括但不限于对适销性和特定用途适用性的暗示担保。在任何情况下，版权所有人或贡献者均不对任何直接、间接、偶然、特殊、惩戒性或后果性损害（包括但不限于替代商品或服务的采购；使用、数据或利润的损失；或业务中断）负责，无论是在合同中还是在任何责任理论下，严格责任，或因使用本软件而产生的侵权行为（包括疏忽或其他），即使告知可能发生此类损害。
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
domain name extension schema
for provisioning DNS security (DNSSEC) extensions.
</documentation>
</annotation>
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
domain name extension schema
for provisioning DNS security (DNSSEC) extensions.
</documentation>
</annotation>
<!-- Child elements found in EPP commands. -->
<!-- 在EPP命令中找到子元素。-->
<element name="create" type="secDNS:dsOrKeyType"/>
<element name="update" type="secDNS:updateType"/>
<element name="create" type="secDNS:dsOrKeyType"/>
<element name="update" type="secDNS:updateType"/>
<!--
Child elements supporting either the
dsData or the keyData interface.
-->
<complexType name="dsOrKeyType">
<sequence>
<element name="maxSigLife" type="secDNS:maxSigLifeType"
minOccurs="0"/>
<choice>
<element name="dsData" type="secDNS:dsDataType"
maxOccurs="unbounded"/>
<element name="keyData" type="secDNS:keyDataType"
maxOccurs="unbounded"/>
</choice>
</sequence>
</complexType>
<!--
Child elements supporting either the
dsData or the keyData interface.
-->
<complexType name="dsOrKeyType">
<sequence>
<element name="maxSigLife" type="secDNS:maxSigLifeType"
minOccurs="0"/>
<choice>
<element name="dsData" type="secDNS:dsDataType"
maxOccurs="unbounded"/>
<element name="keyData" type="secDNS:keyDataType"
maxOccurs="unbounded"/>
</choice>
</sequence>
</complexType>
<!--
Definition for the maximum signature lifetime (maxSigLife)
-->
<simpleType name="maxSigLifeType">
<restriction base="int">
<minInclusive value="1"/>
</restriction>
</simpleType>
<!--
Definition for the maximum signature lifetime (maxSigLife)
-->
<simpleType name="maxSigLifeType">
<restriction base="int">
<minInclusive value="1"/>
</restriction>
</simpleType>
<!--
Child elements of dsData used for dsData interface
-->
<complexType name="dsDataType">
<sequence>
<element name="keyTag" type="unsignedShort"/>
<element name="alg" type="unsignedByte"/>
<element name="digestType" type="unsignedByte"/>
<element name="digest" type="hexBinary"/>
<element name="keyData" type="secDNS:keyDataType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Child elements of dsData used for dsData interface
-->
<complexType name="dsDataType">
<sequence>
<element name="keyTag" type="unsignedShort"/>
<element name="alg" type="unsignedByte"/>
<element name="digestType" type="unsignedByte"/>
<element name="digest" type="hexBinary"/>
<element name="keyData" type="secDNS:keyDataType"
minOccurs="0"/>
</sequence>
</complexType>
<!-- Child elements of keyData used for keyData interface and optionally with dsData interface --> <complexType name="keyDataType">
<!-- keyData的子元素用于keyData接口，也可以与dsData接口一起使用--><complexType name=“keyDataType”>
<sequence>
<element name="flags" type="unsignedShort"/>
<element name="protocol" type="unsignedByte"/>
<element name="alg" type="unsignedByte"/>
<element name="pubKey" type="secDNS:keyType"/>
</sequence>
</complexType>
<sequence>
<element name="flags" type="unsignedShort"/>
<element name="protocol" type="unsignedByte"/>
<element name="alg" type="unsignedByte"/>
<element name="pubKey" type="secDNS:keyType"/>
</sequence>
</complexType>
<!--
Definition for the public key
-->
<simpleType name="keyType">
<restriction base="base64Binary">
<minLength value="1"/>
</restriction>
</simpleType>
<!--
Definition for the public key
-->
<simpleType name="keyType">
<restriction base="base64Binary">
<minLength value="1"/>
</restriction>
</simpleType>
<!--
Child elements of the <update> element.
-->
<complexType name="updateType">
<sequence>
<element name="rem" type="secDNS:remType"
minOccurs="0"/>
<element name="add" type="secDNS:dsOrKeyType"
minOccurs="0"/>
<element name="chg" type="secDNS:chgType"
minOccurs="0"/>
</sequence>
<attribute name="urgent" type="boolean" default="false"/>
</complexType>
<!--
Child elements of the <update> element.
-->
<complexType name="updateType">
<sequence>
<element name="rem" type="secDNS:remType"
minOccurs="0"/>
<element name="add" type="secDNS:dsOrKeyType"
minOccurs="0"/>
<element name="chg" type="secDNS:chgType"
minOccurs="0"/>
</sequence>
<attribute name="urgent" type="boolean" default="false"/>
</complexType>
<!--
Child elements of the <rem> command.
-->
<complexType name="remType">
<choice>
<element name="all" type="boolean"/>
<element name="dsData" type="secDNS:dsDataType"
maxOccurs="unbounded"/>
<element name="keyData" type="secDNS:keyDataType"
maxOccurs="unbounded"/>
</choice>
</complexType>
<!--
Child elements of the <rem> command.
-->
<complexType name="remType">
<choice>
<element name="all" type="boolean"/>
<element name="dsData" type="secDNS:dsDataType"
maxOccurs="unbounded"/>
<element name="keyData" type="secDNS:keyDataType"
maxOccurs="unbounded"/>
</choice>
</complexType>
<!--
Child elements supporting the <chg> element.
-->
<!--
Child elements supporting the <chg> element.
-->
<complexType name="chgType">
<sequence>
<element name="maxSigLife" type="secDNS:maxSigLifeType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="chgType">
<sequence>
<element name="maxSigLife" type="secDNS:maxSigLifeType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Child response elements.
-->
<element name="infData" type="secDNS:dsOrKeyType"/>
<!--
Child response elements.
-->
<element name="infData" type="secDNS:dsOrKeyType"/>
</schema> END
</schema>END
EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8 [RFC3629]. Conformant XML processors recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists.
EPP用XML表示，它为使用Unicode字符集及其更紧凑的表示（包括UTF-8[RFC3629]）编码信息提供了本机支持。一致性XML处理器同时识别UTF-8和UTF-16[RFC2781]。尽管XML包含通过在<？XML？>声明中使用“encoding”属性来识别和使用其他字符编码的规定，但在解析器编码支持不兼容的环境中，建议使用UTF-8。
As an extension of the EPP domain mapping [RFC5731], the internationalization requirements in the EPP domain mapping [RFC5731] are followed by this extension. This extension does not override any of the EPP domain mapping [RFC5731] internationalization features.
作为EPP域映射[RFC5731]的扩展，此扩展遵循EPP域映射[RFC5731]中的国际化要求。此扩展不覆盖任何EPP域映射[RFC5731]国际化功能。
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in RFC 3688 [RFC3688]. Two URI assignments have been completed by the IANA.
本文档使用URN来描述符合RFC 3688[RFC3688]中描述的注册表机制的XML名称空间和XML模式。IANA已经完成了两个URI分配。
Registration request for the extension namespace:
扩展命名空间的注册请求：
URI: urn:ietf:params:xml:ns:secDNS-1.1
URI: urn:ietf:params:xml:ns:secDNS-1.1
Registrant Contact: IESG
注册联系人：IESG
XML: None. Namespace URIs do not represent an XML specification.
XML：没有。命名空间URI不表示XML规范。
Registration request for the extension XML schema:
扩展XML架构的注册请求：
URI: urn:ietf:params:xml:schema:secDNS-1.1
URI: urn:ietf:params:xml:schema:secDNS-1.1
Registrant Contact: IESG
注册联系人：IESG
XML: See the "Formal Syntax" section of this document.
XML：请参阅本文档的“正式语法”部分。
The mapping extensions described in this document do not provide any security services beyond those described by EPP [RFC5730], the EPP domain name mapping [RFC5731], and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well.
除EPP[RFC5730]、EPP域名映射[RFC5731]和EPP使用的协议层所述的安全服务外，本文档中描述的映射扩展不提供任何安全服务。这些其他规范中描述的安全注意事项也适用于本规范。
As with other domain object transforms, the EPP transform operations described in this document MUST be restricted to the sponsoring client as authenticated using the mechanisms described in Sections 2.9.1.1 and 7 of RFC 5730 [RFC5730]. Any attempt to perform a transform operation on a domain object by any client other than the sponsoring client MUST be rejected with an appropriate EPP authorization error.
与其他域对象转换一样，本文档中描述的EPP转换操作必须限于使用RFC 5730[RFC5730]第2.9.1.1和7节中描述的机制进行身份验证的发起客户端。必须拒绝发起客户端以外的任何客户端对域对象执行转换操作的任何尝试，并显示相应的EPP授权错误。
The provisioning service described in this document involves the exchange of information that can have an operational impact on the DNS. A trust relationship MUST exist between the EPP client and server, and provisioning of public key information MUST only be done after the identities of both parties have been confirmed using a strong authentication mechanism.
本文档中描述的配置服务涉及对DNS有操作影响的信息交换。EPP客户端和服务器之间必须存在信任关系，只有在使用强身份验证机制确认双方的身份后，才能提供公钥信息。
An EPP client might be acting as an agent for a zone administrator who wants to send delegation information to be signed and published by the server operator. Man-in-the-middle attacks are thus possible as a result of direct client activity or inadvertent client data manipulation.
EPP客户端可能充当区域管理员的代理，该管理员希望发送要由服务器操作员签名和发布的委派信息。因此，直接的客户端活动或无意的客户端数据操纵可能导致中间人攻击。
Acceptance of a false key by a server operator can produce significant operational consequences. The child and parent zones MUST be consistent to secure the delegation properly. In the absence of consistent signatures, the delegation will not appear in the secure namespace, yielding untrustworthy query responses. If a key is compromised, a client can either remove the compromised information or update the delegation information via EPP commands using the "urgent" attribute.
服务器操作员接受假密钥可能会产生严重的操作后果。子区域和父区域必须一致，以确保适当的委派。如果没有一致的签名，委托将不会出现在安全命名空间中，从而产生不可信的查询响应。如果密钥泄露，客户端可以删除泄露的信息，或者使用“紧急”属性通过EPP命令更新委派信息。
Operational scenarios requiring quick removal of a secure domain delegation can be implemented using a two-step process. First, security credentials can be removed using an "urgent" update as just described. The domain can then be removed from the parent zone by changing the status of the domain to either of the EPP "clientHold" or "serverHold" domain status values. The domain can also be removed
需要快速删除安全域委派的操作场景可以使用两步流程实现。首先，如前所述，可以使用“紧急”更新删除安全凭据。然后，通过将域的状态更改为EPP“clientHold”或“serverHold”域状态值之一，可以将域从父区域中删除。也可以删除该域
from the zone using the EPP <delete> command, but this is a more drastic step that needs to be considered carefully before use.
使用EPP<delete>命令从区域中删除，但这是一个更激烈的步骤，在使用前需要仔细考虑。
Data validity checking and Delegation Signer record creation at the server require computational resources. A purposeful or inadvertent denial-of-service attack is possible if a client requests some number of update operations that exceed a server's processing capabilities. Server operators SHOULD take steps to manage command load and command processing requirements to minimize the risk of a denial-of-service attack.
服务器上的数据有效性检查和委托签名者记录创建需要计算资源。如果客户端请求的更新操作数量超过服务器的处理能力，则可能会发生故意或无意的拒绝服务攻击。服务器操作员应采取措施管理命令负载和命令处理要求，以最大限度地降低拒绝服务攻击的风险。
The signature lifetime values provided by clients are requests that can be rejected. Blind acceptance by a server operator can have an adverse impact on a server's processing capabilities. Server operators SHOULD seriously consider adopting implementation rules to limit the range of acceptable signature lifetime values to counter potential adverse situations.
客户端提供的签名生存期值是可以拒绝的请求。服务器操作员的盲目接受可能会对服务器的处理能力产生不利影响。服务器操作员应该认真考虑采用执行规则来限制可接受的签名生命期的范围，以应对潜在的不利情况。
The authors would like to thank the following people who have provided significant contributions to the development of this document:
作者要感谢为本文件的编写做出重大贡献的以下人员：
David Blacka, Howard Eland, Patrik Faltstrom, Olafur Gudmundsson, Bernie Hoeneisen, Ed Lewis, Klaus Malorny, Alexander Mayrhofer, Patrick Mevzek, David Smith, Andrew Sullivan, and Srikanth Veeramachaneni.
大卫·布莱克、霍华德·埃兰、帕特里克·法尔茨特罗姆、奥拉弗尔·古德蒙德森、伯尼·霍内森、埃德·刘易斯、克劳斯·马洛尼、亚历山大·梅尔霍夫、帕特里克·梅泽克、大卫·史密斯、安德鲁·沙利文和斯里坎特·维拉马查内尼。
This document replaces RFC 4310 [RFC4310]. Please see the Acknowledgements section in that RFC for additional acknowledgements.
本文件取代RFC 4310[RFC4310]。请参阅该RFC中的确认部分，以了解更多确认。
This document incorporates feedback from early implementers on the PROVREG mailing list and users.
本文档包含了早期实施者对PROVREG邮件列表和用户的反馈。
[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月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.
[RFC3757]Kolkman，O.，Schlyter，J.，和E.Lewis，“域名系统密钥（DNSKEY）资源记录（RR）安全入口点（SEP）标志”，RFC 3757，2004年4月。
[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月。
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009.
[RFC5730]Hollenbeck，S.，“可扩展资源调配协议（EPP）”，STD 69，RFC 5730，2009年8月。
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, August 2009.
[RFC5731]Hollenbeck，S.，“可扩展供应协议（EPP）域名映射”，STD 69，RFC 57312009年8月。
[W3C.REC-xml-20001006] Maler, E., Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[W3C.REC-xml-20001006]Maler，E.，Sperberg McQueen，C.，Bray，T.，和J.Paoli，“可扩展标记语言（xml）1.0（第二版）”，万维网联盟第一版REC-xml-20001006，2000年10月<http://www.w3.org/TR/2000/REC-xml-20001006>.
[W3C.REC-xmlschema-1-20010502] Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures", World Wide Web Consortium FirstEdition REC-xmlschema-1-20010502, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502>.
[W3C.REC-xmlschema-1-20010502]Beech，D.，Thompson，H.，Mendelsohn，N.，和M.Maloney，“XML模式第1部分：结构”，万维网联盟第一版REC-xmlschema-1-20010502，2001年5月<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502>.
[W3C.REC-xmlschema-2-20010502] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", World Wide Web Consortium FirstEdition REC-xmlschema-2- 20010502, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502>.
[W3C.REC-xmlschema-2-20010502]Malhotra，A.和P.Biron，“XML模式第2部分：数据类型”，万维网联盟第一版REC-xmlschema-2-20010502，2001年5月<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781]Hoffman，P.和F.Yergeau，“UTF-16，ISO 10646编码”，RFC 2781，2000年2月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[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月。
[RFC4310] Hollenbeck, S., "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4310, December 2005.
[RFC4310]Hollenbeck，S.，“可扩展供应协议（EPP）的域名系统（DNS）安全扩展映射”，RFC 4310，2005年12月。
1. Added the motivation in obsoleting RFC 4310 [RFC4310] to Section 1.
1. 在第1节中增加了淘汰RFC 4310[RFC4310]的动机。
2. Updated Section 1 to add an explicit statement about deprecation of RFC 4310.
2. 更新了第1节，添加了一条关于RFC 4310弃用的明确声明。
3. Added secDNS-1.0 and secDNS-1.1 abbreviation definitions in Section 1.1.
3. 在第1.1节中增加了secDNS-1.0和secDNS-1.1缩写定义。
4. Updated "Data validity checking at the server..." to "Data validity checking and Delegation Signer record creation at the server..." in Section 9.
4. 将第9节中的“服务器上的数据有效性检查…”更新为“服务器上的数据有效性检查和委托签名人记录创建…”。
5. Added Section 2.
5. 增加了第2节。
6. Updated the second paragraph of Section 7 to clarify that the internationalization features of [RFC5731] are followed.
6. 更新了第7节第二段，以澄清遵循[RFC5731]的国际化特征。
7. Moved <secDNS:rem> prior to <secDNS:add> to conform to the EPP order semantics for supporting <secDNS:all> with <secDNS:rem> to remove all data, and for supporting the replace semantics previously supported by <secDNS:chg>.
7. 将<secDNS:rem>移动到<secDNS:add>之前，以符合EPP订单语义，支持<secDNS:all>和<secDNS:rem>删除所有数据，并支持先前由<secDNS:chg>支持的替换语义。
8. Added support for the use of the <secDNS:all> boolean element under <secDNS:rem> to remove all DS or key data in place of using <secDNS:chg/>.
8. 添加了对使用<secDNS:rem>下的<secDNS:all>布尔元素删除所有DS或密钥数据的支持，以代替使用<secDNS:chg/>。
9. Updated <secDNS:add>, <secDNS:rem>, and <secDNS:chg> to function in a consistent way to the other EPP RFCs.
9. 更新了<secDNS:add>、<secDNS:rem>和<secDNS:chg>以与其他EPP RFC一致的方式运行。
10. Removed support for <secDNS:rem> using just <secDNS:keyTag>.
10. 仅使用<secDNS:keyTag>删除了对<secDNS:rem>的支持。
11. Moved the <secDNS:maxSigLife> element out of the <secDNS:dsData> and <secDNS:keyData> elements and directly under the <secDNS: create> element, under the <secDNS:chg> element of the <secDNS: update> element, and under the <secDNS:infData> element. Section 3.3 element was updated to better describe the <secDNS: maxSigLife> element, and references to the <secDNS:maxSigLife> element were updated throughout the document.
11. 将<secDNS:maxSigLife>元素移出<secDNS:dsData>和<secDNS:keyData>元素，并直接移动到<secDNS:create>元素、<secDNS:update>元素的<secDNS:chg>元素和<secDNS:infData>元素下。更新了第3.3节元素以更好地描述<secDNS:maxSigLife>元素，并且在整个文档中更新了对<secDNS:maxSigLife>元素的引用。
12. Replaced references to urn:ietf:params:xml:schema:secDNS-1.0 with urn:ietf:params:xml:schema:secDNS-1.1, and replaced "Two URI assignments have been completed by the IANA" with "Two URI assignments have been completed by the IANA" in Section 8.
12. 将对urn:ietf:params:xml:schema:secDNS-1.0的引用替换为urn:ietf:params:xml:schema:secDNS-1.1，并将第8节中的“IANA已完成两个URI分配”替换为“IANA已完成两个URI分配”。
13. Added "The <secDNS:keyTag> element is represented as an unsignedShort [W3C.REC-xmlschema-2-20010502]" in Section 4.1.
13. 在第4.1节中添加了“将<secDNS:keyTag>元素表示为无符号短[W3C.REC-xmlschema-2-20010502]”。
14. Added "The <secDNS:digest> element is represented as a hexBinary [W3C.REC-xmlschema-2-20010502]" in Section 4.1.
14. 在第4.1节中添加了“将<secDNS:digest>元素表示为十六进制二进制[W3C.REC-xmlschema-2-20010502]”。
15. Added "The <secDNS:pubKey> element is represented as a base64Binary [W3C.REC-xmlschema-2-20010502] with a minimum length of 1" in Section 4.2.
15. 在第4.2节中添加了“将<secDNS:pubKey>元素表示为base64Binary[W3C.REC-xmlschema-2-20010502]，最小长度为1”。
16. Combined "the command MUST contain an <extension> element" with the following sentence in Section 5.2.1 and Section 5.2.5.
16. 将“命令必须包含<extension>元素”与第5.2.1节和第5.2.5节中的以下句子组合在一起。
17. Added sentence "If the server does not support the <secDNS: maxSigLife> element, a 2102 error MUST be returned" to Section 5.2.1 and Section 5.2.5.
17. 在第5.2.1节和第5.2.5节中添加了一句“如果服务器不支持<secDNS:maxSigLife>元素，则必须返回2102错误”。
18. Added sentence "This document replaces RFC 4310. Please see the Acknowledgements section in that RFC for additional acknowledgements" in Section 10.
18. 增加了第10节中的“本文件取代RFC 4310。有关其他确认，请参阅该RFC中的确认部分”。
19. Added "This document incorporates feedback from implementers on the PROVREG mail list and users" as well as "This document obsoletes RFC 4310" in the Abstract.
19. 在摘要中增加了“本文件包含来自PROVREG邮件列表和用户实施者的反馈”以及“本文件淘汰RFC 4310”。
20. Removed all references to xsi:schemaLocation to be consistent with the other EPP RFCs.
20. 删除了所有对xsi:schemaLocation的引用，以与其他EPP RFC保持一致。
21. Added the "DS Data Interface and Key Data Interface" section.
21. 增加了“DS数据接口和关键数据接口”部分。
22. Moved the "create, add, remove, and replace Delegation Signer (DS) information" paragraph from the "Object Attributes" section to the "DS Data Interface" section.
22. 将“创建、添加、删除和替换委托签名人（DS）信息”段落从“对象属性”部分移至“DS数据接口”部分。
23. Replaced the element descriptions in the "EPP <info> Command" section with a reference to the <secDNS:dsData> and <secDNS: keyData> elements described in the "DS Data Interface" and "Key Data Interface" sections, respectively.
23. 将“EPP<info>命令”部分中的元素描述替换为分别在“DS数据接口”和“密钥数据接口”部分中描述的<secDNS:dsData>和<secDNS:keyData>元素。
24. Updated the "EPP <info> Command" section examples to include both the DS Data Interface and the Key Data Interface.
24. 更新了“EPP<info>命令”部分示例，以包括DS数据接口和关键数据接口。
25. Updated the "EPP <create> Command" section to refer to both the use of <secDNS:dsData> and <secDNS:keyData> described in the "DS Data Interface" and "Key Data Interface" sections, respectively.
25. 更新了“EPP<create>命令”部分，以分别引用“DS数据接口”和“密钥数据接口”部分中描述的<secDNS:dsData>和<secDNS:keyData>的使用。
26. Updated the "EPP <create> Command" section examples to include both the DS Data Interface and the Key Data Interface.
26. 更新了“EPP<create>命令”部分示例，以包括DS数据接口和关键数据接口。
27. Updated the "EPP <update> Command" section to describe the use of <secDNS:add>, <secDNS:rem>, and <secDNS:chg> together.
27. 更新了“EPP<update>命令”部分，描述了<secDNS:add>、<secDNS:rem>和<secDNS:chg>的用法。
28. Updated the "EPP <update> Command" section examples to include both the DS Data Interface and the Key Data Interface. Also included additional examples of adding and removing DS data or key data.
28. 更新了“EPP<update>Command”部分示例，以包括DS数据接口和关键数据接口。还包括添加和删除DS数据或关键数据的其他示例。
29. Updated the "Formal Syntax" section with the updated XML schema.
29. 使用更新的XML模式更新了“正式语法”部分。
30. Updated the Acknowledgements section with a new list of contributors.
30. 用新的贡献者列表更新了确认部分。
31. Replaced references to RFC 3730 with references to RFC 5730.
31. 将参考RFC 3730替换为参考RFC 5730。
32. Replaced references to RFC 3731 with references to RFC 5731.
32. 将对RFC 3731的引用替换为对RFC 5731的引用。
33. Added clarification on when the extension MUST be included for each of the commands and responses (<secDNS:create>, <secDNS: update>, <secDNS:infData>).
33. 添加了关于每个命令和响应何时必须包含扩展名的说明（<secDNS:create>，<secDNS:update>，<secDNS:infData>）。
34. Changed "In addition, the EPP <extension> element MUST contain a child <secDNS:infData> element" to "In addition, the EPP <extension> element SHOULD contain a child <secDNS:infData> element" and added "and based on server policy".
34. 将“此外，EPP<extension>元素必须包含子<secDNS:infData>元素”更改为“此外，EPP<extension>元素应包含子<secDNS:infData>元素”，并添加了“并基于服务器策略”。
Authors' Addresses
作者地址
James Gould VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
James Gould VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: jgould@verisign.com
EMail: jgould@verisign.com
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: shollenbeck@verisign.com
EMail: shollenbeck@verisign.com