| Internet-Draft | QNAME Minimization Trade-offs | December 2025 |
| Li, et al. | Expires 26 June 2026 | [Page] |
This document examines the current protocol policies and operational state of QNAME Minimization (QMIN), defined in RFC 9156 [RFC9156]. While QMIN is a DNS privacy mechanism, its existing implementation strategies introduce subtle trade-offs between privacy and security. Specifically, current policies may still present potential information leakage or introduce query amplification potential. This informational document aims to alert protocol designers, implementers, and users to these emerging challenges and suggests that a careful re-evaluation and improvement of the QMIN mechanism are necessary to fully mitigate these combined privacy and security risks.¶
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 26 June 2026.¶
Copyright (c) 2025 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.¶
The Domain Name System (DNS) is foundational to the modern internet. However, its inherent design, which involves recursive resolution and delegation chains, presents challenges related to both privacy and operational efficiency. In the traditional DNS resolution process, recursive resolvers typically send the Original QNAME (the query name identical to the initial client request) across the entire delegation chain [RFC1034][RFC1035]. This practice results in the unnecessary exposure of sensitive subdomain information to intermediate, higher-level nameservers that do not require the full name to perform their delegation task [RFC6973][RFC7626][RFC9076].¶
To address this critical privacy concern, the QNAME Minimization (QMIN) mechanism was introduced and standardized in RFC 9156 [RFC9156]. QMIN is a technique where a recursive resolver minimizes the DNS query name sent to an authoritative nameserver. Instead of sending the full name, the resolver only sends the minimum set of labels necessary to receive a referral to the next nameserver in the delegation chain[RFC7816].¶
For example, to resolve www.example.com., a QMIN-enabled resolver first asks the root server only for com., then asks the .com server only for example.com., and so on.¶
However, while QMIN successfully mitigates privacy leakage, its implementation has inadvertently introduced new security and performance complexities, primarily related to query amplification. The inherent structure of DNS, where resolution is hierarchical and delegated, means that resolvers must traverse the entire delegation chain, generating a minimum number of requests equal to the chain's length [firstlook][secondlook]. As detailed in the following sections, this baseline query volume is further inflated by factors such as the need to resolve NS records (glue records) and domain redirections (CNAME/DNAME RRs). The adoption of QMIN, due to its label-by-label request nature and the potential to apply minimization to passively introduced Referral QNAMEs (domain names encountered during resolution), can significantly exacerbate this traffic inflation. This characteristic makes QMIN a potential amplifier in various types of DNS resolver amplification attacks.¶
The key terms used in this document are defined as follows:¶
Delegation point: The specific label that leads to a delegation to another nameserver.¶
Original QNAME: The QNAME identical to the initial client query.¶
Referral QNAME: Other QNAMEs introduced during the resolution process.¶
Privacy leakage: Any QNAME labels sent to the current server but not necessary for its task—and are instead destined for servers further down the chain.¶
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.¶
The DNS resolution scope is hierarchical and delegated. Consequently, each authoritative nameserver can only resolve queries for the specific Zone of Authority it directly manages, along with any subdomains within that zone that have not been further delegated [RFC1034][RFC1035].¶
To resolve any given domain name, regardless of the method used, recursive resolvers must traverse the entire delegation chain, querying each nameserver in the chain until the nameserver holding the final Resource Records (RRs) is reached, at which point the final resolution is performed. Therefore, the minimum number of requests generated on the authority side by a single user query is equal to the length of the nameserver delegation chain. As a result, the number of requests observed on the authority side generally exceeds the number of user-initiated queries.¶
Beyond potential network or server anomalies, or domain errors, the primary reasons for this inflation include:¶
Delegation Chain Length: A single user query generates a minimum of requests equal to the length of the delegation chain, resulting in higher authority-side traffic for longer chains.¶
NS Record Resolution: Resolvers may not be able to obtain the IP addresses of the delegated child nameservers directly from the parent nameserver's referral response (e.g., due to the lack of glue records in the Additional section), necessitating separate queries to resolve those NS hostnames.¶
Domain Redirection: Resolvers may encounter redirection records, such as CNAME or DNAME RRs, during resolution, which redirects the query to a new domain name, thereby increasing the total number of required queries.¶
The adoption of QNAME Minimization (QMIN), as defined in RFC 9156 [RFC9156], can further amplify the traffic on the authority side because:¶
Label-by-Label Request: Under QMIN, resolvers may repeatedly query the same authoritative server label-by-label. If the number of labels in the QNAME exceeds the length of the nameserver delegation chain, the sequential label-by-label querying inherent to QMIN will result in a higher query count compared to non-QMIN resolution.¶
Undefined Scope for Referral QNAMEs: RFC 9156 [RFC9156] does not explicitly specify the domain scope for QMIN execution. By default, resolvers may apply QMIN to both the Original QNAME from the user request and any Referral QNAMEs passively introduced in responses, further increasing query traffic.¶
Exploitation via Referral Responses: An attacker can exploit QMIN by intentionally returning referral responses that omit glue records in every QMIN request, thus increasing the number of Referral QNAMEs the resolver must process. This can be further escalated by increasing the depth of referral resolution, significantly expanding the authority-side request volume.¶
Consequently, due to its inherent query amplification characteristics, QMIN can be leveraged as an amplifier in various types of DNS resolver amplification attacks.¶
While RFC 9156 [RFC9156] imposes necessary constraints on the functionality and deployment of QNAME Minimization (QMIN), significant variations in protocol implementation approaches persist among recursive resolvers. These implementation differences result in notable variances in the amplification risk profile presented by different QMIN strategies.¶
In summary, three main implementation strategies are currently observed.¶
Resolvers deploying Complete QMIN apply the minimization technique to both the Original QNAME from the client request and all Referral QNAMEs generated throughout the resolution process. Consequently, Complete QMIN presents the greatest amplification potential and is subject to the largest traffic pressure when facing amplification attacks.¶
Under this QMIN implementation strategy, resolvers still apply minimization to the Original QNAME and all Referral QNAMEs, but QMIN querying is strictly used only for labels that are resolved by Root or Top-Level Domain (TLD) nameservers. For subsequent domain prefixes, the No QMIN (full QNAME) policy is used.¶
The Root & TLD Only strategy mitigates amplification risk by:¶
Limiting the scope of QMIN execution to the top levels, thereby avoiding repeated, label-by-label requests to the same authoritative server.¶
Restricting the total number of QMIN queries, which limits the volume of malicious Referral QNAMEs that an attacker can construct during an amplification attack.¶
Therefore, the Root & TLD Only strategy achieves an effectiveness in mitigating amplification attacks that is comparable to the No-QMIN policy.¶
In this implementation, resolvers only perform QNAME minimization on the original domain name requested by the user, while adopting the No-QMIN policy for querying all Referral QNAMEs generated during the recursive resolution. However, the "Original QNAME Only" strategy is not effective in reducing the issue of repeatedly querying the same name server with the original QNAME. While it effectively lowers the amplification factor, it still carries a certain risk of amplification.¶
This document considers the security challenges introduced by the deployment of the QNAME Minimization (QMIN) mechanism.¶
QMIN's design goal is to enhance privacy by reducing the exposure of sensitive subdomain information to upstream nameservers. However, as discussed in Section 3, certain QMIN implementation strategies (specifically Complete QMIN) can significantly increase query traffic on authoritative nameservers due to their label-by-label querying nature and the handling of Referral QNAMEs.¶
This amplification of query traffic makes QMIN a potential amplifier in DNS resolver amplification attacks. A malicious attacker can exploit this characteristic by manipulating referral responses (e.g., omitting glue records) to force resolvers to send a large volume of queries to a target authoritative server, thus posing a Denial of Service (DoS) or Distributed Denial of Service (DDoS) threat.¶
The guidelines in this document aim to direct protocol designers and implementers to balance the privacy benefits of QMIN against the amplification risks it may exacerbate, recommending strategies that restrict the scope of QMIN, such as the Root & TLD Only approach, to mitigate security risks.¶
This document has no IANA actions.¶