Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
obsoletes
- rfc-4310 — Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
Extracted elements (26)
RFC 4310 (secDNS-1.0) was obsoleted primarily because its removal of DS data based on the non-unique <secDNS:keyTag> element was unsafe. The replacement requires clients to specify all four DS data elements that are guaranteed to be unique, preventing accidental or ambiguous deletions.
The <secDNS:rem> element was moved before <secDNS:add> in the XML schema to conform to EPP order semantics, enabling a replace pattern: sending <secDNS:rem><secDNS:all>true</secDNS:all></secDNS:rem> followed by <secDNS:add> atomically replaces all DNSSEC data. This replaced the ambiguous <secDNS:chg> replace behavior from RFC 4310.
Two distinct interfaces are defined: the DS Data Interface (for 'thin' DNSSEC servers where the client generates DS records) and the Key Data Interface (for 'thick' DNSSEC servers that accept only key data and generate the DS records themselves). This accommodates different registry deployment models without requiring a single approach.
During a migration period, the version of <secDNS:infData> returned by the server in response to a <domain:info> SHOULD depend on which <extURI> elements the client included in the EPP <login> command: return secDNS-1.1 if that namespace URI was included, secDNS-1.0 if only secDNS-1.0 was included, and omit the element entirely if neither was included.
secDNS-1.1 (this document) obsoletes secDNS-1.0 (RFC 4310). If a server announces support for both in the EPP greeting, clients supporting both versions SHOULD prefer secDNS-1.1. A server migrating between versions SHOULD support both for a reasonable migration period.
A server MUST return EPP error result code 2306 if it supports the 'urgent' attribute but an urgent update (with urgent='true') cannot be completed with high priority. This distinguishes the case of unsupported feature (2102) from a supported but currently unserviceable request (2306).
A server MUST support only one form of interface (DS Data Interface or Key Data Interface) within a single command or response; <secDNS:dsData> and <secDNS:keyData> MUST NOT be mixed, except when <secDNS:keyData> is a child of <secDNS:dsData> for server validation. The server MUST return EPP error 2306 if it receives a command using an unsupported interface.
For the EPP <update> command, the server MUST process <secDNS:rem> elements prior to <secDNS:add> elements. At least one <secDNS:add>, <secDNS:rem>, or <secDNS:chg> element MUST be provided in the <secDNS:update> element.
If a client wants to associate DNSSEC data with a domain on <create>, the command MUST contain an <extension> element and that element MUST contain a child <secDNS:create> element identifying the extension namespace.
If the server does not support the <secDNS:maxSigLife> element, it MUST return EPP error result code 2102 when a client includes this element in a <secDNS:create> or <secDNS:chg> element. A server MUST also return 2102 if the 'urgent' attribute is specified as true but the server does not support it.
In the DS Data Interface, it is RECOMMENDED that the child zone operator have key data online in the DNS tree to allow the parent zone administrator to validate the data. The key data SHOULD have the Secure Entry Point (SEP) bit set as described in RFC 3757 and RFC 4034.
The server MUST support use of only one interface form (DS Data or Key Data) across all <secDNS:create>, <secDNS:update>, and <secDNS:infData> elements, except during a defined transition period during which the server MAY support both on a per-domain basis.
When an <info> command is processed successfully, the EPP <extension> element SHOULD contain a child <secDNS:infData> element if the domain object has data associated with this extension and based on server policy. The element contains either <secDNS:dsData> or <secDNS:keyData> elements, but not both.
The DS Data Interface uses the <secDNS:dsData> element for creates, adds, removes, and <domain:info> responses. It contains four required child elements: <secDNS:keyTag> (unsignedShort), <secDNS:alg> (algorithm number), <secDNS:digestType> (digest algorithm identifier), and <secDNS:digest> (hexBinary). An optional <secDNS:keyData> child may be included for server validation.
The Key Data Interface uses the <secDNS:keyData> element for creates, adds, removes, and <domain:info> responses. It contains four required child elements: <secDNS:flags> (unsignedShort), <secDNS:protocol> (unsignedByte), <secDNS:alg> (unsignedByte), and <secDNS:pubKey> (base64Binary, minimum length 1). The server generates DS data from this key data based on server policy.
The <secDNS:maxSigLife> element represents a child's preference in seconds for the signature lifetime on the parent's DS information. It is an OPTIONAL element expressed as an extended XML Schema 'int' with a minimum value of 1. If not provided or unsupported, the server operator's default signature expiration policy applies.
The <secDNS:rem> element supports removing DS or key data via three exclusive sub-choices: <secDNS:all> (boolean true removes all DS and key data), one or more <secDNS:dsData> elements (DS Data Interface), or one or more <secDNS:keyData> elements (Key Data Interface). The <secDNS:dsData> removal requires all four fields to uniquely identify the record.
The <secDNS:update> element contains optional <secDNS:rem>, <secDNS:add>, and <secDNS:chg> child elements for modifying DNSSEC data on a domain delegation. It also carries an optional 'urgent' boolean attribute (default false) allowing clients to request high-priority processing of the update. At least one of rem, add, or chg MUST be provided.
This document registers two URIs in the IETF XML Registry (RFC 3688): the extension namespace URI 'urn:ietf:params:xml:ns:secDNS-1.1' and the extension XML schema URI 'urn:ietf:params:xml:schema:secDNS-1.1'. Both are registered with IESG as the registrant contact.
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, because the exchanged information can have direct operational impact on the DNS.
Data validity checking and DS record creation at the server require computational resources. Server operators SHOULD take steps to manage command load to minimize the risk of a denial-of-service attack. Server operators SHOULD also limit the range of acceptable signature lifetime values (maxSigLife) to counter potential adverse situations.
EPP transform operations on domain objects MUST be restricted to the sponsoring client as authenticated per RFC 5730 Sections 2.9.1.1 and 7. Any attempt by a non-sponsoring client to perform a transform MUST be rejected with an appropriate EPP authorization error.
If a key is compromised, the client can use an 'urgent' update to quickly remove the compromised credentials. For complete removal of a secure delegation, the domain can be set to 'clientHold' or 'serverHold' status after removing the DNSSEC credentials via urgent update.
Man-in-the-middle attacks are possible since an EPP client may act as an agent for a zone administrator sending delegation information to be signed by the server. Acceptance of a false key can cause the child and parent zones to be inconsistent, yielding untrustworthy DNS query responses or breaking the secure delegation entirely.
The <secDNS:dsData> element's fields encode as: <secDNS:keyTag> as unsignedShort (16-bit), <secDNS:alg> as unsignedByte (8-bit algorithm number), <secDNS:digestType> as unsignedByte (8-bit digest algorithm identifier), and <secDNS:digest> as hexBinary. Together these four fields are guaranteed to uniquely identify a DS record.
The <secDNS:keyData> element's fields encode as: <secDNS:flags> as unsignedShort (16-bit DNSKEY flags field), <secDNS:protocol> as unsignedByte (must be 3 per RFC 4034), <secDNS:alg> as unsignedByte (algorithm number), and <secDNS:pubKey> as base64Binary with minimum length of 1. These four fields together uniquely identify a DNSKEY record.