Extensible Provisioning Protocol (EPP) Mapping for DNS Time-to-Live (TTL) Values
Extracted elements (27)
An empty <ttl:ttl> element (rather than a deletion command or special value) was chosen to signal 'reset to server default', providing a clean mechanism within a single create/update command to restore a record type's TTL to its default without a separate operation.
The document does not enumerate or restrict DNS record types allowable in the 'custom' attribute in order to facilitate forward compatibility with future DNS protocol changes, eliminating the need to update this document when new above-zone-cut record types are specified.
Two <info> modes (Default and Policy) were defined: Default Mode returns only non-default TTLs to minimize response size, while Policy Mode returns all supported record types with min/default/max bounds so clients can discover server policy without trial-and-error.
DS record TTL management is only applicable when the server also implements the DNSSEC EPP extension (RFC 5910). DNAME record TTL management is only applicable when the server implements IDN variants using DNAME records.
The extension applies to both the EPP domain name mapping (RFC 5731) and the host object mapping (RFC 5732). A and AAAA TTL management depends on whether a server uses the host object model or the host attribute model; the applicable object type differs between the two models.
A conforming implementation MUST NOT require the use of specific namespace prefixes (such as 'ttl'). Implementations MUST support both '0'/'false' and '1'/'true' lexical representations for xs:boolean attributes.
A server supporting host objects that receives a command attempting to set TTL values for A and AAAA records on a domain object MUST respond with a 2306 'Parameter value policy' error. EPP servers using the host attribute model MAY allow clients to set A and AAAA TTL values for domain objects.
A server that receives a <create> or <update> command that includes a restricted record type MUST respond with a 2306 'Parameter value policy' error. Clients can discover permitted record types via a Policy Mode <info> command.
EPP servers implementing this extension MUST restrict accepted DNS record types to those registered in IANA-RRTYPES and appropriate for use above a zone cut. A server receiving a <create> or <update> command attempting to set TTL values for inapplicable DNS record types MUST respond with a 2306 'Parameter value policy' error.
EPP servers implementing this extension SHOULD use TTL values provided by clients for DNS records published for domain and host objects. Servers using the host attribute model SHOULD use NS, A, and/or AAAA TTL values specified for the domain object when publishing those records derived from host attributes.
If an EPP server receives a <create> or <update> command containing a TTL value outside the server's permitted range, it MUST reject the command with a 2004 'Parameter value range error' response.
In Default Mode (policy attribute is '0' or 'false'), the EPP <info> response MUST contain <ttl:ttl> records for all DNS record types with non-default TTL values, and these elements MUST NOT have 'min', 'default', or 'max' attributes.
In Policy Mode (policy attribute is '1' or 'true'), the EPP <info> response MUST contain <ttl:ttl> records for all supported DNS record types regardless of whether those types are in use, and these elements MUST have the 'min', 'default', and 'max' attributes.
It is RECOMMENDED that guidance be provided to users clarifying that TTL changes are only effective in shortening transition periods if implemented at least one full current-TTL period before the planned DNS record change, accounting also for the latency between EPP command receipt and DNS publication.
Registry operators SHOULD implement limits on maximum and minimum accepted TTL values that are narrower than those permitted by the XML schema (0 to 2147483647), to prevent excessively high or low TTLs from causing operational issues on either side of the zone cut.
The 'for' attribute on <ttl:ttl> is REQUIRED in both commands and responses, and MUST have one of the values: NS, DS, DNAME, A, AAAA, or custom. If 'for' is 'custom', the element MUST also have a 'custom' attribute containing a DNS record type conforming to the regex in RFC 6895 Section 3.1 and registered in IANA-RRTYPES.
The 'min', 'default', and 'max' attributes MUST NOT be present in EPP commands; they MAY be present in EPP responses. When present, 'min' MUST be lower than 'max', and 'default' MUST be between 'min' and 'max' inclusively.
The <ttl:create> element is used in EPP <create> commands and MUST contain one or more <ttl:ttl> records. The <ttl:update> element is used in EPP <update> commands and MUST contain one or more <ttl:ttl> records. Both are placed in the <extension> element of the command.
The <ttl:infData> response container element appears in <info> responses and contains one or more <ttl:ttl> elements. The XML schema enforces uniqueness of the 'for' attribute across all <ttl:ttl> children within a single create, update, or infData container.
The <ttl:info> element is used by clients in EPP <info> commands to request TTL data. It has a single optional boolean 'policy' attribute defaulting to 'false', selecting between Default Mode (non-default TTLs only) and Policy Mode (all supported types with min/default/max bounds).
The <ttl:ttl> element defines TTL values for DNS resource records associated with domain and host objects. It has a required 'for' attribute specifying the DNS record type (NS, DS, DNAME, A, AAAA, or custom), and optional 'min', 'default', and 'max' attributes that MUST NOT appear in commands but MAY appear in responses.
IANA has registered the XML namespace 'urn:ietf:params:xml:ns:epp:ttl-1.0' and schema 'urn:ietf:params:xml:schema:epp:ttl-1.0' in the IETF XML Registry (RFC 3688), with IESG as registrant contact.
IANA has registered this extension ('Extensible Provisioning Protocol (EPP) Mapping for DNS Time-to-Live (TTL) Values') in the 'Extensions for the Extensible Provisioning Protocol (EPP)' registry (RFC 7451) as a Standards Track document applicable to any TLD.
An attacker who compromises a registrar customer account could make unauthorized NS/glue record changes and then increase associated TTLs so the malicious changes persist in caches long after detection. Client implementations should enforce upper TTL limits and apply best practices for credential management, MFA, and risk-based access control.
Short TTLs on delegation records enhance the effectiveness of fast flux DNS techniques, where malicious actors rapidly change DNS configuration to evade takedown. Server operators should set a lower TTL limit that accounts for this risk, and client implementations should consider controls to deter abusive behavior as outlined in ICANN SAC-025.
Out-of-band TTL changes: server operators MAY change TTL values outside the EPP <update> flow to address operational or security issues. Servers MAY also implement automatic TTL reset to default after a configurable period. When an out-of-band change occurs, servers MAY notify the sponsoring client via the EPP Change Poll Extension (RFC 8590).
The <ttl:ttl> element content is a union type (ttlOrNull) that is either a non-negative integer (0–2147483647, representing seconds) or an empty string indicating the server's default TTL should be applied. The TTL value is encoded as an xs:nonNegativeInteger.