| Internet-Draft | EPP DS Automation Extension | June 2026 |
| Brown | Expires 27 December 2026 | [Page] |
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 https://github.com/gbxyz/epp-ds-automation-extension.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC7344], [RFC8078], and [RFC9615] automate DNSSEC ([RFC9364]) 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"). [I-D.ietf-dnsop-ds-automation] provides operational recommendations for parent operators wishing to deploy these protocols.¶
Section 6.1 of [I-D.ietf-dnsop-ds-automation] states that domain name
registries (see Section 9 of [RFC9499]) MUST NOT suspend DS automation
solely on the basis of the presence of the serverUpdateProhibited
status code (defined in Section 2.3 of [RFC5731]). This status code causes
any request to modify the domain name (including DNSSEC information as per
[RFC5910]) to be rejected by the EPP server.¶
The most common use of the serverUpdateProhibited status is as part of a
"registry lock" (see [CENTR-REGISTRY-LOCK]), a security measure designed to
mitigate the risk of (a) a compromised customer account at the sponsoring
registrar (see Section 9 of [RFC9499]), 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) [RFC5730] [RFC5731] 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 ([STD95]) responses.¶
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 [BCP14] RFC2119 RFC8174 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
[XSD-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.¶
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".¶
<info> Command
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.¶
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 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: <?xml version="1.0"?> S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>OK</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:ns> S: <domain:hostObj>ns1.example.net</domain:hostObj> S: <domain:hostObj>ns2.example.org</domain:hostObj> S: </domain:ns> S: <domain:clID>ClientX</domain:clID> S: </domain:infData> S: </resData> S: <extension> S: <ds-automation:infData S: xmlns:ds-automation="urn:ietf:params:xml:ns:ds-automation-1.0"> S: <ds-automation:automation enabled="true"/> S: </ds-automation:infData> S: </extension> S: <trID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S: </epp>¶
<create> Command
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.¶
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
<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: <?xml version="1.0" encoding="UTF-8" standalone="no"?> C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> 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">1</domain:period> C: <domain:ns> C: <domain:hostObj>ns1.example.net</domain:hostObj> C: <domain:hostObj>ns2.example.org</domain:hostObj> C: </domain:ns> C: <domain:authInfo> C: <domain:pw/> C: </domain:authInfo> C: </domain:create> C: </create> C: <extension> C: <ds-automation:create C: xmlns:ds-automation="urn:ietf:params:xml:ns:ds-automation-1.0"> C: <ds-automation:automation enabled="true"/> C: </ds-automation:create> C: </extension> C: </command> C: </epp>¶
<update> Command
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.¶
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: <?xml version="1.0" encoding="UTF-8" standalone="no"?> C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> 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: <ds-automation:update C: xmlns:ds-automation="urn:ietf:params:xml:ns:ds-automation-1.0"> C: <ds-automation:automation enabled="false"/> C: </ds-automation:update> C: </extension> C: </command> C: </epp>¶
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 [RDAP-JSON-VALUES] (see Section 6.3).¶
These two values MUST NOT both be present at the same time.¶
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.¶
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ds-automation="urn:ietf:params:xml:ns:ds-automation-1.0"
targetNamespace="urn:ietf:params:xml:ns:ds-automation-1.0"
elementFormDefault="qualified">
<annotation>
<documentation>
DS Automation Status Extension for the
Extensible Provisioning Protocol (EPP)
</documentation>
</annotation>
<!--
Child elements found in EPP commands.
-->
<element name="infData" type="ds-automation:infDataType"/>
<element name="create" type="ds-automation:createType"/>
<element name="update" type="ds-automation:updateType"/>
<complexType name="automationType">
<attribute name="enabled" type="boolean" default="true"/>
</complexType>
<complexType name="infDataType">
<sequence>
<element name="automation"
type="ds-automation:automationType"/>
</sequence>
</complexType>
<complexType name="createType">
<sequence>
<element name="automation"
type="ds-automation:automationType"/>
</sequence>
</complexType>
<complexType name="updateType">
<sequence>
<element name="automation"
type="ds-automation:automationType"/>
</sequence>
</complexType>
</schema>
END
¶
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. 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¶
IANA is requested to register the EPP extension described in this document in [EPP-EXTENSIONS], described in [RFC7451]. 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¶
IANA is requested to list this document as a reference for [RDAP-JSON-VALUES] 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¶
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.¶
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 [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.¶
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.¶
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
[RFC5910].¶
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 [I-D.ietf-dnsop-ds-automation].¶
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.¶
This section is to be removed before publishing as an RFC.¶
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.¶