Internet-Draft EPP Delegation Maintenance Automation Ex July 2026
Brown Expires 4 January 2027 [Page]
Workgroup:
REGEXT Working Group
Internet-Draft:
draft-brown-epp-delegation-automation-extension-00
Published:
Intended Status:
Standards Track
Expires:
Author:
G. Brown
ICANN

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

Abstract

This document specifies an extension to the Domain Mapping for the Extensible Provisioning Protocol (EPP) which allows EPP clients to enable and disable automatic delegation maintenance carried out by the server. It also describes how the maintenance automation 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.

Status of This Memo

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 4 January 2027.

▲

Table of Contents

1. Introduction

[RFC7477] automates the maintenance of delegation information records, typically NS records and any associated glue records (see Section 7 of [RFC9499]) through the publication of CSYNC records in the child zone which indicate the delegation's desired delegation information ("NS automation").

Similarly, [RFC7344], [RFC8078], and [RFC9615] automate DNSSEC ([RFC9364]) 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 DS automation.

Section 6.1 of [I-D.ietf-dnsop-ds-automation] states that parent zone operators running under the registrant-registrar-registry (RRR) model and using the Extensible Provisioning Protocol (EPP, [STD69]) 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 either DS automation or NS automation to take place.

This document specifies an extension to the Domain Mapping for EPP RFC5731 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, [STD95]) responses.

