rfc8767.original.v2v3.xml		rfc8767.form.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->		<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
	-ietf-dnsop-serve-stale-10" category="std" updates="1034, 1035, 2181" obsoletes=		docName="draft-ietf-dnsop-serve-stale-10" number="0000" category="std" updates=
	"" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs		"1034, 1035, 2181" obsoletes="" submissionType="IETF" consensus="true" xml:lang=
	="true" version="3">		"en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 2.39.0 -->		<!-- xml2rfc v2v3 conversion 2.39.0 -->
	<front>		<front>
	<title abbrev="DNS Serve Stale">Serving Stale Data to Improve DNS Resiliency </title>		<title abbrev="DNS Serve Stale">Serving Stale Data to Improve DNS Resiliency </title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-serve-stale-10"/>		<seriesInfo name="RFC" value="0000"/>
	<author initials="D.C." surname="Lawrence" fullname="David C Lawrence">		<author initials="D.C." surname="Lawrence" fullname="David C Lawrence">
	<organization>Oracle</organization>		<organization>Oracle</organization>
	<address>		<address>
	<email>tale@dd.org</email>		<email>tale@dd.org</email>
	</address>		</address>
	</author>		</author>
	<author initials="W." surname="Kumari" fullname="Warren &quot;Ace&quot; Kuma ri">		<author initials="W." surname="Kumari" fullname="Warren &quot;Ace&quot; Kuma ri">
	<organization>Google</organization>		<organization>Google</organization>
	<address>		<address>
	<postal>		<postal>
	<street>1600 Amphitheatre Parkway</street>		<street>1600 Amphitheatre Parkway</street>
	<city>Mountain View</city>		<city>Mountain View</city>
	<code>CA 94043</code>		<region>CA</region>
	<country>USA</country>		<code>94043</code>
			<country>United States of America</country>
	</postal>		</postal>
	<email>warren@kumari.net</email>		<email>warren@kumari.net</email>
	</address>		</address>
	</author>		</author>
	<author initials="P." surname="Sood" fullname="Puneet Sood">		<author initials="P." surname="Sood" fullname="Puneet Sood">
	<organization>Google</organization>		<organization>Google</organization>
	<address>		<address>
	<email>puneets@google.com</email>		<email>puneets@google.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2019" month="December" day="09"/>		<date year="2020" month="March"/>
	<area>Internet</area>		<area>Internet</area>
	<workgroup>DNSOP Working Group</workgroup>		<workgroup>DNSOP Working Group</workgroup>
	<keyword>Internet-Draft</keyword>		<keyword>Internet-Draft</keyword>
			<!-- Reviewer: There is also a "0000" in Section 4 that will need to be
			updated. -->
	<abstract>		<abstract>
	<t>This draft defines a method (serve-stale) for recursive resolvers to		<t>This draft defines a method (serve-stale) for recursive resolvers to
	use stale DNS data to avoid outages when authoritative nameservers		use stale DNS data to avoid outages when authoritative nameservers
	cannot be reached to refresh expired data. One of the motivations		cannot be reached to refresh expired data. One of the motivations
	for serve-stale is to make the DNS more resilient to DoS attacks,		for serve-stale is to make the DNS more resilient to DoS attacks,
	and thereby make them less attractive as an attack vector.		and thereby make them less attractive as an attack vector.
	This document updates the definitions of TTL from RFC 1034		This document updates the definitions of TTL from RFC 1034
	and RFC 1035 so that data can be kept in the cache beyond		and RFC 1035 so that data can be kept in the cache beyond
	the TTL expiry, updates RFC 2181 by interpreting		the TTL expiry, updates RFC 2181 by interpreting
	values with the high order bit set as being positive, rather		values with the high order bit set as being positive, rather
	skipping to change at line 74 ¶		skipping to change at line 77 ¶
	<t>We describe a method below for this use of stale data, balancing the		<t>We describe a method below for this use of stale data, balancing the
	competing needs of resiliency and freshness.</t>		competing needs of resiliency and freshness.</t>
	<t>This document updates the definitions of TTL from <xref target="RFC1034 " format="default"/>		<t>This document updates the definitions of TTL from <xref target="RFC1034 " format="default"/>
	and <xref target="RFC1035" format="default"/> so that data can be kept in the ca che beyond		and <xref target="RFC1035" format="default"/> so that data can be kept in the ca che beyond
	the TTL expiry, and also updates <xref target="RFC2181" format="default"/> by in terpreting		the TTL expiry, and also updates <xref target="RFC2181" format="default"/> by in terpreting
	values with the high order bit set as being positive, rather		values with the high order bit set as being positive, rather
	than 0, and also suggests a cap of 7 days.</t>		than 0, and also suggests a cap of 7 days.</t>
	</section>		</section>
	<section anchor="terminology" numbered="true" toc="default">		<section anchor="terminology" numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	"OPTIONAL" in this document are to be interpreted as described in		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="		"<bcp14>SHOULD NOT</bcp14>",
	default"/> when, and only when, they appear in all		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	capitals, as shown here.</t>		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
			are to be interpreted as described in BCP&nbsp;14
			<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
			when, they appear in all capitals, as shown here.</t>
	<t>For a glossary of DNS terms, please see <xref target="RFC8499" format=" default"/>.</t>		<t>For a glossary of DNS terms, please see <xref target="RFC8499" format=" default"/>.</t>
	</section>		</section>
	<section anchor="background" numbered="true" toc="default">		<section anchor="background" numbered="true" toc="default">
	<name>Background</name>		<name>Background</name>
	<t>There are a number of reasons why an authoritative server may become		<t>There are a number of reasons why an authoritative server may become
	unreachable, including Denial of Service (DoS) attacks, network		unreachable, including Denial of Service (DoS) attacks, network
	issues, and so on. If a recursive server is unable to contact the		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		authoritative servers for a query but still has relevant data that has
	aged past its TTL, that information can still be useful for generating		aged past its TTL, that information can still be useful for generating
	an answer under the metaphorical assumption that "stale bread is		an answer under the metaphorical assumption that "stale bread is
	better than no bread."</t>		better than no bread."</t>
	<t><xref target="RFC1035" format="default"/> Section 3.2.1 says that the T		<!-- Is quoted text DNE? -->
	TL "specifies the time		<t><xref target="RFC1035" sectionFormat="comma" section="3.2.1"/>
			says that the TTL "specifies the time
	interval that the resource record may be cached before the source of		interval that the resource record may be cached before the source of
	the information should again be consulted", and Section 4.1.3 further		the information should again be consulted", and <xref target="RFC1035" sectionFo
			rmat="comma" section="4.1.3"/> further
			<!-- Is quoted text DNE? -->
	says the TTL, "specifies the time interval (in seconds) that the		says the TTL, "specifies the time interval (in seconds) that the
	resource record may be cached before it should be discarded."</t>		resource record may be cached before it should be discarded."</t>
	<t>A natural English interpretation of these remarks would seem to be		<t>A natural English interpretation of these remarks would seem to be
	clear enough that records past their TTL expiration must not be used.		clear enough that records past their TTL expiration must not be used.
	However, <xref target="RFC1035" format="default"/> predates the more rigorous te rminology of		However, <xref target="RFC1035" format="default"/> predates the more rigorous te rminology of
	<xref target="RFC2119" format="default"/> which softened the interpretation of " may" and "should".</t>		<xref target="RFC2119" format="default"/> which softened the interpretation of " may" and "should".</t>
	<t><xref target="RFC2181" format="default"/> aimed to provide "the precise		<!-- Is quoted text DNE? -->
	definition of the Time to		<t><xref target="RFC2181" format="default"/> aimed to provide "the
	Live", but in Section 8 was mostly concerned with the numeric range of		precise definition of the Time to
			Live", but in <xref target="RFC2181" sectionFormat="of" section="8"/>
			was mostly concerned with the numeric range of
	values rather than data expiration behavior. It does, however, close		values rather than data expiration behavior. It does, however, close
			<!-- Is quoted text DNE? -->
	that section by noting, "The TTL specifies a maximum time to live, not		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		a mandatory time to live." This wording again does not contain BCP 14
	<xref target="RFC2119" format="default"/> key words, but does convey the natural language		<xref target="RFC2119" format="default"/> key words, but does convey the natural language
	connotation that data becomes unusable past TTL expiry.</t>		connotation that data becomes unusable past TTL expiry.</t>
	<t>As of the time of this writing, several large-scale operators use stale		<t>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,		data for answers in some way. A number of recursive resolver packages,
	including BIND, Knot, OpenDNS, and Unbound, provide options to use stale data.		including BIND, Knot, OpenDNS, and Unbound, provide options to use stale data.
	Apple MacOS can also use stale data as part of the Happy Eyeballs algorithms in		Apple MacOS can also use stale data as part of the Happy Eyeballs algorithms in
	mDNSResponder. The collective operational experience is that using stale data		mDNSResponder. The collective operational experience is that using stale data
	can provide significant benefit with minimal downside.</t>		can provide significant benefit with minimal downside.</t>
	</section>		</section>
	<section anchor="standards-action" numbered="true" toc="default">		<section anchor="standards-action" numbered="true" toc="default">
	<name>Standards Action</name>		<name>Standards Action</name>
	<t>The definition of TTL in <xref target="RFC1035" format="default"/> Sect		<t>The definition of TTL in Sections&nbsp;<xref target="RFC1035" section="
	ions 3.2.1 and 4.1.3 is		3.2.1"
			sectionFormat="bare"/> and <xref target="RFC1035" section="4.1.3"
			sectionFormat="bare"/> of <xref target="RFC1035"/> is
	amended to read:</t>		amended to read:</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal" indent="5">
	<dt>TTL</dt>		<dt>TTL</dt>
	<dd>		<dd>
	a 32-bit unsigned integer number of seconds that specifies the		a 32-bit unsigned integer number of seconds that specifies the
	duration that the resource record MAY be cached before the source of		duration that the resource record <bcp14>MAY</bcp14> be cached before the source
	the information MUST again be consulted. Zero values are interpreted		of
			the information <bcp14>MUST</bcp14> again be consulted. Zero values are interpr
			eted
	to mean that the RR can only be used for the transaction in progress,		to mean that the RR can only be used for the transaction in progress,
	and should not be cached. Values SHOULD be capped on the orders of		and should not be cached. Values <bcp14>SHOULD</bcp14> be capped on the orders of
	days to weeks, with a recommended cap of 604,800 seconds (seven days). If the		days to weeks, with a recommended cap of 604,800 seconds (seven days). If the
	data is unable to be authoritatively refreshed when the TTL expires,		data is unable to be authoritatively refreshed when the TTL expires,
	the record MAY be used as though it is unexpired. See [RFC Editor:		the record <bcp14>MAY</bcp14> be used as though it is unexpired. See Sections&nb
	replace by RFC number] <xref target="example-method" format="default"/>		sp;<xref target="example-method" format="counter"/>
	and <xref target="implementation-considerations" format="default"/> for details.		and <xref target="implementation-considerations" format="counter"/> of
	</dd>		RFC 0000 for details.</dd>
	</dl>		</dl>
	<t>Interpreting values which have the high-order bit set as being		<t>Interpreting values which have the high-order bit set as being
	positive, rather than 0, is a change from <xref target="RFC2181" format="default "/>, the rationale		positive, rather than 0, is a change from <xref target="RFC2181" format="default "/>, the rationale
	for which is explained in <xref target="implementation-considerations" format="d efault"/>.		for which is explained in <xref target="implementation-considerations" format="d efault"/>.
	Suggesting a cap of seven days, rather than the 68 years allowed by		Suggesting a cap of seven days, rather than the 68 years allowed by
	<xref target="RFC2181" format="default"/>, reflects the current practice of majo r modern DNS		<xref target="RFC2181" format="default"/>, reflects the current practice of majo r modern DNS
	resolvers.</t>		resolvers.</t>
	<t>When returning a response containing stale records, a recursive		<t>When returning a response containing stale records, a recursive
	resolver MUST set the TTL of each expired record in the message to a		resolver <bcp14>MUST</bcp14> set the TTL of each expired record in the message t
	value greater than 0, with a RECOMMENDED value of 30 seconds. See		o a
			value greater than 0, with a <bcp14>RECOMMENDED</bcp14> value of 30 seconds. See
	<xref target="implementation-considerations" format="default"/> for explanation. </t>		<xref target="implementation-considerations" format="default"/> for explanation. </t>
	<t>Answers from authoritative servers that have a DNS Response Code of		<t>Answers from authoritative servers that have a DNS Response Code of
	either 0 (NoError) or 3 (NXDomain) and the Authoritative Answers (AA)		either 0 (NoError) or 3 (NXDomain) and the Authoritative Answers (AA)
	bit set MUST be considered to have refreshed the data at the resolver.		bit set <bcp14>MUST</bcp14> be considered to have refreshed the data at the reso lver.
	Answers from authoritative servers that have any other response code		Answers from authoritative servers that have any other response code
	SHOULD be considered a failure to refresh the data and therefore leave		<bcp14>SHOULD</bcp14> be considered a failure to refresh the data and therefore leave
	any previous state intact. See <xref target="implementation-considerations" form at="default"/> for		any previous state intact. See <xref target="implementation-considerations" form at="default"/> for
	a discussion.</t>		a discussion.</t>
	</section>		</section>
	<section anchor="example-method" numbered="true" toc="default">		<section anchor="example-method" numbered="true" toc="default">
	<name>Example Method</name>		<name>Example Method</name>
	<t>There is more than one way a recursive resolver could		<t>There is more than one way a recursive resolver could
	responsibly implement this resiliency feature while still respecting		responsibly implement this resiliency feature while still respecting
	the intent of the TTL as a signal for when data is to be refreshed.</t>		the intent of the TTL as a signal for when data is to be refreshed.</t>
	<t>In this example method four notable timers drive considerations for		<t>In this example method four notable timers drive considerations for
	the use of stale data:</t>		the use of stale data:</t>
	skipping to change at line 255 ¶		skipping to change at line 271 ¶
	<t>The client response timer is another variable which deserves		<t>The client response timer is another variable which deserves
	consideration. If this value is too short, there exists the risk that		consideration. If this value is too short, there exists the risk that
	stale answers may be used even when the authoritative server is		stale answers may be used even when the authoritative server is
	actually reachable but slow; this may result in undesirable answers		actually reachable but slow; this may result in undesirable answers
	being returned. Conversely, waiting too long will negatively impact		being returned. Conversely, waiting too long will negatively impact
	user experience.</t>		user experience.</t>
	<t>The balance for the failure recheck timer is responsiveness in		<t>The balance for the failure recheck timer is responsiveness in
	detecting the renewed availability of authorities versus the extra		detecting the renewed availability of authorities versus the extra
	resource use for resolution. If this variable is set too large, stale		resource use for resolution. If this variable is set too large, stale
	answers may continue to be returned even after the authoritative		answers may continue to be returned even after the authoritative
	server is reachable; per <xref target="RFC2308" format="default"/>, Section 7, t his should be no		server is reachable; per <xref target="RFC2308" sectionFormat="comma" section="7 "/>, this should be no
	more than five minutes. If this variable is too small, authoritative		more than five minutes. If this variable is too small, authoritative
	servers may be targeted with a significant amount of excess traffic.</t>		servers may be targeted with a significant amount of excess traffic.</t>
	<t>Regarding the TTL to set on stale records in the response,		<t>Regarding the TTL to set on stale records in the response,
	historically TTLs of zero seconds have been problematic for some		historically TTLs of zero seconds have been problematic for some
	implementations, and negative values can't effectively be communicated		implementations, and negative values can't effectively be communicated
	to existing software. Other very short TTLs could lead to congestive		to existing software. Other very short TTLs could lead to congestive
	collapse as TTL-respecting clients rapidly try to refresh. The		collapse as TTL-respecting clients rapidly try to refresh. The
	recommended value of 30 seconds not only sidesteps those potential problems		recommended value of 30 seconds not only sidesteps those potential problems
	with no practical negative consequences, it also rate limits		with no practical negative consequences, it also rate limits
	further queries from any client that honors the TTL, such as a		further queries from any client that honors the TTL, such as a
	skipping to change at line 303 ¶		skipping to change at line 319 ¶
	previously looked up.</t>		previously looked up.</t>
	<t>The directive in <xref target="standards-action" format="default"/> tha t only NoError and NXDomain		<t>The directive in <xref target="standards-action" format="default"/> tha t only NoError and NXDomain
	responses should invalidate any previously associated answer stems		responses should invalidate any previously associated answer stems
	from the fact that no other RCODEs that a resolver normally		from the fact that no other RCODEs that a resolver normally
	encounters make any assertions regarding the name in the question or		encounters make any assertions regarding the name in the question or
	any data associated with it. This comports with existing resolver		any data associated with it. This comports with existing resolver
	behavior where a failed lookup (say, during pre-fetching) doesn't		behavior where a failed lookup (say, during pre-fetching) doesn't
	impact the existing cache state. Some authoritative server operators		impact the existing cache state. Some authoritative server operators
	have said that they would prefer stale answers to be used in the event		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		that their servers are responding with errors like ServFail instead of
	giving true authoritative answers. Implementers MAY decide to return		giving true authoritative answers. Implementers <bcp14>MAY</bcp14> decide to re turn
	stale answers in this situation.</t>		stale answers in this situation.</t>
	<t>Since the goal of serve-stale is to provide resiliency for all obvious		<t>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		errors to refresh data, these other RCODEs are treated as though they
	are equivalent to not getting an authoritative response. Although		are equivalent to not getting an authoritative response. Although
	NXDomain for a previously existing name might well be an error, it is		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		not handled that way because there is no effective way to distinguish
	operator intent for legitimate cases versus error cases.</t>		operator intent for legitimate cases versus error cases.</t>
	<t>During discussion in the IETF, it was suggested that,		<t>During discussion in the IETF, it was suggested that,
	if all authorities return responses with RCODE of Refused,		if all authorities return responses with RCODE of Refused,
	it may be an explicit signal to take down the zone from		it may be an explicit signal to take down the zone from
	servers that still have the zone's delegation pointed to them.		servers that still have the zone's delegation pointed to them.
	Refused, however, is also		Refused, however, is also
	overloaded to mean multiple possible failures which could represent		overloaded to mean multiple possible failures which could represent
	transient configuration failures. Operational experience has shown		transient configuration failures. Operational experience has shown
	that purposely returning Refused is a poor way to achieve an		that purposely returning Refused is a poor way to achieve an
	explicit takedown of a zone compared to either updating the delegation		explicit takedown of a zone compared to either updating the delegation
	or returning NXDomain with a suitable SOA for extended negative		or returning NXDomain with a suitable SOA for extended negative
	caching. Implementers MAY nonetheless consider whether to		caching. Implementers <bcp14>MAY</bcp14> nonetheless consider whether to
	treat all authorities returning Refused as preempting the use of stale		treat all authorities returning Refused as preempting the use of stale
	data.</t>		data.</t>
	</section>		</section>
	<section anchor="implementation-caveats" numbered="true" toc="default">		<section anchor="implementation-caveats" numbered="true" toc="default">
	<name>Implementation Caveats</name>		<name>Implementation Caveats</name>
	<t>Stale data is used only when refreshing has failed in order to adhere		<t>Stale data is used only when refreshing has failed in order to adhere
	to the original intent of the design of the DNS and the behaviour		to the original intent of the design of the DNS and the behaviour
	expected by operators. If stale data were to always be used		expected by operators. If stale data were to always be used
	immediately and then a cache refresh attempted after the client		immediately and then a cache refresh attempted after the client
	response has been sent, the resolver would frequently be sending data		response has been sent, the resolver would frequently be sending data
	skipping to change at line 373 ¶		skipping to change at line 389 ¶
	on Akamai's production network since 2011, and effectively		on Akamai's production network since 2011, and effectively
	smoothed over transient failures and longer outages that would have		smoothed over transient failures and longer outages that would have
	resulted in major incidents. The patch was contributed to Internet		resulted in major incidents. The patch was contributed to Internet
	Systems Consortium and the functionality is now available in BIND 9.12		Systems Consortium and the functionality is now available in BIND 9.12
	and later via the options stale-answer-enable, stale-answer-ttl, and		and later via the options stale-answer-enable, stale-answer-ttl, and
	max-stale-ttl.</t>		max-stale-ttl.</t>
	<t>Unbound has a similar feature for serving stale answers, and will		<t>Unbound has a similar feature for serving stale answers, and will
	respond with stale data immediately if it has recently tried and		respond with stale data immediately if it has recently tried and
	failed to refresh the answer by pre-fetching.</t>		failed to refresh the answer by pre-fetching.</t>
	<t>Knot Resolver has a demo module here:		<t>Knot Resolver has a demo module here:
	https://knot-resolver.readthedocs.io/en/stable/modules.html#serve-stale</t>		<eref
			target="https://knot-resolver.readthedocs.io/en/stable/modules.html#serve-st
			ale" brackets="angle"/></t>
	<t>Apple's system resolvers are also known to use stale answers, but the		<t>Apple's system resolvers are also known to use stale answers, but the
	details are not readily available.</t>		details are not readily available.</t>
	<t>In the research paper "When the Dike Breaks: Dissecting DNS Defenses		<t>In the research paper "When the Dike Breaks: Dissecting DNS Defenses
	During DDoS" <xref target="DikeBreaks" format="default"/>, the authors detected some use of		During DDoS" <xref target="DikeBreaks" format="default"/>, the authors detected some use of
	stale answers by resolvers when authorities came under attack. Their		stale answers by resolvers when authorities came under attack. Their
	research results suggest that more widespread adoption of the technique		research results suggest that more widespread adoption of the technique
	would significantly improve resiliency for the large number of requests		would significantly improve resiliency for the large number of requests
	that fail or experience abnormally long resolution times during an attack.</t>		that fail or experience abnormally long resolution times during an attack.</t>
	</section>		</section>
	<section anchor="edns-option" numbered="true" toc="default">		<section anchor="edns-option" numbered="true" toc="default">
	skipping to change at line 438 ¶		skipping to change at line 455 ¶
	<section anchor="nat-considerations" numbered="true" toc="default">		<section anchor="nat-considerations" numbered="true" toc="default">
	<name>NAT Considerations</name>		<name>NAT Considerations</name>
	<t>The method described here is not affected by the use of NAT devices.</t >		<t>The method described here is not affected by the use of NAT devices.</t >
	</section>		</section>
	<section anchor="iana-considerations" numbered="true" toc="default">		<section anchor="iana-considerations" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>There are no IANA considerations.</t>		<t>There are no IANA considerations.</t>
	</section>		</section>
	<section anchor="acknowledgements" numbered="true" toc="default">		<section anchor="acknowledgements" numbered="true" toc="default">
	<name>Acknowledgements</name>		<name>Acknowledgements</name>
	<t>The authors wish to thank Brian Carpenter, Robert Edmonds, Tony Finch,		<t>The authors wish to thank <contact fullname="Brian Carpenter"/>, <conta
	Bob Harold, Tatuya Jinmei, Matti Klock, Jason Moreau, Giovane Moura,		ct fullname="Robert Edmonds"/>, <contact fullname="Tony Finch"/>,
	Jean Roy, Mukund Sivaraman, Davey Song, Paul Vixie, Ralf Weber and		<contact fullname="Bob Harold"/>, <contact fullname="Tatuya Jinmei"/>, <contact
	Paul Wouters for their review and feedback. Paul Hoffman deserves		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="R
			alf Weber"/> and
			<contact fullname="Paul Wouters"/> for their review and feedback. <contact full
			name="Paul Hoffman"/> deserves
	special thanks for submitting a number of Pull Requests.</t>		special thanks for submitting a number of Pull Requests.</t>
	<t>Thank you also to the following members of the IESG for their final		<t>Thank you also to the following members of the IESG for their final
	review: Roman Danyliw, Benjamin Kaduk, Suresh Krishnan, Mirja		review: <contact fullname="Roman Danyliw"/>, <contact fullname="Benjamin
	Kuehlewind, and Adam Roach.</t>		Kaduk"/>, <contact fullname="Suresh Krishnan"/>, <contact fullname="Mirja
			Kuehlewind"/>, and <contact fullname="Adam Roach"/>.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.
	035" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.10		xml"/>
	35.xml">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2181.
	<front>		xml"/>
	<title>Domain names - implementation and specification</title>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.
	<seriesInfo name="DOI" value="10.17487/RFC1035"/>		xml"/>
	<seriesInfo name="RFC" value="1035"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
	<seriesInfo name="STD" value="13"/>		xml"/>
	<author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
	tris">		xml"/>
	<organization/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2308.
	</author>		xml"/>
	<date year="1987" month="November"/>
	<abstract>
	<t>This RFC is the revised specification of the protocol and forma
	t used in the implementation of the Domain Name System. It obsoletes RFC-883. T
	his memo documents the details of the domain name client - server communication.
	</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC2181" target="https://www.rfc-editor.org/info/rfc2
	181" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21
	81.xml">
	<front>
	<title>Clarifications to the DNS Specification</title>
	<seriesInfo name="DOI" value="10.17487/RFC2181"/>
	<seriesInfo name="RFC" value="2181"/>
	<author initials="R." surname="Elz" fullname="R. Elz">
	<organization/>
	</author>
	<author initials="R." surname="Bush" fullname="R. Bush">
	<organization/>
	</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 remedie
	s for the defects identified. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
	034" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.10
	34.xml">
	<front>
	<title>Domain names - concepts and facilities</title>
	<seriesInfo name="DOI" value="10.17487/RFC1034"/>
	<seriesInfo name="RFC" value="1034"/>
	<seriesInfo name="STD" value="13"/>
	<author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
	tris">
	<organization/>
	</author>
	<date year="1987" month="November"/>
	<abstract>
	<t>This RFC is the revised basic definition of The Domain Name Sys
	tem. It obsoletes RFC-882. This memo describes the domain style names and thei
	r used for host address look up and electronic mail forwarding. It discusses th
	e clients and servers in the domain name system and the protocol used between th
	em.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21
	19.xml">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="BCP" value="14"/>
	<author initials="S." surname="Bradner" fullname="S. Bradner">
	<organization/>
	</author>
	<date year="1997" month="March"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized.
	This document defines these words as they should be interpreted in IETF document
	s. This document specifies an Internet Best Current Practices for the Internet
	Community, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
	74.xml">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="BCP" value="14"/>
	<author initials="B." surname="Leiba" fullname="B. Leiba">
	<organization/>
	</author>
	<date year="2017" month="May"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC2308" target="https://www.rfc-editor.org/info/rfc2
	308" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.23
	08.xml">
	<front>
	<title>Negative Caching of DNS Queries (DNS NCACHE)</title>
	<seriesInfo name="DOI" value="10.17487/RFC2308"/>
	<seriesInfo name="RFC" value="2308"/>
	<author initials="M." surname="Andrews" fullname="M. Andrews">
	<organization/>
	</author>
	<date year="1998" month="March"/>
	<abstract>
	<t>RFC1034 provided a description of how to cache negative respons
	es. 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 th
	e effect of the caching. This document addresses issues raise in the light of e
	xperience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="DikeBreaks" target="https://www.isi.edu/~johnh/PAPERS /Moura18b.pdf">		<reference anchor="DikeBreaks" target="https://www.isi.edu/~johnh/PAPERS /Moura18b.pdf">
	<front>		<front>
	<title>When the Dike Breaks: Dissecting DNS Defenses During DDos</ti tle>		<title>When the Dike Breaks: Dissecting DNS Defenses During DDos</ti tle>
	<seriesInfo name="DOI" value="10.1145/3278532.3278534"/>		<seriesInfo name="DOI" value="10.1145/3278532.3278534"/>
	<seriesInfo name="ACM" value="2018 Internet Measurement Conference"/ >		<seriesInfo name="ACM" value="2018 Internet Measurement Conference"/ >
	<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Mo ura">		<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Mo ura">
	<organization/>		<organization/>
	skipping to change at line 602 ¶		skipping to change at line 535 ¶
	</reference>		</reference>
	<reference anchor="DITL" target="https://www.dns-oarc.net/oarc/data/ditl ">		<reference anchor="DITL" target="https://www.dns-oarc.net/oarc/data/ditl ">
	<front>		<front>
	<title>DITL Traces and Analysis | DNS-OARC</title>		<title>DITL Traces and Analysis | DNS-OARC</title>
	<author>		<author>
	<organization/>		<organization/>
	</author>		</author>
	<date>n.d.</date>		<date>n.d.</date>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.
	499" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84		xml"/>
	99.xml">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6672.
	<front>		xml"/>
	<title>DNS Terminology</title>
	<seriesInfo name="DOI" value="10.17487/RFC8499"/>
	<seriesInfo name="RFC" value="8499"/>
	<seriesInfo name="BCP" value="219"/>
	<author initials="P." surname="Hoffman" fullname="P. Hoffman">
	<organization/>
	</author>
	<author initials="A." surname="Sullivan" fullname="A. Sullivan">
	<organization/>
	</author>
	<author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
	<organization/>
	</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 prot
	ocols, and by operators of DNS systems, has sometimes changed in the decades sin
	ce 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>
	</reference>
	<reference anchor="RFC6672" target="https://www.rfc-editor.org/info/rfc6
	672" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.66
	72.xml">
	<front>
	<title>DNAME Redirection in the DNS</title>
	<seriesInfo name="DOI" value="10.17487/RFC6672"/>
	<seriesInfo name="RFC" value="6672"/>
	<author initials="S." surname="Rose" fullname="S. Rose">
	<organization/>
	</author>
	<author initials="W." surname="Wijngaards" fullname="W. Wijngaards">
	<organization/>
	</author>
	<date year="2012" month="June"/>
	<abstract>
	<t>The DNAME record provides redirection for a subtree of the doma
	in name tree in the DNS. That is, all names that end with a particular suffix a
	re 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 a
	ddresses in DNS (RFC 3363). [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	</references>		</references>
	</references>		</references>
	</back>		</back>
	<!-- ##markdown-source:		<!-- ##markdown-source:
	H4sIAErV7l0AA7V8W3cbR5Lme/6KXPrB0hwAIiXZltQP0xApt9UWRa1It3d3		H4sIAErV7l0AA7V8W3cbR5Lme/6KXPrB0hwAIiXZltQP0xApt9UWRa1It3d3
	ZrdPApUA0ixUYSqrCKF7PL9s3vaPbXwRkVlVJOhxP6zPkUkCWXmJ6xeXrOl0		ZrdPApUA0ixUYSqrCKF7PL9s3vaPbXwRkVlVJOhxP6zPkUkCWXmJ6xeXrOl0
	atrQlv6NvfbNXajW9rp1pbcXrnW2re377a6p7+jvj9f2s4+hDL5aHoxbLBp/		atrQlv6NvfbNXajW9rp1pbcXrnW2re377a6p7+jvj9f2s4+hDL5aHoxbLBp/
	94Y/xoNeHjNFvazclmYrGrdqp8G3q2lRxXo3jRg1jRg1PTs1hWtplH1+evZ6		94Y/xoNeHjNFvazclmYrGrdqp8G3q2lRxXo3jRg1jRg1PTs1hWtplH1+evZ6
	evZ8evramLBr3ti26WL7/PT09elz4xrv3tj3Veubyrdmv+b1rj7Zn+vmFlv9		evZ8evramLBr3ti26WL7/PT09elz4xrv3tj3Veubyrdmv+b1rj7Zn+vmFlv9
	U1N3O3O77wdNL7CuWbr2jY1tYbodFopv7Nnpi5cT/P+biX1+9urMmGVd0Bxv		U1N3O3O77wdNL7CuWbr2jY1tYbodFopv7Nnpi5cT/P+biX1+9urMmGVd0Bxv
End of changes. 27 change blocks.
	222 lines changed or deleted		86 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/