How Phoenix Domain Attacks Keep Revoked Domains Alive in DNS Caches

TLDR: The Phoenix Domain Attack exploits implementation flaws in recursive DNS resolvers to keep revoked or expired domains resolvable long after they should have been purged. By manipulating the cache update and search operations, attackers can maintain persistence on domains that security teams believe they have successfully taken down. This research highlights a critical design gap in how DNS software handles delegation and revocation, forcing a re-evaluation of how we trust DNS cache integrity.

Domain name revocation is supposed to be the final nail in the coffin for malicious infrastructure. When a registrar or registry pulls the plug on a domain used for C2 or phishing, the expectation is that the domain will stop resolving globally as the cache entries expire. Research presented at Black Hat 2023 proves that this assumption is dangerously flawed. The Phoenix Domain Attack demonstrates that an attacker can effectively "resurrect" a domain that has been removed from the TLD zone file, keeping it alive in the caches of recursive resolvers indefinitely.

The Mechanics of the Phoenix Attack

At its core, the Phoenix Domain Attack exploits the way recursive resolvers handle cache updates and the "closest name server" logic. When a resolver receives a query for a domain, it traverses the DNS hierarchy. If the domain has been revoked, the TLD name servers will no longer provide a delegation for it. However, if an attacker can force the resolver to perform a cache update or search operation at the exact moment the domain is being removed, they can inject a new, malicious name server record.

The attack relies on two primary variations, T1 and T2, which target different aspects of the resolver's cache management. In the T1 variation, the attacker exploits the cache insertion implementation. By timing the injection of a new name server record to coincide with the expiration of the old one, the attacker ensures the resolver accepts the malicious record as the new source of truth. Because many resolvers do not strictly validate the delegation chain during these updates, the malicious record persists.

The T2 variation is more insidious. It exploits the cache searching operation by injecting name server records for subdomains. Since recursive resolvers often cache these records to optimize future lookups, the attacker can build a chain of trust that keeps the parent domain resolvable even after the original delegation has been stripped. This effectively turns the resolver into a long-term host for the attacker's infrastructure.

Technical Vulnerabilities in Common Resolvers

The research tested eight major DNS software implementations, including BIND 9, Knot DNS, Unbound, MaraDNS, Technitium, and PowerDNS. All eight were found to be vulnerable to at least one variation of the attack. The sheer number of associated vulnerabilities, such as CVE-2022-30250 and CVE-2022-30699, underscores the systemic nature of the problem.

The issue stems from a lack of deterministic definitions in the DNS RFCs regarding how resolvers should handle these edge cases. When the specification is ambiguous, developers make their own choices, leading to inconsistent behavior across the ecosystem. For a pentester, this means that the success of an infrastructure takedown is entirely dependent on the specific DNS software used by the target's ISP or corporate network.

Real-World Impact for Security Researchers

For those of us conducting red team engagements or tracking threat actor infrastructure, this research changes the game. If you are testing a client's ability to respond to a domain-based threat, you can no longer assume that a domain takedown is instantaneous or permanent. During an engagement, you might find that your C2 domain remains reachable from specific internal networks long after you have "revoked" it.

This is not just a theoretical concern. The researchers tested 41 public DNS resolvers, including those operated by Google Public DNS, Cloudflare, Quad9, and AdGuard. All of them were susceptible to Phoenix-style attacks. If you are relying on these services to block malicious domains, you are potentially exposed to persistent threats that have already been "neutralized" by the registry.

Defensive Strategies and Mitigation

Defending against this requires moving away from the "set and forget" mentality of domain management. The researchers suggest several mitigations, most notably the implementation of Delegation Revalidation by DNS Resolvers, which is currently in the draft stage. This approach forces the resolver to re-verify the delegation chain rather than blindly trusting cached records.

For infrastructure operators, the most immediate defense is to reduce TTL values for critical records. While this increases the load on your authoritative name servers, it significantly shrinks the window of opportunity for an attacker to maintain a "ghost" record in a recursive cache. Furthermore, if you are running your own recursive resolvers, ensure they are patched against the specific CVEs identified in this research.

The DNS protocol is showing its age. Forty years of patches and extensions have created a complex, often contradictory set of behaviors that attackers are increasingly adept at weaponizing. We need to stop treating DNS as a static utility and start treating it as a dynamic, high-risk component of our attack surface. If you are building security tools or managing enterprise networks, start auditing your resolver configurations today. The persistence of revoked domains is a silent threat that will continue to undermine our best efforts at infrastructure defense until we address these fundamental design flaws.