]> Tsinghua University

Beijing China

Zhongguancun Laboratory

Beijing China

Tsinghua University

Beijing China

Zhongguancun Laboratory

Beijing China

Protective DNS is a defense mechanism deployed on recursive resolvers to prevent users from accessing malicious domains. For domain names in the blocklist, it rewrites DNS resolution responses to point to secure destinations (e.g., safe servers) to prevent users from accessing malicious entities. Owing to its effective defenses against common cyber attack behaviors—such as command-and-control (C2) communications of malware—Protective DNS deployment has surged via various initiatives. Not only have renowned DNS service providers adopted this defense, but some countries have also launched national-scale deployments. Meanwhile, studies analyzing Protective DNS have identified implementation diversity. Thus, this document aims to provide specific operational and security considerations for Protective DNS. It is intended primarily for entities seeking to deploy Protective DNS for defensive purposes, offering deployment and security considerations. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at protective-dns.html. Status information for this document may be found at dns/. Source for this draft and an issue tracker can be found at

Introduction Protective DNS (also termed as PDNS) is a lightweight defensive measure deployed at recursive resolvers to proactively rewrite DNS resolution responses for malicious domains, thereby preventing users from accessing malicious resources. Specifically, when a client initiates a domain name resolution request, PDNS first performs a security check on the target domain—determining whether the domain poses a security risk by matching it against blocklists. If the domain is identified as malicious, PDNS uses DNS rewriting technology to intercept the resolution request and return a secure response (e.g., a safe server address controlled by the PDNS service provider), blocking users from establishing connections with malicious resources. For domains outside blocklists, PDNS will perform normal recursive queries and return authentic DNS responses. The defensive benefits offered by PDNS have spurred extensive deployment efforts. Large DNS resolution service providers have increasingly deployed PDNS on their recursive servers. Moreover, some countries or regions have initiated national-level infrastructure deployments of PDNS. The UK's National Cyber Security Centre (NCSC), for instance, launched a PDNS service in 2017 to enhance cyber defenses, which has since been used by central government departments, local authorities, schools, and emergency services . Notably, statistics from the UK NCSC indicate that approximately 7.2 million individual users utilized the system in 2023 . In 2022, PDNS in UK processed 810 billion DNS queries and blocked 11 billion queries involving 420,000 domains, accounting for approximately 2% of all queries . As the deployment of PDNS continues to grow, efforts have been made to systematically analyze PDNS services, including deployment status, operational mechanism and security implications. A recent work has revealed that 9% of open recursive resolvers exhibit PDNS behaviors , and finds significant discrepancies among providers in terms of rewriting policies, blocklist selection and performance. Particularly, security risks such as implementation flaws, over- blocking, and dangling resources have been identified. This document is primarily intended for readers familiar with Protective DNS technology and somewhat aware of the potential impacts that deploying such technologies may entail. Moreover, existing documents , are recommended for legal considerations. On this basis, this document focuses on discussing technical considerations at the deployment level.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Background

Overview of Protective DNS

The workflow of Protective DNS. | | | Blocklist | | | | Authoritative | | v | |<--------------| Server | | Resolver | | | +------------------------+ +---------------+ Rewritten | ^ Domain Response v | Query +------------------------+ | Client | +------------------------+ ]]>

Figure 1 shows the workflow of Protective DNS (PDNS). Protective DNS is deployed on a recursive resolver. When the PDNS resolver receives a DNS query for a domain name, it first matches the domain against its maintained blocklist. The resolver then makes a decision based on the blocklist lookup result. If the domain is found in the blocklist, PDNS rewrites the DNS response to resolve the query to a "secure" result (e.g., special-purpose addresses), effectively preventing the client from accessing the corresponding malicious resource. Conversely, if the domain is not in the blocklist, the resolver returns a normal response by querying authoritative servers or using local cache results to respond to the client , . Thus, the two functional components that underpin the critical role of PDNS are the Blocklist and the Rewriting Policy. *Blocklist.* PDNS determines whether to rewrite the resolution result of a domain name based on its presence in the blocklist. Blocklist sources include multiple aspects: commercial threat intelligence (TI), open-source TI, vendor-maintained domain blocklists, and user complaints. The types of malicious domains included in blocklists vary by vendor definition, encompassing but not limited to: malware, botnet command-and-control (C2), phishing, fraud, and adult content. Additionally, PDNS deployments implement blocklist lookup in two primary forms:

