Dear Mingxuan Liu and DNSOP colleagues,
Thank you for sharing /draft-liu-dnsop-protective-dns/. The draft
addresses a very relevant topic, and I appreciate the effort to frame
Protective DNS operational guidance in a structured way.
I’d like to offer feedback on the phrase in Section 3.2:
/“maintain a blocklist that includes a series of malicious domain
names to be blocked.”///
As someone operating a Protective DNS service in Latin America, I would
like to highlight that this wording may significantly oversimplify the
practical and regulatory realities of Protective DNS deployments.
1.Multiple Sources, Not a Single Blocklist
PDNS operators typically rely on a combination of threat intelligence
feeds, government-mandated lists, internal telemetry, and
customer-defined filters. These inputs vary widely by region, vertical,
and operational goal.
2.Beyond “Malicious” Domains
Not all blocked domains are “malicious” in a cybersecurity sense. PDNS
is often used to enforce:
*
Content controls (e.g. adult sites, gambling, piracy)
*
Privacy-enhancing policies (blocking trackers, advertising networks)
*
Educational and family-safe modes that filter even benign but
inappropriate content
*
Corporate policies that prevent data leaks or unauthorized services
*
Infrastructure-based rules, such as blocking domains that:
o
Are resolved by suspicious or unauthorized upstream DNS servers
o
Resolve to IP address ranges known to host malware, proxies,
bulletproof hosting, or other undesired infrastructure
These use cases are common in Latin America, where local laws or
customer demands may prioritize child protection, data privacy,
copyright enforcement (e.g., unauthorized streaming or sports events),
and compliance with telecom and media regulators.
3.Different Blocking Techniques
Blocking can mean many things:
*
Returning NXDOMAIN
*
Serving a redirect to an explanatory landing page
*
Issuing REFUSEDor custom DNS answers
*
Logging with notification for internal policy violations
The blocking behavior itself often depends on jurisdictional rules or
user transparency requirements.
------------------------------------------------------------------------
Suggested Alternative Text
“Maintain one or more policy-driven domain lists derived from threat
intelligence, regulatory sources, and organizational policy. These may
include domains associated with security threats, inappropriate content,
privacy risks, or policy violations. Blocking behavior may vary by
context, including NXDOMAIN synthesis, redirection, or other response
modes aligned with regulatory and operational requirements.”
I hope this comment is helpful in refining the draft to reflect the
diverse real-world applications of Protective DNS.
Best regards,
Carlos Horowicz
CTO, Planisys
Protective DNS Operator – Latin America
[email protected]
On 24/07/2025 04:56, 刘明烜 wrote:
*Dear Experts of the DNSOP Working Group,*
I hope this email finds you well.
I am Mingxuan Liu, an Assistant Researcher at Zhongguancun Laboratory.
Recently, we have submitted a new standards draft on Protective DNS,
titled "Considerations for Protective DNS Server Operators".
The draft is available at the following link:
https://datatracker.ietf.org/doc/draft-liu-dnsop-protective-dns/
<https://datatracker.ietf.org/doc/draft-liu-dnsop-protective-dns/>
To provide some context:
Protective DNS is a defensive mechanism deployed on recursive
resolvers, designed to effectively block access to malicious domains.
For domains listed on blacklists, Protective DNS rewrites DNS
resolution responses to point to secure results (e.g., controlled
security servers), thereby preventing users from accessing malicious
resources.
Given its effectiveness in mitigating common cyber threats (such as
command-and-control communications of malware), the deployment of
Protective DNS has been on the rise. It is now adopted not only by DNS
service providers but also implemented nationwide in some countries.
However, recent research has identified discrepancies in current
Protective DNS implementations. This document aims to outline specific
operational and security considerations for Protective DNS, targeting
entities providers to deploy it for defensive purposes by offering
guidance on deployment and security best practices.
We would greatly appreciate the opportunity to discuss this draft with
each expert, with the goal of providing valuable references for the
deployment and security of Protective DNS.
Your comments and insights are most welcome, and we look forward to
engaging in constructive discussions with you.
Best regards,
Mingxuan Liu
Zhongguancun Laboratory
Email: [email protected]
July 24, 2025
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
