RFC 4310

Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

📅 published December 2005, from ietf

🎀 RFC 4310: DNS Security Extensions Mapping for EPP 🎀

Okay bestie, this is the spec for how a registrar talks to a shared registry to manage DNSSEC for domain names. 💖

Title block (the vitals): This is RFC 4310, titled "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)" 📋. It was written by S. Hollenbeck from VeriSign, Inc. and filed under the Network Working Group 🧚. It's on the Standards Track 👑 and dates from November 2005 🍓. The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own 💅.

Status of this Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice 🌸

Abstract 🦋

Okay so this doc describes an EPP extension mapping for managing DNS security extensions (DNSSEC) for domain names kept in a shared central repository 🗄️. It's written in XML, and it extends the EPP domain name mapping to add the extra features you need to provision DNS security extensions. Iconic, honestly 💅.

Table of Contents 📚

1. Introduction ....................................................2
   1.1. Conventions Used in This Document ..........................2
   2. Object Attributes ...............................................3
      2.1. Delegation Signer Information ..............................3
           2.1.1. Public Key Information ..............................3
      2.2. Booleans ...................................................3
      2.3. Maximum Signature Lifetime Values ..........................4
   3. EPP Command Mapping .............................................4
      3.1. EPP Query Commands .........................................4
           3.1.1. EPP <check> Command .................................4
           3.1.2. EPP <info> Command ..................................4
           3.1.3. EPP <transfer> Command ..............................8
      3.2. EPP Transform Commands .....................................8
           3.2.1. EPP <create> Command ................................8
           3.2.2. EPP <delete> Command ...............................11
           3.2.3. EPP <renew> Command ................................11
           3.2.4. EPP <transfer> Command .............................11
           3.2.5. EPP <update> Command ...............................11
   4. Formal Syntax ..................................................15
   5. Internationalization Considerations ............................18
   6. IANA Considerations ............................................18
   7. Security Considerations ........................................18
   8. Acknowledgements ...............................................20
   9. References .....................................................20
      9.1. Normative References ......................................20
      9.2. Informative References ....................................21

1. Introduction 🌈

Okay this one's the foundation. This doc describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 3730 [1]. The mapping extends the domain name mapping from RFC 3731 [2], and it's specified using Extensible Markup Language (XML) 1.0 [3] and XML Schema notation ([4], [5]).

The EPP core protocol spec [1] has the full description of EPP command and response structures ✨. You really need to understand the base protocol before this mapping makes sense. You also need to be familiar with the Domain Name System (DNS) from RFC 1034 [11] and RFC 1035 [12], plus the DNS security extensions from RFC 4033 [13], RFC 4034 [6], and RFC 4035 [7], so you can follow the DNS security concepts in here 🤓.

The EPP mapping here gives you a mechanism for provisioning and managing DNS security extensions in a shared central repository 🗄️. Info exchanged through this mapping can be pulled from the repository and used to publish DNSSEC delegation signer (DS) resource records, as described in RFC 4034 [6] 🔑.

1.1. Conventions Used in This Document 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [8].

In examples, "C:" marks lines sent by a protocol client, and "S:" marks lines returned by a protocol server 💬. "////" is used to flag element values that got shortened so they fit on the page 📄. Indentation and whitespace in examples are only there to show how elements relate to each other. They are not a mandatory feature of this protocol 🫶.

XML is case sensitive 🙈. Unless stated otherwise, XML specs and examples in this document MUST be interpreted in the character case presented, so you can build a conforming implementation. No skipping the capitalisation, bestie 💀.

2. Object Attributes 🎀

This extension adds new elements to the EPP domain name mapping [2]. Only the new element descriptions are covered here ✨.

This document walks through operational scenarios where a client can create, add, remove, and replace delegation signer (DS) information 🦋. The client MAY provide the key data for the DS information, but the server is not obligated to use it 🤷‍♀️. The server operator MAY also send out-of-band DNS queries to fetch the key data from the registered domain's apex, so it can check the DS information it received 🔍. It is RECOMMENDED that the child zone operator keep this key data online in the DNS tree, so the parent zone administrator can validate the data whenever needed 🌳. The key data SHOULD have the Secure Entry Point (SEP) bit set, as described in RFC 3757 [9] 🔐.

