DNS Abuse Mitigation and NARALO activities
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*
Good work, Glenn! 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.
-- -------------------------------------- Joly MacFie +12185659365 -------------------------------------- -
Hello Glenn: Thank you for sharing this resource and for taking the initiative to create such a helpful educational tool. I really appreciate the effort you put into making this complex topic more accessible. As someone whose expertise lies in public policy rather than technical matters, I found the slideshow incredibly useful. The clarity and plain language approach you've taken is exactly what many of us need to better understand DNS abuse mitigation fundamentals. Best regards, Ana Teresa 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.
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
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.
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.
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide Dear Glenn and Evan, I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO. The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13). However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats. To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs. This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal. Best regards, Mohibul (360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA> On Mon, Mar 9, 2026 at 8:57 PM 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.
Hi Mohibul, As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future. Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue. In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20). I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9. Even further protection is available at the DNS level if you want to extend blocking to ads or adult content. Again, thanks for the suggestion. I hope it gets picked up and is offered some resources. - Evan On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Hi Evan, Glenn, and all, Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience. I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread: • ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call. Best regards, Mohibul Mahmud NARALO Member On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch <evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Hi Mohibul, I appreciate the direction this discussion is taking, and I agree that a simple, user‑friendly guide could become a valuable NARALO resource. The combination of ICANN’s policy framework with practical tools like Quad9, CIRA’s Canadian Shield, and RBL‑based email protections creates a strong foundation for something our community can actually use day‑to‑day. Mohibul, your proposal is aligned with the needs , so I am curious how you envision the next step? Would you prefer to draft an initial outline for an overview during an upcoming NARALO call? Regards, Muhammad Ali Data & AI Analyst On Mon, Mar 23, 2026 at 7:25 AM Mohibul Mahmud via NA-Discuss < na-discuss@icann.org> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch <evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- 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.
Subject: Re: DNS Abuse & AI – Proposed NARALO Action: Member Guide Hi Evan, Glenn, and all, I wanted to add one more relevant development to our discussion that I believe significantly strengthens the case for the member guide we have been building. On March 19, 2026, NIST published SP 800-81r3 — the Secure Domain Name System (DNS) Deployment Guide — the first update to this foundational document in over twelve years: • Official NIST page: https://csrc.nist.gov/pubs/sp/800/81/r3/final • Direct PDF download: https://doi.org/10.6028/NIST.SP.800-81r3 For the NARALO community and the end-users we represent, this is a landmark moment. Here are four takeaways directly relevant to our work: 1. DNS is Now Officially a "First Line of Defense" Rather than being viewed merely as a lookup service, DNS is now officially positioned as an active enforcement layer capable of detecting and mitigating threats in real time. This gives NARALO the policy weight to advocate for Protective DNS as a standard recommendation for schools, local governments, and small businesses across North America — exactly the practical guidance our proposed member guide would provide. 2. Encrypted DNS is Now a Federal Standard SP 800-81r3 addresses encrypted DNS through three key protocols — DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) — and mandates encrypted DNS for US federal civilian agencies wherever technically feasible. This directly validates what Evan highlighted: encrypted DNS is not just a privacy preference but a recognized federal standard. It also reinforces the case for CIRA Canadian Shield and Quad9 (9.9.9.9) as the practical implementations we would feature in our guide. 3. DNSSEC Recommendations Have Been Modernized The publication updates DNSSEC signing recommendations to reflect current cryptographic standards. For end-users, this reinforces the importance of domain owners signing their zones — preventing website hijacking and fake site redirects that disproportionately harm non-technical users. 4. Zero Trust for Everyday Users SP 800-81r3 integrates DNS into Zero Trust Architecture, positioning DNS as both a policy enforcement point and a source of information when evaluating access requests. In plain language: every connection should be verified before being trusted — a principle that becomes essential as AI-driven phishing grows more sophisticated. I believe NIST SP 800-81r3 gives our proposed member guide an authoritative US federal policy foundation — one that did not exist just one week ago. Best regards, Mohibul Mahmud NARALO Member On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch <evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Hi All I understand that Greg would be very interested in a presentation on this subject. I will reach out to him and Rookayya on a special session open to all ALAC I will send it today 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* On Wed, 25 Mar 2026 at 01:33, Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: Re: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Hi Evan, Glenn, and all,
I wanted to add one more relevant development to our discussion that I believe significantly strengthens the case for the member guide we have been building.
On March 19, 2026, NIST published SP 800-81r3 — the Secure Domain Name System (DNS) Deployment Guide — the first update to this foundational document in over twelve years:
• Official NIST page: https://csrc.nist.gov/pubs/sp/800/81/r3/final
• Direct PDF download: https://doi.org/10.6028/NIST.SP.800-81r3
For the NARALO community and the end-users we represent, this is a landmark moment. Here are four takeaways directly relevant to our work:
1. DNS is Now Officially a "First Line of Defense"
Rather than being viewed merely as a lookup service, DNS is now officially positioned as an active enforcement layer capable of detecting and mitigating threats in real time. This gives NARALO the policy weight to advocate for Protective DNS as a standard recommendation for schools, local governments, and small businesses across North America — exactly the practical guidance our proposed member guide would provide.
2. Encrypted DNS is Now a Federal Standard
SP 800-81r3 addresses encrypted DNS through three key protocols — DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) — and mandates encrypted DNS for US federal civilian agencies wherever technically feasible. This directly validates what Evan highlighted: encrypted DNS is not just a privacy preference but a recognized federal standard. It also reinforces the case for CIRA Canadian Shield and Quad9 (9.9.9.9) as the practical implementations we would feature in our guide.
3. DNSSEC Recommendations Have Been Modernized
The publication updates DNSSEC signing recommendations to reflect current cryptographic standards. For end-users, this reinforces the importance of domain owners signing their zones — preventing website hijacking and fake site redirects that disproportionately harm non-technical users.
4. Zero Trust for Everyday Users
SP 800-81r3 integrates DNS into Zero Trust Architecture, positioning DNS as both a policy enforcement point and a source of information when evaluating access requests. In plain language: every connection should be verified before being trusted — a principle that becomes essential as AI-driven phishing grows more sophisticated.
I believe NIST SP 800-81r3 gives our proposed member guide an authoritative US federal policy foundation — one that did not exist just one week ago.
Best regards,
Mohibul Mahmud
NARALO Member
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch <evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Hi All No response from staff or Greg on the open discussion with NARALO. My impression is that NARALO is looking for community members to discuss the policy issues . If they don't want to do it. I am prepared to organize our own ZOOM call within VSIS Please confirm the main topic for a ZOOM call. I will create a promotional flyer and book the zoom meeting Please confirm your willingness for this separate session Also Zulgar and I spoke about the expressed limits of the ICANN board on the issues of UA and I think given our friday event perhaps we can do a special purpose call in response on this issue in detail or we can add it to the above Zoom discussion. We have a NARALO ALAC person Kathleen Sloggin perhaps she too can join us. Speakers Evan Mohibul Kathleen Glenn( Moderator Avri Comments? G Glenn McKnight, MA Virtual School of Internet Governance Chief Information Officer www.virtualsig.org *YOUR SOURCE FOR INTERNET GOVERNANCE EDUCATION * *Mobile 437-237-4655* On Wed, 25 Mar 2026 at 10:08, Glenn McKnight <mcknight.glenn@gmail.com> wrote:
Hi All I understand that Greg would be very interested in a presentation on this subject. I will reach out to him and Rookayya on a special session open to all ALAC I will send it today 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*
On Wed, 25 Mar 2026 at 01:33, Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: Re: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Hi Evan, Glenn, and all,
I wanted to add one more relevant development to our discussion that I believe significantly strengthens the case for the member guide we have been building.
On March 19, 2026, NIST published SP 800-81r3 — the Secure Domain Name System (DNS) Deployment Guide — the first update to this foundational document in over twelve years:
• Official NIST page: https://csrc.nist.gov/pubs/sp/800/81/r3/final
• Direct PDF download: https://doi.org/10.6028/NIST.SP.800-81r3
For the NARALO community and the end-users we represent, this is a landmark moment. Here are four takeaways directly relevant to our work:
1. DNS is Now Officially a "First Line of Defense"
Rather than being viewed merely as a lookup service, DNS is now officially positioned as an active enforcement layer capable of detecting and mitigating threats in real time. This gives NARALO the policy weight to advocate for Protective DNS as a standard recommendation for schools, local governments, and small businesses across North America — exactly the practical guidance our proposed member guide would provide.
2. Encrypted DNS is Now a Federal Standard
SP 800-81r3 addresses encrypted DNS through three key protocols — DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) — and mandates encrypted DNS for US federal civilian agencies wherever technically feasible. This directly validates what Evan highlighted: encrypted DNS is not just a privacy preference but a recognized federal standard. It also reinforces the case for CIRA Canadian Shield and Quad9 (9.9.9.9) as the practical implementations we would feature in our guide.
3. DNSSEC Recommendations Have Been Modernized
The publication updates DNSSEC signing recommendations to reflect current cryptographic standards. For end-users, this reinforces the importance of domain owners signing their zones — preventing website hijacking and fake site redirects that disproportionately harm non-technical users.
4. Zero Trust for Everyday Users
SP 800-81r3 integrates DNS into Zero Trust Architecture, positioning DNS as both a policy enforcement point and a source of information when evaluating access requests. In plain language: every connection should be verified before being trusted — a principle that becomes essential as AI-driven phishing grows more sophisticated.
I believe NIST SP 800-81r3 gives our proposed member guide an authoritative US federal policy foundation — one that did not exist just one week ago.
Best regards,
Mohibul Mahmud
NARALO Member
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch < evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Glenn: Contact Rookayya directly. I am prety sure she is be able to organize a NARALO call just for this. -ed On Wed, Mar 25, 2026 at 4:21 PM Glenn McKnight via NA-Discuss < na-discuss@icann.org> wrote:
Hi All No response from staff or Greg on the open discussion with NARALO. My impression is that NARALO is looking for community members to discuss the policy issues . If they don't want to do it. I am prepared to organize our own ZOOM call within VSIS Please confirm the main topic for a ZOOM call. I will create a promotional flyer and book the zoom meeting Please confirm your willingness for this separate session
Also Zulgar and I spoke about the expressed limits of the ICANN board on the issues of UA and I think given our friday event perhaps we can do a special purpose call in response on this issue in detail or we can add it to the above Zoom discussion. We have a NARALO ALAC person Kathleen Sloggin perhaps she too can join us.
Speakers Evan Mohibul Kathleen Glenn( Moderator Avri
Comments? G
Glenn McKnight, MA Virtual School of Internet Governance Chief Information Officer www.virtualsig.org *YOUR SOURCE FOR INTERNET GOVERNANCE EDUCATION * *Mobile 437-237-4655*
On Wed, 25 Mar 2026 at 10:08, Glenn McKnight <mcknight.glenn@gmail.com> wrote:
Hi All I understand that Greg would be very interested in a presentation on this subject. I will reach out to him and Rookayya on a special session open to all ALAC I will send it today 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*
On Wed, 25 Mar 2026 at 01:33, Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: Re: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Hi Evan, Glenn, and all,
I wanted to add one more relevant development to our discussion that I believe significantly strengthens the case for the member guide we have been building.
On March 19, 2026, NIST published SP 800-81r3 — the Secure Domain Name System (DNS) Deployment Guide — the first update to this foundational document in over twelve years:
• Official NIST page: https://csrc.nist.gov/pubs/sp/800/81/r3/final
• Direct PDF download: https://doi.org/10.6028/NIST.SP.800-81r3
For the NARALO community and the end-users we represent, this is a landmark moment. Here are four takeaways directly relevant to our work:
1. DNS is Now Officially a "First Line of Defense"
Rather than being viewed merely as a lookup service, DNS is now officially positioned as an active enforcement layer capable of detecting and mitigating threats in real time. This gives NARALO the policy weight to advocate for Protective DNS as a standard recommendation for schools, local governments, and small businesses across North America — exactly the practical guidance our proposed member guide would provide.
2. Encrypted DNS is Now a Federal Standard
SP 800-81r3 addresses encrypted DNS through three key protocols — DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) — and mandates encrypted DNS for US federal civilian agencies wherever technically feasible. This directly validates what Evan highlighted: encrypted DNS is not just a privacy preference but a recognized federal standard. It also reinforces the case for CIRA Canadian Shield and Quad9 (9.9.9.9) as the practical implementations we would feature in our guide.
3. DNSSEC Recommendations Have Been Modernized
The publication updates DNSSEC signing recommendations to reflect current cryptographic standards. For end-users, this reinforces the importance of domain owners signing their zones — preventing website hijacking and fake site redirects that disproportionately harm non-technical users.
4. Zero Trust for Everyday Users
SP 800-81r3 integrates DNS into Zero Trust Architecture, positioning DNS as both a policy enforcement point and a source of information when evaluating access requests. In plain language: every connection should be verified before being trusted — a principle that becomes essential as AI-driven phishing grows more sophisticated.
I believe NIST SP 800-81r3 gives our proposed member guide an authoritative US federal policy foundation — one that did not exist just one week ago.
Best regards,
Mohibul Mahmud
NARALO Member
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch < evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- 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.
-- *Notice*: This email may contain confidential information, is subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
Hi All, Thank you for your contributions to this email chain. The information has been both valuable and educational regarding the policy issues and coordination options (particularly helpful as I am relatively new to the group). Count me in for the upcoming Zoom session, whether through NARALO or VSIG… Looking forward to it! Best regards, Ana Teresa On Wed, Mar 25, 2026 at 4:21 PM Glenn McKnight via NA-Discuss < na-discuss@icann.org> wrote:
Hi All No response from staff or Greg on the open discussion with NARALO. My impression is that NARALO is looking for community members to discuss the policy issues . If they don't want to do it. I am prepared to organize our own ZOOM call within VSIS Please confirm the main topic for a ZOOM call. I will create a promotional flyer and book the zoom meeting Please confirm your willingness for this separate session
Also Zulgar and I spoke about the expressed limits of the ICANN board on the issues of UA and I think given our friday event perhaps we can do a special purpose call in response on this issue in detail or we can add it to the above Zoom discussion. We have a NARALO ALAC person Kathleen Sloggin perhaps she too can join us.
Speakers Evan Mohibul Kathleen Glenn( Moderator Avri
Comments?
G
Glenn McKnight, MA Virtual School of Internet Governance Chief Information Officer www.virtualsig.org *YOUR SOURCE FOR INTERNET GOVERNANCE EDUCATION * *Mobile 437-237-4655*
On Wed, 25 Mar 2026 at 10:08, Glenn McKnight <mcknight.glenn@gmail.com> wrote:
Hi All I understand that Greg would be very interested in a presentation on this subject. I will reach out to him and Rookayya on a special session open to all ALAC I will send it today 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*
On Wed, 25 Mar 2026 at 01:33, Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: Re: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Hi Evan, Glenn, and all,
I wanted to add one more relevant development to our discussion that I believe significantly strengthens the case for the member guide we have been building.
On March 19, 2026, NIST published SP 800-81r3 — the Secure Domain Name System (DNS) Deployment Guide — the first update to this foundational document in over twelve years:
• Official NIST page: https://csrc.nist.gov/pubs/sp/800/81/r3/final
• Direct PDF download: https://doi.org/10.6028/NIST.SP.800-81r3
For the NARALO community and the end-users we represent, this is a landmark moment. Here are four takeaways directly relevant to our work:
1. DNS is Now Officially a "First Line of Defense"
Rather than being viewed merely as a lookup service, DNS is now officially positioned as an active enforcement layer capable of detecting and mitigating threats in real time. This gives NARALO the policy weight to advocate for Protective DNS as a standard recommendation for schools, local governments, and small businesses across North America — exactly the practical guidance our proposed member guide would provide.
2. Encrypted DNS is Now a Federal Standard
SP 800-81r3 addresses encrypted DNS through three key protocols — DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) — and mandates encrypted DNS for US federal civilian agencies wherever technically feasible. This directly validates what Evan highlighted: encrypted DNS is not just a privacy preference but a recognized federal standard. It also reinforces the case for CIRA Canadian Shield and Quad9 (9.9.9.9) as the practical implementations we would feature in our guide.
3. DNSSEC Recommendations Have Been Modernized
The publication updates DNSSEC signing recommendations to reflect current cryptographic standards. For end-users, this reinforces the importance of domain owners signing their zones — preventing website hijacking and fake site redirects that disproportionately harm non-technical users.
4. Zero Trust for Everyday Users
SP 800-81r3 integrates DNS into Zero Trust Architecture, positioning DNS as both a policy enforcement point and a source of information when evaluating access requests. In plain language: every connection should be verified before being trusted — a principle that becomes essential as AI-driven phishing grows more sophisticated.
I believe NIST SP 800-81r3 gives our proposed member guide an authoritative US federal policy foundation — one that did not exist just one week ago.
Best regards,
Mohibul Mahmud
NARALO Member
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch < evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- 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 and team, I have been following the recent discussion about the need for more practical, end-user-focused materials as NARALO’s DNS abuse work moves forward. With that in mind, I drafted a plain-language DNS abuse guide for the NARALO community. The goal was to create something practical and accessible, with a focus on actions members can take right away, such as using protective resolvers like Quad9 and CIRA Canadian Shield, as well as encrypted DNS. In that sense, I hoped to help move the conversation from policy definitions toward practical end-user protection. I have attached the draft here and would welcome your feedback on whether this is the kind of operational outreach resource that would be useful for the committee’s work. Best regards, Mohibul On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch <evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
*Subject: AI-Enhanced Phishing and the Evolution of MFA Bypass: Key Insights for At-Large* *Dear NARALO and ALAC Colleagues,* As we continue our discussions on DNS abuse and end-user safety, I wanted to share some critical updates regarding the evolving threat landscape, particularly how AI is being used to refine attacks against individual users. In a recent briefing from Microsoft Security, several trends were highlighted that I believe are directly relevant to our policy work and outreach efforts: - *The "Refinement" Shift:* AI is no longer just about the volume of attacks. Threat actors are using it to create highly localized and role-specific messaging. This has resulted in a *450% increase* in phishing click-through rates, as the traditional "red flags" (like poor grammar or generic lures) are disappearing. - *Modular Cybercrime Ecosystems:* We are seeing a shift toward "modular" service models, such as the recently disrupted *Tycoon 2FA*. These systems allow even low-skilled actors to launch sophisticated "adversary-in-the-middle" attacks that can bypass standard Multi-Factor Authentication (MFA) in real time. - *Impact on North America:* Approximately *25% of these observed AI-driven threats* are currently targeting the United States and Canada, making this a primary concern for our NARALO constituency. I believe these developments underscore the need for us to advocate for more resilient, phishing-resistant authentication standards (such as FIDO2/Passkeys) and to update our digital literacy frameworks to reflect this new "AI-upgraded" threat tempo. You can watch the full briefing here: How AI agents change the threat landscape <https://www.youtube.com/watch?v=Iz5-Bf-4Crg> I look forward to discussing how we might integrate these insights into our upcoming policy statements and community outreach. Best regards, *Mohibul Mahmud* NARALO / ALAC Candidate RSSAC Caucus Member On Mon, Apr 20, 2026 at 12:59 AM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan and team,
I have been following the recent discussion about the need for more practical, end-user-focused materials as NARALO’s DNS abuse work moves forward.
With that in mind, I drafted a plain-language DNS abuse guide for the NARALO community. The goal was to create something practical and accessible, with a focus on actions members can take right away, such as using protective resolvers like Quad9 and CIRA Canadian Shield, as well as encrypted DNS. In that sense, I hoped to help move the conversation from policy definitions toward practical end-user protection.
I have attached the draft here and would welcome your feedback on whether this is the kind of operational outreach resource that would be useful for the committee’s work.
Best regards, Mohibul
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch <evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Subject: Impact of Canada’s Bill C-22 (Lawful Access Act 2026) on the North American End-User Dear NARALO Colleagues and At-Large Community, As we move through the 2026 leadership cycle, I have been closely monitoring legislative developments in Canada that carry significant implications for our regional mission: protecting the rights and security of internet end-users. I recently followed the discussions hosted by ISOC Canada in Ottawa regarding Bill C-22 (The Lawful Access Act). This bill just cleared a major milestone on April 20, 2026, passing its second reading and moving to the Committee stage (SECU) for detailed study. It introduces several measures that the NARALO community should have on its radar: - Subscriber Information Access: The bill lowers the evidentiary threshold for law enforcement to access subscriber details from "reasonable grounds to believe" to the lower standard of "reasonable grounds to suspect." - Mandatory Data Retention: Under Part 2, the government could mandate that electronic service providers retain metadata (including location data) for up to a year, creating potential security "honeypots." - Technical Integrity: There are serious concerns about "mandated capabilities" for interception. Experts (including Michael Geist) have flagged that these requirements could introduce systemic vulnerabilities or "backdoors" into the DNS and network architecture. As a candidate for the ALAC position, I believe NARALO must play a central role in translating these complex national legislative trends into actionable insights for the At-Large community. Whether it is through educational initiatives—similar to the technical translation work I’ve led for the VSIG course—or formal policy comments, we must ensure the end-user's voice is heard. I would love to hear from our colleagues in the US and the Caribbean—are you seeing similar "lawful access" or metadata retention pressures in your jurisdictions? How can NARALO better coordinate a regional response to these infrastructure-level shifts? I look forward to discussing this further during our upcoming monthly call. Best regards, Mohibul Mahmud NARALO ALAC Candidate On Tue, Apr 21, 2026 at 1:43 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
*Subject: AI-Enhanced Phishing and the Evolution of MFA Bypass: Key Insights for At-Large*
*Dear NARALO and ALAC Colleagues,*
As we continue our discussions on DNS abuse and end-user safety, I wanted to share some critical updates regarding the evolving threat landscape, particularly how AI is being used to refine attacks against individual users.
In a recent briefing from Microsoft Security, several trends were highlighted that I believe are directly relevant to our policy work and outreach efforts:
-
*The "Refinement" Shift:* AI is no longer just about the volume of attacks. Threat actors are using it to create highly localized and role-specific messaging. This has resulted in a *450% increase* in phishing click-through rates, as the traditional "red flags" (like poor grammar or generic lures) are disappearing. -
*Modular Cybercrime Ecosystems:* We are seeing a shift toward "modular" service models, such as the recently disrupted *Tycoon 2FA*. These systems allow even low-skilled actors to launch sophisticated "adversary-in-the-middle" attacks that can bypass standard Multi-Factor Authentication (MFA) in real time. -
*Impact on North America:* Approximately *25% of these observed AI-driven threats* are currently targeting the United States and Canada, making this a primary concern for our NARALO constituency.
I believe these developments underscore the need for us to advocate for more resilient, phishing-resistant authentication standards (such as FIDO2/Passkeys) and to update our digital literacy frameworks to reflect this new "AI-upgraded" threat tempo.
You can watch the full briefing here: How AI agents change the threat landscape <https://www.youtube.com/watch?v=Iz5-Bf-4Crg>
I look forward to discussing how we might integrate these insights into our upcoming policy statements and community outreach.
Best regards,
*Mohibul Mahmud*
NARALO / ALAC Candidate
RSSAC Caucus Member
On Mon, Apr 20, 2026 at 12:59 AM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan and team,
I have been following the recent discussion about the need for more practical, end-user-focused materials as NARALO’s DNS abuse work moves forward.
With that in mind, I drafted a plain-language DNS abuse guide for the NARALO community. The goal was to create something practical and accessible, with a focus on actions members can take right away, such as using protective resolvers like Quad9 and CIRA Canadian Shield, as well as encrypted DNS. In that sense, I hoped to help move the conversation from policy definitions toward practical end-user protection.
I have attached the draft here and would welcome your feedback on whether this is the kind of operational outreach resource that would be useful for the committee’s work.
Best regards, Mohibul
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch < evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Hi Mohibul, I am seriously concerned about mission-creep in regards to the initiative that you indicate. ICANN is mandated to oversee Internet names and numbers. That's it. It's in the org's name. NARALO must limit involvement to the extent that C-22 affects the DNS. ISOC (and other groups such as EFF) are the proper venues for addressing broader issues and no part of ICANN has any business duplicating their efforts. NARALO members interested in the issue should be encouraged to participate in these groups rather than take ICANN into areas where it has no authority and little respect. Let's concentrate on the areas of the DNS that impact the At-Large bylaw mandate, such as your initiative public education on end-user mitigation of DNS abuse. Until directly mission-relevant efforts like that gain traction I am hesitant to support spending resources on areas in which ICANN as an entity has no proven institutional competence. There are indeed areas of concern in C-22, but I would urge you to limit any NARALO or broader At-Large activity to the components that directly affect Internet names and numbers. I encourage members to look at the official background information on C-22 <https://www.canada.ca/en/public-safety-canada/news/2026/03/backgrounder--sec...>, as well as other commentary and identify the specific components that might affect the DNS to be potential NARALO areas of action. - Evan On Sat, Apr 25, 2026 at 11:47 AM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: Impact of Canada’s Bill C-22 (Lawful Access Act 2026) on the North American End-User
Dear NARALO Colleagues and At-Large Community,
As we move through the 2026 leadership cycle, I have been closely monitoring legislative developments in Canada that carry significant implications for our regional mission: protecting the rights and security of internet end-users.
I recently followed the discussions hosted by ISOC Canada in Ottawa regarding Bill C-22 (The Lawful Access Act). This bill just cleared a major milestone on April 20, 2026, passing its second reading and moving to the Committee stage (SECU) for detailed study. It introduces several measures that the NARALO community should have on its radar:
- Subscriber Information Access: The bill lowers the evidentiary threshold for law enforcement to access subscriber details from "reasonable grounds to believe" to the lower standard of "reasonable grounds to suspect." - Mandatory Data Retention: Under Part 2, the government could mandate that electronic service providers retain metadata (including location data) for up to a year, creating potential security "honeypots." - Technical Integrity: There are serious concerns about "mandated capabilities" for interception. Experts (including Michael Geist) have flagged that these requirements could introduce systemic vulnerabilities or "backdoors" into the DNS and network architecture.
As a candidate for the ALAC position, I believe NARALO must play a central role in translating these complex national legislative trends into actionable insights for the At-Large community. Whether it is through educational initiatives—similar to the technical translation work I’ve led for the VSIG course—or formal policy comments, we must ensure the end-user's voice is heard.
I would love to hear from our colleagues in the US and the Caribbean—are you seeing similar "lawful access" or metadata retention pressures in your jurisdictions? How can NARALO better coordinate a regional response to these infrastructure-level shifts?
I look forward to discussing this further during our upcoming monthly call.
Best regards,
Mohibul Mahmud
NARALO ALAC Candidate
On Tue, Apr 21, 2026 at 1:43 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
*Subject: AI-Enhanced Phishing and the Evolution of MFA Bypass: Key Insights for At-Large*
*Dear NARALO and ALAC Colleagues,*
As we continue our discussions on DNS abuse and end-user safety, I wanted to share some critical updates regarding the evolving threat landscape, particularly how AI is being used to refine attacks against individual users.
In a recent briefing from Microsoft Security, several trends were highlighted that I believe are directly relevant to our policy work and outreach efforts:
-
*The "Refinement" Shift:* AI is no longer just about the volume of attacks. Threat actors are using it to create highly localized and role-specific messaging. This has resulted in a *450% increase* in phishing click-through rates, as the traditional "red flags" (like poor grammar or generic lures) are disappearing. -
*Modular Cybercrime Ecosystems:* We are seeing a shift toward "modular" service models, such as the recently disrupted *Tycoon 2FA*. These systems allow even low-skilled actors to launch sophisticated "adversary-in-the-middle" attacks that can bypass standard Multi-Factor Authentication (MFA) in real time. -
*Impact on North America:* Approximately *25% of these observed AI-driven threats* are currently targeting the United States and Canada, making this a primary concern for our NARALO constituency.
I believe these developments underscore the need for us to advocate for more resilient, phishing-resistant authentication standards (such as FIDO2/Passkeys) and to update our digital literacy frameworks to reflect this new "AI-upgraded" threat tempo.
You can watch the full briefing here: How AI agents change the threat landscape <https://www.youtube.com/watch?v=Iz5-Bf-4Crg>
I look forward to discussing how we might integrate these insights into our upcoming policy statements and community outreach.
Best regards,
*Mohibul Mahmud*
NARALO / ALAC Candidate
RSSAC Caucus Member
On Mon, Apr 20, 2026 at 12:59 AM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan and team,
I have been following the recent discussion about the need for more practical, end-user-focused materials as NARALO’s DNS abuse work moves forward.
With that in mind, I drafted a plain-language DNS abuse guide for the NARALO community. The goal was to create something practical and accessible, with a focus on actions members can take right away, such as using protective resolvers like Quad9 and CIRA Canadian Shield, as well as encrypted DNS. In that sense, I hoped to help move the conversation from policy definitions toward practical end-user protection.
I have attached the draft here and would welcome your feedback on whether this is the kind of operational outreach resource that would be useful for the committee’s work.
Best regards, Mohibul
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch < evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Agreed ________________________________ From: Evan Leibovitch via NA-Discuss <na-discuss@icann.org> Sent: Saturday, April 25, 2026 12:29 PM To: Mohibul Mahmud <mohibul.mahmud@gmail.com> Cc: NA Discuss <na-discuss@atlarge-lists.icann.org>; Greg Shatan <gregshatanipc@gmail.com> Subject: [NA-Discuss] Re: Impact of Canada’s Bill C-22 (Lawful Access Act 2026) on the North American End-User Hi Mohibul, I am seriously concerned about mission-creep in regards to the initiative that you indicate. ICANN is mandated to oversee Internet names and numbers. That's it. It's in the org's name. NARALO must limit involvement to the extent that C-22 affects the DNS. ISOC (and other groups such as EFF) are the proper venues for addressing broader issues and no part of ICANN has any business duplicating their efforts. NARALO members interested in the issue should be encouraged to participate in these groups rather than take ICANN into areas where it has no authority and little respect. Let's concentrate on the areas of the DNS that impact the At-Large bylaw mandate, such as your initiative public education on end-user mitigation of DNS abuse. Until directly mission-relevant efforts like that gain traction I am hesitant to support spending resources on areas in which ICANN as an entity has no proven institutional competence. There are indeed areas of concern in C-22, but I would urge you to limit any NARALO or broader At-Large activity to the components that directly affect Internet names and numbers. I encourage members to look at the official background information on C-22<https://www.canada.ca/en/public-safety-canada/news/2026/03/backgrounder--sec...>, as well as other commentary and identify the specific components that might affect the DNS to be potential NARALO areas of action. - Evan On Sat, Apr 25, 2026 at 11:47 AM Mohibul Mahmud <mohibul.mahmud@gmail.com<mailto:mohibul.mahmud@gmail.com>> wrote: Subject: Impact of Canada’s Bill C-22 (Lawful Access Act 2026) on the North American End-User Dear NARALO Colleagues and At-Large Community, As we move through the 2026 leadership cycle, I have been closely monitoring legislative developments in Canada that carry significant implications for our regional mission: protecting the rights and security of internet end-users. I recently followed the discussions hosted by ISOC Canada in Ottawa regarding Bill C-22 (The Lawful Access Act). This bill just cleared a major milestone on April 20, 2026, passing its second reading and moving to the Committee stage (SECU) for detailed study. It introduces several measures that the NARALO community should have on its radar: * Subscriber Information Access: The bill lowers the evidentiary threshold for law enforcement to access subscriber details from "reasonable grounds to believe" to the lower standard of "reasonable grounds to suspect." * Mandatory Data Retention: Under Part 2, the government could mandate that electronic service providers retain metadata (including location data) for up to a year, creating potential security "honeypots." * Technical Integrity: There are serious concerns about "mandated capabilities" for interception. Experts (including Michael Geist) have flagged that these requirements could introduce systemic vulnerabilities or "backdoors" into the DNS and network architecture. As a candidate for the ALAC position, I believe NARALO must play a central role in translating these complex national legislative trends into actionable insights for the At-Large community. Whether it is through educational initiatives—similar to the technical translation work I’ve led for the VSIG course—or formal policy comments, we must ensure the end-user's voice is heard. I would love to hear from our colleagues in the US and the Caribbean—are you seeing similar "lawful access" or metadata retention pressures in your jurisdictions? How can NARALO better coordinate a regional response to these infrastructure-level shifts? I look forward to discussing this further during our upcoming monthly call. Best regards, Mohibul Mahmud NARALO ALAC Candidate On Tue, Apr 21, 2026 at 1:43 PM Mohibul Mahmud <mohibul.mahmud@gmail.com<mailto:mohibul.mahmud@gmail.com>> wrote: Subject: AI-Enhanced Phishing and the Evolution of MFA Bypass: Key Insights for At-Large Dear NARALO and ALAC Colleagues, As we continue our discussions on DNS abuse and end-user safety, I wanted to share some critical updates regarding the evolving threat landscape, particularly how AI is being used to refine attacks against individual users. In a recent briefing from Microsoft Security, several trends were highlighted that I believe are directly relevant to our policy work and outreach efforts: * The "Refinement" Shift: AI is no longer just about the volume of attacks. Threat actors are using it to create highly localized and role-specific messaging. This has resulted in a 450% increase in phishing click-through rates, as the traditional "red flags" (like poor grammar or generic lures) are disappearing. * Modular Cybercrime Ecosystems: We are seeing a shift toward "modular" service models, such as the recently disrupted Tycoon 2FA. These systems allow even low-skilled actors to launch sophisticated "adversary-in-the-middle" attacks that can bypass standard Multi-Factor Authentication (MFA) in real time. * Impact on North America: Approximately 25% of these observed AI-driven threats are currently targeting the United States and Canada, making this a primary concern for our NARALO constituency. I believe these developments underscore the need for us to advocate for more resilient, phishing-resistant authentication standards (such as FIDO2/Passkeys) and to update our digital literacy frameworks to reflect this new "AI-upgraded" threat tempo. You can watch the full briefing here: How AI agents change the threat landscape<https://www.youtube.com/watch?v=Iz5-Bf-4Crg> I look forward to discussing how we might integrate these insights into our upcoming policy statements and community outreach. Best regards, Mohibul Mahmud NARALO / ALAC Candidate RSSAC Caucus Member On Mon, Apr 20, 2026 at 12:59 AM Mohibul Mahmud <mohibul.mahmud@gmail.com<mailto:mohibul.mahmud@gmail.com>> wrote: Hi Evan and team, I have been following the recent discussion about the need for more practical, end-user-focused materials as NARALO’s DNS abuse work moves forward. With that in mind, I drafted a plain-language DNS abuse guide for the NARALO community. The goal was to create something practical and accessible, with a focus on actions members can take right away, such as using protective resolvers like Quad9 and CIRA Canadian Shield, as well as encrypted DNS. In that sense, I hoped to help move the conversation from policy definitions toward practical end-user protection. I have attached the draft here and would welcome your feedback on whether this is the kind of operational outreach resource that would be useful for the committee’s work. Best regards, Mohibul On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud <mohibul.mahmud@gmail.com<mailto:mohibul.mahmud@gmail.com>> wrote: Hi Evan, Glenn, and all, Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience. I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread: • ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call. Best regards, Mohibul Mahmud NARALO Member On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch <evanleibovitch@gmail.com<mailto:evanleibovitch@gmail.com>> wrote: Hi Mohibul, As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future. Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue. In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield"<https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20<http://149.112.121.20/149.112.122.20>). I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9. Even further protection is available at the DNS level if you want to extend blocking to ads or adult content. Again, thanks for the suggestion. I hope it gets picked up and is offered some resources. - Evan On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud <mohibul.mahmud@gmail.com<mailto:mohibul.mahmud@gmail.com>> wrote: Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide Dear Glenn and Evan, I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO. The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13). However, a significant gap remains between these high-level policy discussions and the immediate, practical needs of the general internet user. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats. To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs. This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal. Best regards, Mohibul (360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube<https://www.youtube.com/watch?v=L1csoImspvA> On Mon, Mar 9, 2026 at 8:57 PM Evan Leibovitch via NA-Discuss <na-discuss@icann.org<mailto: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<mailto: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<http://www.virtualsig.org> YOUR SOURCE FOR INTERNET GOVERNANCE EDUCATION Mobile 437-237-4655 ------ NA-Discuss mailing list -- na-discuss@icann.org<mailto:na-discuss@icann.org> To unsubscribe send an email to na-discuss-leave@icann.org<mailto: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<mailto:na-discuss@icann.org> To unsubscribe send an email to na-discuss-leave@icann.org<mailto: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 -- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Hi All Here is a summary of the Canadian Bill C-22 as a powerpoint G Glenn McKnight, MA Virtual School of Internet Governance Chief Information Officer www.virtualsig.org *YOUR SOURCE FOR INTERNET GOVERNANCE EDUCATION * *Mobile 437-237-4655* On Sat, 25 Apr 2026 at 11:47, Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: Impact of Canada’s Bill C-22 (Lawful Access Act 2026) on the North American End-User
Dear NARALO Colleagues and At-Large Community,
As we move through the 2026 leadership cycle, I have been closely monitoring legislative developments in Canada that carry significant implications for our regional mission: protecting the rights and security of internet end-users.
I recently followed the discussions hosted by ISOC Canada in Ottawa regarding Bill C-22 (The Lawful Access Act). This bill just cleared a major milestone on April 20, 2026, passing its second reading and moving to the Committee stage (SECU) for detailed study. It introduces several measures that the NARALO community should have on its radar:
- Subscriber Information Access: The bill lowers the evidentiary threshold for law enforcement to access subscriber details from "reasonable grounds to believe" to the lower standard of "reasonable grounds to suspect." - Mandatory Data Retention: Under Part 2, the government could mandate that electronic service providers retain metadata (including location data) for up to a year, creating potential security "honeypots." - Technical Integrity: There are serious concerns about "mandated capabilities" for interception. Experts (including Michael Geist) have flagged that these requirements could introduce systemic vulnerabilities or "backdoors" into the DNS and network architecture.
As a candidate for the ALAC position, I believe NARALO must play a central role in translating these complex national legislative trends into actionable insights for the At-Large community. Whether it is through educational initiatives—similar to the technical translation work I’ve led for the VSIG course—or formal policy comments, we must ensure the end-user's voice is heard.
I would love to hear from our colleagues in the US and the Caribbean—are you seeing similar "lawful access" or metadata retention pressures in your jurisdictions? How can NARALO better coordinate a regional response to these infrastructure-level shifts?
I look forward to discussing this further during our upcoming monthly call.
Best regards,
Mohibul Mahmud
NARALO ALAC Candidate
On Tue, Apr 21, 2026 at 1:43 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
*Subject: AI-Enhanced Phishing and the Evolution of MFA Bypass: Key Insights for At-Large*
*Dear NARALO and ALAC Colleagues,*
As we continue our discussions on DNS abuse and end-user safety, I wanted to share some critical updates regarding the evolving threat landscape, particularly how AI is being used to refine attacks against individual users.
In a recent briefing from Microsoft Security, several trends were highlighted that I believe are directly relevant to our policy work and outreach efforts:
-
*The "Refinement" Shift:* AI is no longer just about the volume of attacks. Threat actors are using it to create highly localized and role-specific messaging. This has resulted in a *450% increase* in phishing click-through rates, as the traditional "red flags" (like poor grammar or generic lures) are disappearing. -
*Modular Cybercrime Ecosystems:* We are seeing a shift toward "modular" service models, such as the recently disrupted *Tycoon 2FA*. These systems allow even low-skilled actors to launch sophisticated "adversary-in-the-middle" attacks that can bypass standard Multi-Factor Authentication (MFA) in real time. -
*Impact on North America:* Approximately *25% of these observed AI-driven threats* are currently targeting the United States and Canada, making this a primary concern for our NARALO constituency.
I believe these developments underscore the need for us to advocate for more resilient, phishing-resistant authentication standards (such as FIDO2/Passkeys) and to update our digital literacy frameworks to reflect this new "AI-upgraded" threat tempo.
You can watch the full briefing here: How AI agents change the threat landscape <https://www.youtube.com/watch?v=Iz5-Bf-4Crg>
I look forward to discussing how we might integrate these insights into our upcoming policy statements and community outreach.
Best regards,
*Mohibul Mahmud*
NARALO / ALAC Candidate
RSSAC Caucus Member
On Mon, Apr 20, 2026 at 12:59 AM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan and team,
I have been following the recent discussion about the need for more practical, end-user-focused materials as NARALO’s DNS abuse work moves forward.
With that in mind, I drafted a plain-language DNS abuse guide for the NARALO community. The goal was to create something practical and accessible, with a focus on actions members can take right away, such as using protective resolvers like Quad9 and CIRA Canadian Shield, as well as encrypted DNS. In that sense, I hoped to help move the conversation from policy definitions toward practical end-user protection.
I have attached the draft here and would welcome your feedback on whether this is the kind of operational outreach resource that would be useful for the committee’s work.
Best regards, Mohibul
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch < evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
Thanks for the information Glenn. An ICANN which restricts itself to the backwaters of a deeply technical system and policy focused elite with no connection to the outside world has little value to the end users across the world. When I walk down the street of my hometown in Stratford, the people I pass have no clue of the importance of the DNS system and policy. Ivory tower conversations held in rarified air are meaningless to them without being educated. Cheers David On Sun, Apr 26, 2026 at 8:46 AM Glenn McKnight via NA-Discuss < na-discuss@icann.org> wrote:
Hi All Here is a summary of the Canadian Bill C-22 as a powerpoint G Glenn McKnight, MA Virtual School of Internet Governance Chief Information Officer www.virtualsig.org *YOUR SOURCE FOR INTERNET GOVERNANCE EDUCATION * *Mobile 437-237-4655*
On Sat, 25 Apr 2026 at 11:47, Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: Impact of Canada’s Bill C-22 (Lawful Access Act 2026) on the North American End-User
Dear NARALO Colleagues and At-Large Community,
As we move through the 2026 leadership cycle, I have been closely monitoring legislative developments in Canada that carry significant implications for our regional mission: protecting the rights and security of internet end-users.
I recently followed the discussions hosted by ISOC Canada in Ottawa regarding Bill C-22 (The Lawful Access Act). This bill just cleared a major milestone on April 20, 2026, passing its second reading and moving to the Committee stage (SECU) for detailed study. It introduces several measures that the NARALO community should have on its radar:
- Subscriber Information Access: The bill lowers the evidentiary threshold for law enforcement to access subscriber details from "reasonable grounds to believe" to the lower standard of "reasonable grounds to suspect." - Mandatory Data Retention: Under Part 2, the government could mandate that electronic service providers retain metadata (including location data) for up to a year, creating potential security "honeypots." - Technical Integrity: There are serious concerns about "mandated capabilities" for interception. Experts (including Michael Geist) have flagged that these requirements could introduce systemic vulnerabilities or "backdoors" into the DNS and network architecture.
As a candidate for the ALAC position, I believe NARALO must play a central role in translating these complex national legislative trends into actionable insights for the At-Large community. Whether it is through educational initiatives—similar to the technical translation work I’ve led for the VSIG course—or formal policy comments, we must ensure the end-user's voice is heard.
I would love to hear from our colleagues in the US and the Caribbean—are you seeing similar "lawful access" or metadata retention pressures in your jurisdictions? How can NARALO better coordinate a regional response to these infrastructure-level shifts?
I look forward to discussing this further during our upcoming monthly call.
Best regards,
Mohibul Mahmud
NARALO ALAC Candidate
On Tue, Apr 21, 2026 at 1:43 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
*Subject: AI-Enhanced Phishing and the Evolution of MFA Bypass: Key Insights for At-Large*
*Dear NARALO and ALAC Colleagues,*
As we continue our discussions on DNS abuse and end-user safety, I wanted to share some critical updates regarding the evolving threat landscape, particularly how AI is being used to refine attacks against individual users.
In a recent briefing from Microsoft Security, several trends were highlighted that I believe are directly relevant to our policy work and outreach efforts:
-
*The "Refinement" Shift:* AI is no longer just about the volume of attacks. Threat actors are using it to create highly localized and role-specific messaging. This has resulted in a *450% increase* in phishing click-through rates, as the traditional "red flags" (like poor grammar or generic lures) are disappearing. -
*Modular Cybercrime Ecosystems:* We are seeing a shift toward "modular" service models, such as the recently disrupted *Tycoon 2FA*. These systems allow even low-skilled actors to launch sophisticated "adversary-in-the-middle" attacks that can bypass standard Multi-Factor Authentication (MFA) in real time. -
*Impact on North America:* Approximately *25% of these observed AI-driven threats* are currently targeting the United States and Canada, making this a primary concern for our NARALO constituency.
I believe these developments underscore the need for us to advocate for more resilient, phishing-resistant authentication standards (such as FIDO2/Passkeys) and to update our digital literacy frameworks to reflect this new "AI-upgraded" threat tempo.
You can watch the full briefing here: How AI agents change the threat landscape <https://www.youtube.com/watch?v=Iz5-Bf-4Crg>
I look forward to discussing how we might integrate these insights into our upcoming policy statements and community outreach.
Best regards,
*Mohibul Mahmud*
NARALO / ALAC Candidate
RSSAC Caucus Member
On Mon, Apr 20, 2026 at 12:59 AM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Hi Evan and team,
I have been following the recent discussion about the need for more practical, end-user-focused materials as NARALO’s DNS abuse work moves forward.
With that in mind, I drafted a plain-language DNS abuse guide for the NARALO community. The goal was to create something practical and accessible, with a focus on actions members can take right away, such as using protective resolvers like Quad9 and CIRA Canadian Shield, as well as encrypted DNS. In that sense, I hoped to help move the conversation from policy definitions toward practical end-user protection.
I have attached the draft here and would welcome your feedback on whether this is the kind of operational outreach resource that would be useful for the committee’s work.
Best regards, Mohibul
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch < evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud < mohibul.mahmud@gmail.com> wrote:
> Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide > > Dear Glenn and Evan, > > I am writing to synthesize the key takeaways from the ICANN 82 > roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," > and to propose a concrete next step for NARALO. > > The session highlighted a sophisticated, three-dimensional landscape > regarding DNS abuse. On one hand, we have the formal ICANN policy > definitions focusing on malware, botnets, phishing, pharming, and spam. On > the other, we discussed the cutting-edge AI defense mechanisms presented by > panelists like Jeff Bedser of CleanDNS, which leverage machine learning for > near real-time detection (13:13). > > However, a significant gap remains between these high-level policy > discussions and the immediate, *practical needs of the general > internet user*. As Evan highlighted in his response, many average > users are bypassed by these technical efforts and remain vulnerable to > daily threats. > > To bridge this gap, I propose that NARALO develop a simplified, > one-page guide for our members. This guide would synthesize the official > ICANN focus on DNS abuse with a step-by-step tutorial on implementing > effective, DIY mitigation tools — such as utilizing specific DNS providers > like Quad9 (9.9.9.9) or RBLs. > > This initiative would directly align NARALO's policy-driven mission > with tangible, practical benefits for our community. I look forward to > hearing your thoughts on this proposal. > > Best regards, > Mohibul > > > (360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - > YouTube <https://www.youtube.com/watch?v=L1csoImspvA> > > > > > > > On Mon, Mar 9, 2026 at 8:57 PM 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. > >
-- 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.
On Sun, Apr 26, 2026 at 10:18 AM David Mackey via NA-Discuss < na-discuss@icann.org> wrote:
When I walk down the street of my hometown in Stratford, the people I pass have no clue of the importance of the DNS system and policy.
Sure, but you could say the same thing about any significant public infrastructure. Replace "the DNS" with "sewage", "electrical grid", "produce supply chain", "postal mail", "housing swans during the winter", "flood management", etc in the above sentence and it still holds true. Such underlying systems are generally ignored by the public until something goes catastrophically wrong, which is why "US air traffic control" wouldn't apply in this context anymore. Ivory tower conversations held in rarified air are meaningless to them
without being educated.
I challenge the assertion that most people *need* to be educated in the DNS, anymore than they need to be educated on how water comes to their home -- clean and in sufficient pressure to come out the tap. Generally speaking, the public just trusts that enough expertise exists in these fields to keep all this infrastructure working well enough that it *doesn't* need to be thought about. And if such expertise occasionally takes the form of "ivory tower conversations held in rarified air", the public generally doesn't care so long as the result works well enough to remain invisible. - Evan
I don't think David is speaking of educating the mass of the general public on the details. As Evan notes, that's not necessary, even if it were feasible. But what is both possible and necessary is to educate those writing the law. At a high level, the members of the legislature. In detail, the members of their staffs who do the research and drafting that go in to the bill. And advise their various members who were not involved in the drafting process on whether to support it. Granted, some few of them may already be aware (for good or ill). But most of them probably are not. The latter are the ones we can, and should, be reaching out to as advocates for users of the Internet. Bill Jouris Yahoo Mail: Search, Organize, Conquer On Sun, Apr 26, 2026 at 9:42 AM, Evan Leibovitch via NA-Discuss<na-discuss@icann.org> wrote: On Sun, Apr 26, 2026 at 10:18 AM David Mackey via NA-Discuss <na-discuss@icann.org> wrote: When I walk down the street of my hometown in Stratford, the people I pass have no clue of the importance of the DNS system and policy. Sure, but you could say the same thing about any significant public infrastructure.Replace "the DNS" with "sewage", "electrical grid", "produce supply chain", "postal mail", "housing swans during the winter", "flood management", etc in the above sentence and it still holds true.Such underlying systems are generally ignored by the public until something goes catastrophically wrong, which is why "US air traffic control" wouldn't apply in this context anymore. Ivory tower conversations held in rarified air are meaningless to them without being educated. I challenge the assertion that most people *need* to be educated in the DNS, anymore than they need to be educated on how water comes to their home -- clean and in sufficient pressure to come out the tap. Generally speaking, the public just trusts that enough expertise exists in these fields to keep all this infrastructure working well enough that it *doesn't* need to be thought about. And if such expertise occasionally takes the form of "ivory tower conversations held in rarified air", the public generally doesn't care so long as the result works well enough to remain invisible. - Evan ------ 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.
Very nice, excellent work. I hope this becomes an integral part of any abuse mitigation toolkit. - Evan On Mon, Apr 20, 2026 at 12:59 AM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan and team,
I have been following the recent discussion about the need for more practical, end-user-focused materials as NARALO’s DNS abuse work moves forward.
With that in mind, I drafted a plain-language DNS abuse guide for the NARALO community. The goal was to create something practical and accessible, with a focus on actions members can take right away, such as using protective resolvers like Quad9 and CIRA Canadian Shield, as well as encrypted DNS. In that sense, I hoped to help move the conversation from policy definitions toward practical end-user protection.
I have attached the draft here and would welcome your feedback on whether this is the kind of operational outreach resource that would be useful for the committee’s work.
Best regards, Mohibul
On Sun, Mar 22, 2026 at 11:26 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Hi Evan, Glenn, and all,
Thank you, Evan — this is a wonderful and highly relevant addition to the discussion. CIRA's Canadian Shield is something I was not previously aware of, and it strengthens the case for our proposed guide considerably. The combination of DNSSEC support, encrypted DNS over TLS and HTTPS, and the privacy protections you highlighted makes it a compelling recommendation for Canadian members specifically — alongside Quad9 for the broader North American audience.
I think we now have the foundation for a genuinely useful resource. The outline is taking shape naturally from this thread:
• ICANN's official DNS abuse definitions as the policy anchor • Quad9 (9.9.9.9) for general international users • CIRA Canadian Shield for Canadian users • RBLs such as Spamhaus for email protection • Optional advanced protections including DNS over TLS and HTTPS
I would love to see this move forward as a NARALO initiative. I am happy to contribute to the effort and look forward to discussing next steps with the group — perhaps we can identify the right home for this on the agenda of an upcoming NARALO Monthly Call.
Best regards, Mohibul Mahmud NARALO Member
On Sun, Mar 22, 2026 at 9:39 PM Evan Leibovitch <evanleibovitch@gmail.com> wrote:
Hi Mohibul,
As it turns out, I have been doing some thought and research on this topic, and may expand further on it in the future.
Your idea for an end-user guide is an excellent one and I offer my assistance should NARALO pursue.
In my research I found that the only entity in the whole Internet Governance field that has given this issue any attention is Canada's ccTLD, CIRA. In a project called "Canadian Shield" <https://www.cira.ca/en/canadian-shield/>, CIRA has provided mobile apps and configuration guidance (for desktops and routers) on how to use its own public DNS servers (149.112.121.20/149.112.122.20).
I find in my own tests that Canadian Shield servers consistently provide the fastest response ... though that might not be the case for non-Canadians. As well as DNSSEC it supports encrypted DNS over TLS or HTTPS, which is also important in privacy considerations if you suspect your ISP is collecting data on what users access. Personally I use both CIRA and Quad9.
Even further protection is available at the DNS level if you want to extend blocking to ads or adult content.
Again, thanks for the suggestion. I hope it gets picked up and is offered some resources.
- Evan
On Sat, Mar 21, 2026 at 2:51 PM Mohibul Mahmud <mohibul.mahmud@gmail.com> wrote:
Subject: DNS Abuse & AI – Proposed NARALO Action: Member Guide
Dear Glenn and Evan,
I am writing to synthesize the key takeaways from the ICANN 82 roundtable discussion, "DNS Abuse and AI: Combatting and Enabling Threats," and to propose a concrete next step for NARALO.
The session highlighted a sophisticated, three-dimensional landscape regarding DNS abuse. On one hand, we have the formal ICANN policy definitions focusing on malware, botnets, phishing, pharming, and spam. On the other, we discussed the cutting-edge AI defense mechanisms presented by panelists like Jeff Bedser of CleanDNS, which leverage machine learning for near real-time detection (13:13).
However, a significant gap remains between these high-level policy discussions and the immediate, *practical needs of the general internet user*. As Evan highlighted in his response, many average users are bypassed by these technical efforts and remain vulnerable to daily threats.
To bridge this gap, I propose that NARALO develop a simplified, one-page guide for our members. This guide would synthesize the official ICANN focus on DNS abuse with a step-by-step tutorial on implementing effective, DIY mitigation tools — such as utilizing specific DNS providers like Quad9 (9.9.9.9) or RBLs.
This initiative would directly align NARALO's policy-driven mission with tangible, practical benefits for our community. I look forward to hearing your thoughts on this proposal.
Best regards, Mohibul
(360) DNS Abuse and AI: Combatting and Enabling Threats (EDIT) - YouTube <https://www.youtube.com/watch?v=L1csoImspvA>
On Mon, Mar 9, 2026 at 8:57 PM 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.
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
-- Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
participants (11)
-
Ana Teresa Rodríguez-Lebrón -
Bill Jouris -
David Mackey -
Eduardo Diaz -
Evan Leibovitch -
Glenn McKnight -
Joly MacFie -
Jonathan Zuck -
Judith Hellerstein -
Mohibul Mahmud -
Muhammad Ali