The Domain Name System (DNS) stands as the veritable backbone of the Internet. Its role in translating domain names to IP addresses has been pivotal since its inception, which provides a solid basis for multiple applications and services, such as email, Content Delivery Networks (CDNs), and certificates.
Since its cornerstone status, attackers have long been trying to manipulate its response for hijacking via DNS cache poisoning attacks that introduces false DNS information into the DNS resolver’s cache. Typically, to inject forged answers, there are two techniques — the on-path attacker can observe the network link and return responses directly, such as the Kashpureff attack, while the off-path attacker needs to guess the identification fields like the famous Kaminsky attack.
After these attacks were disclosed, the DNS community proposed various mitigation methods to patch the DNS, such as Bailiwick checking, source port randomization, 0x20, DNSSEC, DNS Cookie and others. However, this cache poisoning threat has never been prevented and is like a cat-and-mouse game. Over the decades, new attacks have been continuously developed.
With evolving technology, the threats faced by the DNS have also evolved. We at Tsinghua University have proposed MaginotDNS, a new DNS cache poisoning attack, specifically preying on conditional DNS resolvers (CDNS), where servers double up as both recursive resolvers and forwarders. This attack was also presented at USENIX Security ’23 and Black Hat USA ’23.
A primer on CDNS
To fully comprehend the gravity of MaginotDNS, it’s crucial to first understand CDNS.
CDNS systems that simultaneously act as recursive resolvers and forwarders occupy a unique space in the Internet infrastructure. Their dual roles are defined as:
1. Recursive resolver: This involves catering to requests from client machines via their browsers. If the resolver has the domain data cached, it responds; otherwise, it launches queries to other nameservers iteratively by performing recursive resolution.
2. Forwarder: Here, instead of sending out queries, the forwarder transfers client requests to another, more capable, recursive resolver or nameserver.
These CDNS systems inherently maintain a shared cache due to their dual functionality, making them a prime target for MaginotDNS exploitation.
MaginotDNS: The new threat landscape
MaginotDNS is novel cache poisoning attack. It identifies and exploits vulnerabilities in the bailiwick checking algorithm to attack the CDNS. Bailiwick checking was proposed to eliminate the Kashpureff attack, specifying that only answers from the same domain as the requested name are acceptable. For example, as shown in the following figure, example.com is in-bailiwick while mybank.com is out-of-bailiwick.
Once seen as the cornerstone of DNS security, bailiwick checking, especially in mainstream software like BIND and Microsoft DNS, has shown vulnerabilities. What’s even more alarming is the potency of MaginotDNS. It can seize the entire DNS zones, with even Top-Level Domains (TLDs) like .com and .net falling under its shadow.
Threat model of MaginotDNS
Launching MaginotDNS requires delving into its intricate operation:
- Attack commencement: The attacker triggers a query for their domain to the CDNS. Depending on its zone configuration, CDNS relays the query either to the attacker’s designated nameserver or to an upstream server.
- Injection: Herein lies the genius of MaginotDNS. Using the vulnerabilities in the bailiwick checking mechanism, especially pronounced in the forwarder mode of CDNS, the attacker seamlessly injects forged responses into the shared cache.
- Highjacking future queries: This polluted cache then serves as the trusted data for future recursive queries by the CDNS, leading to potential hijacking or misdirection.
Real-world implications and scale
In total, four mainstream DNS software suites are affected, including BIND (CVE-2021-25220), Knot Resolver (CVE-2022-32983), Microsoft DNS, and Technitium (CVE-2021-43105). We have reported these vulnerabilities to these vendors, and they have acknowledged them and patched their software. We performed both on-path and off-path attack experiments to demonstrate the practicality of MaginotDNS. The off-path attack video (on BIND9) is available at YouTube.
We proposed new CDNS discovery methodology and conducted extensive measurements into the current state of CDNS, and MaginotDNS yields concerning insights. We found that CDNS configurations are not niche; about 41.8% of DNS servers in real-world networks function as CDNS. More worryingly, of this number, an alarming 35.5% lay exposed to the MaginotDNS threat. We also confirmed real MaginotDNS exploitation with several ISPs.
For network engineers, operators, and the broader tech ecosystem, this isn’t just a wakeup call; it’s an urgent clarion call to action.
Navigating the MaginotDNS threat landscape
As professionals responsible for ensuring network integrity, there are certain measures to establish:
- Regular updates: Routine patching and updates, especially for DNS software like BIND or Microsoft DNS, can’t be overstated.
- Rethinking DNS mechanisms: MaginotDNS has cast a spotlight on vulnerabilities, particularly in CDNS configurations. A root-and-branch review is more than warranted.
- Unified front: The DNS community must rally together. A standardized, unified security protocol for DNS software and servers is now essential.
Concluding thoughts
The MaginotDNS threat underscores the ever-evolving challenge faced by DNS systems, with CDNS being the latest in the firing line. As gatekeepers of the Internet’s integrity, the onus is on network professionals to adapt, fortify, and innovate. The security and fluidity of Internet operations depend heavily on our collective foresight, responsiveness, and collaboration.
Xiang Li is a is a 5th-year PhD candidate at Tsinghua University.
Other authors including Chaoyi Lu, Baojun Liu, Qifan Zhang, Zhou Li, Haixin Duan, and Qi Li also contributed to this work.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.