2.1. Delegation Signer Information 🧚

Delegation signer (DS) information is published by a DNS server to show that a child zone is digitally signed, and that the parent zone recognises the indicated key as a valid zone key for the child zone 🔏. A DS RR has four fields: a key tag field, a key algorithm number octet, an octet identifying the digest algorithm used, and a digest field 💜. For the specific field formats, see RFC 4034 [6].

2.1.1. Public Key Information 🔑

Public key info that a client provides maps to the DNSKEY RR presentation field formats in section 2.2 of RFC 4034 [6] 🗝️. A DNSKEY RR has four fields: flags, a protocol octet, an algorithm number octet, and a public key 🌸.

2.2. Booleans ✅

Boolean values MUST be represented in the XML Schema format described in Part 2 of the W3C XML Schema recommendation [5]. No other vibes allowed 🙅‍♀️.

2.3. Maximum Signature Lifetime Values ⏳

Maximum signature lifetime values MUST be represented in seconds, using an extended XML Schema "int" format 🕰️. The base "int" format allows negative numbers, and it's described in Part 2 of the W3C XML Schema recommendation [5]. This format gets further restricted to enforce a minimum value of one 🍓.

3. EPP Command Mapping 💅

The full EPP syntax and semantics live in the EPP core protocol spec [1] 📖. The command mappings here are specifically for provisioning and managing DNS security extensions through EPP 👑.

3.1. EPP Query Commands 🔍

EPP gives you three commands to retrieve object information: <check> to find out whether the server knows an object, <info> to get detailed info about an object, and <transfer> to get object transfer status info 🦋.

3.1.1. EPP `<check>` Command ✨

This extension doesn't add any elements to the EPP <check> command or <check> response described in the EPP domain mapping [2]. Nothing new to see here, bestie 💖.

To be continued in Part 2 🫶🌈

3.1.2. EPP <info> Command 🔍✨

okay bestie, the <info> command is lowkey the easiest one in this whole extension 🫶. this extension does not add any elements to the EPP <info> command described in the EPP domain mapping [2] 💅. the new stuff is all in the <info> response, so that's where we're headed 🎀.

when an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in the EPP domain mapping [2] 🌸. no skipping, no vibes-only, it MUST 😭. on top of that, the EPP <extension> element MUST contain a child <secDNS:infData> element 💖. that element identifies the extension namespace and tells you where the extension schema lives 🧚.

inside <secDNS:infData> you'll find these child elements 👑:

One or more <secDNS:dsData> elements that describe the delegation signer data the client gave for the domain 🦋. so every dsData is basically one DS record's worth of info ✨.

and inside each <secDNS:dsData> you get:

A <secDNS:keyTag> element that contains a key tag value as described in section 5.1.1 of RFC 4034 [6] 🔑.
A <secDNS:alg> element that contains an algorithm value as described in section 5.1.2 of RFC 4034 [6] 🧁.
A <secDNS:digestType> element that contains a digest type value as described in section 5.1.3 of RFC 4034 [6] 🍓.
A <secDNS:digest> element that contains a digest value as described in section 5.1.4 of RFC 4034 [6] 💜.
An OPTIONAL <secDNS:maxSigLife> element that indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire ⏳. a client SHOULD specify the same <secDNS:maxSigLife> value for all <secDNS:dsData> elements associated with a domain 🫶. if the <secDNS:maxSigLife> is not present, or if multiple <secDNS:maxSigLife> values are requested, the default signature expiration policy of the server operator (as determined using an out-of-band mechanism) applies 🙈.
An OPTIONAL <secDNS:keyData> element that describes the key data used as input in the DS hash calculation 🔥. inside that one you get:
- A <secDNS:flags> element that contains a flags field value as described in section 2.1.1 of RFC 4034 [6] 🌈.
- A <secDNS:protocol> element that contains a protocol field value as described in section 2.1.2 of RFC 4034 [6] 🦋.
- A <secDNS:alg> element that contains an algorithm number field value as described in sections 2.1.3 of RFC 4034 [6] ✨.
- A <secDNS:pubKey> element that contains an encoded public key field value as described in sections 2.1.4 of RFC 4034 [6] 💅.

