Subject: Update: RSSAC001v3 Work Party and its Relevance to NARALO/At-Large Hello NARALO Community, I wanted to share an update on the ongoing work on *RSSAC001v3* by the RSSAC Caucus. This is an important topic, as it relates directly to the stability and security of the DNS Root Server System, which is a foundational interest of the At-Large community. The v3 Work Party is undertaking a targeted, narrow update of the RSSAC001 document, which sets the service expectations for Root Server Operators (RSOs). The primary goal is to review existing expectations—keeping, updating, or removing them—rather than undertaking a complete rewrite or making broad editorial changes. Here are the key takeaways from the recent work session: - *Focused Scope:* The intent is *not* to rewrite RSSAC001. The work is concentrated on deciding which existing service expectations should remain, be updated, or be removed. - *High Bar for Changes:* Any material or meaningful changes, such as introducing new or stronger expectations, will require clear identification and open discussion. - *Expectations, Not Enforcement:* The document remains an *expectations* document for RSOs, setting a high-level standard for good root server service. It does not define measurements or enforcement, which are covered by other RSSAC documents. *Why This Matters to ALAC and NARALO* The stability and security of the DNS Root Server System are foundational to the internet, directly affecting every user. This work by the RSSAC to refine and clarify the expectations for the RSOs, who maintain this critical infrastructure, ensures that the system remains reliable and robust. By clearly defining these expectations in RSSAC001, the community helps safeguard the essential function of the internet, which is a primary concern for the At-Large Advisory Committee (ALAC) and the regional NARALO structures. For anyone who missed the session, you can watch the recording here: RSSAC001v3 Work Party Recording <https://www.google.com/url?source=gmail&sa=E&q=https://icann.zoom.us/rec/sha...> . Best regards, Mohibul On Mon, Mar 9, 2026, 8:57 p.m. Evan Leibovitch via NA-Discuss < na-discuss@icann.org> wrote:
Hi Glenn, and thanks for this.
I agree with you about the lack of clarity. The slide deck is very informative, but it seems to ignore what are now the most effective ways that the general public now confronts DNS abuse. They seem to be off the radar of the entire ICANN community because they've evolved as workarounds that do not wait for committees or government agencies or working groups to act, indeed they bypass ICANN completely:
- Abuse-limiting DNS servers: Anyone can override the DNS server provided by their ISP in their phone, PC or home router if they wish. Setting this manually enables anyone to send their DNS queries to a server that maintains lists of abusing DNS domains and refuses to feed them to you. There are many examples, the best of which (IMO) is the Swiss nonprofit Quad9 <https://quad9.net/>. Setting your DNS server to 9.9.9.9 sends queries through this well-trusted site which is free to use and does not require setting up an account. They maintain a database of millions of malicious domains which is updated in real-time. It's easy to use, and an immediate step that protects the privacy of DNS lookups while blocking bad domains. (Quad9 provides setup guides for PCs, phones and routers; here is a video that compares it to alternatives <https://www.youtube.com/watch?v=NUT4K3tk9Ns>.)
- Spam is correctly noted in the slide deck as being an enabler of DNS abuse rather than the abuse itself. However the slide deck makes no mention of the massive amounts of volunteer time that go into creating Remote Blackhole Lists (RBLs) that maintain not only domains but also IP addresses of sources of unwanted and unsolicited email. The best known of these is Spamhaus <https://www.spamhaus.org/> but there are a few of them. They sometimes suffer from false positives, but there is a well-documented process for legitimate bulk-email senders to get removed from the lists. Many mail systems implement some kind of such blocking; anyone who looks at the spam folder of their Gmail will see this in action. Spam is specifically also the subject of legislation in both Canada ( CASL <https://ised-isde.canada.ca/site/canada-anti-spam-legislation/en>) and the US (CAN-SPAM <https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guid...> ).
As the component of the ICANN that is closest to the end-user, if we in NARALO are interested in the actual practice of helping the public mitigate DNS abuse -- something that can be done by anyone, TODAY -- we can (and should) do much more than just point to internal ICANN process churn and pray that the contracted parties do the right thing. The solutions I have listed above unabashedly bypass the ICANN-registry-registrar chain in their pursuit of practical abuse mitigation. ICANN's work is trying to stop abuse at the source with limited success despite decades of work. Well-meaning people joined NARALO chiefly to address abuse (old-timers here will remember Marc, Garth and Beau) but left out of frustration. Abuse-minded DNS servers and RBLs perform the task at the receiving end and appear to be more successful in the actual problem solving; it's much easier to ignore a bad domain than to take it down but the end-user effect is the same. The slide deck makes mention of PDNS but it's never elaborated.
I ask everyone here: what action is both easier and more likely to help you and your family reduce exposure to DNS abuse, right here right now?
1. Explaining ICANN processes and hoping it will all work out? 2. Monitoring Netbeacon and pressuring registries and/or ICANN to act on its information? 3. Setting your devices' DNS to 9.9.9.9?
Education about Abuse-resistant DNS servers and DIY abuse mitigation should be part of ICANN's (and especially At-Large's) public mandate. That these solutions did not come from within ICANN (and indeed ignore it completely) does not negate their intense potential for public benefit in this realm. NIH thinking must be resisted.
- Evan
On Mon, Mar 9, 2026 at 1:01 PM Glenn McKnight via NA-Discuss < na-discuss@icann.org> wrote:
Hi Greg and Rookayya
I attended and watched the recordings of the DNS Abuse Mitigation sessions in Mumbai ( remotely ) and I need to confess that the group dance around the concrete issues which impacts the user community.
As a result I spent some time tailoring a AI Gemini slideshow given the parameters of making sense of the topic and I've added the result of slideshow as a EBOOK
https://online.fliphtml5.com/gnel/DNS_Abuse_Playbook/
We are suffering by a lack of clarity and plain speaking on this topic. I hope this slideshow can help our membership in trying to undersatnd the basics.
Glenn
Glenn McKnight, MA Virtual School of Internet Governance Chief Information Officer www.virtualsig.org *YOUR SOURCE FOR INTERNET GOVERNANCE EDUCATION * *Mobile 437-237-4655*
------ 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.
-- 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.