1. Local Lookup: storing directly on the PDNS server, allowing direct queries against the local blocklist file.
2. Remote Lookup: performing lookups via network interfaces (e.g., DNSBL ).

*Rewriting Policy.* Upon retrieving blocklist matching results, the PDNS server rewrites resolution responses for domains in the blocklist. rewriting strategies exist in multiple forms. Based on empirical analysis of leading Protective DNS vendors, this document summarizes five specific rewriting policies. 1) Using the secure IP addresses in A record controlled by the provider:

• malicious_domain.com

  A 10 controled_IP;

2) Using IP addresses with special purposes, such as the reserved address like 0.0.0.0, link local address like 192.168.0.1, loopback addresses like 127.0.0.1, and so on:

• malicious_domain.com

  A 10 127.0.0.1;

3) Utilizing the CNAME record to rewrite the request to the domain name controlled by the provider: 4) Using an empty Answer field in the response to prevent users from accessing malicious resources:

Format of empty Answer fileld in Protective DNS.

5) Using special response codes for the reply, such as NXDomain, ServerFail, etc:

Format of NXDomain Response in Protective DNS.

Additionally, primary implementations of the rewriting module include, but are not limited to:

1. DNS Response Policy Zones (RPZ) : Implemented as zone files , , specifying both whether rewriting is required and providing domain-specific rewrite results.
2. Domain Lists: This format consists of one domain per line, specifying only the rewrite requirement for each domain.

Relationship between Other Technologies *Relation ship bewteen PDNS and DNS Blockling.* Protective DNS constitutes a subset of DNS Blocking (generally considered as synonymous with DNS Filtering ), sharing the goal of security defense by leveraging known blocklists (e.g., domain blacklists) to prevent user exposure to malicious resources. DNS Blocking is a broader security concept encompassing any rewriting operations of DNS resolution traffic to restrict access to specific domains. Its applicability spans diverse scenarios and architectural layers, specifically including defense at any DNS resolution role (stub in client, recursive resolver, authoritative server) and other security use scenarios (e.g., spam filtering, gateway firewall protection). In contrast, PDNS represents a specific implementation of DNS Blocking, typically deployed on recursive resolvers. Several prior documents define specific techniques within DNS Blocking:

1. DNS Blacklist (DNSBL): DNSBL represents a DNS-based blacklist lookup technology, serving as a concrete implementation of blocklist lookup within the broader DNS Blocking paradigm (including PDNS). First, it maintains blacklists of IP addresses or domain names associated with malicious activities. Then, it utilizes DNS queries to determine whether to block related traffic.
2. DNS Response Policy Zones (RPZ) : Beyond remote blocklist querying (e.g., DNSBL), local deployment offers another blocklist deployment strategy. RPZ achieves localized blocklist query via a zone file containing rewrite instructions for each malicious domain, often utilized in scenarios such as DNS Firewall. RPZ supports multiple triggering mechanisms. Among these, QNAME triggering is the primary mode adopted by PDNS.

*Relationship between PDNS and Censorship.* While censorship shares the objective with DNS blocking, i.e., preventing end users from accessing specific resources, its blocking strategies are far more diverse. Domain blacklist-based blocking represents just one type of DNS-layer mitigation, alongside techniques such as DNS poisoning. Cross-layer mechanisms at network layers include TCP reset (e.g., sending forged RST packets), IP blocking, HTTPS man-in-the-middle attacks, and Deep Packet Inspection (DPI) for payload analysis. *Relationship between PDNS and Other Domain Protection.* Defense mechanisms at the domain level are diverse, with protective actions occurring across various roles in the domain ecosystem. During the initial domain registration process, registries and registrars can use domain seizure to remove malicious domains from registration data, thereby preventing their continued harm to users. Registries and registrars can also employ sinkhole technology to redirect some malicious domains to domain black holes. The Protective DNS defense mechanism addressed in this document is primarily deployed on recursive resolvers.

Deployment Status Due to the significant protective efficacy of Protective DNS, existing academic efforts have evaluated its deployment status through measurement. The results indicate a growing adoption trend of PDNS across large-scale DNS service providers, operational recursive resolvers in the wild, and national-level deployments. *National Deployment.* First, several countries and regions have even deployed national Protective DNS projects, including:

1. DNS4EU ：Launched in January 2023 under the auspices of the European Union Agency for Cybersecurity (ENISA), this initiative serves as an alternative to prevailing public DNS resolution services. It is designed to deliver protective, privacy-compliant, and resilient DNS capabilities, thereby enhancing the EU's digital sovereignty and security. Any device connected to DNS4EU resolvers that attempts to access a malicious domain (e.g., hosting malware or related to phishing content) is immediately blocked, preventing potential harm. Leveraging real- time threat monitoring and defense mechanisms, the project ensures that malicious domains identified in one EU jurisdiction are countered across multiple member states to contain their spread. DNS4EU provides DNS security assurances to critical sectors including EU citizens, public institutions, government entities, and operators, while also supporting voluntary adoption or opt-out by EU residents. Recently, DNS4EU has also opened public query interfaces accessible to the citizens of the European Union .
2. PDNS in UK ：Supported by the UK's National Cyber Security Centre (NCSC), this initiative advises private enterprises and government agencies to adopt Protective DNS to safeguard their IT assets and network security. By blocking access to known malicious domains, it significantly reduces the effectiveness of ransomware, phishing, botnet, and malware attacks. According to NCSC statistics, in 2022, the project's PDNS service processed 810 billion DNS queries and blocked 11 billion queries involving 420 thousand distinct domains .
3. PDNS in US ：This initiative, launched by the Cybersecurity and Infrastructure Security Agency (CISA) in 2022, is designed to provide security safeguards for the United States' national critical infrastructure. The project protects the federal government by blocking network traffic at the DNS resolution layer from reaching potentially malicious destinations, enhancing resilience against intrusions and attacks. When Protective DNS detects a DNS request matching threat intelligence indicators, the service blocks, redirects, or sinkhole the query response to a secure endpoint, while sending alerts to the source agency and CISA. The initiative mandates the use of this Protective DNS service by all Federal Civil Executive Branch (FCEB) agencies and offers limited availability to infrastructure participants in pilot programs.

*Public DNS Provider.* Existing work, by combining surveys of publicly available documentation from widely adopted DNS service providers with active testing, confirms that two-thirds of public DNS providers already offer Protective DNS services. Notably, practices vary significantly across vendors, including differences in the types of malicious domains defended against and rewrite policies. In terms of deployment strategies, the majority of vendors employ hybrid deployments, providing both Protective DNS and regular DNS resolution on a single resolver IP address, such as Comodo DNS and OpenDNS. A smaller subset deploys Protective DNS and regular DNS resolution on separate resolver IPs, and in some cases, even different resolver servers from the same vendor may defend against distinct types of malicious domains. For example, Cloudflare operates standard DNS services on 1.1.1.1, while PDNS servers on 1.1.1.2 and 1.1.1.3 implement differentiated protection: 1) 1.1.1.2 focuses on malware defense; 2) 1.1.1.3 defends against both malware and adult content. *Open Resolver.* Furthermore, existing studies using active scanning of the IPv4 address space in 2023 confirm that approximately 9% of recursive resolvers have deployed Protective DNS capabilities, covering almost two-thirds of the world's countries. By analyzing the types of malicious domains defended against, research has found that malware, botnet, phishing, and spam are the most common categories, with observable blocklist overlap across different recursive resolution services. In terms of rewrite policies, using safe IP addresses and specialized IP addresses represents the most prevalent rewriting approach.

Operational Considerations Considering that deployment is the first step in using and even maintaining the security of Protective DNS, in this section, we propose a series of operational considerations that cover multiple aspects of deployment practice, including blocklist selection, rewriting strategy construction, performance impact assessment, and explanatory offering

Operational Consideration 1: Blocklist Selection One of the necessary conditions for Protective DNS to achieve its defensive capability is to maintain a blocklist that includes a series of malicious domain names to be blocked. First, when collecting blocklists, PDNS providers should explicitly define the types of domains to be blocked based on the intended use case. Common categories of malicious domains include but are not limited to, malware, botnet, phishing, spam, tracking, and adult content. Providers should then identify appropriate blocklist sources aligned with these requirements, such as self-collected data derived from traffic analysis and user feedback; open-source threat intelligence feeds; and commercial threat intelligence services. Meanwhile, relying solely on limited blacklist sources may restrict the coverage of defensive capabilities. Most importantly, regardless of the source, operators should verify the correctness of these malicious domains to avoid false positives that could impact access to not-in-blocklist domains. Second, PDNS operators should select an appropriate blocklist deployment approach based on operational context, including device resource constraints and network access patterns. Remote querying approaches (e.g., using DNSBL) necessitate proactive consideration of potential privacy implications and the impacts of network instability. Local deployments (e.g., RPZ-formated local zone file) necessitate a thorough assessment of local resource limitations. Specifically, the Blocklist scale deployed on Protective DNS should be carefully defined based on the system's processing capability. Blocklist size directly affects both the response efficiency of Protective DNS and hardware resource consumption (e.g., CPU, memory) on the hosting device.