1.1. 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 [BCP14] RFC2119 RFC8174 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 [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.

2. EPP Extension Elements

This specification adds two new elements, <automation:nsAutomation> and <automation:dsAutomation>, to the domain name mapping (RFC5731). These elements both have a single boolean "enabled" attribute.

  1. 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.

  2. 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:

  1. 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.

  2. 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.

3. EPP Command Mapping

3.1. EPP Query Commands

3.1.1. EPP <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 <automation:infData> element that identifies the extension namespace.

The <automation:infData> element MUST contain at least one of the following child elements:

  1. a <automation:nsAutomation> element, if the server supports NS automation.

  2. a <automation:dsAutomation> element, if the server supports DS automation.

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:       <automation:create
S:         xmlns:automation="urn:ietf:params:xml:ns:epp:delegation-maintenance-automation-1.0">
S:         <automation:nsAutomation enabled="false"/>
S:         <automation:dsAutomation enabled="true"/>
S:       </automation:create>
S:     </extension>
S:     <trID>
S:       <svTRID>54322-XYZ</svTRID>
S:     </trID>
S:   </response>
S: </epp>

3.2. EPP Transform Commands

3.2.1. 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 <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:

  1. 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.

  2. 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: <?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:       <automation:create
C:         xmlns:automation="urn:ietf:params:xml:ns:epp:delegation-maintenance-automation-1.0">
C:         <automation:nsAutomation enabled="false"/>
C:         <automation:dsAutomation enabled="true"/>
C:       </automation:create>
C:     </extension>
C:   </command>
C: </epp>

3.2.2. 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 <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:

  1. 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.

  2. 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: <?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:       <automation:create
C:         xmlns:automation="urn:ietf:params:xml:ns:epp:delegation-maintenance-automation-1.0">
C:         <automation:nsAutomation enabled="true"/>
C:         <automation:dsAutomation enabled="false"/>
C:       </automation:create>
C:     </extension>
C:   </command>
C: </epp>

4. 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.

  1. A domain for which NS automation is enabled MUST have the "NS automation enabled" value in its "status" member.

  2. A domain for which NS automation is disabled MUST have the "NS automation disabled" value in its "status" member.

  3. A domain for which DS automation is enabled MUST have the "DS automation enabled" value in its "status" member.

  4. 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 [RDAP-JSON-VALUES] (see Section 6.3).

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.

5. 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.

BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema
  xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:automation="urn:ietf:params:xml:ns:epp:delegation-maintenance-automation-1.0"
  targetNamespace="urn:ietf:params:xml:ns:epp:delegation-maintenance-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="automation:infDataType"/>
  <element name="create" type="automation:createType"/>
  <element name="update" type="automation:updateType"/>

  <complexType name="automationType">
    <attribute name="enabled"
      type="boolean"
      use="required"/>
  </complexType>

  <complexType name="infDataType">
    <sequence>
      <element name="nsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
      <element name="dsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="createType">
    <sequence>
      <element name="nsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
      <element name="dsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="updateType">
    <sequence>
      <element name="nsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
      <element name="dsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
    </sequence>
  </complexType>
</schema>
END

6. IANA Considerations

6.1. XML Namespace

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: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 Section 5 of this document.

6.2. EPP Extension Registry

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

6.3. RDAP JSON Values

IANA is requested to list this document as a reference for [RDAP-JSON-VALUES] 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

7. Security Considerations

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.

8. 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 [RFC5910] 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 [I-D.ietf-dnsop-ds-automation].

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.

9. Change Log

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

9.1. 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.

9.2. v00

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

10. 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.

11. References

11.1. Normative References

[BCP14]
Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[EPP-EXTENSIONS]
"Extensions for the Extensible Provisioning Protocol (EPP)", n.d., <https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml>.
[I-D.ietf-dnsop-ds-automation]
Sheng, S. and P. Thomassen, "Operational Recommendations for DNSSEC Delegation Signer (DS) Automation", Work in Progress, Internet-Draft, draft-ietf-dnsop-ds-automation-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ds-automation-09>.
[RDAP-JSON-VALUES]
"RDAP JSON Values", n.d., <https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml>.
[RFC3688]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/rfc/rfc3688>.
[RFC7451]
Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, , <https://www.rfc-editor.org/rfc/rfc7451>.
[STD69]
Internet Standard 69, <https://www.rfc-editor.org/info/std69>.
At the time of writing, this STD comprises the following:
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, , <https://www.rfc-editor.org/info/rfc5730>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, , <https://www.rfc-editor.org/info/rfc5731>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, , <https://www.rfc-editor.org/info/rfc5732>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, , <https://www.rfc-editor.org/info/rfc5733>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, , <https://www.rfc-editor.org/info/rfc5734>.
[STD95]
Internet Standard 95, <https://www.rfc-editor.org/info/std95>.
At the time of writing, this STD comprises the following:
Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", STD 95, RFC 7480, DOI 10.17487/RFC7480, , <https://www.rfc-editor.org/info/rfc7480>.
Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, DOI 10.17487/RFC7481, , <https://www.rfc-editor.org/info/rfc7481>.
Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, , <https://www.rfc-editor.org/info/rfc9082>.
Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, , <https://www.rfc-editor.org/info/rfc9083>.
Blanchet, M., "Finding the Authoritative Registration Data Access Protocol (RDAP) Service", STD 95, RFC 9224, DOI 10.17487/RFC9224, , <https://www.rfc-editor.org/info/rfc9224>.
[XSD-DATATYPES]
Biron, P. V. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, , <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.

11.2. Informative References

[CENTR-REGISTRY-LOCK]
"Models of registry lock for top-level domain registries", CENTR, , <https://centr.org/library/library/download/9799/6192/41.html>.
[RFC5910]
Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, DOI 10.17487/RFC5910, , <https://www.rfc-editor.org/rfc/rfc5910>.
[RFC7344]
Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, , <https://www.rfc-editor.org/rfc/rfc7344>.
[RFC7477]
Hardaker, W., "Child-to-Parent Synchronization in DNS", RFC 7477, DOI 10.17487/RFC7477, , <https://www.rfc-editor.org/rfc/rfc7477>.
[RFC8078]
Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, , <https://www.rfc-editor.org/rfc/rfc8078>.
[RFC9364]
Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, , <https://www.rfc-editor.org/rfc/rfc9364>.
[RFC9499]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, , <https://www.rfc-editor.org/rfc/rfc9499>.
[RFC9615]
Thomassen, P. and N. Wisiol, "Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator", RFC 9615, DOI 10.17487/RFC9615, , <https://www.rfc-editor.org/rfc/rfc9615>.

Author's Address

Gavin Brown
ICANN