Minimizing ANY-Query Responses at Recursive Resolvers

Introduction The Domain Name System (DNS) specifies a query type known as the "ANY "query (QTYPE=255). In operational deployments, the handling of ANY queries may raise both operational and security considerations. defines a mechanism for authoritative servers to provide minimized responses to ANY queries; however, recursive resolvers may generate ANY responses directly from cached resource record sets (RRsets), thereby bypassing the minimization performed by authoritative servers. As a result, authoritative-side minimization alone does not fully mitigate the security risks posed by ANY queries. This document supplements existing mechanisms by providing guidance on response-minimization strategies for recursive resolvers when processing ANY queries.

Terminology This document uses terminology specific to the Domain Name System (DNS), descriptions of which can be found in . This document uses the term "ANY query" for DNS meta-queries that specify QTYPE=ANY, and uses "ANY response" for the DNS responses produced in that context.

Requirements Language 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.

Motivation ANY queries raise various operational and security considerations in practical deployments. This section first outlines these issues and then identifies why reliance solely upon the authoritative-side minimization mechanism defined in is insufficient to fully mitigate these risks.

Operational and Security Issues Associated with ANY Queries ANY queries may cause a server to return multiple records beyond what the client actually requested, thereby increasing the risk of information disclosure. This naturally leads operators toward minimizing such responses. Responses to ANY queries are often large in size and can be abused in DNS-based amplification attacks. An attacker can spoof the source IP address and send ANY queries to resolvers, causing large responses to be reflected to a victim, thereby amplifying the attack (see ). Processing an ANY query requires the DNS server to aggregate multiple resource records to generate a response, and these responses are typically large, which can introduce additional operational burden. ANY responses are frequently large enough to cause IP datagram fragmentation. Fragmentation during transmission or handling can introduce additional security risks, including packet loss and blocking. Different DNS servers may adopt inconsistent methods for processing ANY queries or generating response content, resulting in unpredictable behavior. This unpredictability may lead to operational challenges and could potentially be exploited to create security risks.

Limitations of Authoritative-Side Minimization Although defines a mechanism for authoritative servers to minimize responses to ANY queries, recursive resolvers may generate ANY responses directly from cached RRsets (e.g., A, AAAA, TXT records) without retrieving minimized results from authoritative servers. As a result, the ANY responses returned by recursive resolvers to clients can still be large, potentially leading to information disclosure, amplification attacks, and other operational and security issues. Therefore, relying solely on authoritative-side minimization is insufficient to fully mitigate these risks. This document provides complementary guidance for recursive resolvers on minimizing responses to ANY queries in order to reduce the potential impact.

Handling of ANY Queries by Recursive Resolvers

Overview To mitigate the operational and security risks associated with ANY queries, this section first defines the core defensive principle for recursive resolvers: a resolver SHOULD rely on the authoritative server's minimized response as the basis for answering ANY queries and SHOULD avoid constructing an ANY response that exceeds the size of the authoritative response by synthesizing data from its local cache. In addition, recognizing that some authoritative servers have not yet deployed response minimization for ANY queries, a recursive resolver MAY implement supplementary mitigation measures in accordance with its local policy and operational requirements.

Core Defense Mechanism A recursive resolver can maintain a dedicated cache for ANY queries to avoid combining multiple cached RRsets into an excessively large ANY response, which helps reduce potential security risks. In this case, if the authoritative server has deployed an ANY-query minimization mechanism, the recursive resolver SHOULD return the minimized response from the authoritative server directly to the client, rather than relying on locally cached RRsets to synthesize a larger ANY response. In addition, since some authoritative servers may refuse or not support ANY queries, a resolver may consider applying negative caching for such responses.

Additional Mitigations RRset Minimization and Response Byte Limits: A resolver MAY respond using a single RRset or a subset of available RRsets. However, certain RRsets (e.g., large TXT or RRSIG records) can have considerable size, and implementers SHOULD consider placing an upper bound on the total response size, such as limiting UDP responses to 512 bytes, to mitigate security risks. Rate Limiting for ANY queries: A recursive resolver may apply a rate-limiting mechanism for QTYPE=ANY queries to reduce the risk associated with potential abuse. Since ANY queries may generate large response sizes, applying moderate rate limits can help mitigate potential risks. The specific rate-limiting policy is left to the implementer to determine based on local deployment considerations.

Implementation Experience NSD implements a subset-mode response to ANY queries. Unbound supports a "deny-any" mode, in which ANY queries are rejected. BIND9 implements a single RRset response to ANY queries.

Security Considerations defines response-minimization mechanisms for authoritative servers, but these mechanisms do not constrain how recursive resolvers may synthesize large ANY responses from their caches. Such synthesized responses can still be exploited for reflection or amplification attacks. This document provides complementary guidance for recursive resolvers to reduce the associated attack surface while preserving the availability of legitimate queries.