| Internet-Draft | Handling Deep Delegations | September 2025 |
| Li, et al. | Expires 8 March 2026 | [Page] |
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.¶
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.¶
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 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.¶
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.¶
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.¶
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 attack proceeds in the following steps:¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