Operational Consideration 2 - Rewriting Policy Construction Based on empirical analyses of popular Protective DNS providers, five primary rewriting approaches have been identified in practice, see the Section of Overview of Protective DNS. Each rewriting strategy caters to specific security scenarios, requiring providers to select appropriate approaches based on their application requirements, specifically as follows: 1) Secure IP addresses: Under this policy, the rewritten target address is a server controlled by the PDNS provider, enabling PDNS providers to monitor traffic. Specifically, the controlled server acts as a "honeypot" managed by the provider, capturing DNS traffic of malicious domain names for further analysis of threat behaviors (e.g., malware communications). However, this approach incurs operational overhead for PDNS providers, who need to actively monitor the status of these servers. Additionally, this scenario necessitates consideration of privacy risks arising from traffic monitoring, such as the security concerns of user traffic collected for surveillance purposes. 2) Specialized IP addresses: Due to the non-routable nature of these IP addresses on public networks, they are better suited for scenarios with strict privacy protection requirements, such as when users do not want any third parties to track their network behavior. However, PDNS operators should consider potential risks when using these specialized IP addresses. For example: a) 192.168.0.1 is typically used for local area network devices. Such configurations may lead to unintended access to internal network devices if clients mistakenly connect to them; b) 127.0.0.1 is commonly used for local inter- process communication. Redirecting to this address may cause clients to attempt to connect to local services, which could be exploited if vulnerabilities exist—such as through port scanning or service spoofing. This is particularly risky when users mistake local services for external ones, potentially exposing sensitive information or enabling attacks. Additionally, this approach lacks transparency for PDNS users, as they cannot obtain explicit explanations on resolution results (i.e., resolved IPs) similar to secure IP indicators. However, rewriting information can be provided in DNS resolutions—for example, through explanations in extended fields (i.e., EDE ), with detailed content elaborated in Section of Operational Considerations 4. 3) Secure CNAME: This strategy, similar to using controlled IP addresses, enables providers to dynamically monitor traffic. However, providers should remain vigilant against dangling resource record risks arising from improper management, details of which are discussed in Security Considerations. 4) Empty Answer Section: This strategy represents a minimalist rewriting approach, simply returning an empty answer section. However, it undermines the transparency of PDNS services for users and may escalate to more aggressive implementations—such as refusing to return resolution responses— which entail denial-of-response risks detailed in the Security Considerations. 5) Special Response Codes (Rcodes): This strategy is compatible with regular DNS error scenarios, which help prevent malware from detecting the defensive mechanisms of PDNS. However, such practices may also undermine the transparency of Protective DNS services, making it difficult for users to understand the principles behind rewriting operations and to distinguish between defensive rewrites from PDNS and genuine failures. Second, PDNS operators should consider the impact of TTL configurations and appropriately configure the TTL values for rewritten records. On one hand, an overly long TTL may lead to delayed updates of defense strategies for malicious domains. On the other hand, a too-short TTL triggers frequent DNS queries, increasing PDNS server load and potentially degrading performance.

Operational Consideration 3 - Performance Impact As Protective DNS services introduce an additional query step on whether a domain is malicious during standard DNS resolution, operators should anticipate potential impacts on DNS resolution performance. Specifically, factors such as blocklist deployment method (remote vs. local), scale, and domain matching techniques (e.g., hash matching) can affect performance. Experimental results show that loading a blocklist into memory with five million malicious domains can still be maintained within 10-second response times, but exceeding this scale may result in loading times exceeding 10 seconds. Additionally, experimental studies on Public DNS Providers have found that 70% of blocked domains receive PDNS responses within 0.2 seconds. Meanwhile, for providers offering both PDNS and non- PDNS services, the response time difference typically does not exceed 2 ms. Therefore, when implementing PDNS, operational references from public PDNS provider experiments should be addressed—specifically, the impact of blocklist loading and domain matching on query latency.

