Negative Caching of DNS Resolution FailuresVerisign12061 Bluemont WayRestonVA20190United States of America+1 703 948-3200dwessels@verisign.comhttps://verisign.comVerisign12061 Bluemont WayRestonVA20190United States of America+1 703 948-3200wicarroll@verisign.comhttps://verisign.comVerisign12061 Bluemont WayRestonVA20190United States of America+1 703 948-3200mthomas@verisign.comhttps://verisign.com
ops
dnsopDNSNegativeCachingIn the DNS, resolvers employ caching to reduce both latency for end
users and load on authoritative name servers. The process of resolution
may result in one of three types of responses: (1) a response containing
the requested data, (2) a response indicating the requested data does
not exist, or (3) a non-response due to a resolution failure in which
the resolver does not receive any useful information regarding the
data's existence. This document concerns itself only with the third
type.RFC 2308 specifies requirements for DNS negative caching. There,
caching of TYPE 2 responses is mandatory and caching of TYPE 3
responses is optional. This document updates RFC 2308 to require
negative caching for DNS resolution failures.RFC 4035 allows DNSSEC validation failure caching. This document
updates RFC 4035 to require caching for DNSSEC validation failures.RFC 4697 prohibits aggressive requerying for NS records at a failed
zone's parent zone. This document updates RFC 4697 to expand this
requirement to all query types and to all ancestor zones.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Motivation
. Related Work
. Terminology
. Conditions That Lead to DNS Resolution Failures
. SERVFAIL Responses
. REFUSED Responses
. Timeouts and Unreachable Servers
. Delegation Loops
. Alias Loops
. DNSSEC Validation Failures
. FORMERR Responses
. Requirements for Caching DNS Resolution Failures
. Retries and Timeouts
. Caching
. Requerying Delegation Information
. DNSSEC Validation Failures
. IANA Considerations
. Security Considerations
. Privacy Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
IntroductionCaching has always been a fundamental component of DNS resolution on
the Internet. For example, states:
The sheer size of the database and frequency of updates suggest
that it must be maintained in a distributed manner, with local
caching to improve performance.
The early DNS RFCs (, , , and ) primarily discuss caching in the context of what
calls "positive responses", that is, when the
response includes the requested data. In this case, a TTL is associated
with each Resource Record (RR) in the response. Resolvers can cache and
reuse the data until the TTL expires.
describes negative
response caching, but notes it is optional and only talks
about name errors (NXDOMAIN). This is the origin of using
the SOA MINIMUM field as a negative caching TTL.
updated to specify
new requirements for DNS negative caching, including making it
mandatory for caching resolvers to cache name error (NXDOMAIN) and no
data (NODATA) responses when an SOA record is available to provide a
TTL. further specified optional negative
caching for two DNS resolution failure cases: server failure and dead/unreachable servers.
This document updates to require negative
caching of all DNS resolution failures and provides additional
examples of resolution failures, to require caching for DNSSEC validation failures,
as well as to expand the scope of prohibiting
aggressive requerying for NS records at a failed zone's parent zone to
all query types and to all ancestor zones.
Motivation
Operators of DNS services have known for some time that
recursive resolvers become more aggressive when they
experience resolution failures. A number of different
anecdotes, experiments, and incidents support this
claim.
In December 2009, a secondary server for a number of
in-addr.arpa subdomains saw its traffic suddenly double, and
queries of type DNSKEY in particular increase by approximately
two orders of magnitude, coinciding with a DNSSEC key rollover
by the zone operator .
This predated a signed root zone, and an operating system
vendor was providing non-root trust anchors to the recursive
resolver, which became out of date following the rollover.
Unable to validate responses for the affected in-addr.arpa
zones, recursive resolvers aggressively retried their queries.
In 2016, the Internet infrastructure company Dyn experienced
a large attack that impacted many high-profile customers.
As documented in a technical presentation detailing the attack (see ), Dyn staff wrote:
At this point we are now experiencing botnet attack
traffic and what is best classified as a "retry storm"Looking at certain large recursive platforms > 10x normal
volume
In 2018, the root zone Key Signing Key (KSK) was rolled over
. Throughout the rollover
period, the root servers experienced a significant increase in
DNSKEY queries. Before the rollover, a.root-servers.net and
j.root-servers.net together received about 15 million DNSKEY
queries per day. At the end of the revocation period, they
received 1.2 billion per day: an 80x increase. Removal of
the revoked key from the zone caused DNSKEY queries to drop
to post-rollover but pre-revoke levels, indicating there is
still a population of recursive resolvers using the previous
root trust anchor and aggressively retrying DNSKEY queries.
In 2021, Verisign researchers used botnet query traffic to
demonstrate that certain large public recursive DNS services exhibit
very high query rates when all authoritative name servers for a zone
return refused (REFUSED) or server failure (SERVFAIL) responses (see
). When the authoritative servers were
configured normally, query rates for a single botnet domain averaged
approximately 50 queries per second. However, with the servers
configured to return SERVFAIL, the query rate increased to 60,000
per second. Furthermore, increases were also observed at the root
and Top-Level Domain (TLD) levels, even though delegations at those
levels were unchanged and continued operating normally.
Later that same year, on October 4, Facebook experienced a
widespread and well-publicized outage . During the 6-hour outage, none of Facebook's
authoritative name servers were reachable and did not respond to
queries. Recursive name servers attempting to resolve Facebook
domains experienced timeouts. During this time, query traffic on the
.COM/.NET infrastructure increased from 7,000 to 900,000 queries per
second .
Related Work describes negative caching for four types
of DNS queries and responses: name errors, no data, server failures,
and dead/unreachable servers. It places the strongest
requirements on negative caching for name errors and no data
responses, while server failures and dead servers are left as
optional.
is a Best Current Practice that
documents observed resolution misbehaviors. It describes a
number of situations that can lead to excessive queries from
recursive resolvers, including requerying for delegation data,
lame servers, responses blocked by firewalls, and records
with zero TTL. makes a number of
recommendations, varying from "SHOULD" to "MUST".
describes "The
DNS thundering herd problem" as a situation arising when cached data
expires at the same time for a large number of users. Although that
document is not focused on negative caching, it does describe the
benefits of combining multiple identical queries to upstream name
servers. That is, when a recursive resolver receives multiple queries
for the same name, class, and type that cannot be answered from cached
data, it should combine or join them into a single upstream query
rather than emit repeated identical upstream queries.
, "",
includes a section that describes the phenomenon known as "Birthday
Attacks". Here, again, the problem arises when a recursive resolver
emits multiple identical upstream queries. Multiple outstanding
queries make it easier for an attacker to guess and correctly match
some of the DNS message parameters, such as the port number and ID
field. This situation is further exacerbated in the case of
timeout-based resolution failures. Of course, DNSSEC is a suitable
defense to spoofing attacks.
describes "". This permits a recursive resolver to return
possibly stale data when it is unable to refresh cached, expired
data. It introduces the idea of a failure recheck timer and
says:
Attempts to refresh from non-responsive or
otherwise failing authoritative nameservers are recommended
to be done no more frequently than every 30 seconds.
Terminology The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
DNS transport:
In this document, "DNS transport" means a protocol used to
transport DNS messages between a client and a server. This includes
"classic DNS" transports, i.e., DNS-over-UDP and DNS-over-TCP , as well as newer
encrypted DNS transports, such as DNS-over-TLS , DNS-over-HTTPS ,
DNS-over-QUIC , and similar communication of
DNS messages using other protocols. Note: at the time of writing,
not all DNS transports are standardized for all types
of servers but may become standardized in the future.
Conditions That Lead to DNS Resolution Failures
A DNS resolution failure occurs when none of the servers available
to a resolver client provide any useful response data for a
particular query name, type, and class. A response is considered
useful when it provides either the requested data, a referral to a descendant zone,
or an indication that no data exists at the given name.
It is common for resolvers to have multiple servers from
which to choose for a particular query. For example,
in the case of stub-to-recursive, the stub resolver may be
configured with multiple recursive resolver addresses. In the case of
recursive-to-authoritative, a given zone usually has more than
one name server (NS record), each of which can have multiple
IP addresses and multiple DNS transports.
Nothing in this document prevents a resolver from retrying a
query at a different server or the same server over a different
DNS transport. In the case of timeouts, a resolver can retry the
same server and DNS transport a limited number of times.
If any one of the available servers provides a useful response, then
it is not considered a resolution failure. However, if
none of the servers for a given query tuple <name, type, class>
provide a useful response, the result is a resolution failure.
Note that NXDOMAIN and NOERROR/NODATA responses are not conditions
for resolution failure. In these cases, the server is providing
a useful response, indicating either that a name does not exist
or that no data of the requested type exists at the name.
These negative responses can be cached as described in .
The remainder of this section describes a number of different
conditions that can lead to resolution failure. This section is not
exhaustive. Additional conditions
may be expected to cause similar resolution failures.
SERVFAIL Responses
Server failure is defined in as:
"The name server was unable to process this query due to a
problem with the name server." A server failure is signaled
by setting the RCODE field to SERVFAIL.
Authoritative servers return SERVFAIL when they don't have any valid
data for a zone. For example, a secondary server has been
configured to serve a particular zone but is unable to retrieve or
refresh the zone data from the primary server.
Recursive servers return SERVFAIL in response to a
number of different conditions, including many described below.
Although the extended DNS errors method exists "primarily to extend
SERVFAIL to provide additional information," it "does not change the
processing of RCODEs" . This document
operates at the level of resolution failure and does not concern
particular causes.
REFUSED Responses
A name server returns a message with the RCODE field set to REFUSED when it refuses to
process the query, e.g., for policy or other reasons .
Authoritative servers generally return REFUSED when processing
a query for which they are not authoritative. For example,
a server that is configured to be authoritative for only the
example.net zone may return REFUSED in response to a query
for example.com.
Recursive servers generally return REFUSED for query
sources that do not match configured access control lists.
For example, a server that is configured to allow queries from
only 2001:db8:1::/48 may return REFUSED in response to a query
from 2001:db8:5::1.
Timeouts and Unreachable Servers
A timeout occurs when a resolver fails to receive any response from
a server within a reasonable amount of time. Additionally, a DNS
transport may more quickly indicate lack of reachability in a way
that wouldn't be considered a timeout: for example, an ICMP port
unreachable message, a TCP "connection refused" error, or a TLS
handshake failure. refers to these
conditions collectively as "dead / unreachable servers".
Note that resolver implementations may have two types of
timeouts: a smaller timeout that might trigger a query retry
and a larger timeout after which the server is considered
unresponsive. discusses
the requirements for resolvers when retrying queries.
Timeouts can present a particular problem for negative
caching, depending on how the resolver handles multiple
outstanding queries for the same <query name, type,
class> tuple. For example, consider a very popular
website in a zone whose name servers are all unresponsive.
A recursive resolver might receive tens or hundreds of queries
per second for that website. If the recursive server
implementation joins these outstanding queries together,
then it only sends one recursive-to-authoritative query for
the numerous pending stub-to-recursive queries. However, if
the implementation does not join outstanding queries together,
then it sends one recursive-to-authoritative query for each
stub-to-recursive query. If the incoming query rate is high
and the timeout is large, this might result in hundreds or
thousands of recursive-to-authoritative queries while waiting
for an authoritative server to time out.
A recursive resolver that does not join outstanding queries together
is more susceptible to Birthday Attacks (), especially when those queries
result in timeouts.
Delegation Loops
A delegation loop, or cycle, can occur when one domain utilizes
name servers in a second domain, and the second domain uses
name servers in the first. For example:
FOO.EXAMPLE. NS NS1.EXAMPLE.COM.
FOO.EXAMPLE. NS NS2.EXAMPLE.COM.
EXAMPLE.COM. NS NS1.FOO.EXAMPLE.
EXAMPLE.COM. NS NS2.FOO.EXAMPLE.
In this example, no names under foo.example or example.com can be
resolved because of the delegation loop. Note that a delegation loop
may involve more than two domains. A resolver that does not
detect delegation loops may generate DDoS-levels of attack traffic
to authoritative name servers, as documented in the TsuNAME vulnerability
.
Alias Loops
An alias loop, or cycle, can occur when one CNAME or DNAME RR refers to
a second name, which, in turn, is specified as an alias for the first.
For example:
APP.FOO.EXAMPLE. CNAME APP.EXAMPLE.NET.
APP.EXAMPLE.NET. CNAME APP.FOO.EXAMPLE.
The need to detect CNAME loops has been known since at least , which states in Section :
Of course, by the robustness principle, domain software should
not fail when presented with CNAME chains or loops; CNAME chains
should be followed and CNAME loops signalled as an error.
DNSSEC Validation Failures
For zones that are signed with DNSSEC, a resolution failure can
occur when a security-aware resolver believes it should be able
to establish a chain of trust for an RRset but is unable to do
so, possibly after trying multiple authoritative name servers.
DNSSEC validation failures may be due to signature mismatch,
missing DNSKEY RRs, problems with denial-of-existence records,
clock skew,
or other reasons.
already discusses
the requirements and reasons for caching validation failures.
of this document strengthens those requirements.
FORMERR Responses
A name server returns a message with the RCODE field set to
FORMERR when it is unable to interpret the query . FORMERR
responses are often associated with problems processing Extension Mechanisms for DNS (EDNS(0)) . Authoritative servers
may return FORMERR when they do not implement EDNS(0), or
when EDNS(0) option fields are malformed, but not for unknown
EDNS(0) options.
Upon receipt of a FORMERR response, some recursive clients will
retry their queries without EDNS(0), while others will not. Nonetheless, resolution failures
from FORMERR responses are rare.
Requirements for Caching DNS Resolution FailuresRetries and Timeouts
A resolver MUST NOT retry a given query to a server address over a given DNS transport more than twice
(i.e., three queries in total) before considering the server address
unresponsive over that DNS transport for that query.
A resolver MAY retry a given query over a different DNS transport to the same server
if it has reason to believe the DNS transport is available for that server and is
compatible with the resolver's security policies.
This document does not place any requirements on how long an implementation should
wait before retrying a query (aka a timeout value),
which may be implementation or configuration dependent.
It is generally expected that typical timeout values range
from 3 to 30 seconds.
Caching
Resolvers MUST implement a cache for resolution failures.
The purpose of this cache is to eliminate repeated upstream
queries that cannot be resolved.
When an incoming query matches a cached resolution failure, the resolver MUST NOT send
any corresponding outgoing queries until after the cache entries expire.
Implementation details for such a cache are not specified
in this document. The implementation might cache different
resolution failure conditions differently. For example, DNSSEC
validation failures might be cached according to the queried
name, class, and type, whereas unresponsive servers might be
cached only according to the server's IP address.
Developers should document their implementation choices so
that operators know what behaviors to expect when resolution
failures are cached.
Resolvers MUST cache resolution failures for at least
1 second. Resolvers MAY cache different types of
resolution failures for different (i.e., longer) amounts of time.
Consistent with , resolution failures
MUST NOT be cached for longer than 5 minutes.
The minimum cache duration SHOULD be configurable by
the operator. A longer cache duration for resolution failures will
reduce the processing burden from repeated queries but may also
increase the time to recover from transitory issues.
Resolvers SHOULD employ an exponential or linear
backoff algorithm to increase the cache duration for persistent
resolution failures. For example, the initial time for negatively
caching a resolution failure might be set to 5 seconds and
increased after each retry that results in another resolution
failure, up to a configurable maximum, not to exceed the 5-minute
upper limit.
Notwithstanding the above, resolvers SHOULD implement
measures to mitigate resource exhaustion attacks on the failed
resolution cache. That is, the resolver should limit the amount of
memory and/or processing time devoted to this cache.
Requerying Delegation Information identifies
circumstances in which:
...every name server in a zone's NS RRSet is unreachable
(e.g., during a network outage), unavailable (e.g., the name server
process is not running on the server host), or misconfigured (e.g.,
the name server is not authoritative for the given zone, also known as
"lame").
It prohibits unnecessary "aggressive requerying" to the
parent of a non-responsive zone by sending NS queries.
The problem of aggressive requerying to parent zones is not limited
to queries of type NS. This document updates the requirement from
to apply
more generally:
Upon encountering a zone whose name servers are all
non-responsive, a resolver MUST cache the resolution
failure. Furthermore, the resolver MUST limit
queries to the non-responsive zone's parent zone (and to other
ancestor zones) just as it would limit subsequent queries to the
non-responsive zone.
DNSSEC Validation Failures states:
To prevent such unnecessary DNS traffic, security-aware
resolvers MAY cache data with invalid signatures, with some
restrictions.
This document updates with the following, stronger, requirement:
To prevent such unnecessary DNS traffic, security-aware
resolvers MUST cache DNSSEC validation failures, with some
restrictions.
One of the restrictions mentioned in
is to use a small TTL when caching data that fails DNSSEC
validation. This is, in part, because the provided TTL cannot
be trusted. The advice from
herein can be used as guidance on TTLs for caching DNSSEC
validation failures.
IANA Considerations
This document has no IANA actions.
Security Considerations
As noted in , an attacker might attempt a resource
exhaustion attack by sending queries for a large number
of names and/or types that result in resolution failure. Resolvers
SHOULD implement measures to protect themselves and bound the
amount of memory devoted to caching resolution failures.
A cache poisoning attack (see ) resulting in denial of service may be possible
because failure messages cannot be signed. An attacker might generate
queries and send forged failure messages, causing the resolver to
cease sending queries to the authoritative name server (see for a similar
"data corruption attack" and Section 5.2 of
for a "DNSDoS attack"). However, this would require continued
spoofing throughout the backoff period and repeated attacks due to the
5-minute cache limit. As in , this attack's effects would be "localized and of
limited duration".
Privacy ConsiderationsThis specification has no impact on user privacy.ReferencesNormative ReferencesDomain names - concepts and facilitiesThis RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.Domain names - implementation and specificationThis RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Negative Caching of DNS Queries (DNS NCACHE)RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]Protocol Modifications for the DNS Security ExtensionsThis document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]Observed DNS Resolution MisbehaviorThis memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesBotnet Traffic Observed at Various Levels of the DNS HierarchyRoll Over and Die?More details about the October 4 outageRoll, Roll, Roll Your Root: A Comprehensive Analysis of the First Ever DNSSEC Root KSK RolloverIMC '19: Proceedings of the Internet Measurement Conference, Pages 1-14Observations on Resolver Behavior During DNS OutagesVerisignDyn, DDoS, and DNSDomain names: Concepts and facilitiesThis RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities.Domain names: Implementation specificationThis RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. This memo provides information for the Internet community.Internet Denial-of-Service ConsiderationsInternet Architecture BoardThis document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. This memo provides information for the Internet community.Measures for Making DNS More Resilient against Forged AnswersThe current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder.Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK]Extension Mechanisms for DNS (EDNS(0))The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.DNS Transport over TCP - Implementation RequirementsThis document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.Specification for DNS over Transport Layer Security (TLS)This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.Domain Name System (DNS) CookiesDNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)DNS Queries over HTTPS (DoH)This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.Serving Stale Data to Improve DNS ResiliencyThis document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days.Extended DNS ErrorsThis document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.DNS over Dedicated QUIC ConnectionsThis document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.The DNS thundering herd problemAkira Systems Private LimitedInfobloxThis document describes an observed regular pattern of spikes in queries that affects caching resolvers, and recommends software mitigations for it.Work in ProgressTsuNAME: exploiting misconfiguration and vulnerability to DDoS DNSIMC '21: Proceedings of the 21st ACM Internet
Measurement Conference, Pages 398-418TuDoor Attack: Systematically Exploring and Exploiting Logic Vulnerabilities in DNS Response Pre-processing with Malformed PacketsIEEE Symposium on Security and Privacy (SP)Acknowledgments
The authors wish to thank ,
, , , , , , , , and other members of the DNSOP Working Group for their
feedback and contributions.
Authors' AddressesVerisign12061 Bluemont WayRestonVA20190United States of America+1 703 948-3200dwessels@verisign.comhttps://verisign.comVerisign12061 Bluemont WayRestonVA20190United States of America+1 703 948-3200wicarroll@verisign.comhttps://verisign.comVerisign12061 Bluemont WayRestonVA20190United States of America+1 703 948-3200mthomas@verisign.comhttps://verisign.com