here's an example <info> response for a secure delegation, the basic version 🎀:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
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:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name>example.com</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="ok"/>
S:        <domain:registrant>jd1234</domain:registrant>
S:        <domain:contact type="admin">sh8013</domain:contact>
S:        <domain:contact type="tech">sh8013</domain:contact>
S:        <domain:ns>
S:          <domain:hostObj>ns1.example.com</domain:hostObj>
S:          <domain:hostObj>ns2.example.com</domain:hostObj>
S:        </domain:ns>
S:        <domain:host>ns1.example.com</domain:host>
S:        <domain:host>ns2.example.com</domain:host>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crID>ClientY</domain:crID>
S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:upID>ClientX</domain:upID>
S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S:        <domain:authInfo>
S:          <domain:pw>2fooBAR</domain:pw>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <secDNS:infData
S:       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
S:       secDNS-1.0.xsd">
S:        <secDNS:dsData>
S:          <secDNS:keyTag>12345</secDNS:keyTag>
S:          <secDNS:alg>3</secDNS:alg>
S:          <secDNS:digestType>1</secDNS:digestType>
S:          <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
S:        </secDNS:dsData>
S:      </secDNS:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

and here's the example with the OPTIONAL data included 🧚✨:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
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:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name>example.com</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="ok"/>
S:        <domain:registrant>jd1234</domain:registrant>
S:        <domain:contact type="admin">sh8013</domain:contact>
S:        <domain:contact type="tech">sh8013</domain:contact>
S:        <domain:ns>
S:          <domain:hostObj>ns1.example.com</domain:hostObj>
S:          <domain:hostObj>ns2.example.com</domain:hostObj>
S:        </domain:ns>
S:        <domain:host>ns1.example.com</domain:host>
S:        <domain:host>ns2.example.com</domain:host>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crID>ClientY</domain:crID>
S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:upID>ClientX</domain:upID>
S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S:        <domain:authInfo>
S:          <domain:pw>2fooBAR</domain:pw>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <secDNS:infData
S:       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
S:       secDNS-1.0.xsd">
S:        <secDNS:dsData>
S:          <secDNS:keyTag>12345</secDNS:keyTag>
S:          <secDNS:alg>3</secDNS:alg>
S:          <secDNS:digestType>1</secDNS:digestType>
S:          <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
S:          <secDNS:maxSigLife>604800</secDNS:maxSigLife>
S:          <secDNS:keyData>
S:            <secDNS:flags>256</secDNS:flags>
S:            <secDNS:protocol>3</secDNS:protocol>
S:            <secDNS:alg>1</secDNS:alg>
S:            <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
S:          </secDNS:keyData>
S:        </secDNS:dsData>
S:      </secDNS:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

last thing for this command: an EPP error response MUST be returned if an <info> command can not be processed for any reason 🚨. no exceptions, periodt 💀.

3.1.3. EPP <transfer> Command 🦋

this one is chill 😌. this extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [2] 🌸. nothing new to see here, just the normal domain mapping stuff 💅.

3.2. EPP Transform Commands ✨

okay so now we're getting into the transform commands 🔥. EPP provides five commands to transform objects: <create> to create an instance of an object 🎀, <delete> to delete an instance of an object 🗑️, <renew> to extend the validity period of an object 🌈, <transfer> to manage object sponsorship changes 🤝, and <update> to change information associated with an object 💖. five commands, five jobs, iconic 👑.

3.2.1. EPP <create> Command ✨

okay bestie, so this extension adds extra elements to the EPP <create> command from the EPP domain mapping [2] 🎀 but there are no extra elements for the EPP <create> response 💅

