DNS Operations (dnsop) Y.Q. Qiu Internet-Draft X.L. Li Intended status: Standards Track Nankai University Expires: 20 January 2026 July 2025 Clarifying DNS Resolver Behavior for the Recursion Desired (RD) Flag draft-qiu-dnsop-rd-flag-clarification-00 Abstract 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. Status of This Memo 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 Notice 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 Qiu & Li Expires 20 January 2026 [Page 1] Internet-Draft RD Flag Clarification July 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. The Recursion Desired (RD) Flag . . . . . . . . . . . . . 2 1.2. Observed Vulnerabilities . . . . . . . . . . . . . . . . 3 1.3. Purpose of this Document . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Problem Description: Inconsistent RD Flag Handling . . . . . 5 3.1. Recursive Behavior for RD=0 Queries . . . . . . . . . . . 5 3.2. RD Flag Modification by Forwarders . . . . . . . . . . . 5 4. Recommended Behavior for RD Flag Processing . . . . . . . . . 5 4.1. General Principles . . . . . . . . . . . . . . . . . . . 5 4.2. Queries with RD=1 (Recursion Desired) . . . . . . . . . . 6 4.3. Queries with RD=0 (Recursion Not Desired) . . . . . . . . 6 4.3.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 6 4.3.2. DNS Forwarders . . . . . . . . . . . . . . . . . . . 7 4.3.3. Authoritative Servers . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 1.1. The Recursion Desired (RD) Flag 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 Qiu & Li Expires 20 January 2026 [Page 2] Internet-Draft RD Flag Clarification July 2025 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. 1.2. Observed Vulnerabilities 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. 1.3. Purpose of this Document 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. Qiu & Li Expires 20 January 2026 [Page 3] Internet-Draft RD Flag Clarification July 2025 2. Conventions and Definitions 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: DNS Resolver: 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. Recursive Resolver: 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. DNS Forwarder: A resolver that, upon receiving a query it cannot answer from its cache, forwards the query to a configured upstream recursive resolver. Stub Resolver: A minimal resolver that relies on an upstream recursive resolver to perform the bulk of the resolution work. Authoritative Server: A name server that holds the definitive data for a particular zone. Iterative Query: 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. Recursive Query: A query mode where the querier requests the name server to perform the full resolution process and return the final answer. RD Flag: The "Recursion Desired" bit in the DNS query header. Qiu & Li Expires 20 January 2026 [Page 4] Internet-Draft RD Flag Clarification July 2025 3. Problem Description: Inconsistent RD Flag Handling 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. 3.1. Recursive Behavior for RD=0 Queries 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. 3.2. RD Flag Modification by Forwarders 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. 4. Recommended Behavior for RD Flag Processing 4.1. General Principles 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. Qiu & Li Expires 20 January 2026 [Page 5] Internet-Draft RD Flag Clarification July 2025 4.2. Queries with RD=1 (Recursion Desired) 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. 4.3. Queries with RD=0 (Recursion Not Desired) 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. 4.3.1. Recursive Resolvers 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: 1. The resolver MUST attempt to answer the query using only locally available information. Locally available information includes: * Its cache. * Local zone data if the resolver is also authoritative for the queried name or has been configured with local zone data. Qiu & Li Expires 20 January 2026 [Page 6] Internet-Draft RD Flag Clarification July 2025 2. 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). 3. The resolver MUST NOT perform iterative queries to external authoritative name servers for this query. 4. 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. 4.3.2. DNS Forwarders When a DNS forwarder receives a query with RD=0: 1. 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. 2. 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. Qiu & Li Expires 20 January 2026 [Page 7] Internet-Draft RD Flag Clarification July 2025 * 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. 4.3.3. Authoritative Servers 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). 5. Security Considerations 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. Qiu & Li Expires 20 January 2026 [Page 8] Internet-Draft RD Flag Clarification July 2025 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. 6. IANA Considerations This document makes no requests of IANA. 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . Qiu & Li Expires 20 January 2026 [Page 9] Internet-Draft RD Flag Clarification July 2025 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [AFEK2020] Afek, Y., Bremler-Barr, A., and L. Shafir, "NXNSAttack: Recursive DNS Inefficiencies and Vulnerabilities", In Proceedings of USENIX Security 2020, August 2020, . [MOURA2021] Moura, G. C. M., Castro, S., Heidemann, J. S., and W. Hardaker, "TsuNAME: Exploiting Misconfiguration and Vulnerability to DDoS DNS", In Proceedings of the ACM Internet Measurement Conference (IMC '21) , November 2021, . [ROSSOW2014] Rossow, C., "Amplification Hell: Revisiting Network Protocols for DDoS Abuse", In Proceedings of the Network and Distributed System Security Symposium (NDSS '14) , February 2014, . Qiu & Li Expires 20 January 2026 [Page 10] Internet-Draft RD Flag Clarification July 2025 [XU2023] Xu, W., Li, X., Lu, C., Liu, B., Duan, H., Zhang, J., Chen, J., and T. Wan, "TsuKing: Coordinating DNS Resolvers and Queries into Potent DoS Amplifiers", In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS '23) , November 2023, . [ZHENG2020] Zheng, X., Lu, C., Peng, J., Yang, Q., Zhou, D., Liu, B., Man, K., Hao, S., Duan, H., and Z. Qian, "Poison Over Troubled Forwarders: A Cache Poisoning Attack Targeting DNS Forwarding Devices", In Proceedings of USENIX Security 2020, August 2020, . Authors' Addresses Yuqi Qiu Nankai University 38 Tongyan Road Tianjin Tianjin, 300355 China Email: norahqiu@163.com Xiang Li Nankai University 38 Tongyan Road Tianjin Tianjin, 300355 China Email: lixiang@nankai.edu.cn Qiu & Li Expires 20 January 2026 [Page 11]