<?xmlversion="1.0" encoding="utf-8"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITYRFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3688 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"> <!ENTITY RFC5731 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5731.xml"> <!ENTITY RFC5732 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5732.xml"> <!ENTITY RFC5910 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5910.xml">nbsp " "> <!ENTITYRFC6895 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml">zwsp "​"> <!ENTITYRFC6927 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6927.xml">nbhy "‑"> <!ENTITYRFC7451 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7451.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8590 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8590.xml"> <!ENTITY RFC9364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"> <!ENTITY RFC9499 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml">wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <?rfc strict="yes" ?> <?rfc toc="yes"?> <?rfc tocdepth="4"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?> <?rfc comments="yes" ?> <?rfc inline="yes" ?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-regext-epp-ttl-18" number="9803" ipr="trust200902" submissionType="IETF"consensus="true">consensus="true" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" updates="" obsoletes="" version="3" xml:lang="en"> <front> <title abbrev="TTLmappingMapping forEPP"> ExtensibleEPP">Extensible Provisioning Protocol (EPP)mappingMapping for DNSTime-To-LiveTime-to-Live (TTL)values </title>Values</title> <seriesInfo name="RFC" value="9803"/> <author fullname="Gavin Brown"> <organization>ICANN</organization> <address> <postal> <street>12025 Waterfront Drive, Suite 300</street> <city>Los Angeles</city> <region>CA</region> <code>90292</code><country>US</country><country>United States of America</country> </postal> <email>gavin.brown@icann.org</email> <uri>https://www.icann.org/</uri> </address> </author><date/> <area>Applications</area> <workgroup>Registration Protocols Extensions (regext)</workgroup><date month="June" year="2025"/> <area>ART</area> <workgroup>regext</workgroup> <keyword>EPP</keyword> <keyword>DNS</keyword> <keyword>TTL</keyword> <keyword>time-to-live</keyword> <abstract><t> This<t>This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage theTime-To-LiveTime-to-Live (TTL) value for domain name delegation records. </t> </abstract><note title="About this draft" removeInRFC="true"> <t> The source for this draft, and an issue tracker, may can be found at <eref target="https://github.com/gbxyz/epp-ttl-extension"/>. </t> </note></front> <middle><section title="Introduction"><section> <name>Introduction</name> <t> The principal output of any domain name registry system is a DNS zone file, which contains the delegation record(s) for names registered within a zone (such as a top-level domain). These records typically include one or more <tt>NS</tt> records, but may also include <tt>DS</tt> records for domains secured with DNSSEC(<xref target="RFC9364"/>),<xref target="RFC9364"/>, and <tt>DNAME</tt> records forIDNInternationalized Domain Name (IDN) variants(<xref target="RFC6927"/>).<xref target="RFC6927"/>. <tt>A</tt> and/or <tt>AAAA</tt> records may also be published for nameservers where they are required by DNS resolvers to avoid an infiniteloop. </t>loop.</t> <t> Typically, theTime-To-LiveTime-to-Live (TTL) value(TTL, see(see <xref section="5" sectionFormat="of" target="RFC9499"/>) of these records is determined by the registry operator. However, in some circumstances it may be desirable to allow the sponsoring client of a domain name to change the TTL values used for that domain's delegation: for example, to reduce the amount of time required to complete a change of DNS servers, DNSSEC deployment or key rollover, or to allow for fast rollback of suchchanges. </t>changes.</t> <t> This document describes an EPP extension to the domain name and host object mappings (described in <xref target="RFC5731"/> and <xref target="RFC5732"/>, respectively)whichthat allows the sponsor of a domain name or host object to change the TTL values of the resource record(s) associated with that object. It also describes how EPP servers should handle TTLs specified by EPP clients and how both partiesco-ordinatecoordinate to manage TTL values in response to changes in operational or securityrequirements. </t> <section title="Conventions usedrequirements.</t> <section> <name>Conventions Used inthis document">This Document</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>target="RFC2119"/> <xreftarget="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> <t> In this document's examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in these examples are provided only to illustrate element relationships and are not required features of thisprotocol. </t>protocol.</t> <t> A protocol client that is authorized to manage an existing object is described as a "sponsoring" client throughout thisdocument. </t>document.</t> <t> XML is case sensitive. Unless stated otherwise, the XML specifications and examples provided in this document <bcp14>MUST</bcp14> be interpreted in the character case presented in order to develop a conformingimplementation. </t>implementation.</t> <t> EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managedobjects. </t>objects.</t> <t> The XML namespace prefixes used in these examples (such as the string <tt>ttl</tt> in <tt>ttl:create</tt>) are solely for illustrative purposes. A conforming implementation <bcp14>MUST NOT</bcp14> require the use of these or any other specific namespaceprefixes. </t>prefixes.</t> <t> In accordance with<xref target="XSD-DATATYPES">SectionSection 3.2.2.1 of XML Schema Part 2:Datatypes</xref>,Datatypes <xref target="XSD-DATATYPES"/>, the allowable lexical representations for the <tt>xs:boolean</tt> datatype are the strings "<tt>0</tt>" and "<tt>false</tt>" for the concept 'false' and the strings "<tt>1</tt>" and "<tt>true</tt>" for the concept 'true'. Implementations <bcp14>MUST</bcp14> support both styles of lexicalrepresentation. </t>representation.</t> </section> <sectiontitle="Extension elements"anchor="extension-elements"><t> This<name>Extension Elements</name> <t>This extension adds additional elements to the EPP domain and hostmappings. </t>mappings.</t> <sectionanchor="ttl_element" title="Theanchor="ttl_element"> <name>The <ttl:ttl>element">Element</name> <t> The <tt><ttl:ttl></tt> element is used to define TTL values for the DNS resource records associated with domain and host objects. </t><t><tt><ttl:ttl></tt><t> <tt><ttl:ttl></tt> elements have the optional following attributes, depending on whether they appear in an EPP command or response: </t><ol> <li> "<tt>for</tt>", which is<dl newline="true"> <dt>"<tt>for</tt>"</dt> <dd> <bcp14>REQUIRED</bcp14> in both commands and responses, andwhichspecifies the DNS record type to which the TTL value pertains. This attribute <bcp14>MUST</bcp14> have one of the following values: "<tt>NS</tt>", "<tt>DS</tt>", "<tt>DNAME</tt>", "<tt>A</tt>", "<tt>AAAA</tt>" or"<tt>custom</tt>"; </li> <li> If"<tt>custom</tt>". </dd> <dt>"<tt>custom</tt>"</dt> <dd>If the value of the "<tt>for</tt>" attribute is "<tt>custom</tt>", then the <tt><ttl:ttl></tt> element <bcp14>MUST</bcp14> also have a "<tt>custom</tt>" attribute containing a DNS record type conforming with the regular expression in <xref sectionFormat="of" section="3.1" target="RFC6895"/>. Additionally, the record type <bcp14>MUST</bcp14> be registered with IANA in <xref target="IANA-RRTYPES"/>.</li> <li> "<tt>min</tt>", which</dd> <dt>"<tt>min</tt>"</dt> <dd> <bcp14>MUST NOT</bcp14> be present in EPP commands but <bcp14>MAY</bcp14> be present in EPP responses (see <xreftarget="info-command"/>), and whichtarget="info-command"/>). It is used by the server to indicate the lowest value that may beset; </li> <li> "<tt>default</tt>", whichset. </dd> <dt>"<tt>default</tt>"</dt> <dd> <bcp14>MUST NOT</bcp14> be present in EPP commands but <bcp14>MAY</bcp14> be present in EPP responses (see <xreftarget="info-command"/>), and whichtarget="info-command"/>). It is used by the server to indicate the defaultvalue; </li> <li> "<tt>max</tt>", whichvalue. </dd> <dt>"<tt>max</tt>"</dt> <dd> <bcp14>MUST NOT</bcp14> be present in EPP commands but <bcp14>MAY</bcp14> be present in EPP responses (see <xreftarget="info-command"/>), and whichtarget="info-command"/>). It is used by the server to indicate the highest value that may beset; </li> </ol>set. </dd> </dl> <t> When present, the value of the "<tt>min</tt>" attribute <bcp14>MUST</bcp14> be lower than the value of the "<tt>max</tt>" attribute. The "<tt>default</tt>" attribute <bcp14>MUST</bcp14> be between the "<tt>min</tt>" and "<tt>max</tt>" values,inclusively. </t>inclusively.</t> <sectiontitle="Element content"anchor="element-content"> <name>Element Content</name> <t> The XML schema found in <xref target="formal-syntax"/> of this document restricts the content of <tt><ttl:ttl></tt> elements to beeither: </t>either:</t> <ol><li> a<li>a non-negative integer, indicating the value of the TTL in seconds,or </li> <li> empty,or</li> <li>empty, in which case the server's default TTL for the given record type is to beapplied. </li>applied.</li> </ol> </section> <sectiontitle="Supported DNS record types"anchor="supported-dns-record-types"> <name>Supported DNS Record Types</name> <t> To facilitate forward compatibility with future changes to the DNS protocol, this document does not enumerate or restrict the DNS record types that can be included in the "<tt>custom</tt>" attribute of the <tt><ttl:ttl></tt>element. </t>element.</t> <t> The regular expressionwhichthat is used to validate the values of the "<tt>custom</tt>" attribute is based on the expression found in <xref sectionFormat="of" section="3.1" target="RFC6895"/>, and it is intended to match both existing and future RRTYPE mnemonics. This eliminates the need to update this document in the event that new DNS records that exist above a zone cut (<xref sectionFormat="of" section="7" target="RFC9499"/>) arespecified. </t>specified.</t> <t> Nevertheless, EPP serverswhichthat implement this extension <bcp14>MUST</bcp14> restrict the DNS record types that are accepted in <tt><create></tt> and <tt><update></tt> commands, and included in <tt><info></tt> responses, allowing only those types that are (a) registered in <xref target="IANA-RRTYPES"/> and (b) appropriate for use above a zonecut. </t>cut.</t> <t> A server that receives a <tt><create></tt> or <tt><update></tt> command that attempts to set TTL values for inapplicable DNS record types <bcp14>MUST</bcp14> respond with a 2306 "Parameter value policy"error. </t>error.</t> <t> As an illustrative example, a server <bcp14>MAY</bcp14> allow clients to specify TTL values for the following record types for domain objects: </t> <ol><li><tt>NS</tt>;<li> <tt>NS</tt>; </li><li><tt>DS</tt><li> <tt>DS</tt> (if the server also implements <xref target="RFC5910"/>); </li><li><tt>DNAME</tt><li> <tt>DNAME</tt> (if the server implements IDN variants using <tt>DNAME</tt> records). </li> </ol><section title="Glue records"><section> <name>Glue Records</name> <t> Glue records are described in <xref section="7" sectionFormat="of"target="RFC9499"/>. </t>target="RFC9499"/>.</t> <t> Serverswhichthat implement host objects(<xref target="RFC5732"/>)<xref target="RFC5732"/> <bcp14>MAY</bcp14> allow clients to specify TTL values for <tt>A</tt> and <tt>AAAA</tt> records for hostobjects. </t>objects.</t> <t> A server supporting host objectswhichthat receives a command that attempts to set TTL values for <tt>A</tt> and <tt>AAAA</tt> records on a domain object <bcp14>MUST</bcp14> respond with a 2306 "Parameter value policy"error. </t>error.</t> <t> EPP serverswhichthat use the"host attribute"host attribute model (described in <xref sectionFormat="of" section="1.1" target="RFC5731"/>) <bcp14>MAY</bcp14> allow clients to specify TTL values for <tt>A</tt> and <tt>AAAA</tt> records for domainobjects. </t>objects.</t> </section> </section> <sectionanchor="info-element" title="Theanchor="info-element"> <name>The <ttl:info>element">Element</name> <t> The <tt><ttl:info></tt> element is used by clients to request that the server include additional information in <tt><info></tt> responses for domain and hostobjects. </t>objects.</t> <t> It has a single <bcp14>OPTIONAL</bcp14><tt>policy</tt>"<tt>policy</tt>" attribute, which takes a boolean value with a default value of<tt>false</tt>. </t>"<tt>false</tt>".</t> <t> The semantics of this element are described in <xreftarget="info-command"/>. </t> <section title="Example"> <sourcecode><ttl:info policy="true"/></sourcecode> </section>target="info-command"/>.</t> <t>Below is an example of a <tt><ttl:info></tt> element with an explicit "<tt>policy</tt>" attribute:</t> <sourcecode type="xml"><![CDATA[ <ttl:info policy="true"/> ]]></sourcecode> </section> </section><section title="Examples"> <section title="Explicit<section> <name>Examples</name> <section> <name>Explicit TTLvalueValue (<create> or <update>command)"> <sourcecode><ttl:ttl for="NS">3600</ttl:ttl></sourcecode>Command)</name> <sourcecode type="xml"><![CDATA[ <ttl:ttl for="NS">3600</ttl:ttl> ]]></sourcecode> </section><section title="Explicit<section> <name>Explicit TTLvalueValue (<info>policy mode)"> <sourcecode><ttl:ttlPolicy Mode)</name> <sourcecode type="xml"><![CDATA[ <ttl:ttl for="NS" min="60" default="86400"max="172800">3600</ttl:ttl></sourcecode>max="172800">3600</ttl:ttl> ]]></sourcecode> </section><section title="Empty value indicating default<section> <name>Empty Value Indicating Default TTL (<create> or <update>command,Command, <info>default mode)"> <sourcecode><ttl:ttl for="NS"/></sourcecode>Default Mode)</name> <sourcecode type="xml"><![CDATA[ <ttl:ttl for="NS"/> ]]></sourcecode> </section><section title="Custom record type<section> <name>Custom Record Type (<create> or <update>command,Command, <info>default mode)"> <sourcecode><ttl:ttlDefault Mode)</name> <sourcecode type="xml"><![CDATA[ <ttl:ttl for="custom"custom="NEWRRTYPE">3600</ttl:ttl></sourcecode>custom="NEWRRTYPE">3600</ttl:ttl> ]]></sourcecode> </section> </section> </section> </section> <section> <name>EPP Command Mapping</name> <section> <name>EPP Query Commands</name> <sectiontitle="EPP command mapping"> <section title="EPP query commands"> <section anchor="info-command" title="EPPanchor="info-command"> <name>EPP <info>command">Command</name> <t> This extension defines an additional element for EPP <tt><info></tt> commands and responses for domain and hostobjects. </t>objects.</t> <t> The EPP <tt><info></tt> command is extended to support two differentmodes: </t>modes:</t> <ol><li> The<li>The Default Mode (<xref target="default-mode"/>), which requests the inclusion of all non-default TTL values in the response;and </li> <li> Theand</li> <li>The Policy Mode (<xref target="policy-mode"/>), which requests the inclusion of TTL information for all supported DNS record types in the response, along with the minimum,defaultdefault, and maximum values for thoserecords. </li>records.</li> </ol> <sectiontitle="Default Mode"anchor="default-mode"> <name>Default Mode</name> <t> If a server receives an <tt><info></tt> command for a domain or host objectwhichthat includes a <tt><ttl:info></tt> element with a "<tt>policy</tt>" attribute that is "<tt>0</tt>" or "<tt>false</tt>", then the EPP response <bcp14>MUST</bcp14> contain <tt><ttl:ttl></tt> records for all DNS record types that have non-default TTL values. These elements <bcp14>MUST NOT</bcp14> have the "<tt>min</tt>","<tt>default</tt>""<tt>default</tt>", and "<tt>max</tt>"attributes. </t>attributes.</t> <t>ExampleBelow is an example domain <tt><info></tt> command with a <tt><ttl:info></tt> element with a<tt>policy</tt>"<tt>policy</tt>" attribute that is<tt>false</tt>: </t> <sourcecode>C: <?xml"<tt>false</tt>":</t> <sourcecode type="xml" markers="false"><![CDATA[ C: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<command><command> C:<info><info> C:<domain:info<domain:info C:xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C:<domain:name>example.com</domain:name><domain:name>example.com</domain:name> C:</domain:info></domain:info> C:</info></info> C:<extension><extension> C:<ttl:info<ttl:info C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0" C:policy="false"/>policy="false"/> C:</extension></extension> C:</command></command> C:</epp> </sourcecode></epp> ]]></sourcecode> <t>ExampleBelow is an example domain <tt><info></tt> response to a command with a <tt><ttl:info></tt> element with a<tt>policy</tt>"<tt>policy</tt>" attribute that is<tt>false</tt>: </t> <sourcecode>S: <?xml"<tt>false</tt>":</t> <sourcecode type="xml" markers="false"><![CDATA[ S: <?xml version="1.0" encoding="utf-8"standalone="no"?>standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S:<response><response> S:<result code="1000"><result code="1000"> S:<msg>Command<msg>Command completedsuccessfully</msg>successfully</msg> S:</result></result> S:<resData><resData> S:<domain:infData<domain:infData S:xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S:<domain:name>example.com</domain:name><domain:name>example.com</domain:name> S:<domain:roid>EXAMPLE1-REP</domain:roid><domain:roid>EXAMPLE1-REP</domain:roid> S:<domain:status s="ok"/><domain:status s="ok"/> S:<domain:ns><domain:ns> S:<domain:hostObj>ns1.example.com</domain:hostObj><domain:hostObj>ns1.example.com</domain:hostObj> S:<domain:hostObj>ns1.example.net</domain:hostObj><domain:hostObj>ns1.example.net</domain:hostObj> S:</domain:ns></domain:ns> S:<domain:clID>ClientX</domain:clID><domain:clID>ClientX</domain:clID> S:<domain:crID>ClientX</domain:crID><domain:crID>ClientX</domain:crID> S:<domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate><domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate> S:<domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate><domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate> S:</domain:infData></domain:infData> S:</resData></resData> S:<extension><extension> S:<ttl:infData<ttl:infData S:xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> S:<ttl:ttl for="NS">172800</ttl:ttl><ttl:ttl for="NS">172800</ttl:ttl> S:<ttl:ttl for="DS">300</ttl:ttl><ttl:ttl for="DS">300</ttl:ttl> S:</ttl:infData></ttl:infData> S:<secDNS:infData<secDNS:infData S:xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> S:<secDNS:dsData><secDNS:dsData> S:<secDNS:keyTag>12345</secDNS:keyTag><secDNS:keyTag>12345</secDNS:keyTag> S:<secDNS:alg>13</secDNS:alg><secDNS:alg>13</secDNS:alg> S:<secDNS:digestType>2</secDNS:digestType><secDNS:digestType>2</secDNS:digestType> S:<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest><secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> S:</secDNS:dsData></secDNS:dsData> S:</secDNS:infData></secDNS:infData> S:</extension></extension> S:<trID><trID> S:<clTRID>ABC-12345</clTRID><clTRID>ABC-12345</clTRID> S:<svTRID>54322-XYZ</svTRID><svTRID>54322-XYZ</svTRID> S:</trID></trID> S:</response></response> S:</epp> </sourcecode></epp> ]]></sourcecode> <t>ExampleBelow is an example host <tt><info></tt> command with a <ttl:info> element with a<tt>policy</tt>"<tt>policy</tt>" attribute that is<tt>false</tt>: </t> <sourcecode>C: <?xml"<tt>false</tt>":</t> <sourcecode type="xml" markers="false"><![CDATA[ C: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<command><command> C:<info><info> C:<host:info<host:info C:xmlns:host="urn:ietf:params:xml:ns:host-1.0">xmlns:host="urn:ietf:params:xml:ns:host-1.0"> C:<host:name>ns1.example.com</host:name><host:name>ns1.example.com</host:name> C:</host:info></host:info> C:</info></info> C:<extension><extension> C:<ttl:info<ttl:info C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0" C:policy="false"/>policy="false"/> C:</extension></extension> C:</command></command> C:</epp> </sourcecode> <t> Example</epp> ]]></sourcecode> <t>Below is an example host <tt><info></tt> response to a command with a <ttl:info> element with a<tt>policy</tt>"<tt>policy</tt>" attribute that is<tt>false</tt>: </t> <sourcecode>S: <?xml"<tt>false</tt>":</t> <sourcecode type="xml" markers="false"><![CDATA[ S: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S:<response><response> S:<result code="1000"><result code="1000"> S:<msg>Command<msg>Command completedsuccessfully</msg>successfully</msg> S:</result></result> S:<resData><resData> S:<host:infData<host:infData S:xmlns:host="urn:ietf:params:xml:ns:host-1.0">xmlns:host="urn:ietf:params:xml:ns:host-1.0"> S:<host:name>ns1.example.com</host:name><host:name>ns1.example.com</host:name> S:<host:roid>NS1_EXAMPLE1-REP</host:roid><host:roid>NS1_EXAMPLE1-REP</host:roid> S:<host:status s="ok"/><host:status s="ok"/> S:<host:addr ip="v4">192.0.2.2</host:addr><host:addr ip="v4">192.0.2.2</host:addr> S:<host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr><host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr> S:<host:clID>ClientX</host:clID><host:clID>ClientX</host:clID> S:<host:crID>ClientX</host:crID><host:crID>ClientX</host:crID> S:<host:crDate>2023-11-08T10:14:55.0Z</host:crDate><host:crDate>2023-11-08T10:14:55.0Z</host:crDate> S:</host:infData></host:infData> S:</resData></resData> S:<extension><extension> S:<ttl:infData<ttl:infData S:xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> S:<ttl:ttl for="A">172800</ttl:ttl><ttl:ttl for="A">172800</ttl:ttl> S:<ttl:ttl for="AAAA">86400</ttl:ttl><ttl:ttl for="AAAA">86400</ttl:ttl> S:</ttl:infData></ttl:infData> S:</extension></extension> S:<trID><trID> S:<clTRID>ABC-12345</clTRID><clTRID>ABC-12345</clTRID> S:<svTRID>54322-XYZ</svTRID><svTRID>54322-XYZ</svTRID> S:</trID></trID> S:</response></response> S:</epp> </sourcecode></epp> ]]></sourcecode> </section> <sectiontitle="Policy Mode"anchor="policy-mode"> <name>Policy Mode</name> <t> If a server receives an <tt><info></tt> command for a domain or host objectwhichthat includes a <tt><ttl:info></tt> element with a "<tt>policy</tt>" attribute that is "<tt>1</tt>" or "<tt>true</tt>", then the EPP response <bcp14>MUST</bcp14> contain <tt><ttl:ttl></tt> records for all supported DNS record types, irrespective of whether those record types are actually in use by the object in question. These elements <bcp14>MUST</bcp14> have the "<tt>min</tt>","<tt>default</tt>""<tt>default</tt>", and "<tt>max</tt>"attributes. </t>attributes.</t> <t>ExampleBelow is an example domain <tt><info></tt> command requesting the serverpolicies: </t> <sourcecode>C: <?xmlpolicies:</t> <sourcecode type="xml" markers="false"><![CDATA[ C: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<command><command> C:<info><info> C:<domain:info<domain:info C:xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C:<domain:name>example.com</domain:name><domain:name>example.com</domain:name> C:</domain:info></domain:info> C:</info></info> C:<extension><extension> C:<ttl:info<ttl:info C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0" C:policy="true"/>policy="true"/> C:</extension></extension> C:</command></command> C:</epp> </sourcecode> <t> Example</epp> ]]></sourcecode> <t>Below is an example domain <tt><info></tt> response providing the serverpolicies: </t> <sourcecode>S: <?xmlpolicies:</t> <sourcecode type="xml" markers="false"><![CDATA[ S: <?xml version="1.0" encoding="utf-8"standalone="no"?>standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S:<response><response> S:<result code="1000"><result code="1000"> S:<msg>Command<msg>Command completedsuccessfully</msg>successfully</msg> S:</result></result> S:<resData><resData> S:<domain:infData<domain:infData S:xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S:<domain:name>example.com</domain:name><domain:name>example.com</domain:name> S:<domain:roid>EXAMPLE1-REP</domain:roid><domain:roid>EXAMPLE1-REP</domain:roid> S:<domain:status s="ok"/><domain:status s="ok"/> S:<domain:ns><domain:ns> S:<domain:hostObj>ns1.example.com</domain:hostObj><domain:hostObj>ns1.example.com</domain:hostObj> S:<domain:hostObj>ns1.example.net</domain:hostObj><domain:hostObj>ns1.example.net</domain:hostObj> S:</domain:ns></domain:ns> S:<domain:clID>ClientX</domain:clID><domain:clID>ClientX</domain:clID> S:<domain:crID>ClientX</domain:crID><domain:crID>ClientX</domain:crID> S:<domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate><domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate> S:<domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate><domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate> S:</domain:infData></domain:infData> S:</resData></resData> S:<extension><extension> S:<ttl:infData<ttl:infData S:xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> S:<ttl:ttl<ttl:ttl for="NS" S: min="3600" S: default="86400" S:max="172800">172800</ttl:ttl>max="172800">172800</ttl:ttl> S:<ttl:ttl<ttl:ttl for="DS" S: min="60" S: default="86400" S:max="172800">300</ttl:ttl>max="172800">300</ttl:ttl> S:</ttl:infData></ttl:infData> S:<secDNS:infData<secDNS:infData S:xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> S:<secDNS:dsData><secDNS:dsData> S:<secDNS:keyTag>12345</secDNS:keyTag><secDNS:keyTag>12345</secDNS:keyTag> S:<secDNS:alg>13</secDNS:alg><secDNS:alg>13</secDNS:alg> S:<secDNS:digestType>2</secDNS:digestType><secDNS:digestType>2</secDNS:digestType> S:<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest><secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> S:</secDNS:dsData></secDNS:dsData> S:</secDNS:infData></secDNS:infData> S:</extension></extension> S:<trID><trID> S:<clTRID>ABC-12345</clTRID><clTRID>ABC-12345</clTRID> S:<svTRID>54322-XYZ</svTRID><svTRID>54322-XYZ</svTRID> S:</trID></trID> S:</response></response> S:</epp> </sourcecode> <t> Example</epp> ]]></sourcecode> <t>Below is an example host <tt><info></tt> command requesting the serverpolicies: </t> <sourcecode>C: <?xmlpolicies:</t> <sourcecode type="xml" markers="false"><![CDATA[ C: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<command><command> C:<info><info> C:<host:info<host:info C:xmlns:host="urn:ietf:params:xml:ns:host-1.0">xmlns:host="urn:ietf:params:xml:ns:host-1.0"> C:<host:name>ns1.example.com</host:name><host:name>ns1.example.com</host:name> C:</host:info></host:info> C:</info></info> C:<extension><extension> C:<ttl:info<ttl:info C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0" C:policy="true"/>policy="true"/> C:</extension></extension> C:</command></command> C:</epp> </sourcecode> <t> Example</epp> ]]></sourcecode> <t>Below is an example host <tt><info></tt> response providing the serverpolicies: </t> <sourcecode>S: <?xmlpolicies:</t> <sourcecode type="xml" markers="false"><![CDATA[ S: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S:<response><response> S:<result code="1000"><result code="1000"> S:<msg>Command<msg>Command completedsuccessfully</msg>successfully</msg> S:</result></result> S:<resData><resData> S:<host:infData<host:infData S:xmlns:host="urn:ietf:params:xml:ns:host-1.0">xmlns:host="urn:ietf:params:xml:ns:host-1.0"> S:<host:name>ns1.example.com</host:name><host:name>ns1.example.com</host:name> S:<host:roid>NS1_EXAMPLE1-REP</host:roid><host:roid>NS1_EXAMPLE1-REP</host:roid> S:<host:status s="ok"/><host:status s="ok"/> S:<host:addr ip="v4">192.0.2.2</host:addr><host:addr ip="v4">192.0.2.2</host:addr> S:<host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr><host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr> S:<host:clID>ClientX</host:clID><host:clID>ClientX</host:clID> S:<host:crID>ClientX</host:crID><host:crID>ClientX</host:crID> S:<host:crDate>2023-11-08T10:14:55.0Z</host:crDate><host:crDate>2023-11-08T10:14:55.0Z</host:crDate> S:</host:infData></host:infData> S:</resData></resData> S:<extension><extension> S:<ttl:infData<ttl:infData S:xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> S:<ttl:ttl<ttl:ttl for="A" S: min="3600" S: default="86400" S:max="172800">172800</ttl:ttl>max="172800">172800</ttl:ttl> S:<ttl:ttl<ttl:ttl for="AAAA" S: min="3600" S: default="86400" S:max="172800">86400</ttl:ttl>max="172800">86400</ttl:ttl> S:</ttl:infData></ttl:infData> S:</extension></extension> S:<trID><trID> S:<clTRID>ABC-12345</clTRID><clTRID>ABC-12345</clTRID> S:<svTRID>54322-XYZ</svTRID><svTRID>54322-XYZ</svTRID> S:</trID></trID> S:</response></response> S:</epp> </sourcecode></epp> ]]></sourcecode> </section> </section> </section><section title="EPP transform commands"> <section title="EPP<section> <name>EPP Transform Commands</name> <section> <name>EPP <create>command">Command</name> <t> This extension defines an additional element for EPP <tt><create></tt> commands for domain and hostobjects. </t>objects.</t> <t> The <tt><command></tt> element of the <tt><create></tt> command <bcp14>MAY</bcp14> contain an <tt><extension></tt> elementwhichthat <bcp14>MAY</bcp14> contain a <tt><ttl:create></tt> element. This element <bcp14>MUST</bcp14> contain one or more <tt><ttl:ttl></tt> records as described in <xreftarget="extension-elements"/>. </t>target="extension-elements"/>.</t> <t>If an EPP server receives a <tt><create></tt> command containing a TTL value that is outside the server's permitted range, it <bcp14>MUST</bcp14> reject the command with a 2004 "Parameter value range error" response.</t> <t>ExampleBelow is an example domain <tt><create></tt>command: </t> <sourcecode>C: <?xmlcommand:</t> <sourcecode type="xml" markers="false"><![CDATA[ C: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<command><command> C:<create><create> C:<domain:create<domain:create C:xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C:<domain:name>example.com</domain:name><domain:name>example.com</domain:name> C:<domain:period unit="y">1</domain:period><domain:period unit="y">1</domain:period> C:<domain:ns><domain:ns> C:<domain:hostObj>ns1.example.com</domain:hostObj><domain:hostObj>ns1.example.com</domain:hostObj> C:<domain:hostObj>ns1.example.net</domain:hostObj><domain:hostObj>ns1.example.net</domain:hostObj> C:</domain:ns></domain:ns> C:<domain:authInfo><domain:authInfo> C:<domain:pw/><domain:pw/> C:</domain:authInfo></domain:authInfo> C:</domain:create></domain:create> C:</create></create> C:<extension><extension> C:<ttl:create<ttl:create C:xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> C:<ttl:ttl for="NS">172800</ttl:ttl><ttl:ttl for="NS">172800</ttl:ttl> C:<ttl:ttl for="DS">300</ttl:ttl><ttl:ttl for="DS">300</ttl:ttl> C:</ttl:create></ttl:create> C:<secDNS:create<secDNS:create C:xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> C:<secDNS:dsData><secDNS:dsData> C:<secDNS:keyTag>12345</secDNS:keyTag><secDNS:keyTag>12345</secDNS:keyTag> C:<secDNS:alg>13</secDNS:alg><secDNS:alg>13</secDNS:alg> C:<secDNS:digestType>2</secDNS:digestType><secDNS:digestType>2</secDNS:digestType> C:<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest><secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest> C:</secDNS:dsData></secDNS:dsData> C:</secDNS:create></secDNS:create> C:</extension></extension> C:<clTRID>ABC-12345</clTRID><clTRID>ABC-12345</clTRID> C:</command></command> C:</epp> </sourcecode> <t> Example</epp> ]]></sourcecode> <t>Below is an example host <tt><create></tt>command: </t> <sourcecode>C: <?xmlcommand:</t> <sourcecode type="xml" markers="false"><![CDATA[ C: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<command><command> C:<create><create> C:<host:create<host:create C:xmlns:host="urn:ietf:params:xml:ns:host-1.0">xmlns:host="urn:ietf:params:xml:ns:host-1.0"> C:<host:name>ns1.example.com</host:name><host:name>ns1.example.com</host:name> C:<host:addr ip="v4">192.0.2.2</host:addr><host:addr ip="v4">192.0.2.2</host:addr> C:<host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr><host:addr ip="v6">2001:db8::8:800:200c:417a</host:addr> C:</host:create></host:create> C:</create></create> C:<extension><extension> C:<ttl:create<ttl:create C:xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> C:<ttl:ttl for="A"/><ttl:ttl for="A"/> C:<ttl:ttl for="AAAA">86400</ttl:ttl><ttl:ttl for="AAAA">86400</ttl:ttl> C:</ttl:create></ttl:create> C:</extension></extension> C:<clTRID>ABC-12345</clTRID><clTRID>ABC-12345</clTRID> C:</command></command> C:</epp> </sourcecode> <t> If an EPP server receives a <tt><create></tt> command containing a TTL value that is outside the server's permitted range, it <bcp14>MUST</bcp14> reject the command with a <tt>2004</tt> "Parameter value range error" response. </t></epp> ]]></sourcecode> </section><section title="EPP<section> <name>EPP <update>command">Command</name> <t> This extension defines an additional element for EPP <tt><update></tt> commands for domain and hostobjects. </t>objects.</t> <t> The <tt><command></tt> element of the <tt><update></tt> command <bcp14>MAY</bcp14> contain an <tt><extension></tt> elementwhichthat <bcp14>MAY</bcp14> contain a <tt><ttl:update></tt> element. This element <bcp14>MUST</bcp14> contain one or more <tt><ttl:ttl></tt> records as described in <xreftarget="extension-elements"/>. </t>target="extension-elements"/>.</t> <t> If an EPP server receives an <tt><update></tt> command containing a TTL value that is outside the server's permitted range, it <bcp14>MUST</bcp14> reject the command with a 2004 "Parameter value range error" response.</t> <t>ExampleBelow is an example domain <tt><update></tt>command: </t> <sourcecode>C: <?xmlcommand:</t> <sourcecode type="xml" markers="false"><![CDATA[ C: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<command><command> C:<update><update> C:<domain:update<domain:update C:xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C:<domain:name>example.com</domain:name><domain:name>example.com</domain:name> C:</domain:update></domain:update> C:</update></update> C:<extension><extension> C:<ttl:update<ttl:update C:xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> C:<ttl:ttl for="NS"/><ttl:ttl for="NS"/> C:<ttl:ttl<ttl:ttl for="custom" C:custom="DELEG"/>custom="DELEG"/> C:<ttl:ttl for="DS">86400</ttl:ttl><ttl:ttl for="DS">86400</ttl:ttl> C:</ttl:update></ttl:update> C:</extension></extension> C:<clTRID>ABC-12345</clTRID><clTRID>ABC-12345</clTRID> C:</command></command> C:</epp> </sourcecode> <t> Example</epp> ]]></sourcecode> <t>Below is an example host <tt><update></tt>command: </t> <sourcecode>C: <?xmlcommand:</t> <sourcecode type="xml" markers="false"><![CDATA[ C: <?xml version="1.0" encoding="UTF-8"standalone="no"?>standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<command><command> C:<update><update> C:<host:update<host:update C:xmlns:host="urn:ietf:params:xml:ns:host-1.0">xmlns:host="urn:ietf:params:xml:ns:host-1.0"> C:<host:name>ns1.example.com</host:name><host:name>ns1.example.com</host:name> C:</host:update></host:update> C:</update></update> C:<extension><extension> C:<ttl:update<ttl:update C:xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> C:<ttl:ttl for="A">86400</ttl:ttl><ttl:ttl for="A">86400</ttl:ttl> C:<ttl:ttl for="AAAA">3600</ttl:ttl><ttl:ttl for="AAAA">3600</ttl:ttl> C:</ttl:update></ttl:update> C:</extension></extension> C:<clTRID>ABC-12345</clTRID><clTRID>ABC-12345</clTRID> C:</command></command> C:</epp> </sourcecode> <t> If an EPP server receives an <tt><update></tt> command containing a TTL value that is outside the server's permitted range, it <bcp14>MUST</bcp14> reject the command with a <tt>2004</tt> "Parameter value range error" response. </t></epp> ]]></sourcecode> </section> </section> </section> <sectionanchor="server-processing" title="Server processinganchor="server-processing"> <name>Server Processing of TTLvalues">Values</name> <sectionanchor="permitted-types" title="Permitted record types">anchor="permitted-types"> <name>Permitted Record Types</name> <t> EPP servers <bcp14>MAY</bcp14> restrict the supported DNS record types. For example, a server <bcp14>MAY</bcp14> allow clients to specify TTL values for <tt>DS</tt> recordsonly. </t>only.</t> <t> A serverwhichthat receives a <tt><create></tt> or <tt><update></tt> commandwhichthat includes a restricted record type <bcp14>MUST</bcp14> respond with a 2306 "Parameter value policy"error. </t>error.</t> <t> Clients can discover the DNS record types for which an EPP server permits TTL values to be changed by performing a"Policy Mode"Policy Mode <tt><info></tt> command, as outlined in <xreftarget="policy-mode"/>. </t>target="policy-mode"/>.</t> </section> <sectiontitle="Useanchor="using_ttl_values"> <name>Use of TTLvaluesValues indelegation records" anchor="using_ttl_values">Delegation Records</name> <t> EPP serverswhichthat implement this extension <bcp14>SHOULD</bcp14> use the values provided by EPP clients for the TTL values of records published in the DNS for domain and (if supported) host objects. Server operators <bcp14>MAY</bcp14> disregard these values in order to address security and stability issues, as described in <xref target="operational-considerations"/> and <xreftarget="security-considerations"/>. </t>target="security-considerations"/>.</t> <t> EPP servers that use the"host attribute"host attribute model <bcp14>SHOULD</bcp14> use any <tt>NS</tt>,<tt>A</tt><tt>A</tt>, and/or <tt>AAAA</tt> TTL values specified for the domain object when publishing <tt>NS</tt>,<tt>A</tt><tt>A</tt>, and/or <tt>AAAA</tt> records derived from hostattributes. </t>attributes.</t> </section> </section> <sectionanchor="oob-changes" title="Out-of-band changesanchor="oob-changes"> <name>Out-of-Band Changes to TTLvalues"> <t> EPP server operators <bcp14>MAY</bcp14>, inValues</name> <t>In order to address operational or security issues, EPP server operators <bcp14>MAY</bcp14> make changes to TTL values out-of-band (that is, not in response to an <tt><update></tt> command received from the sponsoring client). </t> <t> Server operators <bcp14>MAY</bcp14> also implement automatic reset of TTL values, so that they revert to the default value a certain amount of time after an update has been made. </t> <t> If a TTL value is changed out-of-band, EPP server operators <bcp14>MAY</bcp14> notify the sponsoring client using the EPP Change Pollextension (<xref target="RFC8590"/>),Extension <xref target="RFC8590"/>, which provides ageneralisedgeneralized method for EPP servers to notify clients of changes to objects under their sponsorship. </t> </section> <sectionanchor="operational-considerations" title="Operational considerations"> <section title="Operational impactanchor="operational-considerations"> <name>Operational Considerations</name> <section> <name>Operational Impact of TTLvalues">Values</name> <t> Registry operators must consider the balance between registrants' desire for changes to domains to be visible in the DNS quickly, and the increased DNS query traffic that short TTLs canbring. </t>bring.</t> <t> Registry operators <bcp14>SHOULD</bcp14> implement limits on the maximum and minimum accepted TTL values that are narrower than the values permitted in the XML schema inthe<xreftarget="formal-syntax" format="title"/>target="formal-syntax"/> (which were chosen to allow any TTL permitted in DNSrecords),records). This is in order to prevent scenarios where an excessively high or low TTL causes operational issues on either side of the zonecut. </t>cut.</t> <t><xref target="oob-changes"/> describes how server operators <bcp14>MAY</bcp14> unilaterally change TTL values in order to address operational or security issues, or only permit changes for limited time periods (after which TTLs revert to thedefault). </t>default).</t> </section><section title="When<section> <name>When TTLvalues should be changed">Values Should Be Changed</name> <t> A common operational mistake is changingofthe DNS record TTLs during or after the planned change to the records themselves. This arises due to a misunderstanding about how TTLswork. </t>work.</t> <t> It is <bcp14>RECOMMENDED</bcp14> that guidance be provided to users so they are aware that changes to a TTL are only effective in shortening transition periods if implemented a period of time— at(at least equal to the currentTTL —TTL) <em>before</em> the planned change. The latency between receipt of the <tt><update></tt> command and the actual publication of the changes in the DNS should also be taken into consideration in thiscalculation. </t>calculation.</t> </section><section title="Changes<section> <name>Changes toserver policy">Server Policy</name> <t> Registry operators may change their policies relating to TTL values from time to time. Previously configured TTL values may consequently fall outside anewly-appliednewly applied policy. This document places no obligation on EPP server operators in respect of these values, and server operators may, as part of a policy change, change the TTL values specified by clients for domain and host objects. <xref target="oob-changes"/> describes how such out-of-band changes should be carriedout. </t>out.</t> </section> </section> <sectionanchor="security-considerations" title="Security considerations"> <section title="Fast-flux DNS">anchor="security-considerations"> <name>Security Considerations</name> <section> <name>Fast Flux DNS</name> <t> Some malicious actors use a technique called "fast flux DNS"(<xref target="SAC-025"/>)<xref target="SAC-025"/> to rapidly change the DNS configuration for a zone in order to evade takedown and law enforcement activity. Server operators should take this into consideration when setting the lower limit on TTL values, since a short TTL on delegations may enhance the effectiveness of fast flux techniques onevasion. </t>evasion.</t> <t> Client implementationswhichthat provide an interface for customers to configure TTL values for domain names should consider implementing controls to deter and mitigate abusivebehaviour,behavior, such as those outlined in the "Current and Possible Mitigation Alternatives" section of <xreftarget="SAC-025"/>. </t>target="SAC-025"/>.</t> </section><section title="Compromised user accounts"><section> <name>Compromised User Accounts</name> <t> An attacker who obtains access to a customer account at a domain registrarwhichthat supports this extension could makeunauthorisedunauthorized changes to the <tt>NS</tt> and/or glue records for a domain, and then increase the associated TTLs so that the changes persist in caches for a long time after the attack has beendetected. </t>detected.</t> <t> Client implementationswhichthat provide an interface for customers to configure TTL values for domain names should consider implementing upper limits in order to reduce the impact of account compromise, in addition to best practices relating to credential management, multi-factor authentication, risk-based access control, and soon. </t>on.</t> </section> </section> <sectionanchor="IANA" title="IANA considerations"> <section title="XML namespace"> <t> Thisanchor="IANA"> <name>IANA Considerations</name> <section> <name>XML Namespace</name> <t>This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in <xref target="RFC3688"/>. The following URIassignment is requested of IANA: </t> <t> Registrationassignments have been made by IANA:</t> <t>Registration for the TTLnamespace: </t> <list> <t> <strong>URI:</strong> <tt>urn:ietf:params:xml:ns:epp:ttl-1.0</tt> </t> <t><strong>Registrant Contact:</strong> IESG </t> <t><strong>XML:</strong> None.namespace:</t> <dl spacing="compact" newline="false"> <dt>URI:</dt><dd><tt>urn:ietf:params:xml:ns:epp:ttl-1.0</tt></dd> <dt>Registrant Contact:</dt><dd>IESG</dd> <dt>XML:</dt><dd>None. Namespace URIs do not represent an XMLspecification </t> </list> <t> Registrationspecification.</dd> </dl> <t>Registration for the TTL XMLschema: </t> <list> <t> <strong>URI:</strong> <tt>urn:ietf:params:xml:schema:epp:ttl-1.0</tt> </t> <t><strong>Registrant Contact:</strong> IESG </t> <t><strong>XML:</strong> See the "<xref target="formal-syntax" format="title"/>" sectionschema:</t> <dl spacing="compact" newline="false"> <dt>URI:</dt><dd><tt>urn:ietf:params:xml:schema:epp:ttl-1.0</tt></dd> <dt>Registrant Contact:</dt><dd>IESG</dd> <dt>XML:</dt><dd>See <xref target="formal-syntax"/> of thisdocument </t> </list>document.</dd> </dl> </section><section title="EPP extension registry"> <t> The<section> <name>EPP Extension Registry</name> <t>The EPP extension described in this documentis to behas been registered by IANA in theExtensions"Extensions for the"ExtensibleExtensible Provisioning Protocol (EPP)" registry described in <xref target="RFC7451"/>. The details of the registration are asfollows: </t> <list> <t><strong>Namefollows:</t> <dl spacing="compact" newline="false"> <dt>Name ofExtension:</strong> ExtensibleExtension:</dt> <dd>Extensible Provisioning Protocol (EPP) Mapping for DNSTime-To-LiveTime-to-Live (TTL)values </t> <t><strong>Document Status:</strong> Standards Track </t> <t><strong>Reference:</strong> URL of this document </t> <t><strong>Registrant Name and Email Address:</strong> IESG </t> <t><strong>TLDs:</strong> Any </t> <t><strong>IPR Disclosure:</strong> None </t> <t><strong>Status:</strong> Active </t> <t><strong>Notes:</strong> None </t> </list>Values</dd> <dt>Document Status:</dt> <dd>Standards Track</dd> <dt>Reference:</dt> <dd>RFC 9803</dd> <dt>Registrant:</dt> <dd>IESG</dd> <dt>TLDs:</dt> <dd>Any</dd> <dt>IPR Disclosure:</dt> <dd>None</dd> <dt>Status:</dt> <dd>Active</dd> <dt>Notes:</dt> <dd>None</dd> </dl> </section> </section> <sectionanchor="formal-syntax" title="Formal syntax">anchor="formal-syntax"> <name>Formal Syntax</name> <t> The formal syntax presented here is a complete schema representation of the extension suitable for automated validation of EPP XMLinstances. </t> <sourcecode><?xmlinstances.</t> <sourcecode type="xml" markers="false"><![CDATA[ <?xml version="1.0"encoding="UTF-8"?> <schemaencoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:epp:ttl-1.0" xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"elementFormDefault="qualified"> <annotation> <documentation>elementFormDefault="qualified"> <annotation> <documentation> Extensible Provisioning Protocol v1.0 extension schema forTime-To-LiveTime-to-Live (TTL)valuesValues for domain and host objects.</documentation> </annotation> <element name="info"> <complexType> <attribute</documentation> </annotation> <element name="info"> <complexType> <attribute name="policy" type="boolean"default="false"/> </complexType> </element> <!-- <ttl>default="false"/> </complexType> </element> <!-- <ttl> elements can appear in<create><create> and<update><update> commands, and<info><info> responses--> <element--> <element name="create"type="ttl:commandContainer"> <unique name="uniqueRRTypeForCreate"> <selector xpath="ttl:ttl"/> <field xpath="@for"/> </unique> </element> <elementtype="ttl:commandContainer"> <unique name="uniqueRRTypeForCreate"> <selector xpath="ttl:ttl"/> <field xpath="@for"/> </unique> </element> <element name="update"type="ttl:commandContainer"> <unique name="uniqueRRTypeForUpdate"> <selector xpath="ttl:ttl"/> <field xpath="@for"/> </unique> </element> <elementtype="ttl:commandContainer"> <unique name="uniqueRRTypeForUpdate"> <selector xpath="ttl:ttl"/> <field xpath="@for"/> </unique> </element> <element name="infData"type="ttl:responseContainer"> <unique name="uniqueRRTypeForInfo"> <selector xpath="ttl:ttl"/> <field xpath="@for"/> </unique> </element> <complexType name="commandContainer"> <sequence> <elementtype="ttl:responseContainer"> <unique name="uniqueRRTypeForInfo"> <selector xpath="ttl:ttl"/> <field xpath="@for"/> </unique> </element> <complexType name="commandContainer"> <sequence> <element name="ttl" type="ttl:commandTTLType" minOccurs="1"maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="responseContainer"> <sequence> <elementmaxOccurs="unbounded"/> </sequence> </complexType> <complexType name="responseContainer"> <sequence> <element name="ttl" type="ttl:responseTTLType" minOccurs="1"maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="commandTTLType"> <simpleContent> <extension base="ttl:ttlOrNull"> <attributemaxOccurs="unbounded"/> </sequence> </complexType> <complexType name="commandTTLType"> <simpleContent> <extension base="ttl:ttlOrNull"> <attribute name="for" type="ttl:rrType"use="required"/> <attributeuse="required"/> <attribute name="custom"type="ttl:customRRType"/> </extension> </simpleContent> </complexType> <complexType name="responseTTLType"> <simpleContent> <extension base="ttl:ttlOrNull"> <attributetype="ttl:customRRType"/> </extension> </simpleContent> </complexType> <complexType name="responseTTLType"> <simpleContent> <extension base="ttl:ttlOrNull"> <attribute name="for" type="ttl:rrType"use="required"/> <attributeuse="required"/> <attribute name="custom"type="ttl:customRRType"/> <attributetype="ttl:customRRType"/> <attribute name="min"type="ttl:ttlValue"/> <attributetype="ttl:ttlValue"/> <attribute name="default"type="ttl:ttlValue"/> <attributetype="ttl:ttlValue"/> <attribute name="max"type="ttl:ttlValue"/> </extension> </simpleContent> </complexType> <!--type="ttl:ttlValue"/> </extension> </simpleContent> </complexType> <!-- union type allowing the element to either contain nothing or a TTL value--> <simpleType name="ttlOrNull"> <union--> <simpleType name="ttlOrNull"> <union memberTypes="ttl:emptyValuettl:ttlValue"/> </simpleType> <!--ttl:ttlValue"/> </simpleType> <!-- empty value type--> <simpleType name="emptyValue"> <restriction base="token"> <length value="0"/> </restriction> </simpleType> <!----> <simpleType name="emptyValue"> <restriction base="token"> <length value="0"/> </restriction> </simpleType> <!-- TTL value type--> <simpleType name="ttlValue"> <restriction base="nonNegativeInteger"> <minInclusive value="0"/> <maxInclusive value="2147483647"/> </restriction> </simpleType> <!----> <simpleType name="ttlValue"> <restriction base="nonNegativeInteger"> <minInclusive value="0"/> <maxInclusive value="2147483647"/> </restriction> </simpleType> <!-- resource record mnemonic type--> <simpleType name="rrType"> <restriction base="token"> <enumeration--> <simpleType name="rrType"> <restriction base="token"> <enumeration value="NS"/> <enumeration/> <enumeration value="DS"/> <enumeration/> <enumeration value="DNAME"/> <enumeration/> <enumeration value="A"/> <enumeration/> <enumeration value="AAAA"/> <enumeration/> <enumeration value="custom"/> </restriction> </simpleType> <!--/> </restriction> </simpleType> <!-- custom resource record type--> <simpleType name="customRRType"> <restriction base="token"> <pattern value="A|[A-Z][A-Z0-9\-]*[A-Z0-9]"/> </restriction> </simpleType> </schema> </sourcecode> </section> <section anchor="implementation-status" title="Implementation status" removeInRFC="true"> <section title="Verisign EPP SDK"> <t><strong>Organization:</strong> Verisign Inc. </t> <t><strong>Name:</strong> Verisign EPP SDK </t> <t><strong>Description:</strong> The Verisign EPP SDK includes both a full client implementation and a full server stub implementation of this specification. </t> <t><strong>Level of maturity:</strong> Development </t> <t><strong>Coverage:</strong> All aspects of the protocol are implemented. </t> <t><strong>Licensing:</strong> GNU Lesser General Public License </t> <t><strong>Contact:</strong> jgould@verisign.com </t> <t><strong>URL:</strong> https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks </t> </section> <section title="Pepper EPP Client"> <t><strong>Name:</strong> Pepper EPP Client </t> <t><strong>Description:</strong> The Pepper EPP client fully implements this specification. The underlying <tt>Net::EPP::</tt> Perl module also implements this specification. </t> <t><strong>Level of maturity:</strong> Development </t> <t><strong>Coverage:</strong> All aspects of the protocol will be implemented. </t> <t><strong>Licensing:</strong> Perl Artistic License </t> <t><strong>Contact:</strong> The author of this document. </t> <t><strong>URL:</strong> https://github.com/gbxyz/pepper </t> </section> </section> <section title="Change log" anchor="change_log" removeInRFC="true"> <section title="Changes from 17 to 18"> <ol> <li> Add a space after the <tt>C:</tt> and <tt>S:</tt> line prefixes in examples. </li> <li> Fixed the prefixing of lines in the example in Section 2.1.1.2 (thanks Tim Bray). </li> <li> Fixed broken end tags in examples in Section 1.2.2 and the capitalisation of IPv6 addresses (thanks Erik Kline). </li> <li> Added normative reference to <xref target="IANA-RRTYPES"/>. </li> <li> Replaced references to "command/response frames" with "EPP commands/responses". </li> <li> Minor wording change in paragraph 2 of <xref target="ttl_element"/>. </li> <li> Clarified wording in <xref target="supported-dns-record-types"/>. </li> <li> Wordsmithing of <xref target="server-processing"/> due to feedback from the IESG. </li> </ol> </section> <section title="Changes from 16 to 17"> <ol> <li> Further updates as suggested during IESG review. </li> </ol> </section> <section title="Changes from 15 to 16"> <ol> <li> Updates as suggested during IESG review. </li> </ol> </section> <section title="Changes from 14 to 15"> <ol> <li> Updates as suggested during AD review. </li> <li> In the last paragraph of Section 3.2, make both lists of RR types be the same. </li> <li> Update error codes to be consistent: 2004 (range error) when the TTL value is outside the permitted range, and 2306 (policy error) for an invalid record type. </li> <li> Correct section in reference to RFC 6895 (thanks Jasdip Singh). </li> <li> Minor typographic fixes (thanks Jasdip Singh). </li> </ol> </section> <section title="Changes from 13 to 14"> <ol> <li> Resolve remaining nit before IESG submission. </li> </ol> </section> <section title="Changes from 12 to 13"> <ol> <li> Updates as per the document shepherd's suggestions. </li> </ol> </section> <section title="Changes from 11 to 12"> <ol> <li> Updates as per the document shepherd's email to the list of 2024-06-10. </li> </ol> </section> <section title="Changes from 10 to 11"> <ol> <li> Fix double word in <xref target="using_ttl_values"/>. </li> </ol> </section> <section title="Changes from 09 to 10"> <t> Changes resulting from the Dnsdir review: </t> <ol> <li> Fixed example IPv6 addresses to use the preferred prefix 2001:DB8::. </li> <li> Added paragraph to <xref target="permitted-types"/> describing how clients can use the Policy Mode <tt><info></tt> command (<xref target="policy-mode"/>) to discover the DNS record types supported by the server. </li> </ol> </section> <section title="Changes from 08 to 09"> <ol> <li> Some wording changes suggested by James Gould and Tim Wicinski. </li> </ol> </section> <section title="Changes from 07 to 08"> <ol> <li> Some wording changes suggested by Rick Wilhelm. </li> </ol> </section> <section title="Changes from 06 to 07"> <ol> <li> Minor wording changes and nits reported by JG. </li> </ol> </section> <section title="Changes from 05 to 06"> <ol> <li> Changed how <tt><info></tt> commands work so that a <tt><ttl:info></tt> element is required in order for <tt><ttl:ttl></tt> elements to be included in the response. Thanks to JG for this feedback. </li> </ol> </section> <section title="Changes from 04 to 05"> <ol> <li> removed the erroneous <tt>required="true"</tt> attribute from the <tt>min</tt>, <tt>default</tt> and <tt>max</tt> attributes of the <tt>responseTTLType</tt> type (thanks JG). </li> <li> fixed the reference to RFC 6895 (thanks HS). </li> </ol>--> <simpleType name="customRRType"> <restriction base="token"> <pattern value="A|[A-Z][A-Z0-9\-]*[A-Z0-9]"/> </restriction> </simpleType> </schema> ]]></sourcecode> </section><section title="Changes from 04 to 05"> <ol> <li> Add the Verisign EPP SDK to <xref target="implementation-status"/>. </li> <li> Add the <tt><ttl:info></tt> element and document how it affects server <tt><info></tt> responses. </li> <li></middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5731.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5732.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5910.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <!-- [XSD-DATATYPES] Updatedexamples to exercise more of the schema. </li> <li> Minor schema issue fixed. </li> </ol> </section> <section title="Changes from 03 to 04"> <ol> <li> Changed the <tt>for</tt> attribute to be an enumeration and added the <tt>custom</tt> attribute. </li> <li> Added the <tt>min</tt>, <tt>default</tt> and <tt>max</tt> attributes. </li> <li> Apply feedback from Jim Gould. </li> </ol> </section> <section title="Changes from 02 to 03"> <ol> <li> Rolled back the "straw man" syntax from 02. <tt>ttl:ttl</tt> now has a <tt>for</tt> attribute which can be any DNS record type. <xref target="supported-dns-record-types"/> describes how the set of supported record types may be limited. </li> <li> Removed the global/explicit models and just use the explicit model. </li> <li> Removed the cascading effect where a TTL set on a domain affects subordinate hosts. </li> </ol> </section> <section title="Changes from 01 to 02"> <ol> <li> Renamed the <tt>ttl:seconds</tt> XSD type to <tt>ttl:container</tt>, and the <tt>ttl:nonNegativeInteger</tt> type to <tt>ttl:ttlType</tt>, to permit multiple TTL values. </li> <li> Converted XML instances from artwork to source code. </li> </ol> </section> <section title="Changes from 00 to 01"> <ol> <li> Incorporate feedback from Jim Gould. </li> <li> Add wording to describe how TTL values are jointly managed by both clients and servers. </li> <li> Fix minimum/maximum TTL value and schema namespace (thanks Patrick Mevzek). </li> <li> Moved text on how the server should handle impermissible TTL values from the top of Section 4 to Sections 3.2.1 and 3.2.2 (thanks Rick Wilhelm). </li> <li> Namespace changed from <tt>urn:ietf:params:xml:ns:ttl-1.0</tt> to <tt>urn:ietf:params:xml:ns:epp:ttl-1.0</tt>. </li> <li> Added discussion on EPP servers which use the host attribute model in <xref target="using_ttl_values"/> (thanks Hugo Salgado). </li> <li> Added a <xref target="change_log">Change Log</xref>. </li> </ol> </section> </section> <section title="Acknowledgements"> <t> The author wishestothank the following peoplematch internal guidance fortheir advice and feedback during the development of this document: </t> <ol> <li>James Gould</li> <li>Hugo Salgado</li> <li>Patrick Mevzek</li> <li>Rick Wilhelm</li> <li>Marc Groeneweg</li> <li>Ties de Kock</li> <li>Tim Wicinski</li> <li>Jasdip Singh</li> </ol> </section> </middle> <back> <references title="Normative references"> &RFC2119; &RFC3688; &RFC5731; &RFC5732; &RFC5910; &RFC6895; &RFC8174;W3C references. --> <reference anchor="XSD-DATATYPES"target="https://www.w3.org/TR/xmlschema-2/"><front><title>XMLtarget="https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"> <front> <title>XML Schema Part 2: Datatypes SecondEdition</title><author><organization>World Wide Web Consortium (W3C)</organization></author><dateEdition</title> <author initials="P." surname="Biron" fullname="Paul V. Biron" role="editor"/> <author initials="A." surname="Malhotra" fullname="Ashok Malhotra" role="editor"/> <date month="October"year="2004"/></front></reference>year="2004"/> </front> <refcontent>W3C Recommendation</refcontent> <annotation>Latest version available at <eref target="https://www.w3.org/TR/xmlschema-2/" brackets="angle"/>.</annotation> </reference> <reference anchor="IANA-RRTYPES"target="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4"><front><title>Resourcetarget="https://www.iana.org/assignments/dns-parameters"> <front> <title>Resource Record (RR)TYPEs</title><author><organization>IANA</organization></author></front></reference>TYPEs</title> <author> <organization>IANA</organization> </author> </front> </reference> </references><references title="Informative references"> &RFC6927; &RFC7451; &RFC8590; &RFC9364; &RFC9499;<references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6927.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7451.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8590.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/> <reference anchor="SAC-025"target="https://www.icann.org/en/system/files/files/sac-025-en.pdf"><front><title>SSACtarget="https://www.icann.org/en/system/files/files/sac-025-en.pdf"> <front> <title>SSAC Advisory on Fast Flux Hosting andDNS</title><author><organization>ICANNDNS</title> <author> <organization>ICANN Security and Stability Advisory Committee(SSAC)</organization></author><date(SSAC)</organization> </author> <date month="January"year="2008"/></front><seriesInfoyear="2008"/> </front> <seriesInfo name="SAC"value="25"/></reference>value="025"/> </reference> </references> </references> <section numbered="false"> <name>Acknowledgments</name> <t>The author wishes to thank the following people for their advice and feedback during the development of this document:</t> <ul> <li><t><contact fullname="James Gould"/></t></li> <li><t><contact fullname="Hugo Salgado"/></t></li> <li><t><contact fullname="Patrick Mevzek"/></t></li> <li><t><contact fullname="Rick Wilhelm"/></t></li> <li><t><contact fullname="Marc Groeneweg"/></t></li> <li><t><contact fullname="Ties de Kock"/></t></li> <li><t><contact fullname="Tim Wicinski"/></t></li> <li><t><contact fullname="Jasdip Singh"/></t></li> </ul> </section> </back> </rfc>