the <create> command is the transform op that lets a client make a domain object 🌸 on top of the usual EPP command elements from [2], the command MUST include an <extension> element 🫶 and that <extension> element MUST have a child <secDNS:create> element that names the extension namespace and where the extension schema lives 🦋 the <secDNS:create> element MUST contain one or more <secDNS:dsData> elements 🔥 and the child elements of <secDNS:dsData> are described in Section 3.1.2 💜

the <secDNS:dsData> element has OPTIONAL <secDNS:maxSigLife> and <secDNS:keyData> elements 🌈 and the server MUST abort command processing and send back an appropriate EPP error if the values the client gave can not be accepted for syntax or policy reasons 😭 no cap, this part is serious!

Example <create> Command for a Secure Delegation:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
       domain-1.0.xsd">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">2</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.example.com</domain:hostObj>
          <domain:hostObj>ns2.example.com</domain:hostObj>
        </domain:ns>
        <domain:registrant>jd1234</domain:registrant>
        <domain:contact type="admin">sh8013</domain:contact>
        <domain:contact type="tech">sh8013</domain:contact>
        <domain:authInfo>
          <domain:pw>2fooBAR</domain:pw>
        </domain:authInfo>
      </domain:create>
    </create>
    <extension>
      <secDNS:create
       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
       secDNS-1.0.xsd">
        <secDNS:dsData>
          <secDNS:keyTag>12345</secDNS:keyTag>
          <secDNS:alg>3</secDNS:alg>
          <secDNS:digestType>1</secDNS:digestType>
          <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
        </secDNS:dsData>
      </secDNS:create>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Example <create> Command for a Secure Delegation with OPTIONAL data:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
       domain-1.0.xsd">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">2</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.example.com</domain:hostObj>
          <domain:hostObj>ns2.example.com</domain:hostObj>
        </domain:ns>
        <domain:registrant>jd1234</domain:registrant>
        <domain:contact type="admin">sh8013</domain:contact>
        <domain:contact type="tech">sh8013</domain:contact>
        <domain:authInfo>
          <domain:pw>2fooBAR</domain:pw>
        </domain:authInfo>
      </domain:create>
    </create>
    <extension>
      <secDNS:create
       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
       secDNS-1.0.xsd">
        <secDNS:dsData>
          <secDNS:keyTag>12345</secDNS:keyTag>
          <secDNS:alg>3</secDNS:alg>
          <secDNS:digestType>1</secDNS:digestType>
          <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
          <secDNS:maxSigLife>604800</secDNS:maxSigLife>
          <secDNS:keyData>
            <secDNS:flags>256</secDNS:flags>
            <secDNS:protocol>3</secDNS:protocol>
            <secDNS:alg>1</secDNS:alg>
            <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
          </secDNS:keyData>
        </secDNS:dsData>
      </secDNS:create>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

when a <create> command has been processed successfully 🎉 the EPP response is as described in the EPP domain mapping [2] ✨

3.2.2. EPP <delete> Command 🗑️

this extension doesn't add any elements to the EPP <delete> command or <delete> response described in the EPP domain mapping [2] 💖

3.2.3. EPP <renew> Command 🔁

this extension doesn't add any elements to the EPP <renew> command or <renew> response described in the EPP domain mapping [2] 🌸

3.2.4. EPP <transfer> Command 🦋

this extension doesn't add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [2] 💅

3.2.5. EPP <update> Command ✨

okay bestie, this extension adds extra bits to the EPP <update> command from the EPP domain mapping [2] 💅 It doesn't add anything new to the <update> response, though, so that part is the same as always 🌸

The <update> command is the one that lets a client change a domain object's attributes 🦋 On top of the usual EPP command elements from the domain mapping, the command MUST contain an <extension> element 🎀 That <extension> element MUST contain a child <secDNS:update> element. This is where the extension namespace and the location of its schema get identified 🫶 Inside <secDNS:update> you'll find one of three things: a <secDNS:add> element to add security info to a delegation, a <secDNS:rem> element to remove security info from a delegation, or a <secDNS:chg> element to swap out the security info for new security info 🔥

