DNS Operations (dnsop) X.L. Li Internet-Draft Y.Q. Qiu Intended status: Best Current Practice Nankai University Expires: 8 March 2026 M.M. Zhang Zhongguancun Laboratory 4 September 2025 Best Practices for Handling Deeply Nested Domain Delegations in Recursive Resolvers draft-li-dnsop-deep-delegation-scrutiny-00 Abstract The Domain Name System (DNS) relies on caching to ensure its scalability and performance. However, certain behaviors in the DNS delegation and caching mechanisms can be exploited to circumvent domain name revocation. A recently discovered attack, named PHOENIX DOMAIN T2, allows a malicious domain that has been revoked at its parent zone to remain resolvable for an extended period. This is achieved by creating a chain of deeply nested subdomains, effectively keeping the delegation information alive in recursive resolver caches. This document describes the PHOENIX DOMAIN T2 attack mechanism and proposes a set of operational best practices for DNS recursive resolver operators to mitigate this threat. The primary recommendation is for resolvers to apply additional scrutiny to domain names with an excessive number of labels, which is a key characteristic of this attack. 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 8 March 2026. Li, et al. Expires 8 March 2026 [Page 1] Internet-Draft Handling Deep Delegations September 2025 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 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. Background on Domain Name Revocation . . . . . . . . . . 2 1.2. The PHOENIX DOMAIN T2 Vulnerability and Related Threats . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. The PHOENIX DOMAIN T2 Attack Mechanism . . . . . . . . . . . 4 3. Operational Recommendations . . . . . . . . . . . . . . . . . 5 3.1. Identifying Excessively Deep Domains . . . . . . . . . . 5 3.2. Applying Scrutiny . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Preferential Re-validation . . . . . . . . . . . . . 5 3.2.2. Restricting Maximum Cache TTL . . . . . . . . . . . . 5 3.2.3. Monitoring and Logging . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 1.1. Background on Domain Name Revocation The DNS namespace is structured as a hierarchy, where parent zones delegate authority for sub-zones (children) via NS (Name Server) records [RFC1034] [RFC1035]. Domain name revocation is the process of removing or altering these delegation records in the parent zone to render a domain and its subdomains unresolvable or to redirect them to a sinkhole. This is a critical tool for combating malicious activities such as botnets, phishing, and malware distribution. Li, et al. Expires 8 March 2026 [Page 2] Internet-Draft Handling Deep Delegations September 2025 However, due to the distributed and heavily cached nature of DNS, revocation is not instantaneous. Resolvers will continue to use their cached delegation information until its Time-to-Live (TTL) expires. The "Ghost Domain" attack first demonstrated that a revoked domain's authoritative server could trick resolvers into refreshing the TTL of cached NS records, keeping the domain alive post- revocation [Jiang2012]. While mitigations for this specific attack were widely deployed, the underlying principles of DNS caching still present opportunities for exploitation. 1.2. The PHOENIX DOMAIN T2 Vulnerability and Related Threats A more recent study introduced the PHOENIX DOMAIN T2 attack [Li2023], which bypasses existing defenses. This attack does not violate any DNS protocol specifications but rather exploits a de facto standard behavior in how resolvers search their cache. When a resolver needs to resolve a name for which it has no specific cached data (a cache miss), it searches for the "closest known nameserver" by performing a longest suffix match on the queried name against its cache, a behavior clarified in documents such as [RFC2181]. The T2 attack leverages this behavior by creating a chain of single- label subdomains. An attacker can make a resolver cache a new delegation for a deep subdomain (e.g., "s.s.botnet.com") based on the soon-to-expire cached delegation of its parent ("s.botnet.com"). This process can be repeated, potentially up to the maximum label count of 127, allowing a revoked domain to remain effectively resolvable for months or even years. Because this attack exploits a fundamental aspect of cache searching, it affects virtually all mainstream DNS resolver implementations. The PHOENIX DOMAIN attack is a prime example of vulnerabilities arising from the temporal desynchronization between DNS caching and delegation state. This class of issues is not isolated. A related, widespread problem is that of "dangling domains," where DNS resource records (e.g., CNAME or A records) point to third-party hosting service endpoints that have been deprovisioned but are available for others to claim. As detailed by Zhang et al. [Zhang2023], attackers can take over these dangling domains by registering the same service endpoints, thereby hijacking legitimate traffic for malicious purposes. While the PHOENIX DOMAIN attack exploits the delegation chain, the dangling domain problem exploits the resolution endpoint. Both highlight a critical principle: the security of the DNS ecosystem relies on DNS records accurately reflecting the current, authoritative state of domain control and resources. Li, et al. Expires 8 March 2026 [Page 3] Internet-Draft Handling Deep Delegations September 2025 1.3. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. The PHOENIX DOMAIN T2 Attack Mechanism The attack proceeds in the following steps: 1. Initial State: The attacker controls a domain, e.g., "botnet.com", and its authoritative nameserver. A target recursive resolver is made to query for "botnet.com", thereby caching its NS records with a given TTL (e.g., 24 hours). 2. Revocation: The domain is revoked at the parent registry (e.g., the ".com" TLD). The NS records for "botnet.com" are removed from the ".com" zone. The resolver, however, still holds the original NS records in its cache. 3. Exploitation: Shortly before the 24-hour TTL expires in the resolver's cache, the attacker triggers a query to the resolver for a previously unseen subdomain, e.g., "s.botnet.com". 4. Cache Logic Exploited: The resolver experiences a cache miss for "s.botnet.com". It then performs a longest suffix match and finds the still-valid (though soon-to-expire) NS records for "botnet.com". It sends a query for "s.botnet.com" to the attacker's authoritative nameserver listed in these cached records. 5. Delegation Refresh: The attacker's nameserver responds with a new delegation for "s.botnet.com", pointing to another nameserver (or itself) and providing NS and glue records. This response has a fresh, long TTL (e.g., another 24 hours). The resolver caches this new delegation for "s.botnet.com". 6. Iteration: The attacker can repeat this process. Shortly before the TTL for "s.botnet.com" expires, they can trigger a query for "s.s.botnet.com", and so on. Each step adds a label and refreshes the cache lifetime, effectively keeping subdomains of the revoked "botnet.com" continuously resolvable. Li, et al. Expires 8 March 2026 [Page 4] Internet-Draft Handling Deep Delegations September 2025 3. Operational Recommendations To disrupt the chain of delegation renewals central to the PHOENIX DOMAIN T2 attack, recursive resolver operators SHOULD implement mechanisms to identify and apply additional scrutiny to DNS queries for a domain name with a high number of labels. 3.1. Identifying Excessively Deep Domains Research indicates that the vast majority of legitimate domains used in practice are not deeply nested [Li2023]. A study of DNS responses for Alexa Top 1 Million domains found that over 99% of observed names have 10 or fewer labels. Therefore, it is RECOMMENDED that resolvers use a threshold of 10 labels as a heuristic to identify potentially suspicious domain names that warrant further scrutiny. This threshold MAY be configurable by the operator. 3.2. Applying Scrutiny When a resolver receives a query for a domain name that exceeds the configured label-count threshold, it SHOULD perform one or more of the following actions: 3.2.1. Preferential Re-validation Instead of immediately trusting the delegation information provided by a child zone's nameserver (especially when that information is already in cache), the resolver SHOULD perform a re-validation query to the parent zone. For a query to "label10...label1.example.com", the resolver should explicitly query the nameservers for "example.com" to validate the delegation for "label1.example.com". This action directly confirms whether the delegation is still valid from the parent's perspective, effectively stopping the T2 attack. 3.2.2. Restricting Maximum Cache TTL If re-validation is not performed, resolvers SHOULD enforce a significantly reduced maximum TTL on any resource records received for an excessively deep domain. For example, an operator could configure that any records for a domain with more than 10 labels, regardless of the TTL provided by the authoritative server, will not be cached for more than a short duration (e.g., 1 hour). This would not prevent the attack but would drastically reduce its longevity and increase the cost for the attacker. Li, et al. Expires 8 March 2026 [Page 5] Internet-Draft Handling Deep Delegations September 2025 3.2.3. Monitoring and Logging Queries for domain names with an unusually high number of labels SHOULD be logged with a distinct severity level. This provides network administrators with visibility into potential T2 attack activity within their networks, enabling further investigation or blocking. 4. Security Considerations This entire document is focused on improving the security and resilience of the DNS ecosystem against cache-based attacks that undermine domain name revocation. The recommendations provided herein directly mitigate the PHOENIX DOMAIN T2 attack by disrupting its core mechanism of iterative cache refreshing for deep subdomains. By applying scrutiny based on label count, resolvers can more effectively enforce the intent of domain revocation actions taken at parent zones. A potential risk is the impact on legitimate services that rely on deeply nested domain names. However, as supported by measurement studies [Li2023], such domains are exceptionally rare in common usage. The recommended actions, particularly preferential re- validation, would not break resolution for legitimate deep domains but would simply ensure their delegation is valid. The ability for operators to configure the label threshold provides a mechanism to balance security with any specific local operational needs. It is important to note that the operational recommendations in this document are specifically designed to mitigate the PHOENIX DOMAIN T2 attack vector. However, resolver operators and domain owners must recognize that robust DNS security requires a multi-faceted approach. Other significant threats, such as the hosting-based domain takeovers described in [Zhang2023], depend not on deep delegations but on diligent DNS record management and proper domain ownership validation by hosting providers. While the scrutiny of deep domains improves resolver resilience against delegation-based attacks, it does not replace the fundamental need for domain owners to purge stale DNS records pointing to deprovisioned third-party services. 5. IANA Considerations This document has no IANA actions. 6. References 6.1. Normative References Li, et al. Expires 8 March 2026 [Page 6] Internet-Draft Handling Deep Delegations September 2025 [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, . 6.2. Informative 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, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [Jiang2012] Jiang, J., Liang, J., Li, K., Li, J., Duan, H., and J. Wu, "Ghost Domain Names: Revoked Yet Still Resolvable", in Proceedings of the 19th Annual Network and Distributed System Security Symposium (NDSS '12) , February 2012. [Li2023] Li, X., Liu, B., Bai, X., Zhang, M., Zhang, Q., Li, Z., Duan, H., and Q. Li, "Ghost Domain Reloaded: Vulnerable Links in Domain Name Delegation and Revocation", in Proceedings of the Network and Distributed Systems Security (NDSS) Symposium 2023 , February 2023, . [Zhang2023] Zhang, M., Li, X., Liu, B., Lu, J., Zhang, Y., Chen, J., Duan, H., Hao, S., and X. Zheng, "Detecting and Measuring Security Risks of Hosting-Based Dangling Domains", Proc. ACM Meas. Anal. Comput. Syst. Vol. 7, No. 1, Article 9, March 2023, . Authors' Addresses Xiang Li Nankai University 38 Tongyan Road Li, et al. Expires 8 March 2026 [Page 7] Internet-Draft Handling Deep Delegations September 2025 Tianjin Tianjin, 300355 China Email: lixiang@nankai.edu.cn Yuqi Qiu Nankai University 38 Tongyan Road Tianjin Tianjin, 300355 China Email: norahqiu@163.com Mingming Zhang Zhongguancun Laboratory Beijing Beijing, 100081 China Email: zhangmm@mail.zgclab.edu.cn Li, et al. Expires 8 March 2026 [Page 8]