Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
obsoleted by
- rfc-5910 — Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
Extracted elements (24)
Key data provided by a client maps to DNSKEY RR presentation formats, but the server is not obligated to use it. The server MAY issue out-of-band DNS queries to retrieve key data from the registered domain's apex to independently validate the DS information provided.
The 'urgent' attribute on <secDNS:update> allows clients to signal high-priority processing to the server operator, with 'high priority' defined relative to standard server operator policies determined via out-of-band mechanisms. The default is false.
This extension is specifically designed for EPP version 1.0 as described in RFC 3730 and extends the EPP domain name mapping of RFC 3731. The elements, attributes, and values described here MUST inherit the internationalization conventions of the higher-layer domain and core protocol structures.
A client SHOULD specify the same <secDNS:maxSigLife> value for all <secDNS:dsData> elements associated with a domain; if not present or if multiple values are requested, the server's default signature expiration policy applies.
A server operator MUST return EPP error result code 2306 if an urgent update (indicated by 'urgent' attribute set to boolean true) cannot be completed with high priority.
Boolean values MUST be represented in the XML Schema format described in Part 2 of the W3C XML Schema recommendation.
Maximum signature lifetime values MUST be represented in seconds using an extended XML Schema 'int' format restricted to a minimum value of one.
The key data associated with DS information SHOULD have the Secure Entry Point (SEP) bit set as described in RFC 3757, and it is RECOMMENDED that the child zone operator have this key data online in the DNS tree.
The server MUST abort command processing and respond with an appropriate EPP error if values provided by the client cannot be accepted for syntax or policy reasons, for both <create> and <update> commands.
Use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists, as an extension of the EPP domain mapping.
When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in the EPP domain mapping, and the EPP <extension> element MUST contain a child <secDNS:infData> element identifying the extension namespace and schema location.
When creating a domain with DNSSEC data, the EPP <create> command MUST contain an <extension> element, which MUST contain a <secDNS:create> child element, which in turn MUST contain one or more <secDNS:dsData> elements.
XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation, because XML is case sensitive.
The <secDNS:dsData> element carries delegation signer (DS) information and contains four required fields: <secDNS:keyTag> (key tag value), <secDNS:alg> (algorithm number), <secDNS:digestType> (digest type), and <secDNS:digest> (digest value), plus optional <secDNS:maxSigLife> and <secDNS:keyData> child elements.
The <secDNS:keyData> element carries DNSKEY RR data as input to the DS hash calculation, containing <secDNS:flags> (unsignedShort), <secDNS:protocol> (unsignedByte), <secDNS:alg> (unsignedByte), and <secDNS:pubKey> (base64Binary with minimum length 1).
The <secDNS:update> element supports three mutually exclusive child operations: <secDNS:add> to add DS records to an existing set, <secDNS:rem> to remove DS records by key tag, and <secDNS:chg> to replace all existing DS records. It also carries an optional boolean 'urgent' attribute (default false).
This document registers two URIs in the IETF XML Registry (RFC 3688): the extension namespace URI 'urn:ietf:params:xml:ns:secDNS-1.0' and the extension XML schema URI 'urn:ietf:params:xml:schema:secDNS-1.0', both with IESG as 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 exchanged data can have operational impact on the DNS.
Acceptance of a false key by a server operator can produce significant operational consequences: child and parent zones MUST be consistent to secure the delegation properly, and inconsistent signatures will cause the delegation to disappear from the secure namespace, yielding untrustworthy query responses.
EPP transform operations for DNSSEC data MUST be restricted to the sponsoring client as authenticated per RFC 3730; any attempt by a non-sponsoring client to perform a transform operation MUST be rejected with an appropriate EPP authorization error.
Man-in-the-middle attacks are possible because an EPP client may be acting as an agent for a zone administrator sending delegation information to be signed. A compromised key can be removed or updated via EPP using the 'urgent' attribute.
Server operators SHOULD seriously consider limiting the range of acceptable signature lifetime values, as blind acceptance of client-supplied maxSigLife values can have an adverse impact on the server's processing capabilities.
Server operators SHOULD take steps to manage command load to minimize the risk of a denial-of-service attack, as data validity checking requires computational resources and excessive update requests can constitute an intentional or inadvertent DoS attack.
The dsDataType XML Schema defines keyTag as unsignedShort, alg as unsignedByte, digestType as unsignedByte, and digest as hexBinary. The maxSigLifeType restricts the XML Schema 'int' type to a minimum value of 1 (seconds). The keyType restricts base64Binary to a minimum length of 1.