The <secDNS:update> element also has an OPTIONAL "urgent" attribute 🚨 A client can use it to ask the server operator to finish and apply the update with high priority. This attribute takes boolean values the way Section 2.2 describes, and the default is boolean false 🙈 "High priority" is only relative to the server operator's standard policies, and those policies get worked out through an out-of-band mechanism 🧚

The <secDNS:add> element is for adding DS info to a set that already exists ✨ It MUST contain one or more <secDNS:dsData> elements, the same way Section 3.1.2 describes 💖

The <secDNS:rem> element holds one or more <secDNS:keyTag> elements, and those are used to remove DS data from a delegation 🦋 Each <secDNS:keyTag> element MUST contain a key tag value, as described in section 5.1.1 of RFC 4034 [6] 🌈 Heads up, though: if you remove ALL the DS info, the parent might lose its ability to secure the delegation to the child zone 💀

The <secDNS:chg> element replaces the existing DS info with brand new DS info 💅 It MUST contain one or more <secDNS:dsData> elements, as described in Section 3.1.2. Whatever data is already archived for the delegation gets replaced by the data in these elements 👑

Last thing: the <secDNS:update> element has that OPTIONAL "urgent" attribute we talked about 🌸 And the <secDNS:dsData> element can hold OPTIONAL <secDNS:maxSigLife> and <secDNS:keyData> elements 🍓 If the values the client sends can not be accepted for syntax or policy reasons, the server MUST abort command processing and send back an appropriate EPP error 😭

Example <update> Command, Adding DS Data:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:      </domain:update>
C:    </update>
C:    <extension>
C:      <secDNS:update
C:       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
C:       secDNS-1.0.xsd">
C:        <secDNS:add>
C:          <secDNS:dsData>
C:            <secDNS:keyTag>12346</secDNS:keyTag>
C:            <secDNS:alg>3</secDNS:alg>
C:            <secDNS:digestType>1</secDNS:digestType>
C:            <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
C:          </secDNS:dsData>
C:        </secDNS:add>
C:      </secDNS:update>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example <update> Command, Removing DS Data:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:      </domain:update>
C:    </update>
C:    <extension>
C:      <secDNS:update
C:       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
C:       secDNS-1.0.xsd">
C:        <secDNS:rem>
C:          <secDNS:keyTag>12345</secDNS:keyTag>
C:        </secDNS:rem>
C:      </secDNS:update>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example Urgent <update> Command, Changing DS Data:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:      </domain:update>
C:    </update>
C:    <extension>
C:      <secDNS:update urgent="1"
C:       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
C:       secDNS-1.0.xsd">
C:        <secDNS:chg>
C:          <secDNS:dsData>
C:            <secDNS:keyTag>12345</secDNS:keyTag>
C:            <secDNS:alg>3</secDNS:alg>
C:            <secDNS:digestType>1</secDNS:digestType>
C:            <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
C:          </secDNS:dsData>
C:        </secDNS:chg>
C:      </secDNS:update>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example <update> Command, Changing Data to Include OPTIONAL Data:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:      </domain:update>
C:    </update>
C:    <extension>
C:      <secDNS:update
C:       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
C:       secDNS-1.0.xsd">
C:        <secDNS:chg>
C:          <secDNS:dsData>
C:            <secDNS:keyTag>12345</secDNS:keyTag>
C:            <secDNS:alg>3</secDNS:alg>
C:            <secDNS:digestType>1</secDNS:digestType>
C:            <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
C:            <secDNS:maxSigLife>604800</secDNS:maxSigLife>
C:            <secDNS:keyData>
C:              <secDNS:flags>256</secDNS:flags>
C:              <secDNS:protocol>3</secDNS:protocol>
C:              <secDNS:alg>1</secDNS:alg>
C:              <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
C:            </secDNS:keyData>
C:          </secDNS:dsData>
C:        </secDNS:chg>
C:      </secDNS:update>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

