<?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"> <!ENTITY RFC6895 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"> <!ENTITY RFC6927 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6927.xml">nbsp " "> <!ENTITYRFC7451 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7451.xml">zwsp "​"> <!ENTITYRFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">nbhy "‑"> <!ENTITYRFC8590 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> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</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>",<!-- [rfced] We have reformatted the list below for readability; please review and let us know if you prefer otherwise. Original: <ttl:ttl> elements have the optional following attributes, depending on whether they appear in an EPP command or response: 1. "for", which is<bcp14>REQUIRED</bcp14>REQUIRED in both commands and responses, and which specifies the DNS record type to which the TTL value pertains. This attribute MUST have one of the following values: "NS", "DS", "DNAME", "A", "AAAA" or "custom"; 2. If the value of the "for" attribute is "custom", then the <ttl:ttl> element MUST also have a "custom" attribute containing a DNS record type conforming with the regular expression in Section 3.1 of [RFC6895]. Additionally, the record type MUST be registered with IANA in [IANA-RRTYPES]. 3. "min", which MUST NOT be present in EPP commands but MAY be present in EPP responses (see Section 2.1.1), and which is used by the server to indicate the lowest value that may be set; 4. "default", which MUST NOT be present in EPP commands but MAY be present in EPP responses (see Section 2.1.1), and which is used by the server to indicate the default value; 5. "max", which MUST NOT be present in EPP commands but MAY be present in EPP responses (see Section 2.1.1), and which is used by the server to indicate the highest value that may be set; Current: "for" REQUIRED in both commands and responses, and specifies the DNS record type to which the TTL value pertains. This attribute MUST have one of the following values: "NS", "DS", "DNAME", "A", "AAAA" or "custom". "custom" If the value of the "for" attribute is "custom", then the <ttl:ttl> element MUST also have a "custom" attribute containing a DNS record type conforming with the regular expression in Section 3.1 of [RFC6895]. Additionally, the record type MUST be registered with IANA in [IANA-RRTYPES]. "min" MUST NOT be present in EPP commands but MAY be present in EPP responses (see Section 2.1.1). It is also used by the server to indicate the lowest value that may be set. "default" MUST NOT be present in EPP commands but MAY be present in EPP responses (see Section 2.1.1). It is also used by the server to indicate the default value. "max" MUST NOT be present in EPP commands but MAY be present in EPP responses (see Section 2.1.1). It is also used by the server to indicate the highest value that may be set. --> <dl newline="true"> <dt>"<tt>for</tt>"</dt> <dd> <bcp14>REQUIRED</bcp14> in both commands and responses, and specifies 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 also 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 also 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 also 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>target="info-command"/>.</t> <!-- [rfced] The section titles for 1.2.1.3.1 and 1.2.2. are similar. For clarity, which of these options do you prefer? Or, please feel free to suggest otherwise. a) Make the title of Section 1.2.1.3.1 more specific, or b) Include the example in 1.2.1.3 and remove section 1.2.1.3.1, or c) Move the example in 1.2.1.3.1 to a subsection of Section 1.2.2 ("Examples"). Original: 1.2.1.3. The <ttl:info> element [...] 1.2.1.3.1. Example <ttl:info policy="true"/> 1.2.2. Examples Perhaps (if option b): 1.2.1.3. The <ttl:info> element The <ttl:info> element is used by clients to request that the server include additional information in <info> responses for domain and host objects. It has a single OPTIONAL policy attribute, which takes a boolean value with a default value of false. The semantics of this element are described in Section 2.1.1. Here's an example: <ttl:info policy="true"/> 1.2.2. Examples --> <section> <name>Example</name> <sourcecode type=""><![CDATA[ <ttl:info policy="true"/> ]]></sourcecode> </section> </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><![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><![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><![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><![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 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 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 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 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 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 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 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 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>ExampleBelow is an example domain <tt><create></tt>command: </t> <sourcecode>C: <?xmlcommand:</t> <sourcecode 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 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</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>2004 "Parameter value range error"response. </t>response.</t> </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>ExampleBelow is an example domain <tt><update></tt>command: </t> <sourcecode>C: <?xmlcommand:</t> <sourcecode 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 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></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>2004 "Parameter value range error"response. </t>response.</t> </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><strong>URI:</strong></dt><dd><tt>urn:ietf:params:xml:ns:epp:ttl-1.0</tt></dd> <dt><strong>Registrant Contact:</strong></dt><dd>IESG</dd> <dt><strong>XML:</strong></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><strong>URI:</strong></dt><dd><tt>urn:ietf:params:xml:schema:epp:ttl-1.0</tt></dd> <dt><strong>Registrant Contact:</strong></dt><dd>IESG</dd> <dt><strong>XML:</strong></dt><dd>See <xref target="formal-syntax"/> of thisdocument </t> </list>document.</dd> </dl> </section><section title="EPP<section> <name>EPP Extension Registry</name> <!-- [rfced] Section 7.2: May we update the name of the extensionregistry"> <t> Theas shown below? If so, we will ask IANA to update the registry accordingly (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml). This would match the edited title of this document as well as the value's name as it appears in RFC 9499. CURRENT: Extensible Provisioning Protocol (EPP) Mapping for DNS Time-To-Live (TTL) values SUGGESTED (lowercase 't' and capital 'V'): Extensible Provisioning Protocol (EPP) Mapping for DNS Time-to-Live (TTL) Values In that registry, we note that "Name of Extension" for this one also matches the title of the RFC: Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer (RFC 9167) --> <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><strong>Name ofExtension:</strong> ExtensibleExtension:</strong></dt> <dd>Extensible Provisioning Protocol (EPP) Mapping for DNS Time-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><strong>Document Status:</strong></dt> <dd>Standards Track</dd> <dt><strong>Reference:</strong></dt> <dd>RFC 9803</dd> <dt><strong>Registrant:</strong></dt> <dd>IESG</dd> <dt><strong>TLDs:</strong></dt> <dd>Any</dd> <dt><strong>IPR Disclosure:</strong></dt> <dd>None</dd> <dt><strong>Status:</strong></dt> <dd>Active</dd> <dt><strong>Notes:</strong></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 markers="false" type="xml"><![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 for Time-To-Live (TTL) values 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>--> <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</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] Updated to match internal guidance for W3C references. --> <reference anchor="XSD-DATATYPES" target="https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"> <front> <title>XML Schema Part 2: Datatypes Second Edition</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> <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"> <front> <title>Resource Record (RR) TYPEs</title> <author> <organization>IANA</organization> </author> </front> </reference> </references> <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>SSAC Advisory on Fast Flux Hosting anda 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>DNS</title> <author> <organization>ICANN Security and Stability Advisory Committee (SSAC)</organization> </author> <date month="January" year="2008"/> </front> <seriesInfo name="SAC" value="025"/> </reference> </references> </references> <sectiontitle="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> Thenumbered="false"> <name>Acknowledgments</name> <t>The authorof 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 17wishes to18"> <ol> <li> Add a space afterthank the<tt>C:</tt>following people for their advice and<tt>S:</tt> line prefixes in examples. </li> <li> Fixedfeedback during theprefixingdevelopment oflines in the example in Section 2.1.1.2 (thanks Tim Bray). </li> <li> Fixed broken end tags in examples inthis 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> <!-- [rfced] FYI, we have added expansions for abbreviations upon first use per Section1.2.2 and the capitalisation3.6 ofIPv6 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 wordingRFC 7322 ("RFC Style Guide"). Please review each expansion in<xref target="supported-dns-record-types"/>. </li> <li> Wordsmithing of <xref target="server-processing"/> due to feedback fromtheIESG. </li> </ol> </section> <section title="Changes from 16document carefully to17"> <ol> <li> Furtherensure correctness. --> <!-- [rfced] Regarding usage of <tt>, <em>, and <strong> elements, please review the occurrences and let us know if any updatesas 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>are needed for consistency. Details below. In thelast 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) whenHTML and PDF outputs, <tt> yields fixed-width font. In theTTL valuetext output, there isoutsideno change. - In this document: seemingly used for RR names, attribute names, and some examples. In thepermitted range,HTML and2306 (policy error) forPDF outputs, <em> yields italics. In the text output, <em> yields aninvalid 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 nitunderscore beforeIESG 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 listand after. - In this document: used for one instance of2024-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 fromemphasis. In theDnsdir review: </t> <ol> <li> Fixed example IPv6 addresses to useHTML and PDF outputs, <strong> yields bold. In thepreferred prefix 2001:DB8::. </li> <li> Added paragraph to <xref target="permitted-types"/> describing how clients can usetext output, <strong> yields an asterisk before and after. - In this document: used for field names in thePolicy Mode <tt><info></tt> command (<xref target="policy-mode"/>) to discoverIANA Considerations. - We recommend removing these, as theDNS record types supported byasterisks seem unnecessary in theserver. </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 changestext file, andnits 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> elementthis font styling isrequired in order for <tt><ttl:ttl></tt> elements to be includednot typically used in IANA Considerations sections. Please let us know if you agree. --> <!-- [rfced] Please review theresponse. 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>"type" attributefrom the <tt>min</tt>, <tt>default</tt> and <tt>max</tt> attributesofthe <tt>responseTTLType</tt> type (thanks JG). </li> <li> fixed the reference to RFC 6895 (thanks HS). </li> </ol> </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>each sourcecode elementand document how it affects server <tt><info></tt> responses. </li> <li> Updated examples to exercise more ofin theschema. </li> <li> Minor schema issue fixed. </li> </ol> </section> <section title="Changes from 03XML file to04"> <ol> <li> Changedensure correctness. If the<tt>for</tt> attribute to becurrent list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain anenumeration 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 02applicable type, then feel free to03"> <ol> <li> Rolled backlet us know. Also, it is acceptable to leave the"straw man" syntax from 02. <tt>ttl:ttl</tt> now has a <tt>for</tt>"type" attributewhich can benot set. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if anyDNS record type. <xref target="supported-dns-record-types"/> describes how the setchanges are needed. Updates ofsupported record types maythis nature typically result in more precise language, which is helpful for readers. For example, please consider whether "white space" should belimited. </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>, andupdated in 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> Movedtexton how the server should handle impermissible TTL values from the top of Section 4 to Sections 3.2.1below: Indentation and3.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 modelwhite space 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 wishesexamples are provided only tothank the following people for their adviceillustrate element relationships andfeedback during the developmentare not required features of thisdocument: </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; <reference anchor="XSD-DATATYPES" target="https://www.w3.org/TR/xmlschema-2/"><front><title>XML Schema Part 2: Datatypes Second Edition</title><author><organization>World Wide Web Consortium (W3C)</organization></author><date month="October" year="2004"/></front></reference> <reference anchor="IANA-RRTYPES" target="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4"><front><title>Resource Record (RR) TYPEs</title><author><organization>IANA</organization></author></front></reference> </references> <references title="Informative references"> &RFC6927; &RFC7451; &RFC8590; &RFC9364; &RFC9499; <reference anchor="SAC-025" target="https://www.icann.org/en/system/files/files/sac-025-en.pdf"><front><title>SSAC Advisory on Fast Flux Hosting and DNS</title><author><organization>ICANN Security and Stability Advisory Committee (SSAC)</organization></author><date month="January" year="2008"/></front><seriesInfo name="SAC" value="25"/></reference> </references> </back>protocol. --> </rfc>