Understanding the Implementation and Security Implications of Protective DNS Services

Understanding the Implementation and Security Implications of Protective DNS Services

Speakers: Mingxuan Liu, Researcher

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=xEV61O1G-pU

Overview

The internet's utility is constantly challenged by the proliferation of malicious domain names, which serve as critical infrastructure for cyberattacks such as botnet command and control, phishing, spam, and malware distribution. Industry reports, such as Cisco's, indicate that over 91% of internet attacks are linked to the resolution of these nefarious domains, with ICANN's DAAR project identifying over 622,000 malicious domains in March 2023 alone. While traditional domain takedown procedures are effective, they are often slow and resource-intensive, necessitating complex legal and administrative processes involving registrars and law enforcement. This inherent friction has spurred the security community to seek more agile and real-time solutions for mitigating threats at the domain level.

Protective DNS (PDNS) has emerged as a promising alternative, offering a proactive defense mechanism at the DNS layer. A PDNS server intercepts DNS queries and, if a queried domain is identified on its blocklist (derived from threat intelligence), it rewrites the DNS response to direct the client to a secure address, typically a reserved IP, effectively preventing access to the malicious resource. This approach requires no changes to the fundamental DNS protocol and operates independently of external organizations, providing immediate protection. The concept has garnered significant support, with major DNS providers like Cloudflare and Quad9 offering PDNS services, and national governments in the US, Canada, and the UK launching initiatives for nationwide PDNS infrastructure.

Despite the growing enthusiasm and adoption, a significant research gap exists regarding the practical implementation and security implications of PDNS. The specific security policies and domain blocklists employed by PDNS providers are largely proprietary and opaque. This lack of transparency has led to reported issues, including false positives where benign domains like YouTube and Gmail are inadvertently blocked. Furthermore, prior research has indicated that flaws in smart DNS services can inadvertently expose user information. Motivated by these concerns, the presented study addresses this gap by conducting the first large-scale measurement study of PDNS, aiming to quantify their prevalence, analyze their blocking policies, and identify inherent security risks within the PDNS ecosystem. The findings are intended to guide the development of a more robust and secure PDNS future.

Background

▶ Watch: Introduction to Protective DNS and research motivation (0:00)

To appreciate the scope and findings of this research, it's essential to understand the foundational principles of Protective DNS and the existing landscape. At its core, PDNS functions as a recursive DNS service that actively prevents users from connecting to malicious domains. The workflow is straightforward: a client sends a DNS query to a PDNS server. The server then consults its internal threat intelligence data. If the domain is found on its blocklist, the PDNS server intercepts and rewrites the DNS response, providing a secure answer (e.g., a reserved IP address like 127.0.0.1 or 0.0.0.0) instead of the legitimate, malicious one. If the domain is not on the blocklist, the query is resolved normally through authoritative DNS servers. This mechanism offers real-time protection without altering the DNS protocol or requiring coordination with external entities.

The PDNS industry is rapidly expanding, with many public recursive DNS services integrating these protective features. An initial manual review of 42 popular DNS providers revealed that 28 of them (66.67%) offer PDNS functionalities. Some providers, such as Cloudflare, even distinguish their PDNS services with dedicated IP addresses (e.g., 1.1.1.2 and 1.1.1.3) separate from their standard DNS (1.1.1.1). The strategic importance of PDNS is further highlighted by official guidance and national deployment initiatives from governments in the US, UK, and Canada, underscoring its recognized role in modern cybersecurity strategies.

An empirical study was conducted on these 28 popular PDNS providers to understand their operational nuances, focusing on their domain blocklists and DNS rewriting policies. Regarding blocklists, providers utilize diverse sources:

