Delegation Maintenance Automation Status Extension for the Extensible Provisioning Protocol (EPP)

Introduction automates the maintenance of delegation information records, typically NS records and any associated glue records (see Section 7 of ) through the publication of CSYNC records in the child zone which indicate the delegation's desired delegation information ("NS automation"). Similarly, , , and automate DNSSEC () trust maintenance by having the child publish Child DS (CDS) and/or Child DNSKEY (CDNSKEY) records which indicate the delegation's desired DNSSEC parameters ("DS automation"). provides operational recommendations for parent operators wishing to deploy DS automation. Section 6.1 of states that parent zone operators running under the registrant-registrar-registry (RRR) model and using the Extensible Provisioning Protocol (EPP, ) MUST NOT suspend DS automation solely on the basis of the presence of the serverUpdateProhibited status code (defined in Section 2.3 of ). This status code causes any request to modify the domain name (including DNSSEC information as per ) to be rejected by the EPP server. The most common use of the serverUpdateProhibited status is as part of a "registry lock" (see ), a security measure designed to mitigate the risk of (a) a compromised customer account at the sponsoring registrar (see Section 9 of ), or (b) a compromised or malicious registrar. For domains which have a registry lock, it is not always the case that the registrant of the domain will want either DS automation or NS automation to take place. This document specifies an extension to the Domain Mapping for EPP which allows the sponsoring client of a domain object to specify whether or not DS automation and/or NS automation ("delegation automation") should be carried out by the server. It also describes how the delegation automation state of domain objects should be represented in Registration Data Access Protocol (RDAP, ) responses.

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when, and only when, they appear in all capitals, as shown here. The term "delegation automation" refers to either or both of "DS automation" and "NS automation", as described above. An EPP server may choose to implement either or both of these protocols, in accordance with its own policy. In this document's examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in these examples are provided only to illustrate element relationships and are not required features of this protocol. A protocol client that is authorized to manage an existing object is described as a "sponsoring" client throughout this document. XML is case sensitive. Unless stated otherwise, the XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects. The XML namespace prefixes used in these examples (such as the string automation in automation:ds-automation) are solely for illustrative purposes. A conforming implementation MUST NOT require the use of these or any other specific namespace prefixes. In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes , the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'. Implementations MUST support both styles of lexical representation.

EPP Extension Elements This specification adds two new elements, <automation:nsAutomation> and <automation:dsAutomation>, to the domain name mapping (). These elements both have a single boolean "enabled" attribute. If the value of the "enabled" attribute of the <automation:dsAutomation> element is "true" or "1", then the server MAY perform DS automation for the domain. If the value of the "enabled" attribute of the <automation:dsAutomation> element is "false" or "0", then the server MUST NOT perform DS automation for the domain. Similarly: If the value of the "enabled" attribute of the <automation:ns-automation> element is "true" or "1", then the server MAY perform NS automation for the domain. If the value of the "enabled" attribute of the <automation:ns-automation> element is "false" or "0", then the server MUST NOT perform NS automation for the domain. The <automation:nsAutomation> is only used when the EPP server supports NS automation, and the <automation:dsAutomation> element iso nly used when the EPP server supports NS automation.

EPP Command Mapping

EPP Query Commands

EPP <info> Command This extension does not add any elements to the EPP <info> command described in the EPP domain mapping (). However, additional elements are defined for the <info> response. When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in the EPP domain mapping (). In addition, the EPP <extension> element MUST contain a child <automation:infData> element that identifies the extension namespace. The <automation:infData> element MUST contain at least one of the following child elements: a <automation:nsAutomation> element, if the server supports NS automation. a <automation:dsAutomation> element, if the server supports DS automation. Example domain <info> response:

S: S: S: S: OK S: S: S: S: example.com S: EXAMPLE1-REP S: S: S: ns1.example.net S: ns2.example.org S: S: ClientX S: S: S: S: S: S: S: S: S: S: 54322-XYZ S: S: S: ]]>

EPP Transform Commands

EPP <create> Command This extension defines additional elements for the EPP <create> command described in the EPP domain mapping . No additional elements are defined for the EPP <create> response. 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 (), the command MUST contain an <extension> element, and the <extension> element MUST contain a child <automation:create> element that identifies the extension namespace if the client wants to associate data defined in this extension to the domain object. The <automation:create> element MUST contain at least one of the following child elements: a <automation:nsAutomation> element, if the server supports NS automation. If the server does not support NS automation, then a <create> command containing this element MUST be rejected with a 2102 ("Unimplemented option") response. If omitted, the default NS automation policy (if applicable) MUST be configured for the domain. a <automation:dsAutomation> element, if the server supports DS automation. If the server does not support DS automation, then a <create> command containing this element MUST be rejected with a 2102 ("Unimplemented option") response. If omitted, the default DS automation policy (if applicable) MUST be configured for the domain. Example domain <create> command:

