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.