• Open-source blocklists: Seven providers, including AdGuard, use public lists like URLhaus, CyberCrime Tracker, and VX Vault. However, these are often user-reported, leading to infrequent updates and potential for abuse.
• Private domain blocklists and threat intelligence: This is a more common approach, adopted by 11 providers like Yandex DNS, leveraging commercial threat intelligence (e.g., VirusTotal) or proprietary lists (e.g., OneDNS, 360 Secure DNS, 114 DNS).
• Unknown sources: A significant 16 providers, including UltraDNS, do not disclose their blocklist origins, contributing to the opacity of the ecosystem.
• User complaints and corrections: Only two providers, 360 Secure DNS and 114 DNS, explicitly offer channels for users to report false positives, highlighting a general lack of user feedback mechanisms.

The variety of blocklist sources reflects diverse filtering focuses: 24 providers block malware, 14 block phishing, 14 offer child mode protection, and 2 allow customized filtering.

The investigation into DNS rewriting policies—often undisclosed—involved probing the 28 popular PDNS providers with a small set of known malicious domains. Five primary rewriting policies were identified:

• Special-use IP addresses: Four providers, such as SkyDNS, resolve malicious domains to reserved IPs like 0.0.0.0 or 127.0.0.1.
• Secure IP addresses: Fourteen providers, including UltraDNS, redirect to a limited set of secure IP addresses, which may be affiliated with the PDNS provider or a third-party sinkhole/cloud server.
• Secure CNAMES: Four providers, like Yandex DNS and SafeSurfure DNS, point malicious domains to sinkhole domain names (e.g., safel.yandex.ru) using CNAME records.
• Response code modification: Two providers alter the DNS RCODE, with Norton DNS returning REFUSED and Quad9 DNS returning NXDOMAIN to block access.
• No data: Six providers, including OpenDNS and Comss DNS, return an empty DNS response.

Discussions with collaborating PDNS providers (114 DNS and 360 DNS) confirmed that these identified policies accurately reflect real-world implementations. This empirical analysis underscored the substantial variations and lack of standardization across the PDNS ecosystem, emphasizing the critical need for a large-scale measurement study to understand its actual deployment and security implications.

Technical Deep Dive

▶ Watch: Understanding the core concept and workflow of Protective DNS (2:00)

The study's primary objective was to develop an efficient and scalable system for identifying PDNS services operating in the wild, a non-trivial task given the inherent opacity and diversity of PDNS implementations. The core heuristic for PDNS identification is that they all block malicious domains through DNS response rewriting. This led to a four-step methodology:

1. Collect malicious domain names along with their authoritative DNS answers.
2. Query open DNS servers for these malicious domain names.
3. Compare the DNS responses from these servers with the authoritative answers.
4. Identify instances of response rewriting to classify resolvers as PDNS.

Implementing this methodology at scale presented three significant technical challenges and their respective solutions:

i) Malicious domains without blocklist knowledge: Without prior knowledge of specific PDNS blocklists, selecting domains that reliably trigger blocking is difficult.

• Solution: A comprehensive list of generally malicious domains was compiled. This began with 5.2 million domains from seven open-source blocklists (covering malware, phishing, tracker, botnet, adult, and spam categories). To ensure high maliciousness, 40,753 domains flagged by at least two sources were selected and then cross-checked with VirusTotal, retaining 36,533. For manageable query volume, 10,000 domains were randomly sampled, maintaining original category ratios (e.g., 4,231 malware, 3,962 botnet, 867 phishing). Approximately 22.52% of these were intentionally unresolvable to test PDNS policies. A control group of 100 popular domains from Tranco's top list was also included.

ii) Obtaining comprehensive authoritative DNS answers: Malicious domains frequently change their authoritative answers to evade detection, making it challenging to get a complete picture solely by querying authoritative servers.

• Solution: Authoritative server queries from three geographically diverse vantage points were combined with an extensive passive DNS dataset obtained from a reputable security company. This dataset, comprising aggregated DNS logs, was filtered for recency and reliability (records with count ≥ 5 and time_last later than 2022).

iii) Distinguishing PDNS rewriting from other DNS manipulations: Other DNS alterations like hijacking, censorship, and domain takedowns can also produce forged DNS answers, necessitating a robust differentiation mechanism.