When an extended <update> command goes through successfully, the EPP response looks just like the one in the EPP domain mapping [2] 🎀 One more rule: a server operator MUST return EPP error result code 2306 if an urgent update (the one with the "urgent" attribute set to boolean true) can not be completed with high priority 😭🔥

4. Formal Syntax 💜

okay so here's the formal bit 🤓 The EPP object mapping is written in XML Schema notation, and this schema is a complete representation of the object mapping, so you can use it for automated validation of EPP XML instances ✨ The BEGIN and END tags aren't actually part of the schema. They just mark where the schema starts and ends so it can be registered as a URI 🦋

BEGIN
<?xml version="1.0" encoding="UTF-8"?>

<schema targetNamespace="urn:ietf:params:xml:ns:secDNS-1.0"
        xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
        xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

  <annotation>
    <documentation>
      Extensible Provisioning Protocol v1.0
      domain name extension schema for provisioning
      DNS security (DNSSEC) extensions.
    </documentation>
  </annotation>

<!--
Child elements found in EPP commands.
-->
  <element name="create" type="secDNS:dsType"/>
  <element name="update" type="secDNS:updateType"/>

<!--
Child elements of the <create> command.
-->
  <complexType name="dsType">
    <sequence>
      <element name="dsData" type="secDNS:dsDataType"
       maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="dsDataType">
    <sequence>
      <element name="keyTag" type="unsignedShort"/>
      <element name="alg" type="unsignedByte"/>
      <element name="digestType" type="unsignedByte"/>
      <element name="digest" type="hexBinary"/>
      <element name="maxSigLife" type="secDNS:maxSigLifeType"
       minOccurs="0"/>
      <element name="keyData" type="secDNS:keyDataType"
       minOccurs="0"/>
    </sequence>
  </complexType>

  <simpleType name="maxSigLifeType">
    <restriction base="int">
      <minInclusive value="1"/>

    </restriction>
  </simpleType>

  <complexType name="keyDataType">
    <sequence>
      <element name="flags" type="unsignedShort"/>
      <element name="protocol" type="unsignedByte"/>
      <element name="alg" type="unsignedByte"/>
      <element name="pubKey" type="secDNS:keyType"/>
    </sequence>
  </complexType>

  <simpleType name="keyType">
    <restriction base="base64Binary">
      <minLength value="1"/>
    </restriction>
  </simpleType>

<!--
Child elements of the <update> command.
-->
  <complexType name="updateType">
    <choice>
      <element name="add" type="secDNS:dsType"/>
      <element name="chg" type="secDNS:dsType"/>
      <element name="rem" type="secDNS:remType"/>
    </choice>
    <attribute name="urgent" type="boolean" default="false"/>
  </complexType>

  <complexType name="remType">
    <sequence>
      <element name="keyTag" type="unsignedShort"
       maxOccurs="unbounded"/>
    </sequence>
  </complexType>

<!--
Child response elements.
-->
  <element name="infData" type="secDNS:dsType"/>

<!--
End of schema.
-->
</schema>
END

5. Internationalization Considerations ✨

okay so EPP is written in XML, and XML already speaks Unicode natively 🌍 It can encode stuff using UTF-8 [14], which is the more compact way to do it, and conformant XML processors understand both UTF-8 and UTF-16 [15] 💖 XML also lets you pick another encoding with an encoding attribute in the <?xml?> declaration, but if some parsers in your environment can't handle that, UTF-8 is RECOMMENDED 🫶

since EPP is an extension of the EPP domain mapping [2], the elements, element content, attributes, and attribute values in this document MUST inherit the internationalization conventions already used for the higher-layer domain and core protocol structures in any XML instance that includes this extension 🌸 basically, don't go inventing your own rules, just follow the house rules ✨

6. IANA Considerations 🎀

this doc uses URNs to name XML namespaces and XML schemas, following the registry mechanism from RFC 3688 [10] 📋 and two URI assignments have already been completed by IANA 🦋

the extension namespace registration request:

URI: urn:ietf:params:xml:ns:secDNS-1.0
Registrant Contact: IESG
XML: None. Namespace URIs don't represent an XML specification, so there's nothing to put here 🙈