Operational Consideration 4 - Offering Explanation Protective DNS operates as a complete black-box service for users. Regardless of the rewriting strategy employed, users only perceive the blocking effect—i.e., the inability to access a domain. While providers can refine blocklist quality to minimize false positives, the inevitable presence of false positives significantly degrades user experience. Users may encounter unexplained domain inaccessibility that is indistinguishable from prevalent DNS tampering (e.g., censorship, man-in-the-middle attacks). Therefore, providing explanations for Protective DNS services can enhance user experience and alleviate privacy concerns. Operators should anticipate that omitted explanations may lead users to misperceive service instability or even switch to competing DNS providers. This explanation of PDNS can be realized through multiple approaches. First, to indicate that blocking originates from Protective DNS, service providers may offer a dedicated landing page to explain their protective services, helping users confirm that the observed DNS rewriting originates from the provider’s Protective DNS. Empirical analyses show some PDNS providers redirect DNS queries to a secure IP address hosting a page that notifies users of potential malicious website access. However, using a provider-controlled IP introduces risks of dangling resource takeover, detailed in Security Consideration. Second, the EDE (Extended DNS Error) , protocol can be employed to specify in the extension fields that rewriting results from Protective DNS defense against malicious domains. Existing work has shown that some PDNS implementations already utilize the EDE field for indication—for example, using "PROHIBITED", as illustrated in Figure 4.

Example of EDE usage in Protective DNS.

Moreover, providing user appeal channels on explanation pages, such as an email address, could mitigate negative impacts of potential false positives.

Security Considerations Furthermore, by integrating the operational considerations, we propose security considerations to enhance the security of Protective DNS on the basis of improving its practicality. We outline specific considerations covering multiple dimensions. For each factor, we provide specific recommended mitigations, including rewriting policy flaws, over-blocking, dangling resource risks, interaction with data integrity protection and fallbacks.

Security Consideration 1 - Rewriting Policy Flaws To prevent flaws in the protection function or even bypassing, service providers should consider the following three aspects. *Redundant Rdata.* According to measurements of Protective DNS services, the configurations of Rdata in rewritten records by some providers have defects. Specifically, along with the rewritten records, several PDNS providers may also include the original malicious records in the DNS response. For local stub resolvers of users, the selection of the resolution result is uncontrollable, and users still have a high probability of accessing malicious resources. Therefore, Protective DNS providers should avoid such redundant configurations to ensure the completeness of the defense effectiveness. $ORIGIN malicious_domain.com malicious_domain.com A controled_IP; malicious_domain.com A original_malicious_IP; *Missing Record type.* While A records are the most common type of DNS resolution and are often the primary focus of defensive configuration by service providers—since they directly point users to malicious resources—empirical measurements have revealed that some Protective DNS providers fail to protect less common query types, such as TXT records. In these cases, the provider may return original responses, potentially exposing users to hidden threats. This oversight could be exploited to bypass PDNS protections, particularly when malicious domains embed harmful instructions within less scrutinized record types. Therefore, PDNS providers should proactively consider the potential impacts of missing record type configurations. $ORIGIN malicious_domain.com malicious_domain.com A controled_IP; malicious_domain.com CNAME controled_domain; *Policy Coverage.* In addition to the defensive configuration of the response results, Protective DNS providers should ensure that the defensive functions are effective in all functional scenario. Specifically, encrypted DNS should also have the same defensive effect as non-encrypted DNS, to prevent malicious domain names from bypassing the defense by merely using encrypted DNS. Additionally, IPv6 scenarios should also be considered.

Security Consideration 2 - Dangling Resources Some Protective DNS providers use self-controlled domains or IPs as rewriting strategies. However, mismanagement of these rewritten resources may lead to takeover risks from Dangling Resources, specifically:

1. If the rewritten IP is a cloud service IP, obsolete cloud IP addresses pose a takeover risk.
2. If the rewritten CNAME domain expires, there is an expired domain takeover risk.
3. If the rewritten CNAME domain belongs to a third-party service, subdomain takeover risks may arise.

Upon gaining control of vulnerable rewritten resources (e.g., those at risk of expiration), attackers can trigger DNS queries for malicious domains to the compromised Protective DNS server via phishing tactics. They can then return modified malicious content to victims, enabling connections between victims and attacker servers. Therefore, Protective DNS service providers should exercise due diligence when using third-party network resources. On one hand, they should consider the financial and management costs of regular maintenance of these resources. On the other hand, they need to periodically verify the status of these third-party services to avoid dangling resource risks.

