SAC 127 and DNS abuse
Hi all, Anyone who is following the issue of DNS Abuse, which we have been discussing here, would be well advised to have a look at SSAC 127 <https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> issued last year, on the top of "DNS Blocking Revisited". This one one of the few ICANN documents of which I am aware that deals with personal-level blocking as a way to mitigate abuse as well as state- and infrastructure-level blocking. It spends a useful amount of effort on how end users can implement their own personal "blocking" through VPNs and "Public Resolvers": * Users are aware of the benefits of public DNS resolvers and have been
reconfiguring their systems to leverage these services. This shift has been fueled by a growing understanding of the potential privacy and performance advantages that public resolvers offer over default DNS configurations, and in response to cases of state censorship and the abuse of DNS services offered by ISPs.*
This, to me, offers a rationale on how educating the public - and indeed the broader ICANN community -- about such facilities is directly relevant to ICANN's mission and At-Large's role within it. I note with curiosity the complete lack of mention of one of the main reasons end-users are implementing such services: the blocking of advertising and tracking sites. To many people, myself included, the use of digital fingerprinting and tracking of personal details across different websites is as abusive as phishing and almost as abusive as malware sites. While mention is made of Cloudflare and Canadian Shield, the report completely ignores services such as Control D, Adguard DNS and NextDNS which block ads and trackers as well as more-malicious sites. For some blocking ads is a significant way to speed web-page rendering. And while some may debate the ethics of ad blocking, I am not aware of any jurisdiction in which doing so is illegal. While it speaks of the use of the DNS to block pornography and gambling sites, as well as in-browser checks against malicious sites, oddly SSAC 127 ignores one of the main reasons people search for alternative DNS servers. But except for that notable error of omission, and is a worthwhile read for anyone who cares about what end-users (the ALAC constituency) can do to mitigate DNS abuse ... that is, considering that what constitutes "abuse" is not rigid and many approaches are available. -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Hi Evan, Thank you for bringing SSAC 127 to our attention and for your sharp critique of its omissions. I completely agree that the report is valuable for focusing on *personal-level blocking* through VPNs and Public Resolvers, and that this is directly relevant to At-Large's mission of educating the end-user public. More importantly, your point on the exclusion of *ad and tracker blocking* is crucial. As you noted, the use of digital fingerprinting and tracking is considered "as abusive as phishing" by many. Ignoring services like Control D, Adguard DNS, and NextDNS, which address this, makes the report significantly less comprehensive from an end-user perspective. Perhaps our community can use this report as a starting point to develop our own educational materials—like the DNS abuse guide project already underway—that specifically address the full range of end-user DNS tools, including those used to mitigate tracking and other non-malware forms of abuse. Best regards, Mohibul Mahmud NARALO Member | NARALO ALAC Candidate On Thu, Apr 30, 2026 at 6:40 PM Evan Leibovitch via NA-Discuss < na-discuss@icann.org> wrote:
Hi all,
Anyone who is following the issue of DNS Abuse, which we have been discussing here, would be well advised to have a look at SSAC 127 <https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> issued last year, on the top of "DNS Blocking Revisited".
This one one of the few ICANN documents of which I am aware that deals with personal-level blocking as a way to mitigate abuse as well as state- and infrastructure-level blocking.
It spends a useful amount of effort on how end users can implement their own personal "blocking" through VPNs and "Public Resolvers":
* Users are aware of the benefits of public DNS resolvers and have been
reconfiguring their systems to leverage these services. This shift has been fueled by a growing understanding of the potential privacy and performance advantages that public resolvers offer over default DNS configurations, and in response to cases of state censorship and the abuse of DNS services offered by ISPs.*
This, to me, offers a rationale on how educating the public - and indeed the broader ICANN community -- about such facilities is directly relevant to ICANN's mission and At-Large's role within it.
I note with curiosity the complete lack of mention of one of the main reasons end-users are implementing such services: the blocking of advertising and tracking sites. To many people, myself included, the use of digital fingerprinting and tracking of personal details across different websites is as abusive as phishing and almost as abusive as malware sites. While mention is made of Cloudflare and Canadian Shield, the report completely ignores services such as Control D, Adguard DNS and NextDNS which block ads and trackers as well as more-malicious sites. For some blocking ads is a significant way to speed web-page rendering. And while some may debate the ethics of ad blocking, I am not aware of any jurisdiction in which doing so is illegal.
While it speaks of the use of the DNS to block pornography and gambling sites, as well as in-browser checks against malicious sites, oddly SSAC 127 ignores one of the main reasons people search for alternative DNS servers. But except for that notable error of omission, and is a worthwhile read for anyone who cares about what end-users (the ALAC constituency) can do to mitigate DNS abuse ... that is, considering that what constitutes "abuse" is not rigid and many approaches are available. -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 ------ NA-Discuss mailing list -- na-discuss@icann.org To unsubscribe send an email to na-discuss-leave@icann.org
Visit the NARALO online at http://www.naralo.org ------ _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Evan, Thanks for bringing up SAC127. I've added it to our fresh collection of DNS Abuse mitigation general resources <https://docs.google.com/document/d/1smchQvYap04IMu7BCiAj6TWEhhxFE7wqayI8CyYd...> . Incidentally, there is an upcoming webinar on 13 May, regarding implementing DNS blocking and SAC127, that may interest you. Assuming you hadn't been aware of it, of course. ICANN OCTO ISPCP/SSAC: Implementing DNS Blocking Responsibly Blocking domains that are maliciously used can protect users, but it raises
questions about accuracy, due process, and unintended collateral effects. On 13 May at 16:00 UTC, don't miss our session on implementing #DNS <https://www.facebook.com/hashtag/dns?__eep__=6&__cft__[0]=AZY9lp6xqQ3PO_AH00l-Gq83TBt43t8CcnGuqVBpjt1IFxhXUDZ0PMdhSiaAfCcKMkHlnfXnnLfZeswTn2EbgoSzcuZZtV_QzcYENqDDamT0jSD_Xh75QSFUX5Bn0EwAk8h57x-w_pmteekUV1XjvntXDuI0YvvbRUzSDLC8RzVO1n_e9m0e9MM8uwNhwp363eA&__tn__=*NK-R> blocking responsibly, featuring insights from SSAC’s latest document on this topic (SAC127). Register here >> https://bit.ly/4carPQk
Kind regards, Justine On Fri, 1 May 2026 at 06:38, Evan Leibovitch via ALAC <alac@icann.org> wrote:
Hi all,
Anyone who is following the issue of DNS Abuse, which we have been discussing here, would be well advised to have a look at SSAC 127 <https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> issued last year, on the top of "DNS Blocking Revisited".
This one one of the few ICANN documents of which I am aware that deals with personal-level blocking as a way to mitigate abuse as well as state- and infrastructure-level blocking.
It spends a useful amount of effort on how end users can implement their own personal "blocking" through VPNs and "Public Resolvers":
* Users are aware of the benefits of public DNS resolvers and have been
reconfiguring their systems to leverage these services. This shift has been fueled by a growing understanding of the potential privacy and performance advantages that public resolvers offer over default DNS configurations, and in response to cases of state censorship and the abuse of DNS services offered by ISPs.*
This, to me, offers a rationale on how educating the public - and indeed the broader ICANN community -- about such facilities is directly relevant to ICANN's mission and At-Large's role within it.
I note with curiosity the complete lack of mention of one of the main reasons end-users are implementing such services: the blocking of advertising and tracking sites. To many people, myself included, the use of digital fingerprinting and tracking of personal details across different websites is as abusive as phishing and almost as abusive as malware sites. While mention is made of Cloudflare and Canadian Shield, the report completely ignores services such as Control D, Adguard DNS and NextDNS which block ads and trackers as well as more-malicious sites. For some blocking ads is a significant way to speed web-page rendering. And while some may debate the ethics of ad blocking, I am not aware of any jurisdiction in which doing so is illegal.
While it speaks of the use of the DNS to block pornography and gambling sites, as well as in-browser checks against malicious sites, oddly SSAC 127 ignores one of the main reasons people search for alternative DNS servers. But except for that notable error of omission, and is a worthwhile read for anyone who cares about what end-users (the ALAC constituency) can do to mitigate DNS abuse ... that is, considering that what constitutes "abuse" is not rigid and many approaches are available. -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 _______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Evan, Thank you for initiating this conversation and identifying a specific ICANN document on DNS abuse which directly affects End Users. I acknowledge and support your assertion that educating the public, and the broader ICANN community, about important End User policy content found in specific ICANN artifacts is directly relevant to ICANN's mission and At-Large's role within it. Going beyond Evan's initial email contribution, I wish to thank Mohibul for identifying a need to capture this educational content, and Justine for finding an At-Large document home which captures Evan's initial email contribution about important ICANN Policy content that affects End Users. This email thread shows the value of team collaboration in policy development that I see in the At-Large community. If I explore the specific dimension of "education" a bit further when considering future policy discussions, I'd be curious to see how "education" of End Users and the broader ICANN community might align with Avri's recent presentation on the ICANN's responsibility to the Global Public Interest <https://icann-community.atlassian.net/wiki/spaces/prjxplrpublicint/overview?...>. I have not yet done this work, but I hope that Evan's assertion that some ICANN & At-Large policy work involves an educational component would under the umbrella of Avri's work to define an ICANN Global Public Interest domain of thought. Taking one step higher, I'd like to note that Article 26 of the 1948 UN Declaration of Human Rights <https://www.un.org/en/about-us/universal-declaration-of-human-rights>contains the phrase "Everyone has the right to education". I believe, although ICANN's bylaws (Article 1, Section 1.2, b Core Values, viii ...respecting international human rights... <https://www.icann.org/ar/governance/bylaws#article1> )may limit ICANN's responsibility, it would be good for the At-Large community to consider the Human Right to Education when performing important ICANN policy work. Indeed, if you dig into the weeds of ICANN's bylaws again, specifically looking at the part that describes the role of the At-Large Advisory Committee (Article 12, Section 12.2, d, X, E <https://www.icann.org/ar/governance/bylaws#article12>), you will find the following statement on activities that the ALAC and RALO are responsible for ... "*Developing and maintaining on-going information and education programs, regarding ICANN and its work;*" As Bill Jouris noted in another thread, much caution is warranted when we consider how to use ICANN's and At-Large's limited resources to be directed towards the domain of policy education. Hopefully, we can agree that "education" is within the scope of our responsibilities, and direct attention to how this can be done, rather than does "education" belong as part of our collective work. Great email thread! I look forward to more cogent conversations on End User DNS policy from this group in the future. :-) Cheers! David On Fri, May 1, 2026 at 7:28 AM Justine Chew via NA-Discuss < na-discuss@icann.org> wrote:
Hi Evan,
Thanks for bringing up SAC127. I've added it to our fresh collection of DNS Abuse mitigation general resources <https://docs.google.com/document/d/1smchQvYap04IMu7BCiAj6TWEhhxFE7wqayI8CyYd...> .
Incidentally, there is an upcoming webinar on 13 May, regarding implementing DNS blocking and SAC127, that may interest you. Assuming you hadn't been aware of it, of course.
ICANN OCTO ISPCP/SSAC: Implementing DNS Blocking Responsibly
Blocking domains that are maliciously used can protect users, but it
raises questions about accuracy, due process, and unintended collateral effects. On 13 May at 16:00 UTC, don't miss our session on implementing #DNS <https://www.facebook.com/hashtag/dns?__eep__=6&__cft__[0]=AZY9lp6xqQ3PO_AH00l-Gq83TBt43t8CcnGuqVBpjt1IFxhXUDZ0PMdhSiaAfCcKMkHlnfXnnLfZeswTn2EbgoSzcuZZtV_QzcYENqDDamT0jSD_Xh75QSFUX5Bn0EwAk8h57x-w_pmteekUV1XjvntXDuI0YvvbRUzSDLC8RzVO1n_e9m0e9MM8uwNhwp363eA&__tn__=*NK-R> blocking responsibly, featuring insights from SSAC’s latest document on this topic (SAC127). Register here >> https://bit.ly/4carPQk
Kind regards, Justine
On Fri, 1 May 2026 at 06:38, Evan Leibovitch via ALAC <alac@icann.org> wrote:
Hi all,
Anyone who is following the issue of DNS Abuse, which we have been discussing here, would be well advised to have a look at SSAC 127 <https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> issued last year, on the top of "DNS Blocking Revisited".
This one one of the few ICANN documents of which I am aware that deals with personal-level blocking as a way to mitigate abuse as well as state- and infrastructure-level blocking.
It spends a useful amount of effort on how end users can implement their own personal "blocking" through VPNs and "Public Resolvers":
* Users are aware of the benefits of public DNS resolvers and have been
reconfiguring their systems to leverage these services. This shift has been fueled by a growing understanding of the potential privacy and performance advantages that public resolvers offer over default DNS configurations, and in response to cases of state censorship and the abuse of DNS services offered by ISPs.*
This, to me, offers a rationale on how educating the public - and indeed the broader ICANN community -- about such facilities is directly relevant to ICANN's mission and At-Large's role within it.
I note with curiosity the complete lack of mention of one of the main reasons end-users are implementing such services: the blocking of advertising and tracking sites. To many people, myself included, the use of digital fingerprinting and tracking of personal details across different websites is as abusive as phishing and almost as abusive as malware sites. While mention is made of Cloudflare and Canadian Shield, the report completely ignores services such as Control D, Adguard DNS and NextDNS which block ads and trackers as well as more-malicious sites. For some blocking ads is a significant way to speed web-page rendering. And while some may debate the ethics of ad blocking, I am not aware of any jurisdiction in which doing so is illegal.
While it speaks of the use of the DNS to block pornography and gambling sites, as well as in-browser checks against malicious sites, oddly SSAC 127 ignores one of the main reasons people search for alternative DNS servers. But except for that notable error of omission, and is a worthwhile read for anyone who cares about what end-users (the ALAC constituency) can do to mitigate DNS abuse ... that is, considering that what constitutes "abuse" is not rigid and many approaches are available. -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 _______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
------ NA-Discuss mailing list -- na-discuss@icann.org To unsubscribe send an email to na-discuss-leave@icann.org
Visit the NARALO online at http://www.naralo.org ------ _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi David, Thank you for your response and for recognizing the value of the discussion. I particularly appreciate you expanding on the community's mandate for end-user education by referencing the ICANN bylaws and the UN Declaration of Human Rights. Your points firmly establish that policy education is a core responsibility for At-Large and the RALOs. My suggestion to use SSAC 127 as a foundation for developing new educational content—like the DNS abuse guide already underway—was indeed intended as a practical step toward identifying *how* we can execute this mandate. I agree with your observation that this thread showcases the "value of team collaboration", with Justine Chew already adding the document to the community's general resources. I look forward to continuing this work and focusing our collective attention on how we can most effectively deliver on our educational responsibilities. Cheers, Mohibul Mahmud NARALO Member | NARALO ALAC Candidate On Fri, May 1, 2026 at 10:35 AM David Mackey via NA-Discuss < na-discuss@icann.org> wrote:
Evan, Thank you for initiating this conversation and identifying a specific ICANN document on DNS abuse which directly affects End Users.
I acknowledge and support your assertion that educating the public, and the broader ICANN community, about important End User policy content found in specific ICANN artifacts is directly relevant to ICANN's mission and At-Large's role within it.
Going beyond Evan's initial email contribution, I wish to thank Mohibul for identifying a need to capture this educational content, and Justine for finding an At-Large document home which captures Evan's initial email contribution about important ICANN Policy content that affects End Users. This email thread shows the value of team collaboration in policy development that I see in the At-Large community.
If I explore the specific dimension of "education" a bit further when considering future policy discussions, I'd be curious to see how "education" of End Users and the broader ICANN community might align with Avri's recent presentation on the ICANN's responsibility to the Global Public Interest <https://icann-community.atlassian.net/wiki/spaces/prjxplrpublicint/overview?...>. I have not yet done this work, but I hope that Evan's assertion that some ICANN & At-Large policy work involves an educational component would under the umbrella of Avri's work to define an ICANN Global Public Interest domain of thought.
Taking one step higher, I'd like to note that Article 26 of the 1948 UN Declaration of Human Rights <https://www.un.org/en/about-us/universal-declaration-of-human-rights>contains the phrase "Everyone has the right to education". I believe, although ICANN's bylaws (Article 1, Section 1.2, b Core Values, viii ...respecting international human rights... <https://www.icann.org/ar/governance/bylaws#article1> )may limit ICANN's responsibility, it would be good for the At-Large community to consider the Human Right to Education when performing important ICANN policy work.
Indeed, if you dig into the weeds of ICANN's bylaws again, specifically looking at the part that describes the role of the At-Large Advisory Committee (Article 12, Section 12.2, d, X, E <https://www.icann.org/ar/governance/bylaws#article12>), you will find the following statement on activities that the ALAC and RALO are responsible for ... "*Developing and maintaining on-going information and education programs, regarding ICANN and its work;*"
As Bill Jouris noted in another thread, much caution is warranted when we consider how to use ICANN's and At-Large's limited resources to be directed towards the domain of policy education. Hopefully, we can agree that "education" is within the scope of our responsibilities, and direct attention to how this can be done, rather than does "education" belong as part of our collective work.
Great email thread! I look forward to more cogent conversations on End User DNS policy from this group in the future. :-)
Cheers! David
On Fri, May 1, 2026 at 7:28 AM Justine Chew via NA-Discuss < na-discuss@icann.org> wrote:
Hi Evan,
Thanks for bringing up SAC127. I've added it to our fresh collection of DNS Abuse mitigation general resources <https://docs.google.com/document/d/1smchQvYap04IMu7BCiAj6TWEhhxFE7wqayI8CyYd...> .
Incidentally, there is an upcoming webinar on 13 May, regarding implementing DNS blocking and SAC127, that may interest you. Assuming you hadn't been aware of it, of course.
ICANN OCTO ISPCP/SSAC: Implementing DNS Blocking Responsibly
Blocking domains that are maliciously used can protect users, but it
raises questions about accuracy, due process, and unintended collateral effects. On 13 May at 16:00 UTC, don't miss our session on implementing #DNS <https://www.facebook.com/hashtag/dns?__eep__=6&__cft__[0]=AZY9lp6xqQ3PO_AH00l-Gq83TBt43t8CcnGuqVBpjt1IFxhXUDZ0PMdhSiaAfCcKMkHlnfXnnLfZeswTn2EbgoSzcuZZtV_QzcYENqDDamT0jSD_Xh75QSFUX5Bn0EwAk8h57x-w_pmteekUV1XjvntXDuI0YvvbRUzSDLC8RzVO1n_e9m0e9MM8uwNhwp363eA&__tn__=*NK-R> blocking responsibly, featuring insights from SSAC’s latest document on this topic (SAC127). Register here >> https://bit.ly/4carPQk
Kind regards, Justine
On Fri, 1 May 2026 at 06:38, Evan Leibovitch via ALAC <alac@icann.org> wrote:
Hi all,
Anyone who is following the issue of DNS Abuse, which we have been discussing here, would be well advised to have a look at SSAC 127 <https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> issued last year, on the top of "DNS Blocking Revisited".
This one one of the few ICANN documents of which I am aware that deals with personal-level blocking as a way to mitigate abuse as well as state- and infrastructure-level blocking.
It spends a useful amount of effort on how end users can implement their own personal "blocking" through VPNs and "Public Resolvers":
* Users are aware of the benefits of public DNS resolvers and have been
reconfiguring their systems to leverage these services. This shift has been fueled by a growing understanding of the potential privacy and performance advantages that public resolvers offer over default DNS configurations, and in response to cases of state censorship and the abuse of DNS services offered by ISPs.*
This, to me, offers a rationale on how educating the public - and indeed the broader ICANN community -- about such facilities is directly relevant to ICANN's mission and At-Large's role within it.
I note with curiosity the complete lack of mention of one of the main reasons end-users are implementing such services: the blocking of advertising and tracking sites. To many people, myself included, the use of digital fingerprinting and tracking of personal details across different websites is as abusive as phishing and almost as abusive as malware sites. While mention is made of Cloudflare and Canadian Shield, the report completely ignores services such as Control D, Adguard DNS and NextDNS which block ads and trackers as well as more-malicious sites. For some blocking ads is a significant way to speed web-page rendering. And while some may debate the ethics of ad blocking, I am not aware of any jurisdiction in which doing so is illegal.
While it speaks of the use of the DNS to block pornography and gambling sites, as well as in-browser checks against malicious sites, oddly SSAC 127 ignores one of the main reasons people search for alternative DNS servers. But except for that notable error of omission, and is a worthwhile read for anyone who cares about what end-users (the ALAC constituency) can do to mitigate DNS abuse ... that is, considering that what constitutes "abuse" is not rigid and many approaches are available. -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 _______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
------ NA-Discuss mailing list -- na-discuss@icann.org To unsubscribe send an email to na-discuss-leave@icann.org
Visit the NARALO online at http://www.naralo.org ------ _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
------ NA-Discuss mailing list -- na-discuss@icann.org To unsubscribe send an email to na-discuss-leave@icann.org
Visit the NARALO online at http://www.naralo.org ------ _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Matthias, David, and all, Thank you, Matthias, for sharing this crucial summary of SAC127. It provides the necessary technical foundation for the important policy discussion underway. This detailed summary of *What Is DNS Blocking* and the *Potential Side Effects* is exactly the "educational content" David Mackey identified that we need to capture to fulfill our mandate. It clarifies *what* end-users need to know and *why* it matters. To move from discussion to execution, I propose that we use the three SSAC Recommendations detailed in your summary as the key learning objectives for the DNS abuse educational guide that Justine is compiling. This ensures our materials are technically accurate and policy-aligned from the outset. I look forward to starting that work. Cheers, Mohibul Mahmud NARALO Member | NARALO ALAC Candidate On Fri, May 1, 2026 at 10:53 AM Matthias M. Hudobnik via NA-Discuss < na-discuss@icann.org> wrote:
Dear all, below is a short summary I posted when the SSAC published its advice.
Have a nice one! Best, Matthias __________________________ Ing. Mag. Matthias M. Hudobnik FIP, CIPP/E, CIPT, DPO, CIS LA matthias@hudobnik.at http://www.hudobnik.at @mhudobnik
Hi colleagues, the SSAC has published SAC127.
*### SSAC has published SAC127: DNS Blocking Revisited:*
*What Is DNS and DNS Blocking?*
· The *Domain Name System (DNS)* translates human-readable domain names (e.g., example.com) into IP addresses that computers use to communicate.
· *DNS blocking* is a technique to *restrict access to online content* by interfering with DNS queries. This can involve:
o Pretending a domain doesn't exist.
o Providing false IP addresses.
*Why DNS Blocking Is Used*
· Often implemented because it’s *technically simple and low-cost* .
· Commonly used by *governments* *and organizations* for:
o *Public safety* (e.g., blocking illegal content).
o *Censorship* or regulation of online resources.
*How DNS Blocking Works*
· By altering the behavior of *recursive resolvers*(DNS servers that respond to user queries).
· DNS blocking modifies the translation of a domain name into an IP address, effectively preventing access via DNS.
*Effectiveness and Limitations*
· Blocking only works if users *rely on the DNS infrastructure* where the block is applied.
· It can be *bypassed* through:
o Alternative DNS resolvers.
o VPNs or other routing methods.
· Important: DNS blocking does *not remove the content*—only access through DNS is affected.
*Potential Side Effects*
· *Collateral damage:* Can impact unrelated services or domains.
· *Cross-border effects:* May unintentionally affect users outside the blocking jurisdiction.
· *User confusion:* May appear as a technical error, leading to risky behavior.
· *Legal ambiguity:* Laws vary; determining whether DNS blocking is lawful or constitutes censorship depends on local context.
*SSAC Recommendations*
*Recommendation 1*
· Any entity implementing DNS blocking should fully understand its technical and policy implications.
*Recommendation 2*
· Entities implementing DNS blocki ng (governments, ISPs, organizations) should follow these principles:
o *A. Clear Objectives:* Ensure DNS blocking aligns with intended goals.
o *B. Defined Policy:* Maintain transparent, reviewed processes for deciding what to bl ock.
o *C. Minimize Damage:* Use methods that avoid overblocking or harming unrelated users. < p class="MsoListParagraphCxSpLast" style="margin: 0cm 0cm 8pt 72pt; line-height: 15.4px; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -18pt;">o *D. Respect Boundaries:* Do not affect users or networks outside your administrative control.
*Recommendation 3*
· &n bsp; Recursive DNS server operators should use Extended DNS Error (EDE) codes to inform users when DNS blocking is active and aid troubleshooting.
This report *updates previous SSAC advisories* (SAC050 and SAC056 from 2011–2012) to reflect changes in technology and growing use cases for DNS blocking.
Link to the report: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee... <https://itp.cdn.ic%20ann.org/en/files/security-and-stability-advisory-commit...> .
Have a nice day!
Best,
Matthias
______________________________
Ing. Mag. Matthias M. Hudobnik
FIP • CIPP/E • CIPT • DPO • CIS LA
matthias@hudobnik.at
@mhudobnik _______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________
On 01.05.2026, at 16:33, David Mackey <mackey361@gmail.com> wrote:
Evan, Thank you for initiating this conversation and identifying a specific ICANN document on DNS abuse which directly affects End Users.
I acknowledge and support your assertion that educating the public, and the broader ICANN community, about important End User policy content found in specific ICANN artifacts is directly relevant to ICANN's mission and At-Large's role within it.
Going beyond Evan's initial email contribution, I wish to thank Mohibul for identifying a need to capture this educational content, and Justine for finding an At-Large document home which captures Evan's init ial email contribution about important ICANN Policy content that affects End Users. This email thread shows the value of team collaboration in policy development that I see in the At-Large community.
If I explore the specific dimension of "education" a bit further when considering future policy discussions, I'd be curious to see how "education" of End Users and the broader ICANN community might align with Avri's recent presentation on the ICANN's responsibility to the Global Public Interest <https://icann-community.atlassian.net/wiki/spaces/prjxplrpublicint/overview?...>. I have not yet done this work, but I hope that Evan's assertion that some ICANN & At-Large policy work involves an educa tional component would under the umbrella of Avri's work to define an ICANN Global Public Interest domain of thought.
Taking one step higher, I'd like to note that Article 26 of the 1948 UN Declaration of Human Rights <https://www.un.org/en/about-us/universal-declaration-of-human-rights>contains the phrase "Everyone has the right to education". I believe, although ICANN's bylaws (Article 1, Section 1.2, b Core Values, viii ...respecting international human rights... <https://www.icann.org/ar/governance/bylaws#article1> )may limit ICANN's responsibility, it would be good for the At-Large community to consider the Human Right to Education when performing important ICANN policy work.&nbs p;
Indeed, if you dig into the weeds of ICANN's bylaws again, specifically looking at the part that describes the role of the At-Large Advisory Committee (Article 12, Section 12.2, d, X, E <https://www.icann.org/ar/governance/bylaws#article12>), you will find the following statement on activities that the ALAC and RALO are responsible for ... "*Developing and maintaining on-going information and education programs, regarding ICANN and its work;*"
As Bill Jouris noted in another thread, much caution is warranted when we consider how to use ICANN's and At-Large's limited resources to be directed towards the domain of policy education. Hopefully, we can agree that "education" is within the scope of our responsibilities, and direct attention to how this can be done, rather than does "education" belong as part of our collective work.
Great email thread! I look forward to more cogent conversations on End User DNS policy from this group in the future. :-)
Cheers! David
On Fri, May 1, 2026 at 7:28 AM Justine Chew via NA-Discuss < na-discuss@icann.org> wrote:
Hi Evan,
Thanks for bringing up SAC127. I've added it to our fresh collection of DNS Abuse mitigation general resources <https://docs.google.com/document/d/1smchQvYap04IMu7BCiAj6TWEhhxFE7wqayI8CyYd...> .
Incidentally, there is an upcoming webinar on 13 May, regarding implementing DNS blocking and SAC127, that may interest you. Assuming you hadn't been aware of it, of course.
ICANN OCTO ISPCP/SSAC: Implementing DNS Blocking Responsibly
Blocking domains that are maliciously used can protect users, but it
raises questions about accuracy, due process, and unintended collateral effects. On 13 May at 16:00 UTC, don't miss our session on implementing #DNS <https:%20//www.facebook.com/hashtag/dns?__eep__=6&__cft__[0]=AZY9lp6xqQ3PO_AH00l-Gq83TBt43t8CcnGuqVBpjt1IFxhXUDZ0PMdhSiaAfCcKMkHlnfXnnLfZeswTn2EbgoSzcuZZtV_QzcYENqDDamT0jSD_Xh75QSFUX5Bn0EwAk8h57x-w_pmteekUV1XjvntXDuI0YvvbRUzSDLC8RzVO1n_e9m0e9MM8uwNhwp363eA&__tn__=*NK-R> blocking responsibly, featuring insights from SSAC’s latest document on this topic (SAC127). Register here >> https://bit.ly/4carPQk
Kind regards, Justine
On Fri, 1 May 2026 at 06:38, Evan Leibovitch via ALAC <alac@icann.org> wrote:
Hi all,
Anyone who is following the issue of DNS Abuse, which we have been discussing here, would be well advised to have a look at SSAC 127 <https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> issued last year, on the top of "DNS Blocking Revisited".
This one one of the few ICANN documents of which I am aware that deals with personal -level blocking as a way to mitigate abuse as well as state- and infrastructure-level blocking.
It spends a useful amount of effort on how end users can implement their own personal "blocking" through VPNs and "Public Resolvers":
* Users are aware of the benefits of public DNS resolvers and have been
reconfiguring their systems to leverage these services. This shift has been fueled by a growing understanding of the potential privacy and performance advantages that public resolvers offer over default DNS configurations, and in response to cases of state censorship and the abuse of DNS services offered by ISPs.*
This, to me, offers a rationale on how educating the public - and indeed the broader ICANN community -- about such facilities is directly relevant to ICANN's mission and At-Large's role within it.
I note with curiosity the complete lack of mention of one of the main reasons end-users are implementing such services: the blocking of advertising and tracking sites. To many people, myself included, the use of digital fingerprinting and tracking of personal details across different websites is as abusive as phishing and almost as abusive as malware sites. While mention is made of Cloudflare and Canadian Shield , the report completely ignores services such as Control D, Adguard DNS and NextDNS which block ads and trackers as well as more-malicious sites. For some blocking ads is a significant way to speed web-page rendering. And while some may debate the ethics of ad blocking, I am not aware of any jurisdiction in which doing so is illegal.
While it speaks of the use of the DNS to block pornography and gambling sites, as well as in-browser checks against malicious sites, oddly SSAC 127 ignores one of the main reasons people search for alternative DNS servers. But except for that notable error of omission, and is a worthwhile read for anyone who cares about what end-users (the ALAC constituency) can do to mitigate DNS abuse ... that is, considering that what constitutes "abuse" is not rigid and many approaches are available. -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 _______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
------ NA-Discuss mailing list -- na-discuss@icann.org To unsubscribe send an email to na-discuss-leave@icann.org
Visit the NARALO online at http://www.naralo.org ------ _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
------ NA-Discuss mailing list -- na-discuss@icann.org To unsubscribe send an email to na-discuss-leave@icann.org
Visit the NARALO online at http://www.naralo.org ------ _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Fri, May 1, 2026 at 12:00 PM Mohibul Mahmud via NA-Discuss < na-discuss@icann.org> wrote:
Hi Matthias, David, and all,
Thank you, Matthias, for sharing this crucial summary of SAC127. It provides the necessary technical foundation for the important policy discussion underway.
While I appreciate the summary that Matthias did, I note that none of it makes any mention of private individuals' own blocking and the use of public resolvers and VPNs except as a one-line afterthought. All its attention was focused on "entities". Looking at his summary and mine, you'd never know we were examing the same document. The vital work that lies ahead for At-Large is extracting from SSAC 127, and other documents and research, those parts *that are relevant to Internet end-users*; - the basics of the DNS routing (and diverting) that a lay person can understand - why they need to care about potential abuse and the various forms that abuse may take - what tools exist to help *end-users* meet their own personal needs, whether it is simple blocking of malware and phishing sites, or advanced blocking of undesirable content such as tracking, advertising, social media or adult material - benefits and risks of using public alternative DNS from an end-users' perspective. Indeed, SSAC 127 incorrectly interprets why end users choose alternative DNS servers. Such action is rarely done, at least in the West, to bypass government blocking. It is to take control of privacy, content bloat due to advertising, protect children and other factors. Abuse is in the eye of the beholder, which is why many public DNS systems are highly configurable. (For example, ControlD offers six different configurations for its free DNS services <https://controld.com/free-dnshttps://controld.com/free-dns> and many more for its paid ones.) There are many constituencies in ICANN who are capable of looking after themselves. Only At-Large exists to serve end-users; it is vital that we approach the issue primarily through this perspective. Far too often in my time I have seen At-Large fight the battles of others. Here more than anywhere we need to concentrate not on the needs of governments or other entities, but of the global Internet end-user. Sharp focus is critical. - Evan
*"To many people, myself included, the use of digital fingerprinting and tracking of personal details across different websites is as abusive as phishing and almost as abusive as malware sites."* - Evan Leibovitch Therein, is the recognition that the fight against privacy abuse is aligned with the fight against security threats. My reading of SAC127 says this is also recognized. It seems to me that what is being argued in SAC127 is that a platform-level resolution via DNS blocking is fraught. And, equally so, the alternate DNS resolvers, mainly due to the [even] inadvertent possibility of a trespass on the rights-of-use of others. I agree with Evan that digital fingerprinting and cross-site tracking exploit users in ways that are uncomfortably close to phishing and, in many cases, indistinguishable from malware behaviour. The current internet business model actively incentivizes this; platforms productize the user, extract behavioral data and normalize persistent tracking across domains. Which explains the hard trek to meaningful change emerging at the platform level, resulting in the drive to mutate end users from passive taker to active the [self] defender Evan is suggesting At-Large should be promoting. Fatigue-by-design is the result of the systemic application of consent banners, tracking requests and hidden scripts. Most users cannot realistically fight this one prompt at a time. Solution rests with fomenting a material change to the incentives that drive tracking, fingerprinting, phishing and malware ecosystems. Proactive control preventing connections to fingerprinting infrastructure and reduce the exposure of user metadata before it ever reaching the browser valorize public DNS resolvers such as Cloudflare (1.1.1.1), Control D and AdGuard. One-stop-shop and you block known tracking domains, phishing domains before a connection is established, prevent access to malware command-and-control servers and reduce exposure to malicious redirects and spoofed domains. As many of these as they know. Even me who reserves the right to be offended sees the benefits here. Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* ============================= On Thu, 30 Apr 2026 at 17:38, Evan Leibovitch via ALAC <alac@icann.org> wrote:
Hi all,
Anyone who is following the issue of DNS Abuse, which we have been discussing here, would be well advised to have a look at SSAC 127 <https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> issued last year, on the top of "DNS Blocking Revisited".
This one one of the few ICANN documents of which I am aware that deals with personal-level blocking as a way to mitigate abuse as well as state- and infrastructure-level blocking.
It spends a useful amount of effort on how end users can implement their own personal "blocking" through VPNs and "Public Resolvers":
* Users are aware of the benefits of public DNS resolvers and have been
reconfiguring their systems to leverage these services. This shift has been fueled by a growing understanding of the potential privacy and performance advantages that public resolvers offer over default DNS configurations, and in response to cases of state censorship and the abuse of DNS services offered by ISPs.*
This, to me, offers a rationale on how educating the public - and indeed the broader ICANN community -- about such facilities is directly relevant to ICANN's mission and At-Large's role within it.
I note with curiosity the complete lack of mention of one of the main reasons end-users are implementing such services: the blocking of advertising and tracking sites. To many people, myself included, the use of digital fingerprinting and tracking of personal details across different websites is as abusive as phishing and almost as abusive as malware sites. While mention is made of Cloudflare and Canadian Shield, the report completely ignores services such as Control D, Adguard DNS and NextDNS which block ads and trackers as well as more-malicious sites. For some blocking ads is a significant way to speed web-page rendering. And while some may debate the ethics of ad blocking, I am not aware of any jurisdiction in which doing so is illegal.
While it speaks of the use of the DNS to block pornography and gambling sites, as well as in-browser checks against malicious sites, oddly SSAC 127 ignores one of the main reasons people search for alternative DNS servers. But except for that notable error of omission, and is a worthwhile read for anyone who cares about what end-users (the ALAC constituency) can do to mitigate DNS abuse ... that is, considering that what constitutes "abuse" is not rigid and many approaches are available. -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 _______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Sun, May 3, 2026 at 6:34 PM Carlton Samuels <carlton.samuels@gmail.com> wrote:
*"To many people, myself included, the use of digital fingerprinting and tracking of personal details across different websites is as abusive as phishing and almost as abusive as malware sites."*
Which explains the hard trek to meaningful change emerging at the platform level, resulting in the drive to mutate end users from passive taker to active the [self] defender Evan is suggesting At-Large should be promoting.
In the interest of keeping expectations low for Mohibul's project, I'll be happy if we can merely be supported by ICANN in calling attention to these options. The leap from education to advocacy can wait until we get that far.
Proactive control preventing connections to fingerprinting infrastructure and reduce the exposure of user metadata before it ever reaching the browser valorize public DNS resolvers such as Cloudflare (1.1.1.1), Control D and AdGuard.
Important note: Although it is best known for its unique IP address, Cloudflare (1.1.1.1) does *not* protect against malware, tracking or ads. Its primary benefits over the use of ISP resolvers are in speed and (for providers of Internet services rather than consumers) heightened DDoS resilience. It has a free tier but most usages of this service are paid. More appropriate here is Cloudflare's 1.1.1.1 for Families <https://blog.cloudflare.com/introducing-1-1-1-1-for-families/>, a free service. To use this one would point at *1.1.1.2* to block malware or *1.1.1.3* to block malware and adult content. Critically, none of the Cloudflare services block ad or tracking servers. Another popular service that does this (block malware but not ads or tracking) is the Swiss nonprofit Quad9 <https://quad9.net/service/service-addresses-and-features/> (unsurprisingly, 9.9.9.9). To block ads and trackers one needs to go to services such as AdGuard <https://adguard.com/en/welcome.html> and NextDNS <https://nextdns.io/>. Both are paid services but the NextDNS free tier will work for those who do fewer than 300,000 queries per month. Control D <https://controld.com/free-dns> appears to be the only one that offers ad and tracker blocking for free (though paid tiers enable more-detailed configuration). There is also a solution based on adding a Raspberry Pi to your home network but it requires serious geek zen and is somewhat rudely named <https://pi-hole.net/>. SSAC 127 also makes mention of blocking capabilities built into most browsers (section 2.1) that don't require any user configuration at all. While all of the mainstream browsers have basic malware protection they are less comprehensive and less current than using the public-DNS method. And just as SSAC 127 avoids mentioning use of personal DNS blocking to thwart tracking and invasive ads, it makes no mention of browser-based approaches to this issue either. Ublock Origin is one of the most-popular extensions for Firefox, though its Chrome version is neutered because ... Google. While not in the mainstream, Brave and Vivaldi (and a number of good but lesser-known browsers) come with ad and tracker blocking built in. This is all information I believe belongs in any At-Large education program. We don't need to advocate it, just letting the public know that such options exist would be achievement enough at this stage. And we could likely get support (if not sponsorship) from some of the DNS providers mentioned above. - Evan
participants (6)
-
Carlton Samuels -
David Mackey -
Evan Leibovitch -
Justine Chew -
Matthias M. Hudobnik -
Mohibul Mahmud