• DNS Response Rewriting Definition: A DNS response was considered rewritten if the enclosed IP addresses did not share any Autonomous System Numbers (ASNs) with the authoritative answers.
• Censorship Mitigation: To minimize interference, VPS vantage points in high-freedom countries (US, Japan, UK) were used. Potentially censored domains were filtered using the Citizenlab dataset. Established censorship detection methods were also employed, sending test domains to random IPs in each resolver's AS not offering DNS resolution on port 53; any returned result indicating censorship led to the exclusion of that domain from the PDNS resolver results.
• DNS Hijacking Mitigation: Distributed domain queries from three vantage points were used. Inconsistent responses across these points were excluded, reducing false alarms.
• Domain Takedown Differentiation: Takedowns typically involve modifications at the authoritative level (e.g., NS record changes), not the recursive level. Since the method compares resolver responses with authoritative answers, takedowns were not mis-detected as PDNS modifications.

To robustly identify PDNS, an empirically derived PDNS Identification Threshold was established. By evaluating 42 popular DNS providers (28 known PDNS, 14 non-PDNS) as ground truth, and conducting 30 rounds of scanning experiments, it was observed that PDNSes blocked an average of 302 domains, while non-PDNSes rewrote only 33. A threshold of 50 rewritten malicious domains yielded the highest F1-score of 94.06%, providing optimal precision and recall for classification.

The system design and architecture integrated this methodology into a cohesive pipeline. It began with collecting 100 popular domains (control) and 10,000 malicious domains (test set, maintaining category ratios from malware, botnet, phishing, adult, spam, tracker). Authoritative DNS answers were gathered from three vantage points and augmented with passive DNS data. Next, 193,888 stable recursive DNS resolvers were identified through an Internet-wide scan of port 53 (Feb-Mar 2022), filtering for recursive mode, ASNs associated with popular DNS services, and DNS keywords in PTR records. These resolvers were queried from three cloud servers (US, JP, UK) on Alibaba Cloud using a modified XMap scanner at a conservative rate of 2 queries per second per target, with each query repeated three times to mitigate network jitter. The final step involved identifying PDNS by processing responses using Algorithm 1, which systematically checks for censorship, hijacking, normal responses, ASN sharing, passive DNS data, and special-use/secure IPs. Resolvers rewriting more than 50 malicious domains were classified as PDNS. Ethical considerations included obtaining explicit permission from Alibaba Cloud, configuring PTR records as a research scanner with contact info, anonymizing sensitive IP addresses, and responsibly disclosing vulnerabilities to CERT agencies.

This extensive measurement study identified 17,601 PDNS resolvers, representing 9.08% of all probed stable resolvers, distributed across 117 countries and 1,473 ASNs. The geographic distribution showed the US leading with 6,296 PDNS IPs (35.8%), followed by Iran (1,225 IPs, 7.0%) and China (1,205 IPs, 6.8%). Netflow data from an educational network indicated significant real-world adoption, with an average of 23,847 clients utilizing PDNS resolvers daily. Querying performance analysis showed PDNS responding significantly faster to blocked domains (70.47% in less than 0.2 seconds without caching, compared to 44.44% for non-blocked domains), suggesting early-stage blocking. The domain blocklists varied, with 57% of PDNSes blocking over 500 malicious domains. Malware (99.97%), botnet (99.59%), and phishing (97.80%) were the most frequently blocked categories. Analysis of blocklist similarities using the Jaccard Index revealed high commonality between some vendors (e.g., SkyDNS and SafeDNS at 0.99), with Quad9 appearing as a significant blocklist hub. The five identified DNS rewriting policies were confirmed in the wild: secure IP addresses (56.45%), special-use IP addresses (40.96%), secure CNAMEs (2.55%), error response codes (2.32%), and no data (4.67%). Notably, 1,222 PDNSes applied diverse rewriting policies based on domain categories. A critical finding was that 13 PDNS vendors returned insecure (authoritative) results for query types not explicitly configured with blocking measures (e.g., AAAA, CNAME, TXT, NS records), creating a bypass vulnerability.

