| Internet-Draft | EPP DELEG Extension | September 2026 |
| Brown & Hoffman | Expires 2 April 2027 | [Page] |
This document describes an extension to the Extensible Provisioning Protocol ([STD69]) which allows clients to provision DELEG records for domain names.¶
This note is to be removed before publishing as an RFC.¶
The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/epp-deleg-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 2 April 2027.¶
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.¶
The Internet-Draft "Extensible Delegation for DNS" ([DELEG]) describes an enhanced method of delegation in the DNS to supplement the traditional NS record.¶
This document describes an extension to the EPP domain mapping (RFC5731) to allow EPP clients to provision DELEG records for domain names in an EPP server.¶
EPP provides mechanisms for extending the protocol by (a) adding new properties to existing object mappings and (b) definining new object mappings.
Although EPP supports two different models for traditional NS records (host attributes and host objects, as described in Section 1.12 of [RFC5731]),
this document only uses the former, and does not define a new object mapping for DELEG records because the DELEG specification itself implements many of the features that would otherwise require an object mapping.¶
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in 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, 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 examples (such as the string deleg in deleg:create) are solely for illustrative purposes.
A conforming implementation MUST NOT require the use of these or any other specific namespace prefixes.¶
This document defines a new element, <deleg:deleg>, which appears in query and transform commands for domain objects.¶
This element is a representation of a DELEG record in XML.
The <deleg:deleg> element correspond to the DelegInfos field of a DELEG record.
It contains one or more <deleg:param> child elements, which each represent the DelegInfo key=value pairs of the DELEG record.¶
A <deleg:param> element MUST have the "name" attribute which identifies the DelegInfoKey, and MAY contain a DelegInfoValue which contains the value in presentation format.
A <deleg:deleg> element MUST NOT contain two or more <deleg:param> elements with the same "name" attribute.¶
Examples of the <deleg:deleg> element with parameters which have values:¶
<deleg:deleg> <deleg:param name="server-ipv4">192.0.2.1</deleg:param> <deleg:param name="server-ipv6">2001:db8::1</deleg:param> </deleg:deleg>¶
<deleg:deleg> <deleg:param name="server-ipv4">192.0.2.1,192.0.2.53</deleg:param> </deleg:deleg>¶
<deleg:deleg>
<deleg:param name="server-name">
ns2.example.net.,ns3.example.org.</deleg:param>
</deleg:deleg>
¶
<deleg:deleg> <deleg:param name="secure-transport">adot</deleg:param> <deleg:param name="mandatory">secure-transport</deleg:param> </deleg:deleg>¶
Example of a <deleg:deleg> element with a parameter which has no value:¶
<deleg:deleg> <deleg:param name="no-do53"/> </deleg:deleg>¶
<info> command
This extension defines an additional element for EPP <info> responses for domain object.¶
When a server receives a domain or host <info> command from a client which included the extension namespace in the <svcExtension> element of the <login> command,
the response MAY contain an <extension> element,
which MAY contain a <deleg:infData> element.
This element MUST contain one or more <deleg:deleg> elements as described in Section 3.¶
Example <info> response:¶
S:<?xml version="1.0" encoding="utf-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</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:clID>ClientX</domain:clID> S: <domain:crID>ClientX</domain:crID> S: <domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate> S: <domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate> S: </domain:infData> S: </resData> S: <extension> S: <deleg:infData S: xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.02"> S: <deleg:deleg> S: <deleg:param name="server-ipv4">192.0.2.1</deleg:param> S: <deleg:param name="server-ipv6">2001:db8::1</deleg:param> S: </deleg:deleg> S: <deleg:deleg> S: <deleg:param name="server-name">ns2.example.net.,ns3.example.org.</deleg:param> S: </deleg:deleg> S: </deleg:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>¶
<create> command
This extension defines an additional element for EPP <create> commands for domain objects.¶
The <command> element of the <create> command frame MAY contain an <extension> element which MAY contain a <deleg:create> element.
This element MUST contain one or more <deleg:deleg> records as described in Section 3.¶
Example <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:authInfo> C: <domain:pw/> C: </domain:authInfo> C: </domain:create> C: </create> C: <extension> C: <deleg:create C: xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.02"> C: <deleg:deleg> C: <deleg:param name="server-ipv4">192.0.2.1</deleg:param> C: <deleg:param name="server-ipv6">2001:db8::1</deleg:param> C: </deleg:deleg> C: <deleg:deleg> C: <deleg:param name="server-name"> C: ns2.example.net.,ns3.example.org.</deleg:param> C: </deleg:deleg> C: </deleg:create> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>¶
<update> command
This extension defines an additional element for EPP <update> commands for domain objects.¶
The <command> element of the <create> command frame MAY contain an <extension> element which MAY contain a <deleg:update> element.¶
The <deleg:update> element has the following child elements:¶
<deleg:add> element, containing any <deleg:deleg> records to be added to the domain; and¶
<deleg:rem> element, which contains (1) any <deleg:deleg> records to be removed from the domain or (2) an empty <deleg:all/> element, indicating that all records should be removed.¶
Example <update> command, which removes one <deleg:deleg> record and adds another:¶
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: <deleg:update xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.02"> C: <deleg:add> C: <deleg:deleg> C: <deleg:param name="server-ipv4">192.0.2.2</deleg:param> C: <deleg:param name="server-ipv6">2001:db8::2</deleg:param> C: </deleg:deleg> C: </deleg:add> C: <deleg:rem> C: <deleg:deleg> C: <deleg:param name="server-ipv4">192.0.2.1</deleg:param> C: <deleg:param name="server-ipv6">2001:db8::1</deleg:param> C: </deleg:deleg> C: </deleg:rem> C: </deleg:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>¶
Example <update> command, which removes one <deleg:deleg> record but does not add any:¶
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: <deleg:update xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.02"> C: <deleg:rem> C: <deleg:deleg> C: <deleg:param name="server-ipv4">192.0.2.1</deleg:param> C: <deleg:param name="server-ipv6">2001:db8::1</deleg:param> C: </deleg:deleg> C: </deleg:rem> C: </deleg:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>¶
Example <update> command, which removes all <deleg:deleg> records but does not add any:¶
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: <deleg:update xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.02"> C: <deleg:rem> C: <deleg:all/> C: </deleg:rem> C: </deleg:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>¶
Example <update> command, which adds one <deleg:deleg> record but does not remove any:¶
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: <deleg:update xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.02"> C: <deleg:add> C: <deleg:deleg> C: <deleg:param name="server-ipv4">192.0.2.1</deleg:param> C: <deleg:param name="server-ipv6">2001:db8::1</deleg:param> C: </deleg:deleg> C: <deleg:deleg> C: <deleg:param name="server-name">ns2.example.net.,ns3.example.org.</deleg:param> C: </deleg:deleg> C: </deleg:add> C: </deleg:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>¶
DELEG and host objects/attributes
It is anticpated that most domains will need both DELEG and traditional NS records published in their parent zone for the foreseeable future.¶
Therefore, EPP servers SHOULD allow clients to configure domain names to have both DELEG records and host objects (RFC5732) or host attributes (see Section 1.1 of [RFC5731]).¶
Servers MUST reject commands which contain <deleg:param> elements whose "name" elements are unknown, or whose contents are syntactically invalid.¶
Both servers and clients MUST periodically update the list of registered DelegInfoKeys in the DELEG Delegation Information registry to ensure that newly-added values can be used.¶
Under the initial design of the DELEG record, the security implications of properly carrying the record in EPP,
and name servers using such information in zones, are similar to the security implications for NS records.
If there are later extensions to the DELEG record, those extension may have different security considerations that will need to be documented.¶
The formal syntax presented here is a complete schema representation of the extension suitable for automated validation of EPP XML instances.¶
<?xml version="1.0" encoding="UTF-8"?>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:epp:deleg-0.02"
xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.02"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
elementFormDefault="qualified">
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0 extension
schema for DELEG records.
</documentation>
</annotation>
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
<element name="infData" type="deleg:containerType"/>
<element name="create" type="deleg:containerType"/>
<element name="update" type="deleg:updateType"/>
<complexType name="updateType">
<sequence>
<element name="add" type="deleg:containerType"
minOccurs="0"/>
<element name="rem" type="deleg:remContainerType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="containerType">
<sequence>
<element name="deleg" type="deleg:delegType"
minOccurs="1" maxOccurs="unbounded">
<unique name="DelegInfoKeyMustBeUnique">
<selector xpath="deleg:param"/>
<field xpath="@name"/>
</unique>
</element>
</sequence>
</complexType>
<complexType name="remAllType"/>
<complexType name="remContainerType">
<choice>
<element name="all" type="deleg:remAllType"/>
<sequence>
<element name="deleg" type="deleg:delegType"
minOccurs="1" maxOccurs="unbounded"/>
</sequence>
</choice>
</complexType>
<complexType name="delegType">
<sequence>
<element name="param" type="deleg:paramType"
minOccurs="1" maxOccurs="unbounded"/>
</sequence>
</complexType>
<simpleType name="paramNameType">
<restriction base="NMTOKEN">
<pattern value="[a-z0-9-]+"/>
</restriction>
</simpleType>
<complexType name="paramType">
<simpleContent>
<extension base="token">
<attribute name="name"
type="deleg:paramNameType"
use="required"/>
</extension>
</simpleContent>
</complexType>
</schema>
¶
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 DELEG namespace:¶
URI: urn:ietf:params:xml:ns:epp:deleg-0.02¶
Registrant Contact: See the author(s) of this document¶
XML: None. Namespace URIs do not represent an XML specification¶
Registration for the DELEG XML schema:¶
URI:
urn:ietf:params:xml:schema:epp:deleg-0.02¶
Registrant Contact: See the author(s) of this document¶
XML: See the "Formal syntax" section of this document¶
The EPP extension described in this document will be registered by the IANA in the Extensions for the "Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. The details of the registration are as follows:¶
Name of Extension: Extensible Provisioning Protocol (EPP) Mapping for DELEG records¶
Document Status: Standards Track¶
Reference: URL of this document¶
Registrant Name and Email Address: See the author(s) of this document¶
TLDs: Any¶
IPR Disclosure: None¶
Status: Active¶
Notes: None¶
This section is to be removed before publishing as an RFC.¶