Subject : Connecting the Dots: How the IETF's Standards Process Impacts DNS & ICANN Policy Hello NARALO Community, I wanted to share a quick update and some resources for anyone interested in the technical standards work that underpins much of our community’s discussion, especially as the IETF 125 meeting is currently underway in Shenzhen, China. While attending the ICANN Meeting, I participated in a session on 'How the IETF Works,' which provided great insight. Understanding the IETF’s work is vital for our community because: - Foundational Stability: The protocols defined by the IETF (DNS, TCP/IP, security protocols) are the technical foundation for the internet. Monitoring this work is key to our interest in DNS stability and security. - Encouraging Participation: The IETF's process is open, and it explicitly welcomes input from civil society and end-users, ensuring that the protocols being developed consider human rights and policy implications. - Bridging Policy and Tech: Familiarity with the standards process ensures that NARALO/ALAC’s policy advocacy is technically informed and more effective within the broader Internet Governance ecosystem. Here are the key takeaways from the session, which may be helpful for anyone considering participation: - Individual Participation: The IETF operates on the principle that everyone participates as an individual, with contributions judged solely on technical merit—not on organizational affiliation. - Consensus-Driven: Decisions are made by rough consensus and running code, rather than voting. - Open and Hybrid: The IETF strongly promotes first-class citizen remote participation, making it highly accessible for those who cannot travel. - Relevant Work: New working groups (BOFs) and existing work are addressing key areas like AI agent-to-agent communications, new DNS delegation mechanisms (DELEG), and protocol considerations for human rights (HRPC). -----IETF 125 Information - Meeting Dates: March 14 – 20, 2026 - Meeting Link: All meeting details, remote participation links (via Meetecho, requires registration), and the full agenda can be found on the main event page: IETF | IETF 125 Shenzhen <https://www.ietf.org/meeting/125/> - Session Recording: The recording and materials for the "How the IETF Works" ICANN85 - 105 A/B - Zoom <https://icann.zoom.us/rec/play/TAJOMJa966Fbxmr7cTUSLkmNQMh_wTXteKDKI8kE4Q4do...> I encourage you all to check out the meeting schedule—especially sessions related to DNS Operations—and consider joining remotely. Best regards, Mohibul On Sat, Mar 14, 2026 at 5:14 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
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.