| Internet-Draft | RD Flag Clarification | July 2025 |
| Qiu & Li | Expires 20 January 2026 | [Page] |
This document addresses inconsistencies observed in the handling of the Recursion Desired (RD) flag in DNS queries by various DNS resolver implementations, particularly when the RD flag is cleared (set to 0). Such inconsistencies have been shown to be exploitable, leading to potent Denial of Service (DoS) amplification attacks. This document provides clear guidance and recommendations for DNS resolver (including forwarding and recursive resolvers) behavior when processing queries with different RD flag settings. The goal is to enhance DNS security, mitigate specific amplification attack vectors, and ensure more predictable and robust DNS operations.¶
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 2 January 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 a hierarchical and distributed naming system for computers, services, or other resources connected to the Internet or a private network. DNS queries contain a one-bit field known as the Recursion Desired (RD) flag. As defined in [RFC1034] and [RFC1035], this flag directs the name server receiving the query:¶
If RD is set (1), and the queried name server supports recursive queries, it is directed to pursue the query recursively. That is, the name server should take responsibility for resolving the query and returning the final answer.¶
If RD is cleared (0), and the name server does not support recursive queries, or recursion is not desired for this specific query, the name server should return an answer based on its own data (e.g., from its cache or authoritative zones) without contacting other name servers. If the name server does not have the information locally, it should return a response indicating that, which might include referrals to other name servers.¶
Recent research, such as the "TsuKing" attack [XU2023], has highlighted that a significant number of DNS resolvers, including open resolvers and forwarding devices, do not strictly adhere to the intended semantics of the RD flag, particularly when it is cleared (RD=0). Specific problematic behaviors include:¶
Resolvers performing recursive lookups or forwarding queries upstream even when the incoming query has RD=0.¶
DNS forwarders modifying the RD flag, for example, by changing an incoming RD=0 to RD=1 in the query forwarded upstream.¶
These deviations from standard behavior create vulnerabilities that can be exploited for various purposes, most notably for constructing Denial of Service (DoS) amplification attacks. In such attacks, like the DNSCHAIN and DNSLOOP variants described in [XU2023], attackers leverage these incorrect RD flag handling behaviors to coordinate multiple resolvers into amplifying query traffic towards a victim. The vulnerability of performing recursion when RD=0 was identified as a key factor (termed "V1" in [XU2023]) enabling these attacks. The study also noted that some widely-used DNS software and public DNS services exhibited these behaviors under certain configurations.¶
The purpose of this document is to:¶
Reiterate and clarify the expected behavior of DNS resolvers (including recursive resolvers and DNS forwarders) concerning the RD flag.¶
Provide explicit operational guidance to promote consistent implementation and deployment of RD flag handling.¶
Mitigate the security risks associated with incorrect RD flag processing, thereby reducing the attack surface for certain types of DNS amplification attacks.¶
This document aims to update or clarify existing guidance in [RFC1034] and [RFC1035] by providing more explicit behavioral requirements for resolvers.¶
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 uses the following terms:¶
A program that acts as a client to the DNS system, issuing queries and processing responses. Resolvers can be stub resolvers, recursive resolvers, or forwarders.¶
A resolver that, upon receiving a query for which it does not have an answer, will itself query other name servers to find the answer.¶
A resolver that, upon receiving a query it cannot answer from its cache, forwards the query to a configured upstream recursive resolver.¶
A minimal resolver that relies on an upstream recursive resolver to perform the bulk of the resolution work.¶
A name server that holds the definitive data for a particular zone.¶
A query mode where a name server, if it does not have the answer, returns a referral to other name servers that are more authoritative for the queried name. The querier then issues queries to these referred servers.¶
A query mode where the querier requests the name server to perform the full resolution process and return the final answer.¶
The "Recursion Desired" bit in the DNS query header.¶
The core issue addressed by this document is the inconsistent and often incorrect handling of the RD flag by DNS resolvers, especially when RD=0. This inconsistency deviates from the original intent of the DNS protocol and introduces security vulnerabilities.¶
As highlighted in [XU2023], a notable number of DNS resolvers, including both recursive resolvers and forwarders, exhibit recursive behavior even when presented with a query where the RD flag is cleared (RD=0). Instead of responding solely from local data (cache or authoritative zones), these resolvers proceed to query other name servers or forward the query upstream, effectively ignoring the RD=0 directive. This behavior is problematic because:¶
It violates the expectation of the querying client, which may have cleared the RD flag specifically to prevent recursion (e.g., for diagnostic purposes or to query a local cache).¶
It allows these resolvers to be unwillingly drafted into attack architectures, as demonstrated by the DNSCHAIN and DNSLOOP attacks [XU2023], where chains or loops of resolvers are formed by exploiting this RD=0 recursion.¶
Another problematic behavior observed, particularly in some DNS forwarding devices [XU2023] (e.g., certain configurations of RouterOS), is the modification of the RD flag. Specifically, a forwarder might receive a query with RD=0, but when it forwards this query to its upstream recursive resolver, it sets the RD flag to 1. This action fundamentally changes the nature of the query as perceived by the upstream resolver and contributes to the vulnerabilities described above. It forces recursion where none was requested by the original querier.¶
All DNS resolvers (recursive resolvers, forwarders, and stub resolvers that might implement caching or forwarding logic) MUST inspect the RD flag in incoming queries. The decision to perform recursion, forward a query, or perform iterative queries MUST be influenced by the state of the RD flag in the incoming query and the resolver's configured role and policy.¶
This section describes behavior for queries where the RD flag is set (RD=1).¶
Recursive Resolvers: If a resolver is configured to provide recursive service and receives a query with RD=1, it SHOULD attempt to resolve the query fully. This typically involves performing iterative queries to authoritative name servers as needed, or consulting its cache. If the resolver is not configured to provide recursive service to the querier, or if a local policy prevents recursion for the specific query or querier, it MAY return a response with RCODE=REFUSED.¶
DNS Forwarders: If a DNS forwarder receives a query with RD=1 that it cannot answer from its local cache, it SHOULD forward the query to one of its configured upstream recursive resolvers. The forwarded query MUST also have the RD flag set to 1.¶
Authoritative Servers: An authoritative server receiving a query with RD=1 MAY ignore the RD flag and respond based on its authoritative data for the zone. It is not obligated to perform recursion. If it is not authoritative for the queried name and does not support recursion, it typically returns a referral or an error.¶
This section describes the REQUIRED behavior for queries where the RD flag is cleared (RD=0). This is the critical area for mitigating the vulnerabilities discussed.¶
When a recursive resolver (i.e., a resolver configured and capable of performing recursion, but not acting as a simple forwarder for this specific query) receives a query with RD=0:¶
The resolver MUST attempt to answer the query using only locally available information. Locally available information includes:¶
The resolver MUST NOT forward the query to other recursive resolvers (unless it is acting as a designated forwarder as per Section 4.3.2, and even then, specific rules apply).¶
The resolver MUST NOT perform iterative queries to external authoritative name servers for this query.¶
If the answer is not available from locally available information:¶
If the name is known to not exist (e.g., from a cached NXDOMAIN or a negative cache entry compliant with [RFC2308]), the resolver SHOULD return a response with RCODE=NXDOMAIN.¶
Otherwise, the resolver SHOULD return a response with RCODE=0 (NoError) and an empty answer section.¶
Under certain policy conditions, it MAY return RCODE=REFUSED.¶
The intent is that an RD=0 query to a recursive resolver probes its local knowledge without causing external network activity for resolution.¶
When a DNS forwarder receives a query with RD=0:¶
The forwarder SHOULD first attempt to answer the query from its local cache, if one exists and is consulted. If a satisfactory answer is found in the cache, it SHOULD be returned to the querier.¶
If the query cannot be answered from its local cache:¶
The forwarder MUST NOT forward the query to its configured upstream recursive resolver(s) with the RD flag set to 1. This directly addresses the problematic behavior of some forwarders modifying the RD flag from 0 to 1.¶
Ideally, a forwarder receiving an RD=0 query that misses its cache SHOULD behave like a recursive resolver as described in Section 4.3.1 (i.e., return an answer based purely on its local state, typically an empty NoError response or NXDOMAIN if known, and not forward the query at all). This is the RECOMMENDED behavior.¶
If, due to a specific and explicit local configuration policy (e.g., a transparent proxying setup where the forwarder's role is strictly to pass queries to a specific upstream without local resolution capabilities beyond caching), a forwarder *does* forward a query that it originally received with RD=0, the forwarded query sent to the upstream resolver MUST also have the RD flag set to 0. The forwarder MUST NOT change the RD flag from 0 to 1.¶
The primary goal for forwarders handling RD=0 queries is to prevent them from initiating or propagating recursion that was not requested by the original querier.¶
Authoritative name servers typically answer queries based on their zone data, regardless of the RD flag's setting. An authoritative server receiving a query with RD=0 SHOULD respond with data from its authoritative zones if the queried name falls within them. It MAY ignore the RD=0 flag in the sense that its primary function is to provide authoritative answers, not to perform recursion. If it is not authoritative for the queried name, it should respond as it normally would (e.g., with a referral or an error like NXDOMAIN if the domain exists but the name does not).¶
The recommendations in this document are crucial for mitigating certain DNS-based amplification attacks, such as those described in [XU2023] (DNSCHAIN and DNSLOOP). Strict adherence to the specified handling of RD=0 queries by recursive resolvers and forwarders breaks the chains or loops that these attacks rely on, as resolvers will no longer perform or request recursion when explicitly told not to.¶
Incorrect handling of the RD=0 flag, specifically:¶
Recursive resolvers performing iterative queries or forwarding when RD=0.¶
Forwarders forwarding RD=0 queries as RD=1 queries.¶
can lead to resolvers being unwillingly co-opted into distributed amplification attacks. By following the normative requirements in Section 4.3, implementers and operators can significantly reduce the attack surface of the DNS infrastructure related to these vectors.¶
Failure to implement negative caching ([RFC2308]) appropriately can exacerbate issues when RD=0 queries are mishandled, as resolvers might repeatedly attempt to resolve unresolvable names. While not directly about RD flag handling, robust negative caching is a complementary mechanism for overall DNS health and can indirectly limit the impact of some misbehaviors. The TsuKing paper [XU2023] also identified "no negative caching" (V2) as a contributing factor in the effectiveness of their attacks.¶
Operators of DNS resolvers should ensure their software is compliant with the behaviors described herein and configure their resolvers according to these best practices.¶
This document makes no requests of IANA.¶