the extension XML schema registration request:

URI: urn:ietf:params:xml:schema:secDNS-1.0
Registrant Contact: IESG
XML: See the "Formal Syntax" section of this document 💅

7. Security Considerations 💀

okay, this part is SERIOUS bestie 😭 the mapping extensions here don't add any security services beyond what EPP [1], the EPP domain name mapping [2], and the protocol layers EPP sits on already provide 🔐 so the security considerations from those other specs apply here too, no exceptions 🫶

transform operations are a whole big deal 👑 as with other domain object transforms, the EPP transform operations in this doc MUST be restricted to the sponsoring client, as authenticated using the mechanisms in sections 2.9.1.1 and 7 of RFC 3730 [1] 🔒 if any client that isn't the sponsoring client tries to transform a domain object, it MUST be rejected with an appropriate EPP authorization error. not me doing a whole plot twist 🙅‍♀️

provisioning here involves swapping info that can have real operational impact on the DNS 🌐 so a trust relationship MUST exist between the EPP client and server, and provisioning public key info MUST only happen after both parties' identities are confirmed using a strong authentication mechanism 🗝️ no vibes-based trust, periodt ✨

an EPP client might be acting as an agent for a zone administrator who wants to send delegation info to be signed and published by the server operator 📨 which means man-in-the-middle attacks are possible, whether from direct client activity or from inadvertent client data manipulation 😱

accepting a false key on the server side can cause serious operational consequences 🚨 the child and parent zones MUST be consistent to secure the delegation properly. without consistent signatures, the delegation won't show up in the secure name space, and you'll get untrustworthy query responses. if a key gets compromised, a client can either remove the compromised info or update the delegation info using EPP commands with the "urgent" attribute 🆘

when you need to yank a secure domain delegation fast, there's a two-step process 🏃‍♀️ step one: remove the security credentials with an "urgent" update, like we just said. step two: take the domain out of the parent zone by changing its status to either the EPP "clientHold" or "serverHold" domain status values 🛑 you can also remove the domain from the zone with the EPP <delete> command, but that's the drastic option, so think it through super carefully before you do it 💅

data validity checking at the server takes computational resources 🧠 so a purposeful or accidental denial-of-service attack is possible if a client requests more update operations than the server can process 😵 server operators SHOULD take steps to manage command load and command processing requirements, to minimize the risk of a denial-of-service attack 🛡️

the signature lifetime values that clients provide are just requests, and they can be rejected 🙋‍♀️ blindly accepting them can hurt a server's processing capabilities. server operators SHOULD seriously consider adopting implementation rules that limit the range of acceptable signature lifetime values, to counter potential bad situations 💜

8. Acknowledgements 🫶

the author would like to thank the people who made significant contributions to this document: David Blacka, Olafur Gudmundsson, Mark Kosters, Ed Lewis, Dan Massey, Marcos Sanz, Sam Weiler, and Ning Zhang 🌈 the real MVPs ✨

9. References 📚

9.1. Normative References

[1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004.
[3] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000.
[4] Maloney, M., Beech, D., Mendelsohn, N., and H. Thompson, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001.
[5] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", W3C REC REC-xmlschema-2-20010502, May 2001.
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.
[10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

9.2. Informative References

[11] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[12] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[13] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[15] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.

Author's Address 🖋️

Scott Hollenbeck
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA  20166-6503
US

EMail: shollenbeck@verisign.com

the copyright here belongs to The Internet Society (2005) 💜 this document is subject to the rights, licenses, and restrictions in BCP 78, and except as set out there, the authors keep all their rights 📜

this document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙅‍♀️

Intellectual Property 🔍

the IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed for the technology in this document are valid, or how far they reach, or whether any license under them would be available 🤷‍♀️ it also doesn't claim to have independently searched for any such rights. info about how rights work for RFC documents lives in BCP 78 and BCP 79 📖

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr 🔗

the IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society 💖 thanks for reading all the way to the end, bestie 🦋

📦 where this page comes from

ietf: rfc4310 2005-12
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms