RFC 5910
Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
RFC 5910: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) 🎀
okay bestie, this one is from the IETF, and it's dated May 2010 🌸 The authors are J. Gould and S. Hollenbeck, both from VeriSign, Inc. It's a Standards Track doc with ISSN 2070-1721, and it obsoletes RFC 4310. It doesn't say it updates anything, so I'm not gonna guess 🙈
Abstract
okay so the big idea is an EPP extension mapping for managing DNSSEC stuff ("DNS security extensions") for domain names that live in a shared central repository 🔐 It's written in XML, and it extends the EPP domain name mapping so you can provision the DNS security bits. This document obsoletes RFC 4310 💅
Status of This Memo
bestie, this section is the official "where does this doc stand" part 📜 This is an Internet Standards Track document ✨
It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more info on Internet Standards, check Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5910 🦋
Copyright Notice
okay, legal section, but make it cute 💜 Copyright is (c) 2010 IETF Trust and the persons identified as the document authors, and all rights are reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read those, bc they spell out your rights and restrictions for this doc 🙏 Any Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
This doc might include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So, unless you get an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌈
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Migrating from RFC 4310 . . . . . . . . . . . . . . . . . . . 4
3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Delegation Signer Information . . . . . . . . . . . . . . 5
3.1.1. Public Key Information . . . . . . . . . . . . . . . . 5
3.2. Booleans . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Maximum Signature Lifetime . . . . . . . . . . . . . . . . 5
4. DS Data Interface and Key Data Interface . . . . . . . . . . . 6
4.1. DS Data Interface . . . . . . . . . . . . . . . . . . . . 7
4.2. Key Data Interface . . . . . . . . . . . . . . . . . . . . 7
4.3. Example DS Data Interface and Key Data Interface . . . . . 8
5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9
5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9
5.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 9
5.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 9
5.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . . 13
5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 14
5.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 14
5.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 17
5.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 18
5.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 18
5.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 18
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Internationalization Considerations . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Changes from RFC 4310 . . . . . . . . . . . . . . . . 331. Introduction ✨
okay so this doc describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP), which is described in RFC 5730 [RFC5730]. This mapping extends the domain name mapping from RFC 5731 [RFC5731], and it's specified using Extensible Markup Language (XML) 1.0 [W3C.REC-xml-20001006] plus XML Schema notation ([W3C.REC-xmlschema-1-20010502] [W3C.REC-xmlschema-2-20010502]) 🧚
The EPP core spec, [RFC5730], has the full scoop on EPP command and response structures. You need a solid grasp of that base spec to get this mapping, no cap 💕 You also need to know the Domain Name System (DNS) from RFC 1034 [RFC1034] and RFC 1035 [RFC1035], plus the DNS security extensions from RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035], to understand the DNS security concepts in here 🔥
The EPP mapping in this doc sets up a way to provision and manage DNS security extensions in a shared central repository. Info that goes through this mapping can be pulled out of the repository and used to publish DNSSEC Delegation Signer (DS) resource records (RRs), as described in RFC 4034 [RFC4034] 🌸
This doc obsoletes RFC 4310 [RFC4310]. So secDNS-1.1, which is defined here, deprecates secDNS-1.0 [RFC4310]. The reasons for obsoleting RFC 4310 [RFC4310] include:
- Fixing the problem with removing DS data based on the non-unique
<secDNS:keyTag>element. The client should explicitly specify which DS data gets removed, by using all four<secDNS:dsData>elements, which are guaranteed to be unique 🔑 - Adding the ability to add and remove
<secDNS:dsData>elements in a single command. This makes it consistent with RFC 5731 [RFC5731] ✨ - Clarifying and fixing how the
<secDNS:chg>element gets used. RFC 4310 [RFC4310] defined<secDNS:chg>as a replacement for the DS data. That's inconsistent with RFC 5731 [RFC5731], where a<domain:chg>element is used to change the values of the domain attributes 🙅♀️ - Adding support for the Key Data Interface described in Section 4.2, for "thick" DNSSEC servers that accept only key data and generate the associated DS data 💜
1.1. Conventions Used in This Document
okay this part is about how to read the keywords 📖 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 [RFC2119]. Yep, those are the ones that carry real weight 💅
In examples, "C:" means lines sent by a protocol client, and "S:" means lines sent back by a protocol server. "////" is used to mark element values that got shortened so they fit on the page ✂️ Indentation and whitespace in examples are only there to show how the elements relate. They are not a mandatory feature of this protocol 🫶
XML is case sensitive 🙈 Unless stated otherwise, XML specs and examples in this doc MUST be read with the character case shown, so you can build a conforming implementation. Notice that "MUST" there, bestie, that's a real requirement ✨
secDNS-1.0 is shorthand for urn:ietf:params:xml:ns:secDNS-1.0, and secDNS-1.1 is shorthand for urn:ietf:params:xml:ns:secDNS-1.1 🦋
2. Migrating from RFC 4310 🧚
okay so this section has implementation recommendations for clients and servers that are moving from secDNS-1.0 [RFC4310] to secDNS-1.1 🎀
Since this doc deprecates RFC 4310 [RFC4310], if a server announces support for both secDNS-1.0 [RFC4310] and secDNS-1.1 in the EPP greeting, clients that support both versions SHOULD prefer secDNS-1.1 👑
A server SHOULD do the following to help clients migrate from secDNS-1.0 [RFC4310] to secDNS-1.1 as defined in this document 🌈
- A server migrating from
secDNS-1.0[RFC4310] tosecDNS-1.1SHOULD support both versions (that is,secDNS-1.0andsecDNS-1.1) for a reasonable migration period ⏳ - The version of the
<secDNS:infData>element that the server returns in the response to a<domain:info>command SHOULD depend on the<extURI>elements (which indicate the secDNS extension) that the client included in the EPP<login>command. Here's the mapping:- Return version
secDNS-1.1of the<secDNS:infData>element ifurn:ietf:params:xml:ns:secDNS-1.1was included as an<extURI>element in the EPP<login>command, no matter whetherurn:ietf:params:xml:ns:secDNS-1.0is also included as an<extURI>element in the EPP<login>command 🔥 - Return version
secDNS-1.0of the<secDNS:infData>element ifurn:ietf:params:xml:ns:secDNS-1.0but noturn:ietf:params:xml:ns:secDNS-1.1was included as an<extURI>element in the EPP<login>command 💖 - Don't return the
<secDNS:infData>element if neitherurn:ietf:params:xml:ns:secDNS-1.0norurn:ietf:params:xml:ns:secDNS-1.1was included as an<extURI>element in the EPP<login>command 💀
- Return version
3. Object Attributes 💅
okay so this extension adds more elements to the EPP domain name mapping [RFC5731]. Only the new elements get described here, bestie 🫶
3.1. Delegation Signer Information 🔐
Delegation Signer (DS) info is published by a DNS server to show that a child zone is digitally signed, and that the parent zone recognizes the indicated key as a valid zone key for the child zone 👑 A DS resource record (RR) has four fields: a key tag field, a key algorithm number octet, an octet identifying a digest algorithm, and a digest field. See RFC 4034 [RFC4034] for the specific field formats 🦋
3.1.1. Public Key Information 🗝️
Public key info that a client provides maps to the DNSKEY RR presentation field formats described in Section 2.2 of RFC 4034 [RFC4034]. A DNSKEY RR has four fields: flags, a protocol octet, an algorithm number octet, and a public key 🌸
3.2. Booleans ✨
Boolean values MUST be represented in the XML Schema format described in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502]. That one's non-negotiable, so no skipping it 🙅♀️
3.3. Maximum Signature Lifetime ⏳
okay so maxSigLife is an OPTIONAL child preference 🫶 It's the number of seconds after signature generation when the parent's signature on the DS info the child sent over will expire. The value applies to the RRSIG resource record (RR) over the DS RRset, and if you want the full scoop on RRSIG, check out Section 3 of RFC 4034 [RFC4034] 📖
The maximum signature lifetime gets written as the <secDNS:maxSigLife> element, and the value MUST be in seconds, using an extended XML Schema "int" format. The base "int" format allows negative numbers (it's described in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502]), but this format gets an extra restriction so the minimum value is 1 🌸
Now the fallback situation 🙈 If the client doesn't send maxSigLife, or the server doesn't support the value the client picked, then the server operator's default signature expiration policy applies instead. That policy is set through an out-of-band mechanism, so it isn't part of this protocol 💅
4. DS Data Interface and Key Data Interface 🎀
okay this part is so good, it's about how a client can create, add, and remove Delegation Signer (DS) info or key data info for a domain name 💖 There are two interface flavors a server can support. The first is the "DS Data Interface," where the client makes the DS info itself and has to pass it along on adds and removes, while the server has to pass DS info back in <domain:info> responses. The second is the "Key Data Interface," where the client passes key data on adds and removes, and the server is the one that hands back key data in <domain:info> responses ✨
The server MUST support one form of interface within a single command or response. <secDNS:dsData> and <secDNS:keyData> MUST NOT be mixed, except when <secDNS:keyData> is a child element of <secDNS:dsData> for server validation 🧚
The server MUST support only one form of interface across all <secDNS:create>, <secDNS:update>, and <secDNS:infData> elements. The exception is a transition period, when the server MAY support both 🦋 For example, during a transition period the server MAY support either the DS Data Interface or the Key Data Interface on a per-domain basis, so the client can migrate over to the target interface 🌈
To switch interfaces, the client can use <secDNS:rem><secDNS:all>true</secDNS:all></secDNS:rem> to wipe out all the data from the old interface, then use <secDNS:add> to add data in the new one (<secDNS:dsData> for the DS Data Interface, <secDNS:keyData> for the Key Data Interface) 💅
If the server gets a command using an interface it doesn't support, it MUST return EPP error result code 2306. No exceptions, bestie 🚫
4.1. DS Data Interface 🍓
The DS Data Interface uses <secDNS:dsData> for creates, adds, removes, and <domain:info> responses. The key data linked to the DS info MAY be provided by the client, but the server doesn't have to use it 🙈 The server operator MAY also send out-of-band DNS queries to grab the key data from the registered domain's apex, so it can check the DS info it got 🔍
It is RECOMMENDED that the child zone operator keep this key data online in the DNS tree, so the parent zone admin can validate the data whenever needed 🌸 The key data SHOULD have the Secure Entry Point (SEP) bit set, as described in RFC 3757 [RFC3757] and RFC 4034 [RFC4034] ✨
The <secDNS:dsData> element has these child elements:
- A
<secDNS:keyTag>element holding a key tag value, as described in Section 5.1.1 of RFC 4034 [RFC4034]. The<secDNS:keyTag>element is represented as an unsignedShort [W3C.REC-xmlschema-2-20010502]. - A
<secDNS:alg>element holding an algorithm value, as described in Section 5.1.2 of RFC 4034 [RFC4034]. - A
<secDNS:digestType>element holding a digest type value, as described in Section 5.1.3 of RFC 4034 [RFC4034]. - A
<secDNS:digest>element holding a digest value, as described in Section 5.1.4 of RFC 4034 [RFC4034]. The<secDNS:digest>element is represented as a hexBinary [W3C.REC-xmlschema-2-20010502]. - An OPTIONAL
<secDNS:keyData>element that describes the key data used as input in the DS hash calculation, for use in server validation. The<secDNS:keyData>element contains the child elements defined in Section 4.2 💜
4.2. Key Data Interface 🌷
The Key Data Interface uses <secDNS:keyData> for creates, adds, removes, and <domain:info> responses. The DS info isn't sent by the client, the server generates it instead 🤖 The attributes used for DS generation come from server policy, so the only thing passed between client and server is the key data 🫧
The <secDNS:keyData> element has these child elements:
- A
<secDNS:flags>element holding a flags field value, as described in Section 2.1.1 of RFC 4034 [RFC4034]. - A
<secDNS:protocol>element holding a protocol field value, as described in Section 2.1.2 of RFC 4034 [RFC4034]. - A
<secDNS:alg>element holding an algorithm number field value, as described in Section 2.1.3 of RFC 4034 [RFC4034]. - A
<secDNS:pubKey>element holding an encoded public key field value, as described in Section 2.1.4 of RFC 4034 [RFC4034]. The<secDNS:pubKey>element is represented as a base64Binary [W3C.REC-xmlschema-2-20010502] with a minimum length of 1 🔑
4.3. Example DS Data Interface and Key Data Interface 🎀
Here's an example of the secDNS-1.1 DS Data Interface for a create 🍒
<secDNS:dsData>
<secDNS:keyTag>12345</secDNS:keyTag>
<secDNS:alg>3</secDNS:alg>
<secDNS:digestType>1</secDNS:digestType>
<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
</secDNS:dsData>And here's the secDNS-1.1 DS Data Interface with optional key data for a create 🧁
<secDNS:dsData>
<secDNS:keyTag>12345</secDNS:keyTag>
<secDNS:alg>3</secDNS:alg>
<secDNS:digestType>1</secDNS:digestType>
<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
<secDNS:keyData>
<secDNS:flags>257</secDNS:flags>
<secDNS:protocol>3</secDNS:protocol>
<secDNS:alg>1</secDNS:alg>
<secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
</secDNS:keyData>
</secDNS:dsData>And finally, the secDNS-1.1 Key Data Interface for a create 👑
<secDNS:keyData>
<secDNS:flags>257</secDNS:flags>
<secDNS:protocol>3</secDNS:protocol>
<secDNS:alg>1</secDNS:alg>
<secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
</secDNS:keyData>5. EPP Command Mapping 🦋
okay so the detailed EPP syntax and semantics live in the EPP core protocol specification [RFC5730] 📚 This section is just the command mappings for provisioning and managing DNS security extensions via EPP 💅
5.1. EPP Query Commands 🔎
EPP has three commands for getting object info. <check> tells you whether the server knows about an object, <info> gets the detailed info for an object, and <transfer> gets an object's transfer status 🌈
5.1.1. EPP <check> Command ✨
this extension doesn't add any elements to the EPP <check> command or <check> response. Those are covered in the EPP domain mapping [RFC5731] 🫶
5.1.2. EPP <info> Command 🔍
Okay bestie, this extension doesn't add any new elements to the EPP <info> command from the EPP domain mapping [RFC5731] 💅. It does add stuff to the <info> response, though, and that's where the fun is 🦋.
When an <info> command is processed successfully, the <resData> element MUST contain child elements as described in [RFC5731]. On top of that, the EPP <extension> element SHOULD contain a <secDNS:infData> child element that identifies the extension namespace, if the domain object has data for this extension and depending on server policy ✨. The <secDNS:infData> element has these child elements:
- An OPTIONAL
<secDNS:maxSigLife>element that shows a child's preference for how many seconds after signature generation the parent's signature on the DS information from the child will expire. We cover maxSigLife in Section 3.3 🌸 - One or more
<secDNS:dsData>elements or<secDNS:keyData>elements, but not both, as defined in Section 4. The<secDNS:dsData>elements describe the Delegation Signer (DS) data the client gave for the domain 🎀. The<secDNS:keyData>elements describe the key data the client gave for the domain 🔑. The child elements of<secDNS:dsData>are in Section 4.1, and the child elements of<secDNS:keyData>are in Section 4.2 💜.
Example <info> Response for a Secure Delegation Using the DS Data Interface:
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: <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: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.1">
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>Example <info> Response for a Secure Delegation Using the DS Data Interface with OPTIONAL Key Data:
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: <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: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.1">
S: <secDNS:maxSigLife>604800</secDNS:maxSigLife>
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:keyData>
S: <secDNS:flags>257</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>Example <info> Response for a Secure Delegation Using the Key Data Interface:
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: <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: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.1">
S: <secDNS:keyData>
S: <secDNS:flags>257</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:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>An EPP error response MUST be returned if an <info> command cannot be processed for any reason 🚨.
5.1.3. EPP <transfer> Command 🔁
This extension doesn't add any elements to the EPP <transfer> command or the <transfer> response from the EPP domain mapping [RFC5731], so nothing new to see here 🫶.
5.2. EPP Transform Commands ⚡
EPP has five commands for transforming objects 👑. <create> makes a new instance of an object, <delete> removes an instance of an object, <renew> extends an object's validity period, <transfer> handles changes in object sponsorship, and <update> changes the information attached to an object 🌈.
5.2.1. EPP <create> Command
Okay so this extension adds extra goodies to the EPP <create> command from the EPP domain mapping [RFC5731] 💅 but it doesn't add anything new to the <create> response 🎀
The <create> command is a transform operation that lets a client make a domain object ✨ On top of the usual [RFC5731] stuff, the command MUST contain an <extension> element, and that <extension> element MUST contain a child <secDNS:create> element which names the extension namespace. You only need this if the client wants to link this extension's data to the domain object 🫶 The <secDNS:create> element has these child elements:
- An OPTIONAL
<secDNS:maxSigLife>element, which is a child's preference for how many seconds after signature generation the parent's signature on the DS information the child gave will expire ⏳maxSigLifeis explained in Section 3.3. If the server doesn't support the<secDNS:maxSigLife>element, a 2102 error MUST be returned 🙈 - Zero or more
<secDNS:dsData>elements or<secDNS:keyData>elements, but not both 💜 The child elements of<secDNS:dsData>are in Section 4.1, and the child elements of<secDNS:keyData>are in Section 4.2.
Example <create> Command for a Secure Delegation Using the DS Data Interface:
Here's a full example with the DS Data Interface 🌸
<?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">
<command>
<create>
<domain:create
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<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.1">
<secDNS:maxSigLife>604800</secDNS:maxSigLife>
<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 Using the DS Data Interface with OPTIONAL Key Data:
Same vibe, but this time the DS data also carries key 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">
<command>
<create>
<domain:create
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<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.1">
<secDNS:maxSigLife>604800</secDNS:maxSigLife>
<secDNS:dsData>
<secDNS:keyTag>12345</secDNS:keyTag>
<secDNS:alg>3</secDNS:alg>
<secDNS:digestType>1</secDNS:digestType>
<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
<secDNS:keyData>
<secDNS:flags>257</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>Example <create> Command for a Secure Delegation Using the Key Data Interface:
And last but not least, the Key Data Interface version 💖
<?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">
<command>
<create>
<domain:create
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<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.1">
<secDNS:keyData>
<secDNS:flags>257</secDNS:flags>
<secDNS:protocol>3</secDNS:protocol>
<secDNS:alg>1</secDNS:alg>
<secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
</secDNS:keyData>
</secDNS:create>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>When a <create> command has been processed successfully, the EPP response is exactly what the EPP domain mapping [RFC5731] describes ✅
5.2.2. EPP <delete> Command
This extension doesn't add any elements to the EPP <delete> command or the <delete> response from the EPP domain mapping [RFC5731] 🦋
5.2.3. EPP <renew> Command
Same deal here: no new elements for the EPP <renew> command or <renew> response in the EPP domain mapping [RFC5731] 🌈
5.2.4. EPP <transfer> Command
And for the EPP <transfer> command: this extension adds nothing to it or to the <transfer> response in the EPP domain mapping [RFC5731] 🧚 Main character energy, but make it minimal 💅
5.2.5. EPP <update> Command ✨
Okay bestie, this is the <update> command, and it's giving main character energy 🔥. 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 is a transform operation that lets a client modify the attributes of a domain object 🦋. Besides the regular EPP command elements from the domain mapping, the command MUST contain an <extension> element. That <extension> element MUST contain a child <secDNS:update> element that identifies the extension namespace, but only if the client wants to update the domain object with data from this extension 🎀.
The <secDNS:update> element holds a <secDNS:add> element to add security information to a delegation, a <secDNS:rem> element to remove security information from a delegation, or a <secDNS:chg> element to change existing security information 🌸. At least one <secDNS:add>, <secDNS:rem>, or <secDNS:chg> element MUST be provided 🍓. The order of <secDNS:rem> and <secDNS:add> matters a lot here, because the server MUST first remove the existing elements before adding the new ones 😭.
The <secDNS:update> element also has an OPTIONAL "urgent" attribute 🔥. Clients use it to ask the server operator to finish and apply the update with high priority. This attribute takes boolean values, as described in Section 3.2, and the default is boolean false. "High priority" is relative to the standard server operator policies, which are set through an out-of-band mechanism 🧚. A server MUST return EPP error result code 2102 if "urgent" is specified with a value of boolean true and the server doesn't support it 💀. A server MUST return EPP error result code 2306 if the server supports "urgent" but an urgent update (one with an "urgent" value of boolean true) can't be completed with high priority 🙈.
The <secDNS:update> element contains the following child elements:
- An OPTIONAL
<secDNS:rem>element that contains a<secDNS:all>element, or one or more<secDNS:dsData>or<secDNS:keyData>elements that are used to remove security data from a delegation ✨.- The
<secDNS:all>element removes all DS and key data when its value is boolean true. A value of boolean false does nothing. Removing all DS information can take away the parent's ability to secure the delegation to the child zone 😱. - The
<secDNS:dsData>element is part of the DS Data Interface. It uniquely defines the DS record to remove by using all four elements:<secDNS:keyTag>,<secDNS:alg>,<secDNS:digestType>, and<secDNS:digest>. Together those are guaranteed to be unique 💜. - The
<secDNS:keyData>element is part of the Key Data Interface. It uniquely defines the key data to remove by using all four elements:<secDNS:flags>,<secDNS:protocol>,<secDNS:alg>, and<secDNS:pubKey>. Those are guaranteed to be unique too 🌈. One key can create more than one DS record, so removing a key could remove more than one DS record 👀.
- The
- An OPTIONAL
<secDNS:add>element that adds security information to an existing set 🦋. The<secDNS:add>element MUST contain one or more<secDNS:dsData>or<secDNS:keyData>elements 🎀. The child elements of<secDNS:dsData>are described in Section 4.1, and the child elements of<secDNS:keyData>are described in Section 4.2 📚. - An OPTIONAL
<secDNS:chg>element that contains security information to be changed 🌸. The<secDNS:chg>element has the following child element:- An OPTIONAL
<secDNS:maxSigLife>element that indicates a child's preference for how many seconds after signature generation the parent's signature on the DS information the child provided will expire 🕰️.maxSigLifeis described in Section 3.3. If the server doesn't support the<secDNS:maxSigLife>element, a 2102 error MUST be returned 🚨.
- An OPTIONAL
Example <update> Command, Adding and Removing DS Data Using the DS Data Interface:
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: <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: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:dsData>
C: <secDNS:keyTag>12345</secDNS:keyTag>
C: <secDNS:alg>3</secDNS:alg>
C: <secDNS:digestType>1</secDNS:digestType>
C: <secDNS:digest>38EC35D5B3A34B33C99B</secDNS:digest>
C: </secDNS:dsData>
C: </secDNS:rem>
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, Updating the maxSigLife:
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: <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: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:chg>
C: <secDNS:maxSigLife>605900</secDNS:maxSigLife>
C: </secDNS:chg>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>Example <update> Command, Adding and Removing Key Data Using the Key Data Interface, and Setting maxSigLife:
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: <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: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:keyData>
C: <secDNS:flags>257</secDNS:flags>
C: <secDNS:protocol>3</secDNS:protocol>
C: <secDNS:alg>1</secDNS:alg>
C: <secDNS:pubKey>AQPJ////4QQQ</secDNS:pubKey>
C: </secDNS:keyData>
C: </secDNS:rem>
C: <secDNS:add>
C: <secDNS:keyData>
C: <secDNS:flags>257</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:add>
C: <secDNS:chg>
C: <secDNS:maxSigLife>605900</secDNS:maxSigLife>
C: </secDNS:chg>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>Example <update> Command, Removing DS Data with <secDNS:dsData> Using the DS Data Interface:
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: <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: <secDNS:update
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
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:rem>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>Example <update> Command, Removing all DS and Key Data Using <secDNS:rem> with <secDNS:all>:
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: <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: <secDNS:update urgent="true"
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0">
C: <secDNS:rem>
C: <secDNS:all>true</secDNS:all>
C: </secDNS:rem>
C: </secDNS:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>Example Urgent <update> Command, Replacing all DS Data Using the DS Data Interface:
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: <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: <secDNS:update urgent="true"
C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
C: <secDNS:rem>
C: <secDNS:all>true</secDNS:all>
C: </secDNS:rem>
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>When an extended <update> command has been processed successfully, the EPP response is as described in the EPP domain mapping [RFC5731] 🌟.
6. Formal Syntax ✨
okay bestie, the schema is the ultimate source of truth 💖 an EPP object mapping is written in XML Schema notation, and this one is complete enough that a machine can validate EPP XML instances automatically 🤖 the BEGIN and END lines are not part of the schema. they're just bookmarks so URI registration knows where the schema starts and stops 🎀
here's the copyright notice and license, word for word, because legal text is not the place to get creative 💅
Copyright (c) 2010 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.and now the schema itself 🌈
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
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:dsOrKeyType"/>
<element name="update" type="secDNS:updateType"/>
<!--
Child elements supporting either the
dsData or the keyData interface.
-->
<complexType name="dsOrKeyType">
<sequence>
<element name="maxSigLife" type="secDNS:maxSigLifeType"
minOccurs="0"/>
<choice>
<element name="dsData" type="secDNS:dsDataType"
maxOccurs="unbounded"/>
<element name="keyData" type="secDNS:keyDataType"
maxOccurs="unbounded"/>
</choice>
</sequence>
</complexType>
<!--
Definition for the maximum signature lifetime (maxSigLife)
-->
<simpleType name="maxSigLifeType">
<restriction base="int">
<minInclusive value="1"/>
</restriction>
</simpleType>
<!--
Child elements of dsData used for dsData interface
-->
<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="keyData" type="secDNS:keyDataType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Child elements of keyData used for keyData interface
and optionally with dsData interface
-->
<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>
<!--
Definition for the public key
-->
<simpleType name="keyType">
<restriction base="base64Binary">
<minLength value="1"/>
</restriction>
</simpleType>
<!--
Child elements of the <update> element.
-->
<complexType name="updateType">
<sequence>
<element name="rem" type="secDNS:remType"
minOccurs="0"/>
<element name="add" type="secDNS:dsOrKeyType"
minOccurs="0"/>
<element name="chg" type="secDNS:chgType"
minOccurs="0"/>
</sequence>
<attribute name="urgent" type="boolean" default="false"/>
</complexType>
<!--
Child elements of the <rem> command.
-->
<complexType name="remType">
<choice>
<element name="all" type="boolean"/>
<element name="dsData" type="secDNS:dsDataType"
maxOccurs="unbounded"/>
<element name="keyData" type="secDNS:keyDataType"
maxOccurs="unbounded"/>
</choice>
</complexType>
<!--
Child elements supporting the <chg> element.
-->
<complexType name="chgType">
<sequence>
<element name="maxSigLife" type="secDNS:maxSigLifeType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Child response elements.
-->
<element name="infData" type="secDNS:dsOrKeyType"/>
</schema>
END7. Internationalization Considerations 🌸
okay so EPP is written in XML, and XML is literally built for Unicode 🌍 it natively handles the Unicode character set and its more compact encodings, including UTF-8 [RFC3629]. conformant XML processors recognize both UTF-8 and UTF-16 [RFC2781] 💜
XML does let you pick other character encodings through an encoding attribute in the <?xml?> declaration, but in environments where parsers don't all support the same encodings, use of UTF-8 is RECOMMENDED ✨ so yeah, UTF-8 is the move 🫶
this extension is built on the EPP domain mapping [RFC5731], so the internationalization requirements in that mapping [RFC5731] are followed here too. this extension does not override any of the internationalization features of the EPP domain mapping [RFC5731] 🦋
8. IANA Considerations 🧚
this document uses URNs to describe XML namespaces and XML schemas, following the registry mechanism described in RFC 3688 [RFC3688] 🌈 IANA has completed two URI assignments already, and they look like this:
Registration request for the extension namespace:
URI: urn:ietf:params:xml:ns:secDNS-1.1
Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification.Registration request for the extension XML schema:
URI: urn:ietf:params:xml:schema:secDNS-1.1
Registrant Contact: IESG
XML: See the "Formal Syntax" section of this document.9. Security Considerations 💀
okay this section is serious, bestie, so let's take it seriously 😭 the mapping extensions in this document don't give you any security services beyond what EPP [RFC5730], the EPP domain name mapping [RFC5731], and the protocol layers EPP uses already provide. all the security considerations in those other specs apply here too 🔒
now the big one 👑 just like with other domain object transforms, the EPP transform operations 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 RFC 5730 [RFC5730]. if any client other than the sponsoring client tries to transform a domain object, that attempt MUST be rejected with an appropriate EPP authorization error 🚫
this provisioning service exchanges info that can have an operational impact on the DNS, so a trust relationship MUST exist between the EPP client and server 🤝 and provisioning of public key information MUST only be done after the identities of both parties have been confirmed using a strong authentication mechanism 🔐
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. that means man-in-the-middle attacks are possible, whether from direct client activity or from inadvertent client data manipulation 🙈
accepting a false key as a server operator can have significant 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 namespace, and query responses can't be trusted. if a key gets compromised, a client can either remove the compromised info or update the delegation info via EPP commands using the "urgent" attribute 🚨
for operational scenarios that need a quick removal of a secure domain delegation, there's a two-step process 🪜 first, remove the security credentials with an "urgent" update, as described above. then, 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 a much more drastic step, so think it through carefully before you use it ⚠️
data validity checking and Delegation Signer record creation at the server both take computational resources. a purposeful or accidental denial-of-service attack is possible if a client sends a bunch of update operations that go past what 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 🛡️
signature lifetime values sent by clients are requests, and they can be rejected 🙅♀️ blindly accepting them can really hurt a server's processing capabilities, so server operators SHOULD seriously consider implementation rules that limit the range of acceptable signature lifetime values to counter these potential problems 🥺
10. Acknowledgements 💜
the authors would like to thank the following people, who made significant contributions to this document 🫶
David Blacka, Howard Eland, Patrik Faltstrom, Olafur Gudmundsson, Bernie Hoeneisen, Ed Lewis, Klaus Malorny, Alexander Mayrhofer, Patrick Mevzek, David Smith, Andrew Sullivan, and Srikanth Veeramachaneni.
this document replaces RFC 4310 [RFC4310]. for more acknowledgements, check the Acknowledgements section of that RFC 🎀
this document also incorporates feedback from early implementers on the PROVREG mailing list, and from users 🌸
11. References ✨
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
- [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
- [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009.
- [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, August 2009.
- [W3C.REC-xml-20001006] Maler, E., Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>. - [W3C.REC-xmlschema-1-20010502] Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures", World Wide Web Consortium FirstEdition REC-xmlschema-1-20010502, May 2001,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502>. - [W3C.REC-xmlschema-2-20010502] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", World Wide Web Consortium FirstEdition REC-xmlschema-2-20010502, May 2001,
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502>.
11.2. Informative References
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
- [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
- [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
- [RFC4310] Hollenbeck, S., "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4310, December 2005.
Appendix A. Changes from RFC 4310
Okay, this is the changelog 📝 It's basically the glow-up story from RFC 4310 to this one, and I'm obsessed with how much got cleaned up 💅
- Added the motivation in obsoleting RFC 4310 [RFC4310] to Section 1.
- Updated Section 1 to add an explicit statement about deprecation of RFC 4310.
- Added secDNS-1.0 and secDNS-1.1 abbreviation definitions in Section 1.1.
- Updated "Data validity checking at the server..." to "Data validity checking and Delegation Signer record creation at the server..." in Section 9.
- Added Section 2.
- Updated the second paragraph of Section 7 to clarify that the internationalization features of [RFC5731] are followed.
- Moved
<secDNS:rem>prior to<secDNS:add>to conform to the EPP order semantics for supporting<secDNS:all>with<secDNS:rem>to remove all data, and for supporting the replace semantics previously supported by<secDNS:chg>. - Added support for the use of the
<secDNS:all>boolean element under<secDNS:rem>to remove all DS or key data in place of using<secDNS:chg/>. - Updated
<secDNS:add>,<secDNS:rem>, and<secDNS:chg>to function in a consistent way to the other EPP RFCs. - Removed support for
<secDNS:rem>using just<secDNS:keyTag>. - Moved the
<secDNS:maxSigLife>element out of the<secDNS:dsData>and<secDNS:keyData>elements and directly under the<secDNS:create>element, under the<secDNS:chg>element of the<secDNS:update>element, and under the<secDNS:infData>element. Section 3.3 element was updated to better describe the<secDNS:maxSigLife>element, and references to the<secDNS:maxSigLife>element were updated throughout the document. - Replaced references to
urn:ietf:params:xml:schema:secDNS-1.0withurn:ietf:params:xml:schema:secDNS-1.1, and replaced "Two URI assignments have been completed by the IANA" with "Two URI assignments have been completed by the IANA" in Section 8. - Added "The
<secDNS:keyTag>element is represented as an unsignedShort [W3C.REC-xmlschema-2-20010502]" in Section 4.1. - Added "The
<secDNS:digest>element is represented as a hexBinary [W3C.REC-xmlschema-2-20010502]" in Section 4.1. - Added "The
<secDNS:pubKey>element is represented as a base64Binary [W3C.REC-xmlschema-2-20010502] with a minimum length of 1" in Section 4.2. - Combined "the command MUST contain an
<extension>element" with the following sentence in Section 5.2.1 and Section 5.2.5. - Added sentence "If the server does not support the
<secDNS:maxSigLife>element, a 2102 error MUST be returned" to Section 5.2.1 and Section 5.2.5. - Added sentence "This document replaces RFC 4310. Please see the Acknowledgements section in that RFC for additional acknowledgements" in Section 10.
- Added "This document incorporates feedback from implementers on the PROVREG mail list and users" as well as "This document obsoletes RFC 4310" in the Abstract.
- Removed all references to xsi:schemaLocation to be consistent with the other EPP RFCs.
- Added the "DS Data Interface and Key Data Interface" section.
- Moved the "create, add, remove, and replace Delegation Signer (DS) information" paragraph from the "Object Attributes" section to the "DS Data Interface" section.
- Replaced the element descriptions in the "EPP
<info>Command" section with a reference to the<secDNS:dsData>and<secDNS:keyData>elements described in the "DS Data Interface" and "Key Data Interface" sections, respectively. - Updated the "EPP
<info>Command" section examples to include both the DS Data Interface and the Key Data Interface. - Updated the "EPP
<create>Command" section to refer to both the use of<secDNS:dsData>and<secDNS:keyData>described in the "DS Data Interface" and "Key Data Interface" sections, respectively. - Updated the "EPP
<create>Command" section examples to include both the DS Data Interface and the Key Data Interface. - Updated the "EPP
<update>Command" section to describe the use of<secDNS:add>,<secDNS:rem>, and<secDNS:chg>together. - Updated the "EPP
<update>Command" section examples to include both the DS Data Interface and the Key Data Interface. Also included additional examples of adding and removing DS data or key data. - Updated the "Formal Syntax" section with the updated XML schema.
- Updated the Acknowledgements section with a new list of contributors.
- Replaced references to RFC 3730 with references to RFC 5730.
- Replaced references to RFC 3731 with references to RFC 5731.
- Added clarification on when the extension MUST be included for each of the commands and responses (
<secDNS:create>,<secDNS:update>,<secDNS:infData>). - Changed "In addition, the EPP
<extension>element MUST contain a child<secDNS:infData>element" to "In addition, the EPP<extension>element SHOULD contain a child<secDNS:infData>element" and added "and based on server policy".
Authors' Addresses
Meet the authors 🫶 (James and Scott, the VeriSign crew who made this happen 🌸)
James Gould
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
US
EMail: jgould@verisign.com
Scott Hollenbeck
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
US
EMail: shollenbeck@verisign.com📦 where this page comes from
- ietf: rfc5910 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms