Rethinking the Security Threats of Stale DNS Glue Records

Rethinking the Security Threats of Stale DNS Glue Records

Speakers: Yunyi Zhang, Baojun Liu, Haixin Duan, Min Zhang, Xiang Li, Fan Shi, Chengxi Xu, Eihal Alowaisheq

Conference: USENIX Security '24

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

Overview

The Domain Name System (DNS) is a foundational component of the internet, responsible for translating human-readable domain names into IP addresses. While seemingly robust, the intricate mechanics of DNS can harbor subtle vulnerabilities. This talk, presented by Chiau from Tsinghua University on behalf of the listed authors, sheds light on a long-overlooked aspect of DNS: glue records. These special resource records, almost as old as DNS itself, are critical for resolving a specific type of domain delegation, yet their mismanagement and misuse have gone largely unaddressed.

The researchers discovered that a staggering quarter of all existing glue records are stale, meaning they point to invalid or outdated IP addresses for authoritative name servers. More alarmingly, they demonstrated how these stale records, when combined with specific behaviors in mainstream DNS software, can be "awakened" under a novel threat model they term Shadow Caching. This attack model enables malicious actors to hijack domain traffic or inflict denial-of-service (DoS) attacks, putting over 6 million domains at risk, including a significant portion of the internet's top 1 million websites.

This work critically re-evaluates the security posture of glue records, challenging long-held assumptions about their priority and usage within DNS resolvers. By exposing widespread mismanagement at the registry level and non-standard compliant behavior in DNS software, the research provides crucial insights for both domain administrators and DNS service providers to enhance the resilience and security of the global DNS infrastructure.

Background

▶ Watch: Introduction to stale DNS glue records problem (0:00)

The Domain Name System functions as a hierarchical and distributed database. When a client needs to resolve a domain name, a recursive resolver initiates a query process, starting from the root servers, moving to Top-Level Domain (TLD) servers (e.g., .com, .org), and finally to the authoritative servers responsible for the specific domain (e.g., example.com). At each step, an authoritative server provides delegation records, typically NS (Name Server) records, which direct the resolver to the next authoritative server in the hierarchy.

The relationship between a child domain and its authoritative name server can manifest in three primary forms:

1. In-domain delegation: The authoritative server for a domain is itself a subdomain of that domain. For example, ns1.example.com is the authoritative server for example.com.
2. Sibling delegation: The authoritative server for a domain is under a different second-level domain but within the same TLD. For example, ns1.otherdomain.com is the authoritative server for example.com.
3. Out-domain delegation: The authoritative server for a domain is under a completely different TLD. For example, ns1.otherdomain.net is the authoritative server for example.com.

Glue records are specifically designed to solve a critical problem that arises in in-domain delegation scenarios, often referred to as the "circular dependency" problem. Consider example.com whose authoritative server is ns1.example.com. When a resolver queries the .com TLD for example.com, it receives an NS record indicating ns1.example.com as the authoritative server. However, to query ns1.example.com, the resolver first needs its IP address. If ns1.example.com itself needs to be resolved by example.com's authoritative server, a logical loop is created. To break this loop, the parent zone (in this case, the .com TLD) provides extra A (IPv4) or AAAA (IPv6) records for ns1.example.com alongside the NS records. These are the glue records, directly providing the IP address of the authoritative server.

Historically, DNS standards have stipulated that glue records are primarily expected to be used only in referral responses to guide resolvers for in-domain delegation. They are not intended to be standalone DNS answers or to be used in other delegation scenarios. Consequently, many DNS software implementations assign glue records a low priority of trust and usage, often under the assumption that they rarely cause problems. This prevailing perception, however, is precisely what the presented research challenges, demonstrating that this perceived unimportance has led to widespread mismanagement and subsequent security vulnerabilities.

Key Findings

▶ Watch: Defining glue records and solving the delegation loop (3:00)

The research uncovered several critical findings that collectively highlight a significant, under-appreciated security risk within the DNS ecosystem:

• Widespread Mismanagement of Glue Records: A comprehensive analysis of over 1,000 TLD zone files revealed that a substantial portion of glue records are mismanaged. The study categorized these mismanaged records into two types:
• Stale Glue Records: Over 20% of all glue records were found to be stale. These records contain IP addresses for name servers that diverge from the actual IP addresses configured by the child domain's authoritative server. This means the parent zone is providing incorrect information.
• Expired Glue Records: Approximately 30% of the domain names associated with glue records were found to be non-existent or inactive, indicating that the child domain no longer uses the specified authoritative server, yet the glue record persists in the parent's zone file.

These mismanaged records provide false or invalid delegation information, potentially directing resolvers to incorrect or non-existent servers.

• DNS Software Misuse of Glue Records: Contrary to standard recommendations, the researchers found that several mainstream DNS software implementations and public DNS services exhibit problematic behavior. They cache and utilize glue records without proper validation, even in out-domain delegation scenarios where standards suggest they should not. This misuse creates a vulnerability where cached, potentially stale, glue records can override correct delegation information.

• The Shadow Caching Attack Model: The paper introduces a novel attack model, Shadow Caching, which leverages the combination of existing stale glue records in parent zone files and the aforementioned DNS software misuse. This attack allows an adversary to deliberately inject stale glue records into a resolver's cache, subsequently hijacking traffic for victim domains or causing denial-of-service.

• Significant Impact and Vulnerability:
• Millions of Domains at Risk: The evaluation revealed that over 6 million domains are susceptible to either takeover or denial-of-service attacks due to their stale glue records.
• Top Websites Affected: A concerning 20% of these vulnerable domains are ranked among the Tranco top 1 million sites, indicating that high-profile and critical internet services are not immune.
• Vulnerable DNS Software and Services: Multiple mainstream DNS software implementations and public DNS services were identified as vulnerable due to their non-standard compliant handling of glue records.

• Industry Acknowledgment and Action: Upon disclosure, several affected vendors and TLD registries confirmed the issues. Notably, the .info and .org TLD registries acknowledged the mismanagement problem and committed to clearing up stale glue records from their zone files. While DNS software and public DNS service vendors confirmed the issue, some reported significant complexity in implementing fixes, underscoring the deep-seated nature of this problem.

Technical Deep Dive

▶ Watch: Why glue record problems are often overlooked (4:20)

The core of the security threats discussed in this talk lies in a dual problem: the pervasive mismanagement of glue records at the registry level and the non-standard compliant behavior of DNS software in utilizing these records.

Let's first revisit the purpose of glue records. For a domain example.com whose authoritative name server is ns1.example.com (an in-domain delegation), a recursive resolver querying the .com TLD will receive an NS record pointing to ns1.example.com. Without an accompanying IP address, the resolver faces a circular dependency: it needs the IP of ns1.example.com to query it, but ns1.example.com itself is part of example.com and requires example.com's authoritative server to resolve. To break this loop, the .com TLD provides glue records (A or AAAA records) for ns1.example.com, containing its IP address, directly within the referral response. This allows the resolver to immediately contact ns1.example.com.

The problem of mismanagement arises when these glue records, stored by the parent zone (e.g., TLD registry), become out of sync with the actual configuration of the child domain. The researchers identified two primary forms of mismanagement:

1. Stale Glue: This occurs when the IP address provided in the glue record by the parent zone (e.g., ns1.example.com pointing to 192.0.2.1 in the .com zone) differs from the IP address that ns1.example.com would actually resolve to if queried directly from its own authoritative zone (e.g., 198.51.100.1). This discrepancy means the parent zone is providing incorrect, outdated information.
2. Expired Glue: This refers to glue records that point to name servers no longer in use or for domains that are non-existent or inactive. For instance, if example.com changes its authoritative name server from ns1.example.com to ns.newprovider.com, the .com TLD might still retain the glue record for ns1.example.com pointing to an old IP.

While mismanagement creates the incorrect data, DNS software misuse provides the vector for exploitation. DNS standards suggest that glue records should primarily be used for in-domain delegation referrals and generally hold low priority. However, the research found that several mainstream DNS resolvers and public DNS services:

• Cache glue records broadly: They cache glue records even when received in contexts outside of in-domain delegation, such as sibling or out-domain delegation scenarios.
• Trust cached glue without validation: Crucially, when a resolver already has a glue record cached for a particular name server, and it receives new delegation data from a TLD, some implementations prioritize the cached glue over the newly received, potentially more authentic, information. This is particularly problematic in out-domain delegation scenarios, where standards recommend against using cached glue without stringent validation.

This combination enables the Shadow Caching attack model. Let's illustrate with an example:

1. Prerequisite: A stale glue record exists. Suppose the .com TLD has a stale glue record for ns.vulner.com pointing to 1.1.1.1. However, the legitimate authoritative server for vulner.com is ns.actual.com, and 1.1.1.1 is an unused or attacker-controlled IP.
2. Victim Setup: A legitimate victim domain, victim.net, uses ns.vulner.com as its authoritative server. This is an out-domain delegation from .net to vulner.com.
3. Attacker Action - Cache Poisoning:

• The attacker registers their own domain, attacker.com.
• The attacker configures a sibling delegation for attacker.com such that its authoritative server is also ns.vulner.com.
• When a vulnerable recursive resolver attempts to resolve attacker.com, it queries the .com TLD. The .com TLD, seeing the delegation for attacker.com pointing to ns.vulner.com, will provide the stale glue record for ns.vulner.com (i.e., ns.vulner.com -> 1.1.1.1).
• Because the resolver misuses glue records, it caches this stale glue for ns.vulner.com at 1.1.1.1. This is the "shadow cache" – the attacker has deliberately injected a false IP for a critical name server into the resolver's cache.

1. Exploitation - Domain Takeover:

• The attacker then takes over the IP address 1.1.1.1. This might involve registering the IP from a cloud provider or leveraging an unused IP.
• When a user now attempts to resolve victim.net, the recursive resolver queries the .net TLD, which correctly returns an NS record pointing to ns.vulner.com.
• However, because the resolver has the stale glue for ns.vulner.com (1.1.1.1) already in its cache, and it prioritizes this cached entry (misuse), it will direct its query for victim.net to the attacker-controlled 1.1.1.1.
• The attacker, now acting as the authoritative server for victim.net, can return malicious A records, effectively hijacking traffic for victim.net.

1. Denial-of-Service Scenario: If the attacker cannot take over the IP 1.1.1.1, or if it points to an unresponsive server, queries for victim.net will fail. Persistent failures can lead the DNS software to mark victim.net as unreachable, causing a denial-of-service for legitimate users.

This sophisticated attack chain highlights how seemingly minor deviations from DNS standards, accumulated over years, can lead to widespread and impactful security vulnerabilities.

Demo / Proof of Concept

▶ Watch: How DNS software misuse creates security risks (7:40)

While the presentation did not include a live demonstration in the traditional sense, the researchers conducted a comprehensive evaluation to prove the practical feasibility and widespread impact of the Shadow Caching attack model. Their findings serve as a compelling proof of concept for the vulnerabilities identified.

The evaluation process involved:

1. Extensive Data Collection: They collected and analyzed over 2 million glue records extracted from more than 1,000 Top-Level Domain (TLD) zone files. This formed the basis for identifying mismanaged glue.
2. Identification of Mismanaged Glue: Through systematic checks, they identified that over 20% of these glue records were stale (IP mismatch) and approximately 30% were expired (pointing to inactive or non-existent domains). These mismanaged records represent the attack surface.
3. Vulnerability Assessment of DNS Software: The researchers tested various mainstream DNS software implementations and public DNS services to ascertain their handling of glue records, particularly in out-domain delegation scenarios. They confirmed that several popular resolvers indeed cache and use glue records without proper validation, even when standards advise against it, thus making them susceptible to Shadow Caching.
4. Quantification of At-Risk Domains: By correlating the identified stale glue records with domain delegation data, they determined that over 6 million domains globally are susceptible to either domain takeover or denial-of-service attacks using the Shadow Caching technique.
5. Impact on High-Profile Targets: The analysis further revealed that 20% of these 6 million vulnerable domains are ranked within the Tranco top 1 million sites, underscoring that critical internet infrastructure and popular services are significantly exposed to this threat.

The results of this evaluation served as a robust proof of concept, demonstrating that the theoretical attack model translates into practical, large-scale vulnerabilities affecting millions of domains and widely used DNS services. The subsequent disclosure to affected vendors and TLD registries, and their confirmation of the issues, further validated the findings. For instance, the .info and .org TLD registries specifically confirmed the mismanagement issue and initiated efforts to clean up stale glue records. While some DNS software vendors acknowledged the vulnerability, they also highlighted the complexity involved in patching these behaviors due to the intricate nature of DNS resolution logic.

Defensive Implications

▶ Watch: Introducing the 'Shadow Caching' attack leveraging stale glue (9:20)

The findings of this research present significant implications for various stakeholders within the internet ecosystem, requiring a multi-pronged defensive strategy.

For Top-Level Domain (TLD) Registries and Domain Holders:

1. Strict Glue Record Management: TLD registries must implement more transparent and rigorous policies for the creation, maintenance, and deletion of glue records. This includes:

• Regular Audits: Periodically scan their zone files to identify and remove stale or expired glue records. The confirmation by .info and .org registries to clear up stale glue records is a positive step that other TLDs should emulate.
• Automated Validation: Implement automated systems to verify that the IP addresses in glue records provided by domain holders actually match the authoritative servers' configurations.
• Clearer Guidelines: Provide explicit guidelines to domain holders on how to correctly manage their glue records, emphasizing the importance of keeping them updated, especially when changing name server IPs or providers.

1. Proactive Deletion: When a child domain's authoritative server changes or becomes inactive, the parent TLD should have mechanisms to promptly remove associated glue records that are no longer valid.

For DNS Software Vendors and Public DNS Services (Resolver Operators):

1. Correct Misuse of Glue Records: This is the most critical defensive measure for resolvers. DNS software must adhere more strictly to standards regarding glue record usage, particularly in out-domain delegation scenarios.

• Prioritize Authoritative Data: When a resolver receives new delegation data (NS records and potentially glue) from a parent zone, it should always prioritize this fresh, authoritative information over potentially stale glue records already in its cache, especially for out-domain delegations.
• Stricter Validation: Implement more robust validation mechanisms for cached glue records. Before using a cached glue record, especially for an out-domain delegation, resolvers should attempt to verify its authenticity by querying the authoritative server directly or cross-referencing with other trusted sources.
• Limited Scope for Glue Usage: Restrict the use of cached glue to only those scenarios where it is strictly necessary (i.e., in-domain delegation referrals) and only after thorough validation. For out-domain or sibling delegations, cached glue should be treated with extreme suspicion or outright ignored in favor of direct resolution.

1. Enhanced Cache Management: Review and refine caching policies for glue records to minimize the window of vulnerability. This might include shorter TTLs (Time-To-Live) for glue records, especially if their authenticity is not frequently re-validated.
2. Security-Aware Design: DNS software development should incorporate security-by-design principles, understanding that even seemingly minor deviations from RFCs can have cascading security implications.

In summary, defending against Shadow Caching requires a concerted effort. TLD registries must ensure the accuracy and freshness of the glue records they publish, eliminating the source of stale data. Concurrently, DNS resolver operators must modify their software to avoid misusing these records, particularly by not trusting unvalidated cached glue in scenarios where it can be exploited. This collaborative approach is essential to secure the millions of domains currently at risk.

Key Takeaways

• Pervasive Mismanagement: Over 20% of all DNS glue records are stale, and ~30% are associated with non-existent or inactive domains, indicating widespread mismanagement at the TLD registry level.
• DNS Software Misuse: Many mainstream DNS software implementations and public DNS services cache and use glue records without proper validation, even for out-domain delegations, contrary to DNS standards.
• Shadow Caching Attack: A novel attack model, Shadow Caching, leverages the combination of stale glue records and DNS software misuse to inject malicious IP addresses into resolver caches, leading to domain takeover or denial-of-service.
• Significant Impact: Over 6 million domains, including 20% of the Tranco top 1 million sites, are susceptible to these attacks, posing a substantial threat to internet stability and security.
• Urgent Remediation Needed: Both TLD registries must implement stricter management and auditing of glue records, and DNS software vendors must correct their implementations to prioritize authoritative data and validate cached glue, especially for out-domain scenarios.

About the Speaker(s)

This research was a collaborative effort by a team of academics: Yunyi Zhang, Baojun Liu, Haixin Duan, Min Zhang, Xiang Li, Fan Shi, Chengxi Xu, and Eihal Alowaisheq. The presentation at USENIX Security '24 was delivered by Chiau, a postdoc at Tsinghua University, on behalf of the authors, due to their inability to attend in person. The collective expertise of this group, particularly from Tsinghua University, highlights a strong focus on fundamental internet security research, specifically delving into the intricacies and potential vulnerabilities of core internet protocols like the Domain Name System.