Domain Name System Operations J. Abley Internet-Draft Cloudflare Updates: RFC 1034, RFC 1035, RFC 8482 (if B. Haberman approved) Fastly Intended status: Standards Track 6 August 2026 Expires: 7 February 2027 Continuing to Reduce Support for ANY Queries in the DNS draft-jabley-dnsop-no-longer-support-any-00 Abstract 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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://ableyjoe.github.io/draft-jabley-dnsop-no-longer-support-any/ draft-jabley-dnsop-no-longer-support-any.html. Status information for this document may be found at https://datatracker.ietf.org/doc/ draft-jabley-dnsop-no-longer-support-any/. Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (mailto:dnsop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Subscribe at https://www.ietf.org/mailman/listinfo/dnsop/. Source for this draft and an issue tracker can be found at https://github.com/ableyjoe/draft-jabley-dnsop-no-longer-support-any. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Abley & Haberman Expires 7 February 2027 [Page 1] Internet-Draft Continuing to Reduce Support for ANY Que August 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 February 2027. Copyright Notice Copyright (c) 2026 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 (https://trustee.ietf.org/ license-info) 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Common Use, Risks and Benefits of ANY Queries . . . . . . . . 3 4. Updated Guidance on the Use of ANY Queries . . . . . . . . . 4 4.1. Do not send ANY queries without good reason . . . . . . . 4 4.2. Do not respond to ANY queries without good reason . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6.1. Update References for RRTYPE 255 . . . . . . . . . . . . 6 6.2. Registration of Extended DNS Error Code . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Abley & Haberman Expires 7 February 2027 [Page 2] Internet-Draft Continuing to Reduce Support for ANY Que August 2026 1. Introduction [RFC1034] and [RFC1035] 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 [RFC6895]. QTYPE 255 is described in [RFC1034] 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 [RFC9364] make more complicated, with authoritative data now published both above and below the zone cut). [RFC8482] 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 [RFC8482] 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document assumes familiarity with DNS-specific terminology as described in [RFC9499]. This document uses the phrase "ANY query" to mean a query with QTYPE=ANY and QCLASS=IN. 3. 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. Abley & Haberman Expires 7 February 2027 [Page 3] Internet-Draft Continuing to Reduce Support for ANY Que August 2026 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 [RFC8482] 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. 4. Updated Guidance on the Use of ANY Queries 4.1. 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. Abley & Haberman Expires 7 February 2027 [Page 4] Internet-Draft Continuing to Reduce Support for ANY Que August 2026 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. 4.2. 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 [RFC1034] and [RFC1035] or with a minimal response as described in [RFC8482]. DNS servers that do not support ANY queries MAY include an Extended DNS Error (EDE) [RFC8914] 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 Section 6.2. 5. Security Considerations ANY queries are known to have been used to provide amplification of source-spoofed DNS queries using UDP transport, as described in [RFC5358]. 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. 6. IANA Considerations Abley & Haberman Expires 7 February 2027 [Page 5] Internet-Draft Continuing to Reduce Support for ANY Que August 2026 6.1. 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 [RFC6895]. +=======+=======+===============+==================================+ | TYPE | Value | Meaning | Reference | +=======+=======+===============+==================================+ | * | 255 | A request for | [RFC1034][RFC6895][RFC8482][this | | (ANY) | | some or all | document] | | | | records the | | | | | server has | | | | | available | | +-------+-------+---------------+----------------------------------+ Table 1 6.2. 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 | [this | | | supported on this nameserver | document] | +-----------+------------------------------+-----------+ Table 2 7. References 7.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . Abley & Haberman Expires 7 February 2027 [Page 6] Internet-Draft Continuing to Reduce Support for ANY Que August 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 2019, . [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . 7.2. Informative References [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, . [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, . Acknowledgments Your name here, etc. Authors' Addresses Joe Abley Cloudflare Email: jabley@cloudflare.com Abley & Haberman Expires 7 February 2027 [Page 7] Internet-Draft Continuing to Reduce Support for ANY Que August 2026 Brian Haberman Fastly Email: brian@innovationslab.net Abley & Haberman Expires 7 February 2027 [Page 8]