]> Cloudflare

jabley@cloudflare.com

Fastly

brian@innovationslab.net

Operations and Management Domain Name System Operations dns any The DNS specification from its earliest day supported a special query type (QTYPE) ANY. The handling of queries with QTYPE=ANY is observed to vary between implementations. Queries with QTYPE=ANY are known to facilitate amplification that can be abused and used by malicious actors to attack third parties, and minimally-sized responses are often constructed in order to mitigate those security risks. While queries with QTYPE=ANY can be used for troubleshooting in some cases, the substantial inconsistency in how such queries are handled makes them at best an unreliable signal. This document continues a careful and gradual process of dropping support for QTYPE=ANY from the DNS. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction and define a special query type (QTYPE) called "*" (type 255) which is commonly described in DNS implementations using the keyword "ANY". The keyword "ANY" is also mentioned in . QTYPE 255 is described in section 3.7.1 as "matches all RR types". Despite the superficial simplicity of this direction, there are significant corner cases for which the specification is ambiguous, especially where a query's QNAME corresponds to a delegation (a case which the DNS Security Extensions make more complicated, with authoritative data now published both above and below the zone cut). recognises that server operators have reasons to provide minimal responses to queries with QTYPE=ANY ("ANY queries"), and provides a number of allowable strategies that can be used. Mechanisms described in have been broadly implemented with no known negative consequences for end users. A consequence of that experience is that it is now even harder to predict the type of response any particular server night provide to an ANY query, and consequently even more difficult to interpret the response. This document continues the careful and gradual process of dropping support for ANY queries from the DNS.

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. This document assumes familiarity with DNS-specific terminology as described in . This document uses the phrase "ANY query" to mean a query with QTYPE=ANY and QCLASS=IN.

Common Use, Risks and Benefits of ANY Queries It is known that some useful and constructive uses of ANY queries exist, despite their limitations. For example, ANY queries are sometimes used to troubleshoot DNS problems, together with other techniques and tools. It is also possible that software exists that sends ANY queries and expects a particular type of response, e.g. a response with a particular RCODE, and that an abrupt behave in server behaviour might have negative consequences. Such scenarios do not seem outlandish, and being able to adapt to such situations when they come to light unexpectedly while remaining consistent with Internet standards is important. More critically, an ANY query has the ability to generate a response that is significantly larger than the query itself, making it an attractive tool for Distributed Denial-of-Service (DDoS) amplification attacks. Such usage has led to significant concerns over the need for ANY queries. ANY queries are not the only available way to achieve amplification using the DNS, but are cheaper than some alternatives since it can be easier to find large responses using ANY than it is to discover specific (QNAME, QTYPE) tuples that achieve the same effect. Even when not used for attacks, processing ANY queries imposes an unnecessary performance burden on authoritative servers. Gathering all records for a name is a complex operation in some DNS implementations that can consume more CPU and memory than a query for a specific type. The resulting large responses can also lead to UDP fragmentation and costly fallbacks to TCP, increasing query latency. ANY queries were a nice idea. However, the idea turns out to have been under-specified. There is a great deal of variation in their implementation and it is difficult to imagine new protocols incorporating ANY queries since their treatment by servers is extremely inconsistent. This document recognises as a first step on a path towards deprecation of ANY queries, and provides a second step in the same direction. The journey will continue.

Updated Guidance on the Use of ANY Queries

Do not send ANY queries without good reason New protocols developed at the IETF SHOULD NOT incorporate ANY queries unless the operational consequences of ambiguous behaviour and inconsistent implementation are thoroughly understood and documented. DNS clients SHOULD NOT send ANY queries without a thorough understanding of their limitations. DNS clients SHOULD NOT rely upon any particular interpretation of a response to an ANY query unless the specific behaviour of the system sending the response is known and predictable. DNS clients MUST NOT assume that this is the situation when sending queries to arbitrary destinations on the Internet. DNS clients MAY send ANY queries for the purposes of troubleshooting or gathering diagnostic information.

Do not respond to ANY queries without good reason DNS servers SHOULD respond to ANY queries with RCODE = 4 (NOTIMPL) unless they have a specific local reason to respond differently. In such circumstances, DNS servers MAY respond following their interpretation of and or with a minimal response as described in . DNS servers that do not support ANY queries MAY include an Extended DNS Error (EDE) in the response of type TBA in order to explain further the nature of the response, e.g. as an aid to troubleshooting. Details of the registration of EDE type TBA can be found in .

Security Considerations ANY queries are known to have been used to provide amplification of source-spoofed DNS queries using UDP transport, as described in . However, there are many other QTYPEs that provide amplification potential when coupled with predictable QNAMEs, and a reduction in support for ANY queries will not eliminate this problem. ANY queries can be expensive to process on some authoritative DNS servers, and hence a volumetric attack against such a server with QTYPE=ANY has the potential to consume more resources than an attack that uses other QTYPEs. By dropping support for ANY queries, a server operator might well reduce the impact of attack traffic. ANY queries can be used to inspect the cache of a recursive server, and this might provide insight into query patterns for users of that recursive server; this ability might present privacy concerns that could be mitigated by dropping support for ANY queries.

IANA Considerations

Update References for RRTYPE 255 The IANA is directed to update the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry entry for type 255 to append this document to the list of references, and to update the TYPE column to reflect the direction in .

TYPE	Value	Meaning	Reference
* (ANY)	255	A request for some or all records the server has available	[this document]

Registration of Extended DNS Error Code The IANA is directed to assign an INFO-CODE code-point from the "Extended DNS Error Codes" subregistry of the "Domain Name Systems (DNS) Paramters" registry and to record the assignment in the registry as follows:

INFO-CODE	Purpose	Reference
TBA	ANY queries are not supported on this nameserver	[this document]

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons. The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance. This document updates RFCs 1034 and 1035. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This 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. Informative References This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

Acknowledgments Your name here, etc.