Key Findings

▶ Watch: Analysis of diverse sources for PDNS domain blocklists (2:45)

Beyond the operational characteristics of PDNS, the study uncovered several critical security flaws stemming from flawed blocking strategy implementations, representing significant contributions to understanding the PDNS ecosystem's vulnerabilities. Three main types of security issues were identified:

i) Denial of Response (DoR) Induced by PDNS

A significant number of PDNSes (822) employ a "No Data" policy to block malicious domains. However, an aggressive implementation of this policy can inadvertently lead to a Denial of Response (DoR) for legitimate traffic. Specifically, 28 identified PDNSes were found to temporarily block all domain resolutions for a client after receiving queries for multiple malicious domains.

• Threat Model: An off-path attacker can exploit this vulnerability by spoofing a victim's IP address (e.g., 6.6.6.6). The attacker sends numerous queries for malicious domains to a vulnerable PDNS resolver. If these domains are on the PDNS blocklist, the resolver's aggressive blocking mechanism is triggered. Consequently, the PDNS server denies DNS lookup services to the actual victim for a certain period, effectively disrupting their internet access.
• Results: All 28 tested PDNS resolvers exhibited DoR, evidenced by the absence of responses for popular domains in test experiments, contrasting with successful resolutions in control experiments. Seven PDNS resolvers from renowned DNS vendors demonstrated DoR issues. For instance, one ControlD DNS resolver became unable to resolve any queries for up to 12 hours after blocking 1,123 malicious domains.

ii) Dangling PDNS Infrastructure

The most prevalent rewriting policy (56.45% of PDNSes) involves redirecting to secure IP addresses. However, if these secure IPs are not actively maintained or are decommissioned, they can become dangling resources (Dare), vulnerable to takeover and misuse by attackers. This risk extends to obsolete cloud IP addresses or expired sinkhole domains.

• Threat Model: An attacker first identifies a PDNS's security policy through pre-testing. The attacker then gains control of a dangling resource (e.g., an obsolete cloud IP like 6.6.6.6). When a victim's client queries a malicious domain (e.g., botnet.com) to the PDNS resolver, the PDNS returns the modified result pointing to the attacker's controlled resource. This redirects the victim's connection to the attacker's server, enabling the attacker to relay malicious content or capture data.
• Results: The study identified 61 cloud IPs used by 693 PDNSes. Among these, 7 obsolete cloud IPs were found to be employed by 21 PDNSes, with an average of 279 malicious domain references. Furthermore, 5 PDNS resolvers in Indonesia were impacted by a seizable CNAME domain (denied.gold), confirming the feasibility of these attacks.

iii) Multiple Flawed Blocking Strategies (Subversion of PDNS)

Two critical flaws related to blocking strategy implementation were identified:

• Inconsistent Responses: 105 PDNSes were observed to return both forged (e.g., to a secure IP) and authoritative (malicious) answers for the same malicious domain queries. This creates a scenario where stub resolvers might inadvertently select the malicious resource records, leaving end-users vulnerable despite the PDNS service being in place.
• Non-configured Query Types: 13 PDNS vendors were found to return original, insecure resolution results for query types not explicitly configured with blocking measures (e.g., AAAA, CNAME, TXT, or NS records). For example, Yandex and CIRA Canadian Shield DNS returned original TXT records for malicious domains. This allows attackers to bypass PDNS protection by utilizing less common resource record types for their malicious operations.

These vulnerabilities were responsibly disclosed to affected DNS vendors, with 14 vendors receiving reports, and Verisign DNS, ControlD DNS, and Neustar DNS actively engaging in discussions for resolution. For vendorless resolvers, collaboration with national CERT agencies, including the China National Vulnerability Database (CNVD), led to 21 vulnerability reports. As of the talk, 12 Denial of Response (DoR) vulnerabilities have received audit verification results as high-risk vulnerabilities, underscoring the severity of these findings and the urgent need for comprehensive review and improvement of PDNS implementations.

Demo / Proof of Concept

