REGEXT Working Group                                            G. Brown
Internet-Draft                                                     ICANN
Intended status: Standards Track                            25 June 2026
Expires: 27 December 2026


DS Automation Status Extension for the Extensible Provisioning Protocol
                                 (EPP)
               draft-brown-epp-ds-automation-extension-00

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

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 27 December 2026.

Copyright Notice

   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



Brown                   Expires 27 December 2026                [Page 1]

Internet-Draft         EPP DS Automation Extension             June 2026


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  EPP Extension Elements  . . . . . . . . . . . . . . . . . . .   4
   3.  EPP Command Mapping . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  EPP Query Commands  . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  EPP <info> Command  . . . . . . . . . . . . . . . . .   4
     3.2.  EPP Transform Commands  . . . . . . . . . . . . . . . . .   5
       3.2.1.  EPP <create> Command  . . . . . . . . . . . . . . . .   5
       3.2.2.  EPP <update> Command  . . . . . . . . . . . . . . . .   6
   4.  RDAP Status Mapping . . . . . . . . . . . . . . . . . . . . .   7
   5.  Formal Syntax (XML) . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  XML Namespace . . . . . . . . . . . . . . . . . . . . . .   9
     6.2.  EPP Extension Registry  . . . . . . . . . . . . . . . . .   9
     6.3.  RDAP JSON Values  . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Operational Considerations  . . . . . . . . . . . . . . . . .  11
   9.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  v00 . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

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




Brown                   Expires 27 December 2026                [Page 2]

Internet-Draft         EPP DS Automation Extension             June 2026


   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.

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.

   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.



Brown                   Expires 27 December 2026                [Page 3]

Internet-Draft         EPP DS Automation Extension             June 2026


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

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












Brown                   Expires 27 December 2026                [Page 4]

Internet-Draft         EPP DS Automation Extension             June 2026


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>

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



Brown                   Expires 27 December 2026                [Page 5]

Internet-Draft         EPP DS Automation Extension             June 2026


   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>

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





Brown                   Expires 27 December 2026                [Page 6]

Internet-Draft         EPP DS Automation Extension             June 2026


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>

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

   These two values *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.





Brown                   Expires 27 December 2026                [Page 7]

Internet-Draft         EPP DS Automation Extension             June 2026


   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



Brown                   Expires 27 December 2026                [Page 8]

Internet-Draft         EPP DS Automation Extension             June 2026


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





Brown                   Expires 27 December 2026                [Page 9]

Internet-Draft         EPP DS Automation Extension             June 2026


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



Brown                   Expires 27 December 2026               [Page 10]

Internet-Draft         EPP DS Automation Extension             June 2026


8.  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 [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.

9.  Change Log

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

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





Brown                   Expires 27 December 2026               [Page 11]

Internet-Draft         EPP DS Automation Extension             June 2026


              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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,
              May 2017, <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, 22 May 2026, <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, January 2004,
              <https://www.rfc-editor.org/rfc/rfc3688>.

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
              <https://www.rfc-editor.org/rfc/rfc5730>.

   [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Domain Name Mapping", STD 69, RFC 5731,
              DOI 10.17487/RFC5731, August 2009,
              <https://www.rfc-editor.org/rfc/rfc5731>.

   [RFC7451]  Hollenbeck, S., "Extension Registry for the Extensible
              Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
              February 2015, <https://www.rfc-editor.org/rfc/rfc7451>.

   [STD95]    Internet Standard 95,
              <https://www.rfc-editor.org/info/std95>.
              At the time of writing, this STD comprises the following:





Brown                   Expires 27 December 2026               [Page 12]

Internet-Draft         EPP DS Automation Extension             June 2026


              Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 7480, DOI 10.17487/RFC7480, March 2015,
              <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, March 2015,
              <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, June 2021,
              <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, June 2021,
              <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, March 2022,
              <https://www.rfc-editor.org/info/rfc9224>.

   [XSD-DATATYPES]
              Biron, P. V. and A. Malhotra, "XML Schema Part 2:
              Datatypes Second Edition", W3C Recommendation, October
              2004,
              <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, August 2020, <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, May 2010,
              <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, September 2014,
              <https://www.rfc-editor.org/rfc/rfc7344>.



Brown                   Expires 27 December 2026               [Page 13]

Internet-Draft         EPP DS Automation Extension             June 2026


   [RFC8078]  Gudmundsson, O. and P. Wouters, "Managing DS Records from
              the Parent via CDS/CDNSKEY", RFC 8078,
              DOI 10.17487/RFC8078, March 2017,
              <https://www.rfc-editor.org/rfc/rfc8078>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/rfc/rfc9364>.

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <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, July 2024,
              <https://www.rfc-editor.org/rfc/rfc9615>.

Author's Address

   Gavin Brown
   ICANN
   Email: gavin.brown@icann.org




























Brown                   Expires 27 December 2026               [Page 14]