C: C: C: C: C: example.com C: 1 C: C: ns1.example.net C: ns2.example.org C: C: C: C: C: C: C: C: C: C: C: C: C: C: ]]>

EPP <update> Command This extension defines additional elements for the EPP <update> command described in the EPP domain mapping . No additional elements are defined for the EPP <update> response. 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 <automation:update> element that identifies the extension namespace if the client wants to update the domain object with data defined in this extension. The <automation:update> element MUST contain at least one of the following child elements: a <automation:nsAutomation> element, if the server supports NS automation. If the server does not support NS automation, then an <update> command containing this element MUST be rejected with a 2102 ("Unimplemented option") response. a <automation:dsAutomation> element, if the server supports DS automation. If the server does not support DS automation, then an <update> command containing this element MUST be rejected with a 2102 ("Unimplemented option") response. Example domain <update> command:

C: C: C: C: C: example.com C: C: C: C: C: C: C: C: C: C: ]]>

RDAP Status Mapping Operators of EPP servers who also operate an RDAP server can include an entry in the "status" member of domain responses to allow interested parties to determine whether delegation automation is enabled or disabled for a given domain name. A domain for which NS automation is enabled MUST have the "NS automation enabled" value in its "status" member. A domain for which NS automation is disabled MUST have the "NS automation disabled" value in its "status" member. A domain for which DS automation is enabled MUST have the "DS automation enabled" value in its "status" member. A domain for which DS automation is disabled MUST have the "DS automation disabled" value in its "status" member. These two status values will be registered in (see ). The DS automation enabled and DS automation disabled values MUST NOT both be present at the same time. Similarly, NS automation enabled and NS automation disabled MUST NOT both be present at the same time.

Formal Syntax (XML) 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.

DS Automation Status Extension for the Extensible Provisioning Protocol (EPP) END ]]>

IANA Considerations

XML Namespace This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in . The following URI assignments are requested of IANA: Registration for the TTL namespace: URI: urn:ietf:params:xml:ns:epp:delegation-maintenance-automation-1.0 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification. Registration for the TTL XML schema: URI: urn:ietf:params:xml:schema:epp:delegation-maintenance-automation-1.0 Registrant Contact: IESG XML: See of this document.

EPP Extension Registry IANA is requested to register the EPP extension described in this document in , described in . The details of the registration are as follows: Name of Extension: DS Automation Status Extension for the Extensible Provisioning Protocol (EPP) Document Status: Standards Track Reference: this document Registrant: IESG TLDs: Any IPR Disclosure: None Status: Active Notes: None

RDAP JSON Values IANA is requested to list this document as a reference for and register the following values: Value: NS automation enabled Type: status Description: The server MAY perform NS automation for this domain. Registrant: IETF Contact Information: iesg@ietf.org Value: NS automation disabled Type: status Description: The server MUST NOT perform NS automation for this domain. Registrant: IETF Contact Information: iesg@ietf.org Reference: this document Value: DS automation enabled Type: status Description: The server MAY perform DS automation for this domain. Registrant: IETF Contact Information: iesg@ietf.org Value: DS automation disabled Type: status Description: The server MUST NOT perform DS automation for this domain. Registrant: IETF Contact Information: iesg@ietf.org Reference: this document

Security Considerations The mapping extensions described in this document do not provide any security services beyond those described by EPP (), the EPP domain name mapping (), and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well. 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 . 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. 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 using a strong authentication mechanism.

Operational Considerations Server operators MUST obey the value for the "enabled" attribute of <automation:nsAutomation> and <automation:dsAutomation> elements, irrespective of the presence (or absence) of EPP status codes such as serverUpdateProhibited. When the "enabled" attribute is "false" or "0", the sponsoring client MAY perform NS/DS automation itself, and submit any necessary changes to the DNSSEC configuration of the domain using an <update> command (extended by as needed). When the "enabled" attribute is "true" or "1", the sponsoring client SHOULD NOT perform NS.DS automation, for the reasons outlined in Section 7.2.3 of . EPP clients may use the presence or absence of these elements in <info> responses to determine whether NS/DS automation are supported by the server, but server operators SHOULD document their operational policy and provide this to client operators during onboarding. It is impractical for EPP clients with large portfolios of domain names that wish to deploy (or decommission) delegation automation themselves to submit <update> commands to enable or disable delegation automation for all domains under their sponsorship. It is RECOMMENDED that server operators provide an out-of-band method for clients to enable or disable delegation automation for all domains under their sponsorship in a single operation.

Change Log This section is to be removed before publishing as an RFC.

v01 Made the extension elements optional according to server policy. Removed the default attribute value is it may be misleading (implying an expected default policy). Updated to cover NS automation as well as DS automation (thanks Peter Thomassen). This includes a namespace URI update.

v00 Initial version based on conversations within ICANN GDS Technical Services, and Peter Thomassen.

Acknowledgements The author wishes to thank the following for their constructive feedback and advice during the development of this document: Andy Newton, Gustavo Lozano, Francisco Arias, Peter Thomassen.