▶ Watch: Exploring five primary DNS rewriting policies used by PDNS (4:00)

The study’s methodology inherently included empirical evaluations that served as proof-of-concept demonstrations for the identified security vulnerabilities. These evaluations systematically confirmed the presence and exploitability of the flaws in real-world PDNS deployments.

For the Denial of Response (DoR) Induced by PDNS vulnerability, a controlled experiment was designed to simulate an attacker's actions and observe the impact on a victim. The researchers tested 28 potential PDNSes from three vantage points (UK, US, JP) using a mix of 10,000 malicious and 100 popular domains. Seven experiments were conducted with varying time intervals, alongside concurrent control experiments from two other vantage points (AE, CH) querying only popular domains. The results unequivocally showed that all 28 PDNS resolvers exhibited DoR. This was evidenced by the complete absence of responses for legitimate popular domains in the test experiments, starkly contrasting with successful resolutions in the control groups. The impact was significant, with certain PDNS resolvers, like one from ControlD DNS, becoming unable to resolve any queries for up to 12 hours after blocking a mere 1,123 malicious domains. This directly demonstrated how an off-path attacker, by spoofing a victim's IP and sending a sufficient volume of malicious queries, could effectively disrupt the victim's internet access by triggering the PDNS's aggressive non-responsive blocking policy.

The Dangling PDNS Infrastructure vulnerability was evaluated by following previous research methodologies for identifying seizable resources. The process involved:

1. Identifying the secure IP addresses employed by PDNSes. The study found 61 distinct cloud IPs used by 693 PDNSes as redirection targets.
2. Assessing the status of these IPs. This involved checking if the IPs were actively in use or had become obsolete.
3. Identifying CNAME domains used for redirection and checking their registration status.

The evaluation successfully revealed 7 obsolete cloud IPs that were still referenced by 21 PDNSes for blocking an average of 279 malicious domains. Furthermore, 5 PDNS resolvers in Indonesia were found to be impacted by a seizable CNAME domain (denied.gold). The researchers confirmed the feasibility of taking over these dangling resources, highlighting how an attacker could register an obsolete cloud IP or an expired CNAME domain and then redirect unsuspecting victims to their controlled infrastructure when a PDNS resolver, configured to use that dangling resource, blocks a malicious query. This would allow the attacker to serve malicious content or collect data from clients attempting to access the originally malicious domain.

For the Multiple Flawed Blocking Strategies vulnerability, the proof-of-concept involved direct observation of DNS responses. The researchers systematically queried PDNS resolvers for malicious domains and analyzed the returned resource records.

• The flaw of returning both forged and authoritative answers was demonstrated by identifying 105 PDNSes that, for the same malicious domain query, would provide a rewritten response (e.g., to a secure IP) alongside the original, malicious authoritative answer. This clearly showed the inconsistency that could lead a stub resolver to pick the harmful record.
• The vulnerability concerning non-configured query types was proven by sending queries for malicious domains using less common record types (e.g., AAAA, CNAME, TXT, NS records) instead of the standard A record. The evaluation confirmed that 13 PDNS vendors, including Yandex and CIRA Canadian Shield DNS, returned the original, insecure resolution results for these non-configured query types. This directly demonstrated a bypass mechanism where an attacker could leverage these alternative query types to circumvent PDNS protection and deliver malicious content.

These evaluations, by meticulously demonstrating the existence and potential exploitation of each vulnerability, served as concrete proof-of-concept for the security issues identified in the PDNS ecosystem.

Defensive Implications

▶ Watch: Key technical approach to identify Protective DNS in practice (5:00)

The findings from this large-scale measurement study provide crucial guidance for both PDNS operators and the broader cybersecurity community to enhance the security and efficacy of Protective DNS services. The identified vulnerabilities necessitate a re-evaluation of current implementation practices and the adoption of more robust defensive strategies.

