<?xmlversion="1.0" encoding="us-ascii"?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 --> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"> <!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"> <!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"> <!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC2308 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml"> <!ENTITY RFC8499 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"> <!ENTITY RFC6672 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6672.xml"> ]> <?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?>version='1.0' encoding='utf-8'?> <rfcipr="trust200902" docName="draft-ietf-dnsop-serve-stale-10"xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-dnsop-serve-stale-10" indexInclude="true" ipr="trust200902" number="8767" prepTime="2020-03-31T14:58:06" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="1034, 1035,2181">2181" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale-10" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8767" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="DNSServe Stale">ServingServe-Stale">Serving Stale Data to Improve DNS Resiliency</title> <seriesInfo name="RFC" value="8767" stream="IETF"/> <authorinitials="D.C."initials="D." surname="Lawrence" fullname="David C Lawrence"><organization>Oracle</organization><organization showOnFrontPage="true">Oracle</organization> <address> <email>tale@dd.org</email> </address> </author> <author initials="W." surname="Kumari" fullname="Warren "Ace" Kumari"><organization>Google</organization><organization showOnFrontPage="true">Google</organization> <address> <postal> <street>1600 Amphitheatre Parkway</street> <city>Mountain View</city><code>CA 94043</code> <country>USA</country><region>CA</region> <code>94043</code> <country>United States of America</country> </postal> <email>warren@kumari.net</email> </address> </author> <author initials="P." surname="Sood" fullname="Puneet Sood"><organization>Google</organization><organization showOnFrontPage="true">Google</organization> <address> <email>puneets@google.com</email> </address> </author> <dateyear="2019" month="December" day="09"/> <area>Internet</area> <workgroup>DNSOP Working Group</workgroup> <keyword>Internet-Draft</keyword> <abstract> <t>This draftmonth="03" year="2020"/> <keyword>DNS</keyword> <keyword>DDoS</keyword> <keyword>Resiliency</keyword> <keyword>Denial-of-Service</keyword> <keyword>Expired</keyword> <abstract pn="section-abstract"> <t pn="section-abstract-1">This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoSattacks,attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL fromRFCRFCs 1034 andRFC1035 so that data can be kept in the cache beyond the TTLexpiry,expiry; it also updates RFC 2181 by interpreting values with thehigh orderhigh-order bit set as being positive, rather than 0, and suggests a cap of 7 days.</t> </abstract> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t pn="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. </t> <t pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8767" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t pn="section-boilerplate.2-1"> Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> </li> <li pn="section-toc.1-1.2"> <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> </li> <li pn="section-toc.1-1.3"> <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t> </li> <li pn="section-toc.1-1.4"> <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-standards-action">Standards Action</xref></t> </li> <li pn="section-toc.1-1.5"> <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-method">Example Method</xref></t> </li> <li pn="section-toc.1-1.6"> <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-consideratio">Implementation Considerations</xref></t> </li> <li pn="section-toc.1-1.7"> <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-caveats">Implementation Caveats</xref></t> </li> <li pn="section-toc.1-1.8"> <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-status">Implementation Status</xref></t> </li> <li pn="section-toc.1-1.9"> <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-edns-option">EDNS Option</xref></t> </li> <li pn="section-toc.1-1.10"> <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.11"> <t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t> </li> <li pn="section-toc.1-1.12"> <t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-nat-considerations">NAT Considerations</xref></t> </li> <li pn="section-toc.1-1.13"> <t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.14"> <t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedContent="14" format="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.14.2"> <li pn="section-toc.1-1.14.2.1"> <t keepWithNext="true" pn="section-toc.1-1.14.2.1.1"><xref derivedContent="14.1" format="counter" sectionFormat="of" target="section-14.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.14.2.2"> <t keepWithNext="true" pn="section-toc.1-1.14.2.2.1"><xref derivedContent="14.2" format="counter" sectionFormat="of" target="section-14.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.15"> <t keepWithNext="true" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.16"> <t keepWithNext="true" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="introduction"title="Introduction"> <t>Traditionallynumbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t pn="section-1-1">Traditionally, the Time To Live (TTL) of a DNSresource recordResource Record (RR) has been understood to represent the maximum number of seconds that a record can be used before it must be discarded, based on its description and usage in <xreftarget="RFC1035"/>target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/> and clarifications in <xreftarget="RFC2181"/>.</t> <t>Thistarget="RFC2181" format="default" sectionFormat="of" derivedContent="RFC2181"/>.</t> <t pn="section-1-2">This document expands the definition of the TTL to explicitly allow for expired data to be used in the exceptional circumstance that a recursive resolver is unable to refresh the information. It is predicated on the observation that authoritative answer unavailability can cause outages even when the underlying data those servers would return is typically unchanged.</t><t>We<t pn="section-1-3">We describe a method below for this use of stale data, balancing the competing needs of resiliency and freshness.</t><t>This<t pn="section-1-4">This document updates the definitions of TTL from <xreftarget="RFC1034"/>target="RFC1034" format="default" sectionFormat="of" derivedContent="RFC1034"/> and <xreftarget="RFC1035"/>target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/> so that data can be kept in the cache beyond the TTLexpiry, andexpiry; it also updates <xreftarget="RFC2181"/>target="RFC2181" format="default" sectionFormat="of" derivedContent="RFC2181"/> by interpreting values with thehigh orderhigh-order bit set as being positive, rather than 0, and also suggests a cap of 7 days.</t> </section> <section anchor="terminology"title="Terminology"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-terminology">Terminology</name> <t pn="section-2-1">The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"/>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xreftarget="RFC8174"/>target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t><t>For<t pn="section-2-2">For a glossary of DNS terms, please see <xreftarget="RFC8499"/>.</t>target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</t> </section> <section anchor="background"title="Background"> <t>Therenumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-background">Background</name> <t pn="section-3-1">There are a number of reasons why an authoritative server may become unreachable, includingDenial of ServiceDenial-of-Service (DoS) attacks, network issues, and so on. If a recursive server is unable to contact the authoritative servers for a query but still has relevant data that has aged past its TTL, that information can still be useful for generating an answer under the metaphorical assumption that "stale bread is better than no bread."</t><t><xref target="RFC1035"/> Section 3.2.1<t pn="section-3-2"><xref target="RFC1035" sectionFormat="comma" section="3.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc1035#section-3.2.1" derivedContent="RFC1035"/> says that the TTL "specifies the time interval that the resource record may be cached before the source of the information should again beconsulted", and Section 4.1.3consulted." <xref target="RFC1035" sectionFormat="comma" section="4.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc1035#section-4.1.3" derivedContent="RFC1035"/> further says that theTTL,TTL "specifies the time interval (in seconds) that the resource record may be cached before it should be discarded."</t><t>A<t pn="section-3-3">A natural English interpretation of these remarks would seem to be clear enough that records past their TTL expiration must not be used. However, <xreftarget="RFC1035"/>target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/> predates the more rigorous terminology of <xreftarget="RFC2119"/>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>, which softened the interpretation of "may" and "should".</t><t><xref target="RFC2181"/><t pn="section-3-4"><xref target="RFC2181" format="default" sectionFormat="of" derivedContent="RFC2181"/> aimed to provide "the precise definition of the Time toLive",Live," butin Section 8<xref target="RFC2181" sectionFormat="of" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2181#section-8" derivedContent="RFC2181"/> was mostly concerned with the numeric range of values rather than data expiration behavior. It does, however, close that section by noting, "The TTL specifies a maximum time to live, not a mandatory time to live." This wording again does not contain BCP 14<xref target="RFC2119"/>keywords,words <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>, but it does convey the natural language connotation that data becomes unusable past TTL expiry.</t><t>As<t pn="section-3-5">As of the time of this writing, several large-scale operators use stale data for answers in some way. A number of recursive resolver packages, including BIND,Knot,Knot Resolver, OpenDNS, and Unbound, provide options to use stale data. AppleMacOSmacOS can also use stale data as part of the Happy Eyeballs algorithms in mDNSResponder. The collective operational experience is that using stale data can provide significant benefit with minimal downside.</t> </section> <section anchor="standards-action"title="Standards Action"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-standards-action">Standards Action</name> <t pn="section-4-1">The definition of TTL in<xref target="RFC1035"/> Sections 3.2.1Sections <xref target="RFC1035" section="3.2.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc1035#section-3.2.1" derivedContent="RFC1035"/> and4.1.3<xref target="RFC1035" section="4.1.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc1035#section-4.1.3" derivedContent="RFC1035"/> of <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/> is amended to read:</t><t><list style="hanging"> <t hangText='TTL'><dl newline="false" spacing="normal" indent="5" pn="section-4-2"> <dt pn="section-4-2.1">TTL</dt> <dd pn="section-4-2.2"> a 32-bit unsigned integer number of seconds that specifies the duration that the resource recordMAY<bcp14>MAY</bcp14> be cached before the source of the informationMUST<bcp14>MUST</bcp14> again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. ValuesSHOULD<bcp14>SHOULD</bcp14> be capped on theordersorder of days to weeks, with a recommended cap of 604,800 seconds(seven days).(7 days). If the data is unable to be authoritatively refreshed when the TTL expires, the recordMAY<bcp14>MAY</bcp14> be used as though it is unexpired. See[RFC Editor: replace by RFC number] <xref target="example-method"/>Sections <xref target="example-method" format="counter" sectionFormat="of" derivedContent="5"/> and <xreftarget="implementation-considerations"/>target="implementation-considerations" format="counter" sectionFormat="of" derivedContent="6"/> of [RFC8767] fordetails.</t> </list></t> <t>Interpretingdetails.</dd> </dl> <t pn="section-4-3">Interpreting valueswhichthat have the high-order bit set as being positive, rather than 0, is a change from <xreftarget="RFC2181"/>,target="RFC2181" format="default" sectionFormat="of" derivedContent="RFC2181"/>, the rationale for which is explained in <xreftarget="implementation-considerations"/>.target="implementation-considerations" format="default" sectionFormat="of" derivedContent="Section 6"/>. Suggesting a cap ofseven days,7 days, rather than the 68 years allowed by the full 31 bits of <xreftarget="RFC2181"/>,target="RFC2181" sectionFormat="of" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2181#section-8" derivedContent="RFC2181"/>, reflects the current practice of major modern DNS resolvers.</t><t>When<t pn="section-4-4">When returning a response containing stale records, a recursive resolverMUST<bcp14>MUST</bcp14> set the TTL of each expired record in the message to a value greater than 0, with aRECOMMENDED<bcp14>RECOMMENDED</bcp14> value of 30 seconds. See <xreftarget="implementation-considerations"/>target="implementation-considerations" format="default" sectionFormat="of" derivedContent="Section 6"/> for explanation.</t><t>Answers<t pn="section-4-5">Answers from authoritative servers that have a DNSResponse Coderesponse code of either 0 (NoError) or 3 (NXDomain) and the AuthoritativeAnswersAnswer (AA) bit setMUST<bcp14>MUST</bcp14> be considered to have refreshed the data at the resolver. Answers from authoritative servers that have any other response codeSHOULD<bcp14>SHOULD</bcp14> be considered a failure to refresh the data and therefore leave any previous state intact. See <xreftarget="implementation-considerations"/>target="implementation-considerations" format="default" sectionFormat="of" derivedContent="Section 6"/> for a discussion.</t> </section> <section anchor="example-method"title="Example Method"> <t>Therenumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-example-method">Example Method</name> <t pn="section-5-1">There is more than one way a recursive resolver could responsibly implement this resiliency feature while still respecting the intent of the TTL as a signal for when data is to be refreshed.</t><t>In<t pn="section-5-2">In this examplemethodmethod, four notable timers drive considerations for the use of stale data:</t><t><list style="symbols"> <t>A<ul spacing="normal" bare="false" empty="false" pn="section-5-3"> <li pn="section-5-3.1">A client response timer, which is the maximum amount of time a recursive resolver should allow between the receipt of a resolution request and sending itsresponse.</t> <t>Aresponse.</li> <li pn="section-5-3.2">A query resolution timer, which caps the total amount of time a recursive resolver spends processing thequery.</t> <t>Aquery.</li> <li pn="section-5-3.3">A failure recheck timer, which limits the frequency at which a failed lookup will be attemptedagain.</t> <t>Aagain.</li> <li pn="section-5-3.4">A maximum stale timer, which caps the amount of time that records will be kept past theirexpiration.</t> </list></t> <t>Mostexpiration.</li> </ul> <t pn="section-5-4">Most recursive resolvers already have the query resolutiontimer, and effectivelytimer and, effectively, some kind of failure recheck timer. The client response timer and maximum stale timer are new concepts for this mechanism.</t><t>When<t pn="section-5-5">When a recursive resolver receives a request, it should start the client response timer. This timer is used to avoid client timeouts. It should be configurable, with a recommended value of 1.8 seconds as being just under a common timeout value of 2 seconds while still giving the resolver a fair shot at resolving the name.</t><t>The<t pn="section-5-6">The resolver then checks its cache for any unexpired records that satisfy the request and returns them if available. If it finds no relevant unexpired data and the Recursion Desired flag is not set in the request, it should immediately return the response without consulting the cache for expired records.TypicallyTypically, this response would be a referral to authoritative nameservers covering the zone, but the specifics areimplementation-dependent.</t> <t>Ifimplementation dependent.</t> <t pn="section-5-7">If iterative lookups will be done, then the failure recheck timer is consulted. Attempts to refresh from non-responsive or otherwise failing authoritative nameservers are recommended to be done no more frequently than every 30 seconds. If this request was received within this period, the cache may be immediately consulted for stale data to satisfy the request.</t><t>Outside<t pn="section-5-8">Outside the period of the failure recheck timer, the resolver should start the query resolution timer and begin the iterative resolution process. This timer bounds the work done by the resolver when contacting externalauthorities,authorities and is commonly around 10 to 30 seconds. If this timer expires on an attempted lookup that is still being processed, the resolution effort is abandoned.</t><t>If<t pn="section-5-9">If the answer has not been completely determined by the time the client response timer has elapsed, the resolver should then check its cache to see whether there is expired data that would satisfy the request. If so, it adds that data to the response message with a TTL greater than 0 (as specified in <xreftarget="standards-action"/>).target="standards-action" format="default" sectionFormat="of" derivedContent="Section 4"/>). The response is then sent to the client while the resolver continues its attempt to refresh the data.</t><t>When<t pn="section-5-10">When no authorities are able to be reached during a resolution attempt, the resolver should attempt to refresh the delegation and restart the iterative lookup process with the remaining time on the query resolution timer. This resumption should be done only once per resolution effort.</t><t>Outside<t pn="section-5-11">Outside the resolution process, the maximum stale timer is used for cache management and is independent of the query resolution process. This timer is conceptually different from the maximum cache TTL that exists in many resolvers, the latter being a clamp on the value of TTLs as received from authoritative servers and recommended to beseven days7 days in the TTL definition in <xreftarget="standards-action"/>.target="standards-action" format="default" sectionFormat="of" derivedContent="Section 4"/>. The maximum stale timer should beconfigurable, andconfigurable. It defines the length of time after a record expires that it should be retained in the cache. The suggested value is between 1 and 3 days.</t> </section> <section anchor="implementation-considerations"title="Implementation Considerations"> <t>Thisnumbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-implementation-consideratio">Implementation Considerations</name> <t pn="section-6-1">This document mainly describes the issues behind serving stale data and intentionally does not provide a formal algorithm. The concept is not overly complex, and the details are best left to resolver authors to implement in their codebases. The processing of serve-stale is a local operation, and consistent variables between deployments are not needed for interoperability. However, we would like to highlight the impact of various implementation choices, starting with the timers involved.</t><t>The<t pn="section-6-2">The most obvious of these is the maximum stale timer. If this variable is toolargelarge, it could cause excessive cache memory usage, but if it is too small, the serve-stale technique becomes less effective, as the record may not be in the cache to be used if needed. Shorter values, even less than a day, can effectively handle the vast majority of outages. Longer values, as much as a week, give time for monitoring systems to notice a resolution problem and for human intervention to fix it; operational experience has been that sometimes the right people can be hard to track down and unfortunately slow to remedy the situation.</t><t>Increased<t pn="section-6-3">Increased memory consumption could be mitigated by prioritizing removal of stale records over non-expired records during cache exhaustion.Implementations may also wish toEviction strategies could considerwhether to trackadditional factors, including thenames in requests for theirlast time of use ortheir popularity, using that as an additional factor when considering cache eviction.the popularity of a record, to retain active but stale records. A feature to manually flush only stale records could also be useful.</t><t>The<t pn="section-6-4">The client response timer is another variablewhichthat deserves consideration. If this value is too short, there exists the risk that stale answers may be used even when the authoritative server is actually reachable but slow; this may result in undesirable answers being returned. Conversely, waiting too long will negatively impact user experience.</t><t>The<t pn="section-6-5">The balance for the failure recheck timer is responsiveness in detecting the renewed availability of authorities versus the extra resource use for resolution. If this variable is set too large, stale answers may continue to be returned even after the authoritative server is reachable; per <xreftarget="RFC2308"/>, Section 7,target="RFC2308" sectionFormat="comma" section="7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2308#section-7" derivedContent="RFC2308"/>, this should be no more thanfive minutes.5 minutes. If this variable is too small, authoritative servers may be targeted with a significant amount of excess traffic.</t><t>Regarding<t pn="section-6-6">Regarding the TTL to set on stale records in the response, historically TTLs ofzero seconds0 seconds have been problematic for some implementations, and negative values can't effectively be communicated to existing software. Other very short TTLs could lead to congestive collapse as TTL-respecting clients rapidly try to refresh. The recommended value of 30 seconds not only sidesteps those potential problems with no practical negative consequences, it alsorate limitsrate-limits further queries from any client that honors the TTL, such as a forwarding resolver.</t><t>As<t pn="section-6-7">As for the change to treat a TTL with the high-order bit set as positive and then clamping it, as opposed to <xreftarget="RFC2181"/>target="RFC2181" format="default" sectionFormat="of" derivedContent="RFC2181"/> treating it as zero, the rationale here is basically one of engineering simplicity versus an inconsequential operational history. Negative TTLs had no rational intentional meaning that wouldn't have been satisfied by just sending 0 instead, and similarly there was realistically no practical purpose for sending TTLs of 2^25 seconds (1 year) or more. There's also no record of TTLs in the wild having the most significant bit set inDNS-OARC'sthe DNS Operations, Analysis, and Research Center's (DNS-OARC's) "Day in the Life" samples <xreftarget="DITL"/>.target="DITL" format="default" sectionFormat="of" derivedContent="DITL"/>. With no apparent reason for operators to use them intentionally, that leaves either errors or non-standard experiments as explanations as to why such TTLs might be encountered, with neither providing an obviously compelling reason as to why having the leading bit set should be treated differently from having any of the next eleven bits set and then capped per <xreftarget="standards-action"/>.</t> <t>Anothertarget="standards-action" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t> <t pn="section-6-8">Another implementation consideration is the use of stale nameserver addresses for lookups. This is mentioned explicitly because, in some resolvers, getting the addresses for nameservers is a separate path from a normal cache lookup. If authoritative server addresses are not able to be refreshed, resolution can possibly still be successful if the authoritative servers themselves are up. For instance, consider an attack on a top-level domain that takes its nameservers offline; serve-stale resolvers that had expired glue addresses for subdomains within thatTLDtop-level domain would still be able to resolve names within those subdomains, even those it had not previously looked up.</t><t>The<t pn="section-6-9">The directive in <xreftarget="standards-action"/>target="standards-action" format="default" sectionFormat="of" derivedContent="Section 4"/> that only NoError and NXDomain responses should invalidate any previously associated answer stems from the fact that no other RCODEs that a resolver normally encounters make any assertions regarding the name in the question or any data associated with it. This comports with existing resolver behavior where a failed lookup (say, duringpre-fetching)prefetching) doesn't impact the existing cache state. Some authoritative server operators have said that they would prefer stale answers to be used in the event that their servers are responding with errors like ServFail instead of giving true authoritative answers. ImplementersMAY<bcp14>MAY</bcp14> decide to return stale answers in this situation.</t><t>Since<t pn="section-6-10">Since the goal of serve-stale is to provide resiliency for all obvious errors to refresh data, these other RCODEs are treated as though they are equivalent to not getting an authoritative response. Although NXDomain for a previously existing name might well be an error, it is not handled that way because there is no effective way to distinguish operator intent for legitimate cases versus error cases.</t><t>During<t pn="section-6-11">During discussion in the IETF, it was suggested that, if all authorities return responses with an RCODE of Refused, it may be an explicit signal to take down the zone from servers that still have the zone's delegation pointed to them. Refused, however, is also overloaded to mean multiple possible failureswhichthat could represent transient configuration failures. Operational experience has shown that purposely returning Refused is a poor way to achieve an explicit takedown of a zone compared to either updating the delegation or returning NXDomain with a suitable SOA for extended negative caching. ImplementersMAY<bcp14>MAY</bcp14> nonetheless consider whether to treat all authorities returning Refused as preempting the use of stale data.</t> </section> <section anchor="implementation-caveats"title="Implementation Caveats"> <t>Stalenumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-implementation-caveats">Implementation Caveats</name> <t pn="section-7-1">Stale data is used only when refreshing has failed in order to adhere to the original intent of the design of the DNS and thebehaviourbehavior expected by operators. If stale data were to always be used immediately and then a cache refresh attempted after the client response has been sent, the resolver would frequently be sending data that it would have had no trouble refreshing. Because modern resolvers use techniques likepre-fetchingprefetching and request coalescing for efficiency, it is not necessary that every client request needs to trigger a new lookup flow in the presence of stale data, but rather that a good-faith effort has been recently made to refresh the stale data before it is delivered to any client.</t><t>It<t pn="section-7-2">It is important to continue the resolution attempt after the stale response has been sent, until the query resolution timeout, because some pathological resolutions can take many seconds to succeed as they cope with unavailable servers, bad networks, and other problems. Stopping the resolution attempt when the response with expired data has been sent would mean that answers in these pathological cases would never be refreshed.</t><t>The<t pn="section-7-3">The continuing prohibition against using data with a0 second0-second TTL beyond the current transaction explicitly extends to it being unusable even for stale fallback, as it is not to be cached at all.</t><t>Be<t pn="section-7-4">Be aware that Canonical Name (CNAME) and DNAME<xref target="RFC6672"/>records <xref target="RFC6672" format="default" sectionFormat="of" derivedContent="RFC6672"/> mingled in the expired cache with other records at the same owner name can cause surprising results. This was observed with an initial implementation in BIND when a hostname changed from having an IPv4 Address (A) record to a CNAME. The version of BIND being used did not evict other types in the cache when a CNAME was received, which in normal operations is not a significant issue. However, after both records expired and the authorities became unavailable, the fallback to stale answers returned the older A instead of the newer CNAME.</t> </section> <section anchor="implementation-status"title="Implementation Status"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-implementation-status">Implementation Status</name> <t pn="section-8-1">The algorithm described in <xreftarget="example-method"/>target="example-method" format="default" sectionFormat="of" derivedContent="Section 5"/> was originally implemented as a patch to BIND 9.7.0. It has been in use on Akamai's production network since2011, and2011; it effectively smoothed over transient failures and longer outages that would have resulted in major incidents. The patch was contributed to the Internet SystemsConsortiumConsortium, and the functionality is now available in BIND 9.12 and later via the options stale-answer-enable, stale-answer-ttl, and max-stale-ttl.</t><t>Unbound<t pn="section-8-2">Unbound has a similar feature for serving staleanswers,answers and will respond with stale data immediately if it has recently tried and failed to refresh the answer bypre-fetching.</t> <t>Knotprefetching. Starting from version 1.10.0, Unbound can also be configured to follow the algorithm described in <xref target="example-method" format="default" sectionFormat="of" derivedContent="Section 5"/>. Both behaviors can be configured and fine-tuned with the available serve-expired-* options.</t> <t pn="section-8-3">Knot Resolver has a demo module here:https://knot-resolver.readthedocs.io/en/stable/modules.html#serve-stale</t> <t>Apple's<eref target="https://knot-resolver.readthedocs.io/en/stable/modules-serve_stale.html" brackets="angle"/>.</t> <t pn="section-8-4">Apple's system resolvers are also known to use stale answers, but the details are not readily available.</t><t>In<t pn="section-8-5">In the research paper "When the Dike Breaks: Dissecting DNS Defenses During DDoS" <xreftarget="DikeBreaks"/>,target="DikeBreaks" format="default" sectionFormat="of" derivedContent="DikeBreaks"/>, the authors detected some use of stale answers by resolvers when authorities came under attack. Their research results suggest that more widespread adoption of the technique would significantly improve resiliency for the large number of requests that fail or experience abnormally long resolution times during an attack.</t> </section> <section anchor="edns-option"title="EDNS Option"> <t>Duringnumbered="true" toc="include" removeInRFC="false" pn="section-9"> <name slugifiedName="name-edns-option">EDNS Option</name> <t pn="section-9-1">During the discussion of serve-stale in the IETF, it was suggested that an EDNS option <xref target="RFC6891" format="default" sectionFormat="of" derivedContent="RFC6891"/> should beavailableavailable. One proposal was toeither explicitly opt-inuse it to opt in to getting data that is possibly stale,or at least as a debugging tooland another was toindicatesignal when stale data has been used for a response.</t><t>The<t pn="section-9-2">The opt-in use case wasrejectedrejected, as the technique was meant to be immediately useful in improving DNS resiliency for all clients.</t><t>The<t pn="section-9-3">The reporting case was ultimately also rejected because even the simpler version of a proposed option was still too much bother to implement for too little perceived value.</t> </section> <section anchor="security-considerations"title="Security Considerations"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-10"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t pn="section-10-1">The most obvious security issue is the increased likelihood of DNSSEC validation failures when using stale data because signatures could be returned outside their validity period. Stale negative records can increase the time window where newly published TLSA or DS RRs may not be used due to cached NSEC or NSEC3 records. These scenarios would only be an issue if the authoritative servers areunreachable, theunreachable (the only time the techniques in this document areused,used), and thus serve-stale does not introduce a new failure in place of what would have otherwise been success.</t><t>Additionally,<t pn="section-10-2">Additionally, bad actors have been known to use DNS caches to keep records alive even after their authorities have gone away. Theserve staleserve-stale feature potentially makes the attack easier, although without introducing a new risk. In addition, attackers could combine this with a DDoS attack on authoritative servers with the explicit intent of having stale information cached forlonger.a longer period of time. But if attackers have this capacity, they probably could do much worse than prolonging the life of old data.</t><t>In<t pn="section-10-3">In <xreftarget="CloudStrife"/>,target="CloudStrife" format="default" sectionFormat="of" derivedContent="CloudStrife"/>, it was demonstrated how stale DNS data, namely hostnames pointing to addresses that are no longer in use by the owner of the name, can be used to co-opt securitysuch as-- for example, to get domain-validated certificates fraudulently issued to an attacker. While this document does not create a new vulnerability in this area, it does potentially enlarge the window in which such an attack could be made. A proposed mitigation is that certificate authorities should fully look up each name starting at the DNS root for every name lookup. Alternatively,CAscertificate authorities should use a resolver that is not serving stale data.</t> </section> <section anchor="privacy-considerations"title="Privacy Considerations"> <t>Thisnumbered="true" toc="include" removeInRFC="false" pn="section-11"> <name slugifiedName="name-privacy-considerations">Privacy Considerations</name> <t pn="section-11-1">This document does not add any practical new privacy issues.</t> </section> <section anchor="nat-considerations"title="NAT Considerations"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-12"> <name slugifiedName="name-nat-considerations">NAT Considerations</name> <t pn="section-12-1">The method described here is not affected by the use of NAT devices.</t> </section> <section anchor="iana-considerations"title="IANA Considerations"> <t>There arenumbered="true" toc="include" removeInRFC="false" pn="section-13"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t pn="section-13-1">This document has no IANAconsiderations.</t> </section> <section anchor="acknowledgements" title="Acknowledgements"> <t>The authors wish to thank Brian Carpenter, Robert Edmonds, Tony Finch, Bob Harold, Tatuya Jinmei, Matti Klock, Jason Moreau, Giovane Moura, Jean Roy, Mukund Sivaraman, Davey Song, Paul Vixie, Ralf Weber and Paul Wouters for their review and feedback. Paul Hoffman deserves special thanks for submitting a number of Pull Requests.</t> <t>Thank you also to the following members of the IESG for their final review: Roman Danyliw, Benjamin Kaduk, Suresh Krishnan, Mirja Kuehlewind, and Adam Roach.</t>actions.</t> </section> </middle> <back> <referencestitle='Normative References'> &RFC1035; &RFC2181; &RFC1034; &RFC2119; &RFC8174; &RFC2308; </references>pn="section-14"> <name slugifiedName="name-references">References</name> <referencestitle='Informative References'>pn="section-14.1"> <name slugifiedName="name-normative-references">Normative References</name> <referenceanchor="DikeBreaks" target="https://www.isi.edu/~johnh/PAPERS/Moura18b.pdf">anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034" quoteTitle="true" derivedAnchor="RFC1034"> <front><title>When the Dike Breaks: Dissecting DNS Defenses During DDos</title> <author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura"> <organization></organization> </author> <author initials="J." surname="Heidemann" fullname="John Heidemann"> <organization></organization> </author> <author initials="M." surname="Mueller" fullname="Moritz Mueller"> <organization></organization> </author> <author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt"> <organization></organization> </author><title>Domain names - concepts and facilities</title> <authorinitials="M." surname="Davids" fullname="Marco Davids"> <organization></organization>initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"> <organization showOnFrontPage="true"/> </author> <dateyear="2018" month="October" day="31"/>year="1987" month="November"/> <abstract> <t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t> </abstract> </front> <seriesInfoname="ACM" value="2018 Internet Measurement Conference"/>name="STD" value="13"/> <seriesInfo name="RFC" value="1034"/> <seriesInfo name="DOI"value="10.1145/3278532.3278534"/>value="10.17487/RFC1034"/> </reference> <referenceanchor="CloudStrife" target="https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_06A-4_Borgolte_paper.pdf">anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" quoteTitle="true" derivedAnchor="RFC1035"> <front><title>Cloud<title>Domain names - implementation and specification</title> <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"> <organization showOnFrontPage="true"/> </author> <date year="1987" month="November"/> <abstract> <t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1035"/> <seriesInfo name="DOI" value="10.17487/RFC1035"/> </reference> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1997" month="March"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC2181" target="https://www.rfc-editor.org/info/rfc2181" quoteTitle="true" derivedAnchor="RFC2181"> <front> <title>Clarifications to the DNS Specification</title> <author initials="R." surname="Elz" fullname="R. Elz"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Bush" fullname="R. Bush"> <organization showOnFrontPage="true"/> </author> <date year="1997" month="July"/> <abstract> <t>This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2181"/> <seriesInfo name="DOI" value="10.17487/RFC2181"/> </reference> <reference anchor="RFC2308" target="https://www.rfc-editor.org/info/rfc2308" quoteTitle="true" derivedAnchor="RFC2308"> <front> <title>Negative Caching of DNS Queries (DNS NCACHE)</title> <author initials="M." surname="Andrews" fullname="M. Andrews"> <organization showOnFrontPage="true"/> </author> <date year="1998" month="March"/> <abstract> <t>RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2308"/> <seriesInfo name="DOI" value="10.17487/RFC2308"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="May"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> </references> <references pn="section-14.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="CloudStrife" target="https://www.ndss-symposium.org/wp-content/uploads/2018/02/ndss2018_06A-4_Borgolte_paper.pdf" quoteTitle="true" derivedAnchor="CloudStrife"> <front> <title>Cloud Strife: Mitigating the Security Risks of Domain-Validated Certificates</title> <seriesInfo name="DOI" value="10.1145/3232755.3232859"/> <seriesInfo name="ACM" value="2018 Applied Networking Research Workshop"/> <author initials="K." surname="Borgolte" fullname="Kevin Borgolte"><organization></organization><organization showOnFrontPage="true"/> </author> <author initials="T." surname="Fiebig" fullname="Tobias Fiebig"><organization></organization><organization showOnFrontPage="true"/> </author> <author initials="S." surname="Hao" fullname="Shuang Hao"><organization></organization><organization showOnFrontPage="true"/> </author> <author initials="C." surname="Kruegel" fullname="Christopher Kruegel"><organization></organization><organization showOnFrontPage="true"/> </author> <author initials="G." surname="Vigna" fullname="Giovanni Vigna"><organization></organization><organization showOnFrontPage="true"/> </author> <date year="2018"month="July" day="16"/>month="July"/> </front><seriesInfo name="ACM" value="2018 Applied Networking Research Workshop"/> <seriesInfo name="DOI" value="10.1145/3232755.3232859"/></reference> <referenceanchor="DITL" target="https://www.dns-oarc.net/oarc/data/ditl">anchor="DikeBreaks" target="https://www.isi.edu/~johnh/PAPERS/Moura18b.pdf" quoteTitle="true" derivedAnchor="DikeBreaks"> <front><title>DITL Traces and Analysis | DNS-OARC</title><title>When the Dike Breaks: Dissecting DNS Defenses During DDoS</title> <seriesInfo name="DOI" value="10.1145/3278532.3278534"/> <seriesInfo name="ACM" value="2018 Internet Measurement Conference"/> <author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Heidemann" fullname="John Heidemann"> <organization showOnFrontPage="true"/> </author> <author initials="M." surname="Müller" fullname="Moritz Müller"> <organization showOnFrontPage="true"/> </author> <author initials="R. de O." surname="Schmidt" fullname="Ricardo de O. Schmidt"> <organization showOnFrontPage="true"/> </author> <author> <organization></organization>initials="M." surname="Davids" fullname="Marco Davids"> <organization showOnFrontPage="true"/> </author> <dateyear="n.d."/>year="2018" month="October"/> </front> </reference>&RFC8499; &RFC6672;<reference anchor="DITL" target="https://www.dns-oarc.net/oarc/data/ditl" quoteTitle="true" derivedAnchor="DITL"> <front> <title>DITL Traces and Analysis</title> <author> <organization showOnFrontPage="true">DNS-OARC</organization> </author> <date month="January" year="2018"/> </front> </reference> <reference anchor="RFC6672" target="https://www.rfc-editor.org/info/rfc6672" quoteTitle="true" derivedAnchor="RFC6672"> <front> <title>DNAME Redirection in the DNS</title> <author initials="S." surname="Rose" fullname="S. Rose"> <organization showOnFrontPage="true"/> </author> <author initials="W." surname="Wijngaards" fullname="W. Wijngaards"> <organization showOnFrontPage="true"/> </author> <date year="2012" month="June"/> <abstract> <t>The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6672"/> <seriesInfo name="DOI" value="10.17487/RFC6672"/> </reference> <reference anchor="RFC6891" target="https://www.rfc-editor.org/info/rfc6891" quoteTitle="true" derivedAnchor="RFC6891"> <front> <title>Extension Mechanisms for DNS (EDNS(0))</title> <author initials="J." surname="Damas" fullname="J. Damas"> <organization showOnFrontPage="true"/> </author> <author initials="M." surname="Graff" fullname="M. Graff"> <organization showOnFrontPage="true"/> </author> <author initials="P." surname="Vixie" fullname="P. Vixie"> <organization showOnFrontPage="true"/> </author> <date year="2013" month="April"/> <abstract> <t>The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.</t> <t>This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.</t> </abstract> </front> <seriesInfo name="STD" value="75"/> <seriesInfo name="RFC" value="6891"/> <seriesInfo name="DOI" value="10.17487/RFC6891"/> </reference> <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8499" quoteTitle="true" derivedAnchor="RFC8499"> <front> <title>DNS Terminology</title> <author initials="P." surname="Hoffman" fullname="P. Hoffman"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Sullivan" fullname="A. Sullivan"> <organization showOnFrontPage="true"/> </author> <author initials="K." surname="Fujiwara" fullname="K. Fujiwara"> <organization showOnFrontPage="true"/> </author> <date year="2019" month="January"/> <abstract> <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t> <t>This document obsoletes RFC 7719 and updates RFC 2308.</t> </abstract> </front> <seriesInfo name="BCP" value="219"/> <seriesInfo name="RFC" value="8499"/> <seriesInfo name="DOI" value="10.17487/RFC8499"/> </reference> </references> </references> <section anchor="acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t pn="section-appendix.a-1">The authors wish to thank <contact fullname="Brian Carpenter"/>, <contact fullname="Vladimir Cunat"/>, <contact fullname="Robert Edmonds"/>, <contact fullname="Tony Finch"/>, <contact fullname="Bob Harold"/>, <contact fullname="Tatuya Jinmei"/>, <contact fullname="Matti Klock"/>, <contact fullname="Jason Moreau"/>, <contact fullname="Giovane Moura"/>, <contact fullname="Jean Roy"/>, <contact fullname="Mukund Sivaraman"/>, <contact fullname="Davey Song"/>, <contact fullname="Paul Vixie"/>, <contact fullname="Ralf Weber"/>, and <contact fullname="Paul Wouters"/> for their review and feedback. <contact fullname="Paul Hoffman"/> deserves special thanks for submitting a number of Pull Requests.</t> <t pn="section-appendix.a-2">Thank you also to the following members of the IESG for their final review: <contact fullname="Roman Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Suresh Krishnan"/>, <contact fullname="Mirja Kühlewind"/>, and <contact fullname="Adam Roach"/>.</t> </section> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author initials="D." surname="Lawrence" fullname="David C Lawrence"> <organization showOnFrontPage="true">Oracle</organization> <address> <email>tale@dd.org</email> </address> </author> <author initials="W." surname="Kumari" fullname="Warren "Ace" Kumari"> <organization showOnFrontPage="true">Google</organization> <address> <postal> <street>1600 Amphitheatre Parkway</street> <city>Mountain View</city> <region>CA</region> <code>94043</code> <country>United States of America</country> </postal> <email>warren@kumari.net</email> </address> </author> <author initials="P." surname="Sood" fullname="Puneet Sood"> <organization showOnFrontPage="true">Google</organization> <address> <email>puneets@google.com</email> </address> </author> </section> </back><!-- ##markdown-source: H4sIAErV7l0AA7V8W3cbR5Lme/6KXPrB0hwAIiXZltQP0xApt9UWRa1It3d3 ZrdPApUA0ixUYSqrCKF7PL9s3vaPbXwRkVlVJOhxP6zPkUkCWXmJ6xeXrOl0 atrQlv6NvfbNXajW9rp1pbcXrnW2re377a6p7+jvj9f2s4+hDL5aHoxbLBp/ 94Y/xoNeHjNFvazclmYrGrdqp8G3q2lRxXo3jRg1jRg1PTs1hWtplH1+evZ6 evZ8evramLBr3ti26WL7/PT09elz4xrv3tj3Veubyrdmv+b1rj7Zn+vmFlv9 U1N3O3O77wdNL7CuWbr2jY1tYbodFopv7Nnpi5cT/P+biX1+9urMmGVd0Bxv bBenLi5DMLvwxlg7pVMv+Wc8bBu/ivJ73bT8h3Fdu6kbHkn/rA0VzX4xO5/Z D27fEHE8fyxUuHB3obDn46/qhla9atyylL/91oWSTk6U+WNRzOhrM57955n9 sdu6Jgxm/tk1NKM9mS/9yfBbnvxPdb3WySNt2xMxzr49PbXz7W4T2o139KH9 5JrbvTvwqGVoD2/sZd1VrQuV/Uvwe/m8Lmit87l9/fL05Qv9iAY1NPqn6/lw +3ve0B9veSsz8Gt8iE8ze13XxeAIn7qKttZ/en/rOvGOh8U/rvmb2bLekqhU q7rZujbceXDiItz6tyQst/ENP9m6Zo1Db9p2F988e7bf72chhpkvumf/8Uu9 qTbPPs0/vft8/YyO3LizV4vZrljJo6IMJz9viLpEKp7b6uT0R4x+2UL2IPkX fuWr6KO96Br+7KKOJzxNLyX4b6o/08n/FOo7V3lLQnM5s7yHR0b+mTZrf/Ch IGJU1SODLusmtH+zl50vS988MuhzWLqmqG3h7RWxYrnZhqJ9bELXLGsR3shf ibaSsr4i3Z2+OBPR8k0gi0CsSOecn1/KqKyP9tK72DV+66vWntfVyvd6QHy7 eg/NnJ2dvfzm2Yvn37365sXzmfx8SUPOy7orrtsmrPzjfK2KGKekqrs6hm4L 7Xm2302XNW2gap91u7J2RXyGTT07ff4Mo/H7X0+/nU9f/vUtDa/L1v9153a+ eSAEvAGrO7CXoQ1rx8yHYFz7JXG9PRBl42209cpe1CSx1fQvrgwgGCm+b9qw IsKTCfo9cvGjJwts06YeGXRTL4KL9vvgF2H9yJjrTedomz+4+pEB55smxLbe bXxjf2w6v/blb8pqFcgorCt3XxpOv5uefftfSsN8tyO/UdiPvt2r6SZf4knK NmzL46beHRcJEoZvvpnh56tvXsOiXLy/+fC4MJCrmdY0LezPM/zyjPbqnhXE zxFjMYu9IRNMuuuqws4rVx5iiPbfodfTq/nn8xNjptOpdQuyoG5J1uxmQ9+z WyMdWoUKj9qtJ34W9snAuz21ZJtsA+mIZJ/ot1iXd76J5FhMF72N4mDJfhTq ZN1dTW6i7lq3pln3MD0iKKFlG8es4CWaSL6tqurWLjCzW26IrDQD+SZaZ2P9 l11o6CPMPLNXZGNILiGt25omosnqKhrsb7BhG7A1u3Vk6Nji0c62dcM7Z3/f 4uuL+tq6tnXL2zgxoBkNbfzikJ/b2tLHiDGgF3btQFx9yN6R3aybmZKxXnZs EtQ/87pM1cBbxK5viEWrpt7az9+fs/vmVfWPb8gj00OuFRoSTUCQW79rydvw bEvQhj481FVh8AHmY/IcJnlZzAY0YOkcASZr13gouLlzZQdWkLfk2TZhvSEH VZC6LEJL1GtxuoWHKMPy4LwT2zgQhVaj7ZxOWLJityaetpCVpdvhXN/Rlg9x ZkS+yAoX5O/MVzCZTV10SxCApK1xBdPCleWBt3ATtvS/2n4AaZ/QaZ5iNsfs gox1zRIsW9Iu7YY35yvTVbRlUvRapYTOF5mhEAn3JWy7ra267YLORZORbyNq RSGs08mMEpdEt6CfK0gGkWBLOA0fFyHCsfhiYhcOQ+qKviYW+7hswg5HACFI 8km4wZy///2/EdnBw19/ZRItS0IMbCWZ9XkIGPPrrzNzT2SIh042ORSZJOdE F0MnpUFlIFRDtCMC1nvWyaFygBzpUCox/svS74TkZhkaWo7Ug5zVgBz3VBqa 01VuQTo00EGaqwcodTWz9n2LkUT7gn0B0wgr1guoIY/SRYZaT/Ie97QIrXBH SMgtSBnJ3YAdSwdDkgyGvyODsU+AhVleHiCZOChJYw2jI9bD7uuuLGirbddU rPiHHe0JMtZVS5LbtS+I4j975R+RKBu5hU+EbMEQ3sFKrRlWggCURDB1kASw tzvWJksArmCdbnIEwZxnepEhjQ+Y/HvsQhakl7/+yrZhJFn/iH2wDwwEpnMl zZE2MhTJ/3/Wgpf8DZPxlb3xzTZUdVmvD6AZznQgpjZE35PLn65vTiby0368 4t8/v/vvP73//O4Cv1//MP/wIf8iIwz9cfXTB/0ev/VPnl9dXr77eCEP06f2 3keX8/95wvs2J1efbt5ffZx/OBHyDllJUZwqW6YZaYCLWcKggObt+Sd79jKT +ew1kVn+eHX2HTGY5VuIVFckrfInEZAkabcjKIGFSY7JWu1If8o4wRIELPaV haMi4n1PkuvsuqxjdM2BARuZTtrSlgbvSgKqUBNPy/4zln35+jVbn6/sW/Jf awo16aAgOZ0HZ3IDw0meOEI895sDu7yR8xbVI3N7ICKQUniyyuy6YTgmtO9l 2RUcPvgquBLzcSxOlucJed2n2e2SHjF+MhSFkLypg6mt2JjVyETpoiMDBVBM rpmV89gWIyu3s//WeaLPoiPJbUNZsjdpfOkJB6o+sWbRx4bsT2F3jlwBbD5p 0ES+G9g/Vj6ZSAzuqit5obWvfMN42oBmydhBa9g9+dbtsEcyT8TL2G13vaE8 EbOzIDqS+ESz8G3Lz9FMVS2fzwjCjUzCtWfnal/Mns/ObCSVksmS8p/EnV+S J1K705LDNSyzpN/9yPu+Vvgq9iQ7SAzUYfWKrcuQIiSWsMJujWAbz5LsdIT4 C1GnvNGXs7PZC7vqGjYUumEvZD6yWZs3+4TmVWf+NO/c/K6dw17J9obOHbSc Ewwlt0HTv6vWZSBPlxXaDVxwxPxbR6henQ3p1FYsgFmW0FRf1d16I/uSrUSR IXo6NL0dllkZaCjihbuemR/qPbm8ZkKa2jMX3jW7DIGvYV2T1kZWcbWZ4AY/ pSZmvwkUg8R6RdGiZ0x75FAnRKgTZsyJkOZkZtIs7A8cEZ8BFnJlFKvbE0xE cyxDPApSwCyKBgDliOXQNGJY4voruyeF29YR6IV4uEQkXfTehcwOxVpL8h/k rXEgdT/iT0QHWEsHRFz4DUXzhL8ZjBQ1rMcmkXFJJtEbZkfUPZCHI5KTapKg 3ah69ALnMnZs5SS2ZI9Gjxh8V9HyNZmQ4bezE2vZx8NZwdqJ9GMrzF02Toh+ 2RGYkSPIPk5oxc/Q+DsvyDiJJYGPdUcWiZAHQqQBrmJyiPGFQSQsCpPIMtd7 fWLqPCYW8db5d2yZDCXTIoJgvBLFnlPSDZql3sGK1Y0goihpUKzHxpStGoPa SIsTZw8zOx95jgegckfGHrhuYnrX8Pb9x4uJ/ZFONbFXO1+R5xJT8VO1gGOa ZNGrd4KUiOx9sMnhoEEY7u2lW15ds1EWgDMaBKe5c02byPADOdeDfXfwBO1K Yny5htPYbHEis6VdUBy/q2GzZ2AvTFlZegn/hDCMp0Fh5AeApoNa3S7iYP3S HGekU8SwrjgmqKD3FWlQKwpAihy2NGFBjj3SSHbQ1y1EDmZknsKnB8EB+Myh xQN/ENUhgJxiccmhUMBNp9KoyRVvaEqKLN6Q6L94PgWo6yrskcFL69fEtkfC qJGZNkXXDMTymDshUPWPuhPGew+dCXHkf/mmtmoegFkGCAxR0ta7wU4+f2ap YHiVQiNB+7QBMjbRiW0IzKY1bVwzAeov1EbLzmnxv8i6iir5G0JqffADfAx9 MwU7ttruvQfKYT5L9LlVLigO/vb05eTV6Wkm8JPIoQ+efzoDAmISQ4xHuAdB zBDu0Pk0VoNZTXFTNgTQPOHMkCFMDgcusvMKrayhMeWMhMnbf/0XJBTeUeCO HB9F26UjjpEtxcciH//6v0kE/Re3JVWcSmCVo5eAD4GZma3IYULCRWAiySuY UZBfCiVigfeDCCTxWNwZmXqf45Dp8TjE3I9DbIpDAgceHAqmOCt7uomIrGq1 50ySrElPIeYmGZSA+r88zcxcS5zDviBxuGfoeF9Y9ttX9kDwIUpED+U4mNHe iKmwPQIByKw2CD92nI1ixSHP9AtteFvTNiqAf5Nzc4h5IQgSGMuWGjZt0SfX 1JsrBS2TIeLOc4k6gtZJqmhlwP2cf1DB0kCUXBKnRpAHFFduSbdcO2CJasQg /BKGY+YXWR1YBs3vEyPmVSX5CXJ76qWY3ccjA0X8yOqlWqAQ57wu2Cj5wNw6 tU8+1u+apm6ekobbF/Tn/5C8+FOrWUM7H62QFn8ynz81SUyZhmrMsHmxxLx+ r7qcHGCn1ZtScGD2Dx6oIljImx9wvPBmYLj6XZBbJ/3rmvsZH91Iyouy1Saw y1mcA6AgoS+CoiQ/LZthEkqxGb+LX4SqAMW7GIVhX9l3YkLsJZuQFJeGKNCX BaeuGG8cz1wtYbKNHjgsyCTmbQjmGaRqVh4Ay0PTS6+hHJ6USphJoLlqB0k4 Tv6yG3cS7bGdTbZZjHLmJFszWVZNY8o5rcjpwbGIKSdM1iAHj5OMycRE4uzX /awUee5/IsS1lER25jDPNemN1zAh6raocfJhgAKdOUK/FMJxcpGiT/JdlQrh 0oddK7lZHt4xJGk8hdWEN9lhkleDNUHMnHY0k31K7N0/N94oWUkN94gk5e/b KKFFxFdNvSRDk4pXvIwumQSaHt745e14xTJsg1rUFR+Bc3etfusMHia1KOv6 ttuRoZIo31E0TuG61xhXF0r0FeYcP9j4SGYUI6bZOY03CBj7OIcWuqS46Wj1 xZUAcofeOz5GaiS0/GolKJYUg4H7bUDmaXWcWAn7soyZsYwxw4+cnPFY5fcS 4e3amDOrZuvhfkPcJq90VINZ0O44GlPZmgyCd1qpaVkjjkr+TIMx2Ypkc4u+ FKUnwbd110aJGvu0AG15FdYEZTmBdQSvZe90NntlElrLKdBfENFLooccPz2k tKel+iefZ5THZseI2VmHuyTCmRBsklkjW8vSgs/TKFTOZhIP5Ada0JTZF1kF JRUs4dqhx3RZ7iCEJpKAxdVBl+51WRBDlApYIKWXXH3pJScXWkNRSIEYt8+h 9UsMvQb5VGYyUeOCjC++XpVuDe4gsIZbDNVw/SG/A5G+CORcGNxydl+JJFwH k4i+RqODRJ7+6PcODQHJpYHkEHgqs09iAJ6vfIOAGJLzWMWSWEw/0op/I7c0 MQjjOaiR6Gip4cnYExYetov+hH8AKdna0+RibXqDUGBOYSsbqmM6iqBuGBrN xUTFoR9nuFDRyskvIoptBBzsAx0dMzM4fPSsTtbNmiCeDhuEBMA5G7WjLROW /DRyCocRjpNQhmkugrbnDCzruySCKPrmAYiq62Iy4KUm9YbykI/NjB4E+219 TKyJ2lek9AjDOY3FSyTX/oizGCqkGZqg37C0LPcLv1ahzuw1g4HqtsbmijMe 4i6QDhfqLg7jTTDe0Iw3WOa/oCMFTlN5F1IGPUQ1QigWcprfnp2CcS9OzUOW yBY0ULRc3By4O/WDkgOPgpWMFn7kKL4YUEsOSc6mbni8W9CG6DSFSDw7RMmL IwcvATYfC4rCvKV4kLObHA71mSuuvx0z/DyRL8ndjjYygDS9dYRxNCJVRA2U RoioGpMp2hyXVHFqzfn2YpWQj9Aw1my1XJHyI6kYO7JWKSZS14LUyzgmsk9Q 3dHUigacMWWBppKo+PXXp+qY87wC9JAb56aGoX8UcDsiCKQnVIir4SWUyfcr vZJaEz9d1UPpkipRn4NI7RqFNIuN0KFOfpwjx1cm1pd+7XKBnT7PCnffVCbh 65PISNFLSCuZTtZBc1xRZ6J89HGqwQwqBNA9Vh3AGLOTKGos2fcMykP1nozg 9xAkJWQCeJ/sW0WSIZVFUV5yr8lRJCt1/xwm25Ex6lHs1bGXK8KK29Na8QPD LfHSyACKzPovAfVZkrotEEPGmHKO0nEtSrTeob1hu0sEzvCG5mJElK36b4Sq AjOyTzEiTn2qJMEC7G+Q9HxEKWYMho4Q2zwG8LB+anniA/pqTWKUw45VyyhM 20WSaRQbOISNqKmk/FB2WKqiWvRO2NGEmKMqycy+6Gvg70cwAW2Fg0jwficB xJztpBSb5QRSQEVVJHA4Jp3Pg1w0ixbHtKkFJxcqUoqaE/xIReek+Ewz4CxT wBsYDuzDPhib/jLJYE8TeWwkFvDxpV+piidcy8IQwe4+NhfShYZTFGi4ibLq IL7jNNqou8uZskYVNWfkZRscQkcO3O9cE8DsnuqkU2V9wJqyR0BQ9HEoiuBM Ms8nbSnExlyW23v1AiV6Z5G3CetNSf+kDEmHQRWatolVkRUZ4z5yPnVYwjuz QcORstmSFIAJ1R1oVCiyR63M1gtJseQq5L2ofiDps+zN07kNJyVqKexAajk/ on02aAyKDAbVBPktqlvc0aTVu5UkhA3miCQUpZiCIR9aQkxVIMuUC1HcL5cj zYlkl+Evc3VWU+qjlpVh49LKCkuI+tckK9BDyQRPDFsHXoE9poP6TDjBP4xt 6atC3d4dAmrOkKLLqF4ZbS+iuT/U1bqfGvvcdoj+EXsiaT9BXKbIY8UZ1gop cCSH4oEEbMsoGwXFpR/5PYgtUX8r3UD05KYji6p1bFE+uOlV+EL0/cNjFaXU 7aYFF6ItdiLcbyB25JZqJJW0DWhD9pAhR4PGRFSSeP0OJZW2qwQ0RyR2WB0J SAuQiYE8haYZ3ldLNH0QE1QaGGSre1wmi7eVlmEBZzsSdiCDv4EuNG19J80e o5wy2wuOQe5HoQobxBX5LxsSzdReNlKfyJLDtb09ivTS+MEWssdvBH348ClE Zh+iQC1lImBlSs6yaC2Uc2v6jdnVuw6Ney3aKTWv5NrU81mk5kUKGND3aRMc 530MznEXlnqKec4zcjNqJU55VXZ0BgYYYzotNf8Wa5PbStQcHAe+sIOV5HmT 1mvyqZDoTeLD7EmGRgJOWy1EhJ5NFAErEBBBi7eaKeB9psqvxmOsr+NGvaNd Qig9LhWQ5CYh6cUhgfyDbAhzAo2V7A+QSYmBfXVaVUMOSQTAPJyjWt5EEmwy zy5I/A97V7N1pTC6YizJRkEMNHqVm4GaKXGlx8/nyuBjwbbtY2h0+KFejFhl 2fb5m8qjijNqbkTWdICgsedO6EvxW+P6FhbIovRZJ1vy0KhzBIY6TDLsEy3P D3mTQH4G6UIy4ZVAmwfMMn13VebRHxAop/61F6evUJBKHR3fTWRjPRSqatMn 6lfgP8VwXeuHkebwGAO/cmwnWcykKT51i7hRHb1PrYpDg/1b0XfE2M/EfOnK SDiSA74WsHWsdmGcV5qYDe4RNJooYlRLC/wNdeeUv+OEK9tntfa086WkItAM N3b+GpMnaUyFTTrA1+3IczFK3W67Slpqpek3SDkR/Tx7Ai1EzCtReIQDrLmy RTEeJZrHxDxyIfIOnSMlx8awYzRy2pc51KqgzWYXCuRu0OCSIzKBseZoErRP 7bBDF2NGdoY8I2e90Z+7qxlsksFUIkXDLKzqVMF0vY6yIZVkPPwx4mmY+wa1 JUnYG20a40gImiThBQUrahyl/FVXdTPoKYvJq6Owu1eJ6KtqaI9Jaq8FYvai ntujITWjDtgHledcc04guJLgSEohjCvqHY2RtNmwwYrXkGGGRkG87pWibcpI ECZWYazl9gMFKxR0iNOJEDb0hR+MmhZGG5mczIAhyhDpBrr9mGjPArRx6Hcw edwgVuCuiuwPGQhDdnstkNxIEFCAXLhJ9aBTXJVrSSq1tZNYSXZL+v9Rf+N4 0ZWQcjniUDrMrmtAPNEsnTEp5PP/8/ybvm3ijAvpXKCFFRLZbfzX5HsgR5yq ZgyaAlXVenIUuFuQk+uMu0etOsJrwuf5Hs3X0Z5cuEOa4kNY+RMiAZQeXdW4 iUMxqbU/q7S73c41UkZBTy1H/n2LlXY1SbJ9GJ9p3ymXXAlUSzHaow5N528M AFUKhdWnaWgTh7Vw/hudKJuDKAOffsuhy4LQSsW3H1EI1rJHpStJUMgBf5Ui EY36fFmKGvFxHMdzmH9ARxgi/J5UpfcTLPjIGaXcBCARqbLRp7l2LTmPijyk RYWBRGyBhBUrXVY06b2hg5vjSQEzV3B0PxgbYqIUU0mVVZFOn/4G7kNbkBc7 oWn6lLwFcBGG+WJwQYOwCodZk9wkN8inkDPLgGE8+TDpDtBExyXBgQXcuVZT +Y4EikN0iZxkP4wTjmEv0y+gAe84e6fF6skwfuGetTpKBT1leyE6cLBodA6r R7Ge1IwIk93pitib/Z6kFVYAIGvSI/f+IhWEiPa0m4LVaIRDhkOkv3W3kqw0 Q+rUqxVJIAGUYTQ6uJUmjRBFzuWukX8ZEzt2C1knavVBnrr5cJHyvam/WymW umE0uMgP8VWUPNlEUJZ8HFq1qhSuabsE0RQ8oz0RabSpj7Yo7YWPpLdkZ+xj tRGFlSB1oeTqbEZjobrTC5t22KqBYkCM9TKw/mkWnmNZk9ODK+mmd+hP1haS z+dXF+8GN6g0lyNySMKeTUiUi3NYktbBRVGYn2YExEC8ZDg5NONexoZbSrRb M++QzVFok7LB8hDc0YxvRka5PJIaghGO8GWGcSH/SUS2QENOIsl05dslsXD9 lBNh5NBSGkewuU4vesZNLkhJQJmPRjnZoBt2i9GFwqY+xIOK1I6Li3YcTR25 tXXHlWp9ODR2XInj7tScQlKHwHkp3LH4ng6dfC4MWiovN939jesGhtE2FkFz YOGXnNquNXi4FwCmCzHD7MF1kHtl3q5rTQI8uI+Z8ozDRhwIM+mZOhijxxnU BeQeluS/RgLJt3DUmfRdjCA3XrNgCf0EUgO96wnTlyzvg+ssuWGFQvZS5jFJ u/QCyUCHsmiwLIsn3Xu1FZUwZKLJMywrCSmVhr1cmXHq8gXgkarlOIBH0IYL WaQLcZPBQupJYk/k1wQ8t9DxJXKmKbDk5eUj4ore4u87rZKMvX938z1vEgis z1RjjxODmn85KiumAnxvalj4mBPg9We/ggTTo22K20AK9YipaQrQGhaC81Op ci7Of9TDlu7oaFcLRn0dh8WhXQ1KFFpk285MWr+/AYDcCDIpnKyunRauuT14 i24BJM/UzeWIP3WbLvVGoV4tNdwqzDFGriLwNtJjCMoez+PxjS1RZ8WzuaFB ro2vRPmRetzVsF8iAWR4gmc9NZmQIB9Tj3uxmHwwi067CRW68Q2/ZHF7shlO LqR1s4CnuLoL0pN2fTXX9olWor4Uo3G5ih49ZjEIjSIPx9nZ47k5DqmOStWQ Co4vlaI2mPY/bH9LpcmHBROSFUcgwVz3rQCp0JYv1yWTgpnBGPUPodKLjaB5 AZ00WrylbVKglWOhBEuRm1rnmy9oHU0VEHVBXQOOkT5LQJRdg9aL+y3uveQG XblH0Uv9gBl2OmS469QVJbs4aEjLKZ377Vo5jQwxvleJFZc06NzgApx4Fr1l K9UuGcjaKGiGrG7dLUo/oCed7K1aNe1F7tFYh5s4qVKgnmrof7UYKG0hS3Ie PvKFW5ZBZHPYU8BYGekbIoEEFsWNR6ldci4kp0hlIrmgy8F8WK+5mlf5vVEw sEIqXE2haPny4dXfrh00bJPwmnVdF1OSGrhdaXDIBEbRk6m4dclx9mXtQRWu v5IW2KKRWqnu9pkM5OL5+8CAx4kH67N644JzKqX3UiCq8pgQEFQL5dGScupY myQPZTh2QfCBm2acr+lHcwZL7DmXjPMVkVqCheSVyR0vSQPEzOSL32UOGXDH ukj3QDVXVqcIlNNGM9LqercbdcmNz54T0KPmsFErhxmRQYW6vy0ygjaAGqNT szvVLrEK4na/11erpGCQNsZswkJq1twuGtPlIFF7sbgph8bNIHptm7VY+/yH N1QGt//FLjOhQ6s1+XQBTGpkfU/UiizugkIszkSJ0EGBBHPqhRyxy3SIt+Rr 9q7RtwOcO7LpfPqPwDlPzj/OL99Jx/sFftVLxd9++91zClE0mWq2tJty+AIC 5oA2OvC5U1+6JF+1zz1iCfJrXqLgwRsBIrnMJkQpMKE+kINvIBd53UBODgPe BM543Qv5cQvv/ccLaaFyhBJiK+vI+wEkts4JCPv+091LO5d40T6ZP03JI77Q wITQGj8EWG9jYf7Ejcj5Dbk/xPUgPXV72HFdyvS1T90RTzpqisud3FUK+XMW L6YGynE2nFsAhlVrMQkLWjvTO6mEuhUz9MbQ+q0f6uhEY0IRIlbtUSCQSgt8 nrqEE50Pgg9N4iDMFKId8dzksNsuigbltoPRRfojt4tAKJO887DRX4yOg/Yu uU7IXHk9+252Kh2/2QqgykQWjnYwv3WEg77mhnJ9WUkyR0ReOIbnp2dnYpgG 6XoTtzW4Wkh9s8eIGUzigVLqzOm9FoN+MjhUFWk5plzloQUD+n6iSpicBIIB +0I06RT45pfIXWs9Gk0j5C5Ct814ZNVVSwGlqESx0Oz7dt6kFUSfs+fcH1Jy P9pdcAJ/9N6lvOFOeD71lQjG6MO2LaXJfOu+6Avx6CNit97lZLK7lP3NVdH0 1p6+U0UFS4iNIp66MVXwAXQaYiTpVdio8kgbahNEylM7/z2XrNkPrmH3UIR2 jAupuAokIEn2XfgtGl2LTpPyb0x6Q9MtjZ7mcgK68SER9TLOQv3MV88iQ+pn 8mycbdpt+dUgLjZygZVkT5oKhr39SGEgdU1LIFoaXmvNVNKeYzPsvMH+sZEA 8Jg7t/U6CntIeUsVvx/sH3wrnOnfCnd9glR3fktdukinHT5WCqO+kPTnKLma jMdi0GY2fkNU4PLY1qeOes4Sij6ExuQTqD9I4asoF9cg9yhF7fhNCq4QMc63 oBMSVXc+MKBiSPjdkPcyFJzR5j6a4TVnaS0QnAwps/WwuGzdIqXIpCZ9D2jl 9oecB5VbUKD31U7u/Cq5OejoQ/j7uZVBRG+ORvRYguet7/c69rYgR49mADVo /DSw8KXcSd8Vi1btPk3sYBOQKeGCReSaFhRnQRvRyjzH/6GSFwYJwwf6nA1z vqTrMoRVgKW7gTABkKm3/EXkzMUxe+WNA17B88KPgip9ZQdNJgxPcn4kMaU1 0nzhAohc8oK6AyQTthqrccky7SiBaE0IeynVSek28RGJpZrrg0Z5w9zj/AcK 5NyUtFDwMGyaY6lEE0AgQ8sd7YIapB1TrpCnt/k97Ca8118W00hGEKkiEnI/ EEK2Mmxq6ZknQl2/OzeaYh7mQYSp92/B53wXZ4FaHpjaiUxuTqj7dtrAfVmh wI6kVX+mr3DN1eLcMiPFTt6nSd10pP5VQY5O8sCEP4g1OwpYA1+xvPlwPYek Xlzbz5/jsCdNYFvH4b9i4490UgzGzxf9RZIbDhEi+Rq0+6W3gqRr5tgTCGl+ s1LC5ZHhW3PY5WKK3O4+iJqPvoNIUl7i7LvY93MGfe8awTu+j5UaWnDNne9v Exf3YyTS3wjRIEnqPSiiFf1b2yRW4/anYRPEyEVBj5h6HKHcer8zGewj3L3X hhKakdnnSdfIazl+scRNajnUqDZBh9xcUMrr+vSqndSTSBoC419N5qarQpkw /IIeJg16nGaEpXJ/10QnkVs+3DFZbxeh8kJ/Dd0u+ncHWvS6H+Vwbh3I6bs+ j6SxRrLg+c0HRgVPio3AjjP7Vtox+31pZhQ1EbdzS25Y4zIDIma34Cot7sIW akAIykZtzKERmDaXacOKpYGwu75RAzjh738fvKcUnl29CnBQhZdHwrxtSMPG 732ccOxGyDiFV1EStWL/B8VO8UmMVRJAVruuFz44EjQpgKCZJnb4yj7OhkzJ YPaWK/V5iKsyUo2b3uX3li4H7y2laM91AGTi8qGqmoHJNJ6Zn/XyxFDn+je7 cNlBUkr2riur3DScFRVveuacFT80FFdfCZSQ9gO2VMjCymt7+Bi5MJrNJLJK 3FCY3EXqw8wVbKLo4IwjnVJ3Tx6PeIMEmO12cn2fY+DckqyxODtCCm0kAce5 NR6ntWYzL/nakURBE3s+zyuAg4MKYYIJoNjDhnT2UZ+acOeWx1zUUbqTCGlF s+8f2qMLlSeRFnie9+P85rjbkzvYfXjZl2CQQVvlnO0g84y5CkTxOvf7+cf5 scn1JWok0zxifJubn5wvYSkpGpHbHinqVcicWluhp7eExINDXrvZcZZ9Yj/X BDxb+67YIs02sTc1EeJ7cn6biXlbL+wPjlSb3MENGciDs38O1daHib0kUQr2 x7JGEujP3LBxSRDZdZP8zmZ+W/PE/BnJsM81sfSyu0XQdk1kbSg2Jpt44fBm ousabwz65Ag6/SV8CaSVn125sj/7hVx9M/zVz2Rp05vXxMCjdkZ84o5o74uF oHke/EO9WqE/Ojes8g0oeTlZdZtL9STt+laNHoB/InmmSE1QOOMz0O1Qd4LD NIe/qnGfHc9uPZ7Mr0N6/+76T4M9rpBKMLLTN5bogF1dkLCVYT+xb331i9uS mv7oio4Ied1xJPkjuY9NBQJdhuYXZ378v/+5KT2UWtzyvHBbmopUbSbvRsXR zf8DFAIysqJeAAA= --></rfc>