Your Shield is My Sword: A Persistent Denial-of-Service Attack via the Reuse of Unvalidated Caches in DNSSEC Validation

Your Shield is My Sword: A Persistent Denial-of-Service Attack via the Reuse of Unvalidated Caches in DNSSEC Validation

Speakers: Shuhan Zhang, PhD student, Tsinghua University

Conference: USENIX Security

YouTube: https://www.youtube.com/watch?v=oB2nQb1cz7k

Overview

In an era where digital security is paramount, the Domain Name System Security Extensions (DNSSEC) stands as a critical bulwark against DNS cache poisoning, a prevalent attack vector that can redirect users to malicious sites or disrupt legitimate services. However, a groundbreaking research paper presented at USENIX Security 2025, titled "Your Shield is My Sword: A Persistent Denial-of-Service Attack via the Reuse of Unvalidated Caches in DNSSEC Validation," reveals a severe vulnerability that turns this protective mechanism into a weapon for persistent denial of service. Authored by Shuhan Zhang, a PhD student at Tsinghua University, and collaborators from Tsinghua University and Dunwanun Laboratory, this work exposes how a fundamental design flaw in DNSSEC troubleshooting—specifically, the mishandling of unvalidated cache data—can lead to widespread and prolonged service outages.

The attack, dubbed RU (Resolver's Reuse of Unvalidated Caches), leverages the CD bit (Checking Disabled) in DNS queries, intended for troubleshooting, to inject forged, unvalidated DNS records into recursive resolvers' caches. Subsequently, when legitimate clients request DNSSEC-validated responses, the resolver reuses these poisoned, unvalidated records, leading to continuous validation failures and effectively denying domain resolution. This ingenious exploitation of a seemingly benign troubleshooting feature has far-reaching implications, capable of persistently breaking the resolution of any domain under a DNSSEC-signed zone, including major top-level domains like .com, .net, and .org. The research not only identifies the vulnerability but also quantifies its extensive impact across mainstream DNS software, public DNS services, and open resolvers globally, underscoring an urgent need for revised specifications and defensive strategies.

Background

▶ Watch: Introduction: RU attack turns DNSSEC into a sword (0:00)

The Domain Name System (DNS) is the internet's foundational directory, translating human-readable domain names into machine-readable IP addresses. Despite its critical role, the original DNS protocol was not designed with robust security in mind, leaving it vulnerable to various attacks, most notably cache poisoning. In a cache poisoning attack, an adversary injects forged DNS data into a recursive resolver's cache, leading legitimate users to incorrect or malicious destinations, or simply disrupting access to services.

To counter these vulnerabilities, the Domain Name System Security Extensions (DNSSEC) were introduced. DNSSEC enhances DNS by adding cryptographic signatures to DNS records, creating a chain of trust from the root zone down to individual domain names. DNSSEC-validating resolvers use public keys to verify the authenticity and integrity of received DNS responses, ensuring that clients receive legitimate, untampered data. The adoption of DNSSEC has been significant, with over 90% of top-level domains currently deployed, and major public DNS services like Google Public DNS and Cloudflare 1.1.1.1 enabling DNSSEC validation by default. Client operating systems, including Windows and macOS, also increasingly default to authenticated answers.

However, the inherent complexity of DNSSEC deployment and management has led to frequent service outages due to misconfigurations along the chain of trust. To assist with troubleshooting these complex issues, DNS resolvers implement a mechanism where clients can set the Checking Disabled (CD) bit in their DNS query header. When the CD bit is set, resolvers are instructed not to perform DNSSEC validation on the received data, returning raw, unvalidated records. This allows administrators to inspect DNS responses directly, bypassing validation failures that might obscure the root cause of a misconfiguration.

The critical flaw identified by Zhang and colleagues lies in the ambiguous specifications regarding the handling of this unvalidated troubleshooting data. Many resolvers, lacking clear guidance, mix and reuse these unvalidated records with data intended for routine, validated operations. This creates a dangerous attack surface where an adversary can exploit the troubleshooting mechanism to inject forged data into a resolver's cache without any validation enforcement. This unvalidated data then contaminates the resolver's cache, leading to persistent DNSSEC validation failures for legitimate queries and ultimately, a denial of service. The RU attack capitalizes on this oversight, turning DNSSEC's intended security "shield" into a "sword" against domain resolution availability.

Key Findings

▶ Watch: Vulnerability: Resolvers reuse unvalidated troubleshooting data (2:40)

The RU attack fundamentally exploits the unvalidated caches that result from the CD bit mechanism in DNSSEC troubleshooting. The core finding is that many DNSSEC-validating resolvers fail to properly segregate or restrict the reuse of data obtained through queries where validation was explicitly disabled. This oversight transforms a diagnostic feature into a powerful vector for denial-of-service.

The attack operates in two distinct phases:

1. Injection Phase: An attacker issues troubleshooting queries (with the CD bit set) to a target recursive resolver. These queries are crafted to inject forged or manipulated DNS records into the resolver's cache. Crucially, because the CD bit is set, the resolver performs no validation on this incoming data, accepting it at face value.
2. Reuse Phase: When an ordinary client subsequently queries the same resolver for a domain that requires DNSSEC validation, the resolver attempts to resolve it. However, it recycles the unvalidated, forged data from its cache, which inevitably leads to DNSSEC validation failures. Even if the resolver could obtain legitimate records from authoritative name servers, the presence and reuse of the poisoned cache entries prevent successful validation, causing a persistent denial of service.

A key aspect of RU's potency is its persistence. The attack targets records that are indirectly involved in resolution, such as DNSKEY or DS records, which are less frequently hit by routine queries. This characteristic prevents the resolver from easily removing the malicious entries, even when retrying queries. Furthermore, due to unrestricted Time-to-Live (TTL) values for these unvalidated caches, a single successful injection can cause a resolution outage lasting for the entire TTL specified by the attacker, potentially extending for days.

The research conducted a comprehensive vulnerability evaluation, revealing the widespread impact of RU:

• Mainstream DNSSEC Validating Software: Five widely used DNSSEC validating software packages were found vulnerable. Notably, BIND, the most prevalent DNS software, does not restrict the TTL for unvalidated cache entries, allowing injected data to persist for up to seven days.
• Public DNS Services: Out of 29 famous public DNS services evaluated, 28 were vulnerable to at least one RU variant. This includes prominent services like Cloudflare 1.1.1.1, Quad9, and OpenDNS. A more severe finding was that 22 of these services could experience denial of service for more than five minutes due to RU.
• Open Resolvers in the Wild: The study identified that over 60% of open resolvers compliant with DNSSEC were vulnerable. Alarmingly, hundreds of thousands of these resolvers could suffer denial of service for over 24 hours.

These findings highlight a critical security oversight in the implementation of DNSSEC troubleshooting mechanisms, demonstrating that a feature designed for operational resilience can be weaponized to compromise the very availability it seeks to protect.

Technical Deep Dive

▶ Watch: How RU attack works: Injection and reuse phases (3:50)

The RU attack is characterized by its ability to persistently disrupt DNSSEC validation by injecting and reusing unvalidated data. The attack leverages specific conditions that, when broken, lead to validation failure. An attacker can achieve this by:

1. Forging records along the DNSSEC chain of trust: This involves manipulating DNSKEY or DS records, removing or altering their cryptographic signatures (RRSIG records).
2. Forging name server information: Directing the resolver to an incorrect or malicious name server IP address.
3. Tricking the resolver about EDNS0 capability: Making the resolver believe that a target name server is not EDNS0-capable, which is crucial for carrying DNSSEC-related options in DNS messages.

Based on these conditions, the research identifies three primary RU attack variants:

1. RU-DSAC

This variant targets the DNSSEC chain of trust. The attacker injects unvalidated DNSKEY or DS records where their corresponding RRSIG records are either missing or maliciously manipulated. When the resolver later attempts to validate a domain under the affected zone, it retrieves these forged records from its cache, leading to immediate DNSSEC validation failure. This variant impacts the owner zone of the forged records and all its subdomains.

2. RU-NSIP

In this variant, the attacker injects forged name server IP addresses for the victim zone. When the resolver subsequently needs to query the authoritative name server for resolution, it reuses the incorrect IP address from its cache. This leads the resolver to attempt communication with a non-existent or incorrect server, preventing it from obtaining any valid DNSSEC records necessary for successful resolution. This attack affects all DNSSEC-signed zones delegated to the compromised name server.

3. RU-EDNS0

This is a particularly insidious variant. The attacker removes the EDNS0 OPT record from a DNS response related to a name server host. The EDNS0 (Extension Mechanisms for DNS version 0) OPT record is vital for indicating the DNSSEC capabilities of a resolver or name server, enabling the transport of larger DNS messages and DNSSEC-specific data. By tricking the resolver into caching that a specific name server host is not EDNS0-capable, the resolver will then cease fetching DNSSEC-related records from that host, effectively breaking DNSSEC validation for all zones delegated to it.

Attack Vectors: On-path and Off-path

The research demonstrates that RU attacks can be launched by both on-path and off-path adversaries:

• On-path Attacks: These require the attacker to be able to intercept or manipulate DNS traffic directly, typically through name server takeover or BGP route hijacking. Even partial or transient on-path control is sufficient. Once the cache injection succeeds, the denial of service becomes persistent due to the resolver's continuous reuse of the injected data, even if the attacker's direct presence on the path is temporary.

• Off-path Attacks: These are more challenging but highly impactful, as they do not require direct control over the network path. Off-path attackers rely on techniques to inject data into the resolver's cache without being on the direct communication path. The primary method involves fragmentation of large DNS responses, which can be exploited after predicting the target resolver's IP ID.
• Off-path RU-EDNS0 Example:

1. IP ID Prediction: The attacker first predicts the resolver's IP ID.
2. Fragment Crafting: The attacker crafts a second IP fragment of a DNS response, originating from the target name server host, deliberately omitting the EDNS0 OPT record.
3. MTU Reduction (Optional): To ensure fragmentation, the attacker can optionally reduce the Maximum Transmission Unit (MTU) of the name server via an ICMP "fragmentation needed" message.
4. Triggering Large NXDOMAIN Response: The attacker then queries the resolver for a long, non-existent domain name under any zone hosted by the target name server. This query is designed to elicit a large NXDOMAIN response, which typically includes the long queried name and potentially large NSEC or NSEC3 records (used in DNSSEC for authenticated denial of existence). This large response is likely to trigger IP fragmentation.
5. Fragment Reassembly and Cache Poisoning: The resolver receives the legitimate first fragment of the large response and, due to IP ID prediction, matches it with the attacker's forged second fragment. Upon reassembly, the resolver believes the name server host is not EDNS0-capable and caches this incorrect information.
6. Subsequent DNSKEY Injection: With the EDNS0 capability compromised, the attacker can then query the resolver with the CD bit set to one, targeting DNSKEY records. The name server will automatically return DNSKEY records without their corresponding RRSIGs (as EDNS0 is perceived as unavailable, affecting DNSSEC capabilities), allowing the unvalidated DNSKEYs to be successfully injected into the resolver's cache.

This intricate sequence demonstrates how an off-path attacker can leverage sophisticated network manipulation and DNS protocol specifics to achieve persistent denial of service, highlighting the critical need for robust validation and segregation of all cached DNS data.

Demo / Proof of Concept

▶ Watch: Launching RU: Off-path and on-path attack methods (6:40)

While the presentation did not feature a live, interactive demonstration of the attack in action, the speaker outlined the mechanisms of the three RU attack variants (RU-DSAC, RU-NSIP, and RU-EDNS0) as practical proofs of concept for the attack's feasibility. These descriptions serve to illustrate how the attack works in practice and how an attacker could leverage the described vulnerabilities.

For instance, in the RU-DSAC variant, the "demonstration" involves showing how an attacker would craft a DNS query with the CD bit set to inject a DNSKEY or DS record with a missing or manipulated RRSIG. This conceptual demonstration highlights that a validating resolver, when instructed to disable checking, will accept such a record and cache it. When later a standard query for a subdomain is made, the resolver attempts to validate using the poisoned DNSKEY/DS, leading to failure.

Similarly, the RU-NSIP variant's "demonstration" explains the process of injecting a forged IP address for a name server. The practical implication is that any subsequent query relying on that name server will be misdirected, effectively demonstrating a resolution outage.

The most complex, RU-EDNS0, is "demonstrated" by detailing the off-path fragmentation attack sequence. This involves predicting IP IDs, crafting specific IP fragments to omit the EDNS0 OPT record, and then triggering a large NXDOMAIN response to force reassembly with the malicious fragment. The outcome, the resolver caching the name server as non-EDNS0 capable, directly proves the mechanism by which DNSSEC validation is subsequently disabled for that host.

These detailed descriptions of the attack mechanics, rather than a live exploit, serve as the proof of concept for the research. They meticulously explain the steps an attacker would take, the types of records manipulated, and the resulting impact on DNSSEC validation, thereby demonstrating the practical viability and widespread applicability of the RU attack across diverse DNS environments.

Defensive Implications

▶ Watch: Attack persistence: Even short-term injection causes lasting DoS (8:00)

The widespread vulnerability to the RU attack necessitates immediate and comprehensive defensive measures from DNS resolver operators, software vendors, and standardization bodies. The research offers several key suggestions to mitigate the threat:

1. Restrict Caching TTL for Unvalidated Data: The most critical recommendation is to impose strict limits on the Time-to-Live (TTL) for any data received when the CD bit is set. Unvalidated troubleshooting data should have a very short, fixed TTL, ideally on the order of seconds or minutes, rather than relying on the TTL specified by the attacker, which can lead to outages lasting days (e.g., 7 days in BIND). This ensures that any inadvertently or maliciously injected unvalidated data quickly expires from the cache.
2. Restrict Reuse Scope for Unvalidated Data: Resolvers should implement clear segregation policies for unvalidated data. Data obtained with the CD bit set should be explicitly marked as "troubleshooting data" and never be reused in routine DNSSEC validation operations. This means that if a resolver has unvalidated data in its cache, it should still perform a fresh, validated query for routine client requests, rather than relying on the unvalidated entries.
3. Constantly Verify EDNS0 Information: For the RU-EDNS0 variant, it is crucial that resolvers do not permanently cache the EDNS0 capabilities of name server hosts based on single, potentially compromised interactions. Resolvers should constantly verify or periodically re-evaluate the EDNS0 capabilities of name servers, especially when encountering validation failures, to prevent persistent misattribution of EDNS0 status.
4. Formal Guidelines for Troubleshooting Data: The research highlights a significant gap in DNSSEC-related specifications. There is an urgent need for formal guidelines from bodies like the IETF on how DNSSEC troubleshooting data (i.e., data obtained with the CD bit set) should be handled by resolvers. These guidelines should explicitly mandate the segregation, restricted TTL, and limited reuse scope for such data. The research team has already submitted an Internet Draft at IETF, which is currently under discussion within the DNSOP working group, aiming to prompt this standardization.
5. Responsible Disclosure and Patching: The researchers responsibly disclosed their findings to all affected DNS vendors. This proactive engagement led to three renowned vendors—BIND, Cloudflare, and OpenDNS—developing and deploying patches to address their RU vulnerabilities. This collaborative approach between researchers and industry is vital for enhancing internet security.

By implementing these suggestions, defenders can transform DNSSEC back into a robust shield, preventing its misuse as a sword for denial-of-service attacks and ensuring the continued integrity and availability of domain resolution services.

Key Takeaways

• Troubleshooting Mechanisms Lack Formal Guidelines: While indispensable for system availability, DNSSEC troubleshooting mechanisms (like the CD bit) lack clear, formal specifications for handling the data they produce.
• Unvalidated Data Has Overlooked Impact: Data intended solely for troubleshooting, when unvalidated, can have severe and often overlooked impacts on the routine functioning and security of production systems.
• Segregation is Crucial: System operators and resolver implementers must handle troubleshooting data with extreme caution, rigorously segregating it from validated data used in routine operations.
• Restrict Reuse and TTL: Resolvers should implement strict policies to restrict the reuse scope and enforce very short Time-to-Live (TTL) values for any unvalidated data obtained via troubleshooting queries.
• Standardization is Needed: There is an urgent need for international standardization bodies like the IETF to develop explicit guidelines for the secure handling and caching of DNSSEC troubleshooting data.
• DNSSEC Vulnerabilities Persist: Even mature security protocols like DNSSEC can harbor subtle design flaws or implementation oversights that, when exploited, can turn their protective features into attack vectors.

About the Speaker(s)

Shuhan Zhang is a PhD student at Tsinghua University. He presented this research, "Your Shield is My Sword: A Persistent Denial-of-Service Attack via the Reuse of Unvalidated Caches in DNSSEC Validation," which was a joint work between Tsinghua University and Dunwanun Laboratory. The paper received one of the 25 honorable mentions at USENIX Security 2025, highlighting the significance and impact of his team's findings in the field of internet security.