Security Consideration 3 - Over-Blocking Protective DNS rewriting should minimize the impact of over-blocking, as this introduces significant collateral damage in two primary aspects. *Blocklist Construction.* First, Protective DNS service providers should avoid errors in blocklists, as blocklist errors directly cause collateral damage to benign domain names. Second, over-generalizing target domains for blocking in Protective DNS may also lead to collateral damage. Using keywords as blocklist entries exacerbates the likelihood of false positives, causing unintended blocking of benign domains and degrading PDNS availability. Employing wildcard domains in blocklists similarly introduces false positives. Meanwhile, blocking at the second-level domain (SLD) or top-level domain (TLD) levels can also trigger false positives—for example, cloud services often host user-specific services on subdomains, so blocking the apex domain of such a cloud service would impact numerous unrelated services. Thus, blocking at the fully qualified domain names (FQDNs) could minimize collateral damage. Finally, providers should promptly update blocklists to avoid false positives from delayed updates. $ORIGIN malicious_domain.com malicious_domain.com A controled_IP; (FQDN) "phishing" in domain A controled_IP; (Keyword) *.malicious_domain.com A controled_IP; (Wildcard Domain) *.com A controled_IP; (SLD/TLD Level Domain) *Blocking Policy.* The primary defense objective of Protective DNS is to prevent users from accessing any malicious resources, i.e., intercepting as many malicious domains as possible. However, empirical analysis has shown that some Protective DNS implementations exhibit over-blocking collateral damage from aggressive blocking. Measurements reveal that certain Protective DNS services apply extreme defensive strategies to queries for one or more malicious domains, temporarily blocking all domain resolution for the client—including legitimate domains. This introduces denial-of- response (DoR) risks, as attackers can exploit this behavior to impose DoR attacks on arbitrary victims. Specifically, sending a set of malicious domain queries with spoofed source IP addresses can force the victim’s client to lose all DNS resolution capabilities, effectively executing a denial-of-service attack. Therefore, PDNS service providers should exercise caution when implementing aggressive defensive strategies and consider the potential impact of such approaches in advance. Meanwhile, Protective DNS providers should preconfigure defense mechanisms against potential denial-of-resolution (DoR) risks. Specifically, when a client initiates a large volume of DNS queries exceeding a defined threshold for malicious domains to a Protective DNS server, providers should evaluate the impact of directly blocking all DNS query responses from the client for a period of time. To effectively mitigate denial-of-response attacks, providers can send oversized DNS responses to enforce TCP fallback, thereby thwarting DoR attacks constructed via IP spoofing. Most critically, operators should strive to avoid controversial blocklist formats to minimize the impact of potential false positives. First, PDNS should refrain from using keywords as Blocklist entries, as this exacerbates the likelihood of introducing false positives and undermines PDNS availability. Second, PDNS providers should avoid using wildcard domains in Blocklists, as such practices may also lead to false positives. To maximize the mitigation of false positives, mitigation at the minimum subdomain granularity (i.e., FQDN) may minimize collateral damage.

Security Consideration 4 - Interaction with data integrity protection For blocked domains, Protective DNS rewrites data in the DNS responses and breaks their data integrity by design. Particularly, when domains are DNSSEC-signed, PDNS will not be able to return validated responses for blocked query names and MUST NOT set the AD bit when this occurs . For clients that have DO bit or CD bit set in DNS queries, meaning they wish to receive DNSSEC RRs in response messages , PDNS will not be able to provide DNSSEC RRs when the query names are blocked, because no actual queries are sent to authoritative servers. In such cases, error messages (e.g., via EDE ) is recommended in responses for diagnosing purposes.

Security Consideration 5 - Fallback As Protective DNS introduces new components, such as blocklists, service providers should consider fault diagnosis for denial-of- service (DoS) failures in individual components and corresponding fallback mechanisms to ensure performance stability. For example, in scenarios involving remote blocklist queries, providers should proactively diagnose the availability of remote blocklist interfaces on a regular basis. If remote blocklist query services become unavailable due to network issues or other causes, and no fallback mechanism is in place, this may render the provider’s DNS query services inoperable. Thus, providers should predefine fallback mechanisms—such as reverting to normal DNS resolution procedures.

IANA Considerations This document has no IANA actions.

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them. This document is not an Internet Standards Track specification; it is published for informational purposes. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. Farsight Security Rhyolite Software This document describes a method for expressing DNS response policy inside a specially constructed DNS zone, and for recursive name servers to use such policy to return modified results to DNS clients. The modified DNS results can stop access to selected HTTP servers, redirect users to "walled gardens", block objectionable email, and otherwise defend against attack. These "DNS Firewalls" are widely used in fighting Internet crime and abuse. Citrix Systems, Inc. Nokia Open-Xchange Orange DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. Informative References

Acknowledgments TODO acknowledge.