| 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 "Ace" Kumari"> | <author initials="W." surname="Kumari" fullname="Warren "Ace" Kumari"> | |||
| <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 format="default"/> | <t>This document updates the definitions of TTL from <xref format="default"/> | |||
| and <xref format="default"/> so that data can be kept in the cache beyond | and <xref format="default"/> so that data can be kept in the cache beyond | |||
| the TTL expiry, and also updates <xref format="default"/> by interpreting | the TTL expiry, and also updates <xref format="default"/> by interpreting | |||
| 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 <xreftarget="RFC2119" format="default"/> <xreftarget="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 inBCP 14 | ||||
| <xreftarget="RFC2119"/> <xreftarget="RFC8174"/> when, and only | ||||
| when, they appear in all capitals, as shown here.</t> | ||||
| <t>For a glossary of DNS terms, please see <xref format="default"/>.</t> | <t>For a glossary of DNS terms, please see <xref 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><xrefformat="default"/> Section 3.2.1 says that theT | <!-- Is quoted text DNE? --> | |||
| TL "specifies the time | <t><xrefsectionFormat="comma" section="3.2.1"/> | |||
| says that theTTL "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", andSection 4.1.3 further | the information should again be consulted", and<xref 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 format="default"/> predates the more rigorous terminology of | However, <xref format="default"/> predates the more rigorous terminology of | |||
| <xref format="default"/> which softened the interpretation of "may" and "should".</t> | <xref format="default"/> which softened the interpretation of "may" and "should".</t> | |||
| <t><xref format="default"/> aimed to provide "the precise | <!-- Is quoted text DNE? --> | |||
| definition of the Time to | <t><xref format="default"/> aimed to provide "the | |||
| Live", but inSection 8 was mostly concerned with the numeric range of | precise definition of the Time to | |||
| Live", but in<xref 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 format="default"/> key words, but does convey the natural language | <xref 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<xrefformat="default"/> Sect | <t>The definition of TTL inSections <xrefsection=" | |||
| ions 3.2.1 and4.1.3 is | 3.2.1" | |||
| sectionFormat="bare"/> and<xref section="4.1.3" | ||||
| sectionFormat="bare"/> of <xref/> 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 recordMAY be cached before the source of | duration that the resource record<bcp14>MAY</bcp14> be cached before the source | |||
| the informationMUST again be consulted. Zero values areinterpreted | of | |||
| the information<bcp14>MUST</bcp14> again be consulted. Zero values areinterpr | ||||
| 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. ValuesSHOULD be capped on the ordersof | and should not be cached. Values<bcp14>SHOULD</bcp14> be capped on the ordersof | |||
| 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 recordMAY be used as though it is unexpired. See[RFC Editor: | the record<bcp14>MAY</bcp14> be used as though it is unexpired. SeeSections&nb | |||
| replace by RFC number] <xrefformat="default"/> | sp;<xrefformat="counter"/> | |||
| and <xrefformat="default"/> fordetails. | and <xrefformat="counter"/> of | |||
| </dd> | RFC 0000 fordetails.</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 format="default"/>, the rationale | positive, rather than 0, is a change from <xref format="default"/>, the rationale | |||
| for which is explained in <xref format="default"/>. | for which is explained in <xref format="default"/>. | |||
| 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 format="default"/>, reflects the current practice of major modern DNS | <xref format="default"/>, reflects the current practice of major 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 | |||
| resolverMUST set the TTL of each expired record in the messageto a | resolver<bcp14>MUST</bcp14> set the TTL of each expired record in the messaget | |||
| value greater than 0, with aRECOMMENDED value of 30 seconds. See | o a | |||
| value greater than 0, with a<bcp14>RECOMMENDED</bcp14> value of 30 seconds. See | ||||
| <xref format="default"/> for explanation.</t> | <xref 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 setMUST be considered to have refreshed the data at the resolver. | bit set<bcp14>MUST</bcp14> be considered to have refreshed the data at the resolver. | |||
| 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 thereforeleave | <bcp14>SHOULD</bcp14> be considered a failure to refresh the data and thereforeleave | |||
| any previous state intact. See <xref format="default"/> for | any previous state intact. See <xref format="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 <xrefformat="default"/>, Section 7, this should be no | server is reachable; per <xrefsectionFormat="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 format="default"/> that only NoError and NXDomain | <t>The directive in <xref format="default"/> that 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. ImplementersMAY decide to return | giving true authoritative answers. Implementers<bcp14>MAY</bcp14> decide to return | |||
| 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. ImplementersMAY 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 | |||
| 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 format="default"/>, the authors detected some use of | During DDoS" <xref 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 thankBrian 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, andAdam 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"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" 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" 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" 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" 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" 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"> | <reference anchor="DikeBreaks"> | |||
| <front> | <front> | |||
| <title>When the Dike Breaks: Dissecting DNS Defenses During DDos</title> | <title>When the Dike Breaks: Dissecting DNS Defenses During DDos</title> | |||
| <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. Moura"> | <author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura"> | |||
| <organization/> | <organization/> | |||
| skipping to change at line 602 ¶ | skipping to change at line 535 ¶ | |||
| </reference> | </reference> | |||
| <reference anchor="DITL"> | <reference anchor="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"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" 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 fromhttp://tools.ietf.org/tools/rfcdiff/ | ||||