]> ICANN

gavin.brown@icann.org

Operations REGEXT Working Group Internet-Draft This document specifies an extension to the Domain Mapping for the Extensible Provisioning Protocol (EPP) which allows EPP clients to enable and disable automatic DNSSEC maintenance carried out by the server. It also describes how the maintenance state of a domain can be included in RDAP responses. The source for this draft, and an issue tracker, may can be found at .

Introduction , , and automate DNSSEC () delegation 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 these protocols. Section 6.1 of states that domain name registries (see Section 9 of ) 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 DS automation to take place. This document specifies an extension to the Domain Mapping for the Extensible Provisioning Protocol (EPP) which allows the sponsoring client of a domain object to specify whether or not DS automation should be carried out by the server. It also describes how the automation state of domain objects should be represented in 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. 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 ds-automation in ds-automation: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 a new element, <ds-automation:automation>, to the domain name mapping. This element has a single boolean "enabled" attribute, whose default value is "true". If the value of the "enabled" attribute is "true" or "1", then the server MAY perform DS automation for the domain. If the value of the "enabled" attribute is "false" or "0", then the server MUST NOT perform DS automation for the domain.

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 <ds-automation:infData> element that identifies the extension namespace if the domain object has data associated with this extension and based on server policy. The <ds-automation:infData> element MUST contain a single <ds-automation:automation> element which represents the current configuration status for the domain. 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: 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 <ds-automation:create> element that identifies the extension namespace if the client wants to associate data defined in this extension to the domain object. The <ds-automation:create> element MUST contain a single <ds-automation:automation> element which represents the desired configuration status 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: ]]>

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 <ds-automation:update> element that identifies the extension namespace if the client wants to update the domain object with data defined in this extension. The <ds-automation:update> element MUST contain a single <ds-automation:automation> element which represents the desired configuration status for the domain. Example domain <update> command:

C: C: C: C: C: example.com 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" property of domain responses to allow interested parties to determine whether DS automation is enabled or disabled for a given domain name. Domains for which DS automation is enabled (ie the value of the "enabled" property is "true" or "1") MUST have the "DS automation enabled" value in their "status" property. Domains for which DS automation is disabled (ie the value of the "enabled" property is "false" or "0") MUST have the "DS automation disabled" value in their "status" property. These two status values will be registered in (see ). These two values 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:ds-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:ds-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: 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" property, irrespective of the presence (or absence) of EPP status codes such as serverUpdateProhibited. When the "enabled" property is "false" or "0", the sponsoring client MAY perform DS automation itself, and submit any necessary changes to the DNSSEC configuration of the domain using an <update> command extended by . When the "enabled" property is "true" or "1", the sponsoring client SHOULD NOT perform DS automation, for the reasons outlined in Section 7.2.3 of . It is impractical for EPP clients with large portfolios of domain names that wish to deploy (or decommission) DS automation themselves to submit <update> commands to enable or disable DS 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 DS automation for all domains under their sponsorship in a single operation.

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

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.

deSEC Enabling support for automatic acceptance of DNSSEC Delegation Signer (DS) parameters from the Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error and success reporting, and multi-party issues such as concurrent updates. This document describes recommendations about how these points are best addressed in practice. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK] The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. W3C Recommendation 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. [STANDARDS-TRACK] This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent. RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records). It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document introduces an in-band method for DNS operators to publish arbitrary information about the zones for which they are authoritative, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document establishes the DS enrollment method described in Section 4 of this document as the preferred method over those from Section 3 of RFC 8078. It also updates RFC 7344. CENTR