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/