Firstly, transparent blocking activity is paramount. While using inherently safe special-use IP addresses (e.g., 0.0.0.0) for blocking is technically secure, it can lead to a poor user experience by simply making domains unreachable without explanation. To mitigate this, PDNS providers should implement dedicated web pages that users are redirected to, clearly explaining why a domain was blocked (e.g., "Malware domain blocked") and offering specific channels (e.g., an email address) for users to report false positives or request corrections. This approach not only improves user trust and satisfaction but also provides valuable feedback for refining blocklists, reducing instances of inadvertently blocking benign domains.

Secondly, PDNS operators must exercise extreme caution when utilizing third-party rewriting infrastructures. The study highlighted the severe security risks associated with dangling resources, such as obsolete cloud IPs or expired sinkhole domains that can be easily hijacked by attackers. PDNS vendors are urged to implement rigorous verification mechanisms to continuously monitor the status and ownership of any third-party infrastructure they rely on for rewriting DNS responses. This includes regular checks for domain registration expiry, IP address re-allocation, and active service status to prevent potential takeover and abuse by malicious actors.

Thirdly, specific defenses against Denial of Response (DoR) attacks are urgently needed. The aggressive non-responsive policies identified in the study make PDNS services vulnerable to spoofed attacks that can disrupt legitimate user internet access. To counter this, PDNS operators should consider implementing countermeasures such as replying with a large DNS answer in response to a client issuing numerous DNS queries for malicious domains. This forces the client to switch from UDP to DNS over TCP, a more robust protocol against IP spoofing, thereby effectively mitigating the DoR attack vector. Implementing rate limiting and reputation-based blocking for clients exhibiting suspicious query patterns could also provide additional layers of defense.

Finally, the significant divergence in PDNS implementations and policies observed across the ecosystem underscores an urgent need for standardization and best practices. Future efforts should focus on developing industry-wide consensus and technical standards for secure PDNS operation. These guidelines should encompass clear specifications for blocklist management (including sources, update frequencies, and false positive handling), secure rewriting policies (detailing the use of secure IPs, CNAMEs, and error codes), and comprehensive vulnerability handling procedures. Such standardization would reduce the attack surface, improve interoperability, and ensure that PDNS services consistently deliver their intended security benefits without introducing new vulnerabilities.

Key Takeaways

• Growing Adoption, Lack of Standardization: Protective DNS (PDNS) is widely adopted, with 9.08% of all probed recursive resolvers being PDNS, but implementations vary significantly in blocklist sources and rewriting policies, indicating a critical lack of industry standardization.
• Performance Benefits: PDNS services generally offer minimal query latency overhead, responding significantly faster to blocked domains (70.47% in <0.2s) than non-blocked ones, suggesting efficient, early-stage blocking.
• Denial of Response (DoR) Vulnerability: Aggressive "No Data" blocking policies in 28 PDNSes can lead to Denial of Response (DoR) attacks, where spoofed malicious queries can temporarily block legitimate traffic for actual victims, with some services causing outages for up to 12 hours.
• Dangling Infrastructure Risk: Reliance on secure IP addresses and CNAMEs for rewriting creates a risk of dangling PDNS infrastructure if these resources become obsolete or expire, allowing attackers to hijack redirection targets and intercept victim traffic.
• Flawed Blocking Strategies: Many PDNSes exhibit flawed blocking strategies, such as returning both forged and authoritative answers for the same query (105 PDNSes) or failing to block malicious domains for non-configured query types (13 PDNS vendors like AAAA, CNAME, TXT, NS records), thereby subverting their own protective efficacy.
• Urgent Need for Review and Standardization: The identified vulnerabilities highlight an urgent need for PDNS operators to review their implementations, adopt transparent blocking, secure third-party infrastructure usage, implement DoR defenses, and contribute to industry-wide standardization efforts.

About the Speaker(s)

Mingxuan Liu is presented as a researcher at the NDSS Symposium, where this work on Protective DNS services was presented. The transcript and metadata do not specify their institutional affiliation or exact title beyond "Researcher." Their work demonstrates expertise in large-scale internet measurement, DNS security, and vulnerability analysis within the cybersecurity domain.