| Internet-Draft | Continuing to Reduce Support for ANY Que | August 2026 |
| Abley & Haberman | Expires 7 February 2027 | [Page] |
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.¶
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 (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.¶
[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.¶
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.¶
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 [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.¶
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.¶
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.¶
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.¶
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 |
|---|---|---|---|
| * (ANY) | 255 | A request for some or all records the server has available | [RFC1034][RFC6895][RFC8482][this document] |
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] |
Your name here, etc.¶