May 2026 - Gnso-dnsabuse-pdp

ICANN86 GNSO Sessions - How to Get Organized / Remote Participation Details
by Julie Bisland May 13, 2026

May 13, 2026

Dear all, With ICANN86<https://meetings.icann.org/en/meetings/icann86/> just around the corner, please take a moment to read the information below for a seamless and successful meeting. ICANN86 key dates: * Prep Week will take place virtually 20 & 21 May 2026. * Deadline for IN-PERSON registration is 07 June 2026. * ICANN86 will take place in Seville 08 - 11 June 2026. On-site registration will not be available. Registration for ICANN86 does not automatically create a user account on sched.com. Instructions and guides to register as well as personalize your schedule can be found on these pages: * Visit this page to REGISTER: https://meetings.icann.org/en/meetings/icann86/ * General information about Seville, hotels, transportation and rates, and links to food options can also be found here * The ICANN86 Schedule: https://icann86.sched.com/ * Instructions for personalizing your schedule can also be found here There will be no calendar invitations sent, as the meeting schedule allows you to download all sessions of interest to your individual calendars A reminder to review the Participation Tools page and update Zoom * All sessions that use Zoom rooms, access details will be available 24hrs prior. * Visit the Participation Tools page<https://meetings.icann.org/en/remote-participation> for links to download the latest version of Zoom for access to the ICANN Meeting sessions. * Please see the ICANN Meeting VIRTUAL AND IN-PERSON PARTICIPATION GUIDES in the blue box on the right side of the Participation Tools page for more information on how to get the most out of the virtual meeting tools. * If participating on-site, please read the Frequently Asked Questions here<https://meetings.icann.org/en/meetings/icann86/#faq>. Links to Bookmark ICANN86 Meeting Schedule<https://icann86.sched.com/> ICANN86 GNSO Remote Participation Wiki Page<https://icann-community.atlassian.net/wiki/x/AQB0Og> GNSO Session agendas<https://icann-community.atlassian.net/wiki/x/AYBUOg> For all GNSO meeting-related queries, please email us at: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> and we will be more than happy to assist! Kind regards, GNSO SO/AC Support team -- Julie Bisland Policy Operations Analyst (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Action Items and High-Level notes: DNSAM PDP1 11 May 12:30 UTC
by Feodora Hamza May 11, 2026

May 11, 2026

Dear DNSAM PDP1, Please find below the high-level notes and Action Items from today’s WG call. Our next meeting is scheduled for Monday, 18 May at 12:30 UTC. Kind regards, Feodora on behalf of Support Staff 2026-05-11 DNS Abuse Mitigation PDP1 WG<https://icann-community.atlassian.net/wiki/spaces/DAMP1/pages/935952445/202…> Action Items: * Staff to provide strawperson language on CQ5 and 6 based on today`s WG discussion. * WG members to review and provide feedback to CQ1-4 Important documents/links: * Wiki/Slides: https://icann-community.atlassian.net/wiki/spaces/DAMP1/pages/935952445/202… * Recording: https://icann.zoom.us/rec/play/czEsEiPY0j9r2m-sKxkX1D072T1q9fwm8rh01IRoLj-R… * CollabDoc: https://docs.google.com/document/d/1GxM-Yrgv6sZPEYU8ikW4cRM5YqWsJuWGiQyO39p… High-Level Notes: 1. Welcome (5min) * Nick Wenban-Smith chaired the meeting, 1. PDP Updates (10min) * Vice Chair presented the path towards ICANN86 and what to expect. * VC shared some best practices when discussing and drafting policy recommendations. * Please provide rationale and alternative language, in case you/your SG cannot live with current draft language. 1. Start deliberations on CQ5 (35min) * WG members noted that ADCs are primarily investigative mechanisms intended to identify related abusive domains, while mitigation actions (such as suspension etc.) fall under existing RAA obligations and are out of scope for this PDP. * WG members noted that a recourse mechanism (outside of current PDP scope) should be added to the list of topics that can be addressed in the future by GNSO Council. * The group discussed whether ADC activities themselves could create adverse impacts for legitimate registrants and what these could be. * WG noted that should ADC have adverse impact on legitimate registrants the PDP should discuss whether remedies exist. * WG members noted existing procedures related to abuse mitigation and registrant protections. 1. Start deliberations on CQ6 (35min) * WG members discussed whether ADC reviews and mitigation actions should be governed by fixed timelines or continue under the existing RAA “promptly” standard. * Many members supported maintaining the existing flexible standard: * They noted DNS abuse cases vary significantly in complexity, urgency, registrar size, and evidentiary requirements. * Members noted that “promptly” already appears multiple times in the RAA and is enforceable through contextual compliance review. * WG members noted potential concerns that rigid deadlines could encourage rushed investigations, false positives, fragmented operational processes, or inconsistent mitigation quality. * Other WG members noted more specific guidance or timelines and pointed out that defined timelines would improve accountability, consistency, and auditability. 1. AOB (5min)

1 0

NCSG Q5 Proposed Language
by Michaela Nakayama Shapiro May 11, 2026

May 11, 2026

INTERNAL Dear all, Ahead of today's meeting, the NCSG has prepared draft language for charter question 5. We look forward to further discussion, and are more than happy to answer any questions. Best, NCSG/NCUC -- Where enforcement actions affect multiple domains based on an association determination, appropriate safeguards must be available to protect registrants from unintended harm. Registrants and end-users have the right to mechanisms for remedy related to DNS abuse mitigation action(s). Registrars must ensure that mitigation measures are proportionate, transparent, and supported by well-evidenced DNS Abuse. Affected registrants should be provided an appeal process. This includes, but is not limited to: * providing avenues for impacted registrants to seek clarification or review through dispute or support channels; * clear procedures for the registrant to appeal the mitigation action(s) * where relevant, for the reversal of any mitigation action(s), where applicable Michaela Nakayama Shapiro (she/her/hers) Programme Officer - Censorship [cid:logo_1c766458-35ee-431a-9a22-e00b47cd2091.png]<https://www.article19.org> Defending freedom of expression and information www.article19.org<https://www.article19.org> Subscribe to our Newsletter<https://www.article19.org/ie-sign-up/> [cid:newsletter_02744340-c607-4374-8a37-11b8b216096d.png] <https://www.article19.org/ie-sign-up> Note: we work half day Fridays (AM) Follow us [cid:bluesky1x_864ef831-9476-4116-88b8-2a3410741630.png]<https://bsky.app/profile/article19.bsky.social> [cid:facebook_2853baa0-f060-42e6-b448-6a8788c1b5dd.png] <https://www.facebook.com/article19org/> [cid:youtube_ffe95af1-d962-4acd-ab59-4eb4ea07466e.png] <https://www.youtube.com/channel/UCDB6E_x0xRSfF62b872n9YQ> [cid:linkedin_199dc89c-14aa-41cd-b2a7-37b8ae8d667d.png] <https://www.linkedin.com/company/article19> [cid:instagram_05fbcc72-6df2-442b-8c34-146d0e9d8c41.png] <https://www.instagram.com/article19org/> [cid:x_d21e0607-da5a-44a7-80c7-e2d86bc18a92.png] <https://twitter.com/intent/follow?screen_name=article19org> [cid:targetedemailsigbannerapr16_e39b35dc-4060-4323-bdf4-a128a2e1d0a3.png]<https://www.article19.org/resources/targeted/?pk_campaign=email_signatures&…>

5 5

Meeting Invitation / DNS Abuse Mitigation PDP1 WG | Monday, 18 May 2026
by Julie Bisland May 11, 2026

May 11, 2026

Dear all, The next DNS Abuse Mitigation PDP1 WG call will take place on Monday, 18 May 2026 at 12:30 UTC for 90 minutes. Join from PC, Mac, iPad, or Android - Zoom Webinar: https://icann.zoom.us/j/91807711636?pwd=q6XCt8cWQU9m3fGgSojQ5X07pbnX6a.1 Passcode:+X8RaawVrW Phone one-tap: +13126266799,,91807711636#,,,,*0006343077# US (Chicago) +13462487799,,91807711636#,,,,*0006343077# US (Houston) Webinar ID: 918 0771 1636 Passcode: 0006343077 International numbers available: https://icann.zoom.us/u/a9jfXWLB8 * 2026 Meetings wiki: https://icann-community.atlassian.net/wiki/x/B4CWLQ ALL: Before joining the call * Please send apologies to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only (members: please include if an alternate is joining on your behalf) * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…>, the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…>, and the ICANN Community Participant Code of Conduct<https://www.icann.org/en/system/files/files/adopted-icann-community-partici…>. * Staff will promote members, participants, and alternates to panelist once joined. OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie -- Julie Bisland Policy Operations Analyst (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Post Call / DNS Abuse Mitigation PDP1 WG / Monday, 11 May 2026
by Julie Bisland May 11, 2026

May 11, 2026

Dear all, All recordings for the DNS Abuse Mitigation PDP1 WG call held on Monday, 11 May 2026 at 12:30 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/PYDJNw> (attendance included), which can also be accessed via the GNSO Master calendar<https://gnso.icann.org/en/group-activities/calendar/2026>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat) * Transcript * Agenda and Notes/Action Items For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-dnsabuse-pdp@icann.org/> and the main wiki page<https://icann-community.atlassian.net/wiki/x/zoKmLQ>. Thank you. With kind regards, Julie -- Julie Bisland Policy Operations Analyst (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

**15-MINUTE REMINDER** Meeting Invitation / DNS Abuse Mitigation PDP1 WG | Monday, 11 May 2026
by Julie Bisland May 11, 2026

May 11, 2026

**15-MINUTE REMINDER** Dear all, The next DNS Abuse Mitigation PDP1 WG call will take place on Monday, 11 May 2026 at 12:30 UTC for 90 minutes. Join from PC, Mac, iPad, or Android - Zoom Webinar: https://icann.zoom.us/j/91807711636?pwd=q6XCt8cWQU9m3fGgSojQ5X07pbnX6a.1 Passcode:+X8RaawVrW Phone one-tap: +13126266799,,91807711636#,,,,*0006343077# US (Chicago) +13462487799,,91807711636#,,,,*0006343077# US (Houston) Webinar ID: 918 0771 1636 Passcode: 0006343077 International numbers available: https://icann.zoom.us/u/a9jfXWLB8 * 2026 Meetings wiki: https://icann-community.atlassian.net/wiki/x/B4CWLQ ALL: Before joining the call * Please send apologies to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only (members: please include if an alternate is joining on your behalf) * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…>, the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…>, and the ICANN Community Participant Code of Conduct<https://www.icann.org/en/system/files/files/adopted-icann-community-partici…>. * Staff will promote members, participants, and alternates to panelist once joined. OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie -- Julie Bisland Policy Operations Analyst (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Proposed Agenda DNSAM PDP1 11 May 12:30 UTC
by Feodora Hamza May 8, 2026

May 8, 2026

Dear DNSAM PDP1, Please see below the proposed agenda for our call on Monday, 11 May at 12:30 UTC. 1. Welcome (5min) 2. PDP Updates (10min) 3. Start deliberations on CQ5 (35min) 4. Start deliberations on CQ6 (35min) 5. AOB (5min) Please see the early input on CQ5 and CQ6 in the Collaboration Document.<https://docs.google.com/document/d/1GxM-Yrgv6sZPEYU8ikW4cRM5YqWsJuWGiQyO39p…> Kind regards, Feodora on behalf of Support Staff

1 0

REMINDER | Meeting Invitation / DNS Abuse Mitigation PDP1 WG | Monday, 11 May 2026
by Terri Agnew May 8, 2026

May 8, 2026

Dear all, The next DNS Abuse Mitigation PDP1 WG call will take place on Monday, 11 May 2026 at 12:30 UTC for 90 minutes. Join from PC, Mac, iPad, or Android - Zoom Webinar: https://icann.zoom.us/j/91807711636?pwd=q6XCt8cWQU9m3fGgSojQ5X07pbnX6a.1 Passcode:+X8RaawVrW Phone one-tap: +13126266799,,91807711636#,,,,*0006343077# US (Chicago) +13462487799,,91807711636#,,,,*0006343077# US (Houston) Webinar ID: 918 0771 1636 Passcode: 0006343077 International numbers available: https://icann.zoom.us/u/a9jfXWLB8 * 2026 Meetings wiki: https://icann-community.atlassian.net/wiki/x/B4CWLQ ALL: Before joining the call * Please send apologies to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only (members: please include if an alternate is joining on your behalf) * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…>, the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…>, and the ICANN Community Participant Code of Conduct<https://www.icann.org/en/system/files/files/adopted-icann-community-partici…>. * Staff will promote members, participants, and alternates to panelist once joined. OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie -- Julie Bisland Policy Operations Analyst (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Re: [MALICIOUS URLS, FILTERED]ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain
by Tan Tanaka, Dennis May 5, 2026

May 5, 2026

Hi Michaela, A few observations: Observation #1. You wrote: This assessment is also in line with the Preliminary Rationale for the Strawperson language for charter question 1<https://secure-web.cisco.com/1lgYdNA3LmWA1u6qgOVHCHbGpI-4Dq4t7RfvSnMTAGdq1Q…> "The WG further considered, as noted in the Charter, that an ADC is most appropriately required where the registrar has sufficient indicators to reasonably determine that the domain name is being used for DNS Abuse.” Thinking about assessing proportionality on the basis of multiple 'signals' or 'indicators' may be a better route to go down given the complexities of assessing 'severity' at the 'trigger' stage The statement you quote from Q1 strawperson is taken out of context. The complete line is: “The WG further considered, as noted in the Charter, that an ADC is most appropriately required where the registrar has sufficient indicators to reasonably determine that the domain name is being used for DNS Abuse, rather than where a legitimate domain has been compromised by a third party.” This is meant to distinguish that ADC should not be targeted at compromised domain names. The ‘sufficient indicators’ is to establish this distinction, and once that distinction is made, then ADC may be applicable. Observation #2. You wrote: Broadly speaking, the NCSG does not think that all instances of actionable evidence of abuse should lead to an ADC. This is for two reasons: (1) limitations on registrar capacity (running an ADC on a single instance of DNS abuse would be operationally complex and costly); and (2) this could lead to ADCs becoming a ‘de-facto’ process for any and all reported instances of DNS abuse. This is correct. ADC should not apply to verified DNS Abuse on compromised domain names (registrar handles these cases under 3.18.2). We then should agree that ADC must apply in cases of malicious registration as reasonably determined by the registrar. Best -Dennis From: Michaela Nakayama Shapiro via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org> Reply-To: Michaela Nakayama Shapiro <michaela.shapiro(a)article19.org> Date: Wednesday, April 29, 2026 at 7:48 AM To: Nick Wenban-Smith <Nick.Wenban-Smith(a)nominet.uk>, Ching Chiao <ching.chiao(a)whoisxmlapi.com>, farzaneh badii <farzaneh.badii(a)gmail.com> Cc: anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org> Subject: [EXTERNAL] [Gnso-dnsabuse-pdp] Re: [MALICIOUS URLS, FILTERED]ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. INTERNAL Hi all, Thanks everyone for the feedback and thoughts on the example shared by @farzaneh badii<mailto:farzaneh.badii@gmail.com>! This came as a response to concerns flagged in the working group meeting that a concrete example of the potential risks associated (pun intended 🙂) with conducting an ADC was needed to better understand why a human rights impact assessment is relevant at the ’trigger’ stage. However, we understand not everyone may agree with this assessment and more discussion may be needed. In the meantime, the NCSG thought it would be helpful to further clarify our position. The NCSG is NOT saying an ADC on the basis of a single reported instance of DNS abuse is always disproportionate. As in the example Farzaneh shared, a domain registered mimicking popular communication channels (such as Telegram) could signal a systematic effort to cause security issues for a specific population at a specific moment. This is a valuable contextual indicator for triggering ADC — the timing and the target indicate something that the domain name alone cannot. This is exactly why the context of the reported abuse must be analyzed. That being said, what the NCSG wants to emphasise is that proportionality principles still apply, regardless of there being one actionable instance of DNS abuse. A quick 'proportionality check' could simply look like ensuring there is one additional indicator of a potential pattern of abusive behavior. Without clarity as to the scope and breadth of the ADC (which will vary per registrar, as noted in the PDP charter), the NCSG emphasises that proportionality must be considered (and is relevant) at every stage of the ADC process - from trigger, to investigation, to mitigation. This assessment is also in line with the Preliminary Rationale for the Strawperson language for charter question 1<https://secure-web.cisco.com/1lgYdNA3LmWA1u6qgOVHCHbGpI-4Dq4t7RfvSnMTAGdq1Q…> "The WG further considered, as noted in the Charter, that an ADC is most appropriately required where the registrar has sufficient indicators to reasonably determine that the domain name is being used for DNS Abuse.” Thinking about assessing proportionality on the basis of multiple 'signals' or 'indicators' may be a better route to go down given the complexities of assessing 'severity' at the 'trigger' stage (thank you, Marc and @Ching Chiao<mailto:ching.chiao@whoisxmlapi.com> for your thoughtful responses on this). Broadly speaking, the NCSG does not think that all instances of actionable evidence of abuse should lead to an ADC. This is for two reasons: (1) limitations on registrar capacity (running an ADC on a single instance of DNS abuse would be operationally complex and costly); and (2) this could lead to ADCs becoming a ‘de-facto’ process for any and all reported instances of DNS abuse. We hope that this also addresses the concerns you raised, @Nick Wenban-Smith<mailto:Nick.Wenban-Smith@nominet.uk>, about the registrar being unable to know whether this is a one-off or part of a broader campaign, for which an ADC would be invaluable for determining what action to take, or whether inaction is the right choice. Happy to discuss more, particularly as folks come back from Manchester (I hope those of you there are enjoying the unusually sunny weather)! Best, Michaela Michaela Nakayama Shapiro (she/her/hers) Programme Officer - Censorship [Logo.png]<https://secure-web.cisco.com/1Dwptg4x3-OILE4Bdam8qzr-Igv4lgkFYksBCSWLwzJRbw…> Defending freedom of expression and information www.article19.org<https://secure-web.cisco.com/1Dwptg4x3-OILE4Bdam8qzr-Igv4lgkFYksBCSWLwzJRbw…> Subscribe to our Newsletter<https://secure-web.cisco.com/1ooP-EOICCrOH4YEKCsEOskTUY4Qs-sYVcnP7cyI2ZWoiR…> [cid:image002.png@01DCDC7D.EE01F280]<https://secure-web.cisco.com/1XpR9URfz5LM11OPd6OEja_8TyqHEK1KGHir6wEUX1AEr4…> Note: we work half day Fridays (AM) Follow us [Bluesky1x.png]<https://secure-web.cisco.com/10DzVfqedZ_1WIDXsESxam9yyLkjKuiGbIL3LGUfqqUdp5…> [cid:image004.png@01DCDC7D.EE01F280]<https://www.facebook.com/article19org/> [cid:image005.png@01DCDC7D.EE01F280]<https://www.youtube.com/channel/UCDB6E_x0xRSfF62b872n9YQ> [cid:image006.png@01DCDC7D.EE01F280]<https://secure-web.cisco.com/1fExeF-E3gjilDU3lkVaveyZGAf-4LaLCnogKsrHOrR3qK…> [cid:image007.png@01DCDC7D.EE01F280]<https://secure-web.cisco.com/165PxV1GT3qGay9EmN5TH4529GX4dy26RSRIZPcckVA20U…> [cid:image008.png@01DCDC7D.EE01F280]<https://twitter.com/intent/follow?screen_name=article19org> [cid:image009.png@01DCDC7D.EE01F280]<https://secure-web.cisco.com/1Vheimlp5xQdBRy00Y9Tqhve1sRN7G_XXQacG-uWk-qhCy…> From: Nick Wenban-Smith via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org> Date: Wednesday, 22 April 2026 at 16:02 To: Ching Chiao <ching.chiao(a)whoisxmlapi.com>, farzaneh badii <farzaneh.badii(a)gmail.com> Cc: anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org> Subject: [Gnso-dnsabuse-pdp] Re: [MALICIOUS URLS, FILTERED]ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain Hi Detective FB Thanks for the investigation and report; I think some contextual examples of when ADC can assist with abuse mitigation are really helpful when considering our policy deliberations. Sharing wider threat intel as between registrars and the wider security and LE community when a widespread attack is spotted could be an important part of a community response bearing in mind that threat actors will spread their attacks across multiple registrars and TLDs, both gTLDs and ccTLDs for that matter (NB not part of this PDP1 Charter but I digress). Just coming back to the multiple signals point, I think there is a risk of conflating the trigger for ADC, the investigations conducted by the registrar, and then the mitigation action taken by the registrar (if any), which I see as all discrete aspects of the policy work in accordance with the Charter instructions to us. What I don't follow with the multiple signals argument as part of the trigger test, is how with respect to a single proven maliciously registered abusive domain, the registrar could possibly know prior to doing some basic investigation at least, whether or not it is part of a wider campaign? In fact I'd go further than that and say that the whole point about the registrar investigation is to determine whether the trigger domain was a one off abusive registration (in which case nothing to see any further) or whether in fact due to multiple signals (or whatever we want to call them) it is clear that (as per your examples below) it could be part of a wider pattern of malicious registrations which therefore need investigation. And if it then found by the registrar that other domains are also abusively registered then they should be actioned by the registrar without separate abuse notifications needing to be filed by anyone. If they aren't abusive then the registrar obviously shouldn't take any mitigation action. But that will only become clear having done the investigation, with no wriggle room for wilful blindness on the part of the registrar. Given registrar friends on the PDP have already told us that they already conduct ADC it would be nice to understand whether I have understood this practice correctly and my analysis here is fair. If a wheel has already been invented then let's not get into different shapes and sizes and a set of competing standards, but document existing good policies which already work. Cheers all Nick ________________________________ From: farzaneh badii via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org> Sent: Wednesday, April 22, 2026 12:53 To: Ching Chiao <ching.chiao(a)whoisxmlapi.com> Cc: anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org> Subject: [MALICIOUS URLS, FILTERED][Gnso-dnsabuse-pdp] ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain Caution: This is an external email and may be malicious. Please take extra care when replying, clicking links or opening attachments. Hi all, I just wanted to show you what we mean by considering other indicators rather than one domain to start ADC. You need multiple signals to trigger ADC, not just one abusive domain. Here's what those signals look like — and how even free agent Detective Badi undertook her analysis with zero equipment or use of intelligence firms (yes yes I know, when it scales it's harder.) Before diving in, here are the kinds of freely available, contextual indicators I can think of: 1. Is the domain on a blocklist? 2. Has it been reported before? 3. Does it relate to a documented, active campaign? 4. Does it share infrastructure (e.g. nameservers) that host a large number of malicious actors? 5. Was it registered during a period of heightened relevance to a specific attack target? 6. Is the registry going through a period of increased abuse? (check domain metrica) 7. Is the registrar going through a period of increased abuse? (check domain metrica) These paint a much richer picture than "one domain in a portfolio is bad, therefore ADC should start and every domain should be checked." This is not a formal NCSG position , but we've been saying for a while that ADC should be triggered based on a combination of such indicators/signals rather than profiling entire registrant portfolios from a single abusive domain. Ching's ADC examples inspired me to actually do this exercise and show what that looks like in practice. One caveat before I go further: I am not comfortable with these indicators. But they might be better than profiling domain name registrants and their entire portfolios based on a single abusive domain. --- THE TELEGRAM-HONG KONG CASE In Ching's examples I came across telegram-hongkong[.]com. This one is very interesting for me I worked on the use of Telegram in Hong Kong during the 2019 uprising. Here's the scenario: imagine this domain was registered around the uprising time in Hong Kong. Telegram was the most popular app during the uprising, and people were desperately trying to download and use it. A domain registered in that window, mimicking Telegram, could signal a systematic effort to cause security issues for a specific population at a specific moment. That's a genuinely good contextual indicator for triggering ADC — the timing and the target tell you something that the domain name alone cannot. But this is not without its complications. During that same period, people also ran apps that helped protesters track police locations, and dear Apple took those down. Now imagine that somewhere in an "abusive" portfolio, a couple of domains exist that were actually helping protesters. Authorities are actively requesting takedowns of such domains. What should the registrar do? Does their knowledge of those domains create legal or political exposure for them? The contextual signal cuts both ways. Which is exactly why context needs to be analyzed. For the record, Malwarebytes documented a campaign where attackers used malicious Google ads exclusively targeting people in Hong Kong, luring victims into downloading a malicious version of Telegram. So yes — this domain relates to a well-known, documented campaign. That's another signal worth noting. --- THE CRAIGSLIT / CALUDE CASE I do DNS abuse reporting as a hobby, partly to understand what doesn't work and what could be better. In one of my hunts I came across Craigslit[.]com. I reported it multiple times through different reporting mechanisms, it got suspended, and then, sigh, it's active again. What's interesting is that it used to share a nameserver that I have come across too often in abusive domain (like calude(.)ai But the name server can be rapidly changed so this metric should not be used on its own. Another signal: whether a domain has been reported before. I was excited to see that Domain Metrica claimed to have this kind of data — until it didn't actually tell me whether the domain had ever been reported, despite the fact that I know I reported it myself. This is admittedly a weak signal, but public reporting history is still better than snooping on registrant accounts. All in all, You need contextual, situational signals alongside the abusive domain to justify starting ADC — things like blocklist presence, prior reports, shared infrastructure, registration timing, and ties to documented malicious campaigns. These signals are freely available in the world. No special access required. No account surveillance needed. you can use abuse.ch<http://secure-web.cisco.com/1BZB0-EyjFrgCcD-rYQevZwzy2424uO_vDgh2061MI04vLW…> and a myriad of free tools that can help you with your decision. Best regards, Detective FB Ching's ADC examples inspired me to do this exercise. This is not an NCSG position but we have been saying that the start of ADC should be based on different indicators instead of just if one domain is abusive, then we should trigger ADC. Before I begin, I want to be very clear that I am not comfortable with these indicators. But they are better than profiling domain name registrants and their portfolios based on one abusive domain. In Ching's examples I came across telegram-hongkong[.]com. This is a very interesting case. It was exciting for me especially because I worked on the use of Telegram in Hong Kong during the 2019 uprising. So the scenario is as follows: imagine if this domain was registered around that time. Telegram was the most popular app around that time and people would want to download it or use it. So perhaps if the domain was registered during that time, it could signal that it's a systematic effort to cause some security issues. So that's actually a good indicator to consider when wanting to trigger ADC. This is not without its shortcomings. During that period they also ran apps that would inform the protestors about the police location. Those apps were taken down by dear Apple. Now imagine if in this abusive portfolio, there are a couple of registered domains that help protestors. There is a clear request from the authorities to take down such apps/domains. What should the registrar do? doesn't their knowledge of existence of such domains create problems? Other factors that should be considered are: is the nameserver ... does the domain relate to a well known campaign (it does, Malwarebytes documented a campaign where attackers used malicious Google ads exclusively targeting people in Hong Kong, luring victims into downloading a malicious version of Telegram.) Anyway I continue. I do DNS abuse reporting as a hobby to understand what doesn't work, what could be better etc. In one of my hunts, I came across Craigslit[.]com. I reported this domain many times using different reporting mechanisms and it was suspended and now I see it's active again. But interestingly it shares the same name-server with my other hunt and that's calude.ai, They both use NS1.HASTYDNS.COM<http://secure-web.cisco.com/1l15LLs-tuNPu4mQFmRuuLKEET2gefIwRKgZNKXh-vo0A-t…> (the name server). Another signal can be if the domain has been reported before. I got excited to see domain metrica said it has such data but it didn't tell me if it was ever reported despite the fact that I know I have reported the domain name! (this is a weak signal, but again public data might be better than snooping on accounts etc). So what is the moral of the story. You need to have different signals (contextual situational) as well as the abusive domain to start ADC. Those signals are available for free out in the world and even Detective Badi without any equipment managed to do it. Farzaneh On Wed, Apr 15, 2026 at 7:01 AM Ching Chiao via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> wrote: Dear all, Please review the attached 2023 research slides regarding typosquatting groups, which may be relevant to this PDP. In short, the research compares two different datasets -- typo groups vs. confirmed IoC domains . Feel free to ask any questions or comments via the list or privately. Best, Ching Ching Chiao 乔敬 Head of APAC & Corporate Development [Image removed by sender.] Check our latest Internet Abuse Signal research: https://main.whoisxmlapi.com/blog/to-cache-a-predator-ilovepoop-toolkit-rea…<https://secure-web.cisco.com/1eTgThDAb10Uv7QOwH8grodWjkEkZ0kdzx4HtV2_ej-kLW…> WhoisXMLAPI.com<http://secure-web.cisco.com/1rKYUKEeCa6HXYaOgHrUs7mvPuMJkx48OvVkSmGjaOJ_Rtt…> 中文：https://zh.main.whoisxmlapi.com/<https://secure-web.cisco.com/1Jg5W7wgvG8hNYDVfPt4h5Hg7EiLVKsKCC-UINN1PR5rX9…> 日本语：https://ja.main.whoisxmlapi.com/<https://secure-web.cisco.com/1bhfrIEZMiPghCvJvStGu1OSPrKJKmxVDKlYr2HESvyT86…> LinkedIn : https://www.linkedin.com/in/chiao/<https://secure-web.cisco.com/1t206i74U7nKgDxBltQMUVTT-lVN75OzDS5E0gP9oGXnm9…> Book a meeting now: https://calendar.app.google/9neWrkwvhPHRqGZ86<https://secure-web.cisco.com/1OG5PtqhWfaTdOV3637C_tKP2GmxnPyjqaEWEqTNefJCd-…> _______________________________________________ Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp(a)icann.org<mailto:gnso-dnsabuse-pdp@icann.org> To unsubscribe send an email to gnso-dnsabuse-pdp-leave(a)icann.org<mailto:gnso-dnsabuse-pdp-leave@icann.org>

1 0

Action Items and High Level Notes: DNSAM PDP1 WG 4 May 12:30 UTC
by Feodora Hamza May 5, 2026

May 5, 2026

Dear DNSAM PDP1, Please find below the high-level notes and Action Items from yesterday`s meeting. Our next meeting is scheduled for Monday, 11 May at 12:30 UTC. Kind regards, Feodora on behalf of Support Staff 2026-05-04 DNS Abuse Mitigation PDP1 WG<https://icann-community.atlassian.net/wiki/spaces/DAMP1/pages/935952425/202…> Action Items: 1. Staff/ LT to add glossary to Collab Document. 2. Staff/LT update Collab Document based on WG discussion. 3. Staff/LT to provide info/reference where possible on what data registrars must contractually collect based on contract agreement – note: https://www.icann.org/en/contracted-parties/consensus-policies/registration… 4. WG members to: * Add comments and suggested edits in the collaboration document. * Add language WG members can live with. * Contribute to glossary definitions. 1. NCSG to provide more granular language on potential adverse impact on registrants. Important Documents/Links: * Wiki/Slides: https://icann-community.atlassian.net/wiki/spaces/DAMP1/pages/935952425/202… * CollabDocument: https://docs.google.com/document/d/1GxM-Yrgv6sZPEYU8ikW4cRM5YqWsJuWGiQyO39p… * Recording: https://icann.zoom.us/rec/play/YVtg31rWi5S0fBZ7N0vdJnou2UKdIPq4gxcg266xQDHf… High-Level Notes: 1. Welcome (5min) * Chair opened the meeting. * Apologies were noted and can be found on the wiki page of each meeting. * Please send your apology to GNSO-Secs(a)icann.org<mailto:GNSO-Secs@icann.org> only, NOT to the whole WG list. 1. PDP Updates (10min) * Chair provided an update on potential methods to be used in the future to increase/enhance WG participation during calls. * Goal: Encourage broader input before reaching consensus calls and avoid late-stage introduction of previously unexpressed views. * Chair noted that a glossary will be introduced in the collaboration document. * Purpose: Create a shared baseline understanding across key terms and improve navigation for external readers of reports. 1. Refine strawperson on CQ3 (20min) * Chair introduced the updated strawperson on CQ3. * WG members asked whether investigation obligations are limited to data “reasonably available” to registrars. * WG members noted: Registrars can only act on data they possess. * Resellers may have additional/different data (e.g., payment info). * Obligation remains with the registrar, even if delegated. * Flexibility is necessary for operational feasibility. * Other WG members noted: Potential risk/concern of creating a loophole (“out”) if limited to available data to registrar. * Asked for clarity on enforcement of ADC when resellers hold data potentially relevant for ADC. * WG suggested refining language to avoid potential “loopholes” and maintain operational feasibility, ideally clarify interaction with reseller data. * WG members discussed whether the baseline criteria should be “At least one data point” is sufficient or “reasonable number of indicators” should be required when available to conduct ADC. * WG members noted concern that minimum requirement may allow “superficial” compliance. * Other WG members noted: policy should define a minimum baseline, not exhaustive procedures. 4. Discussion on strawperson CQ4 (30min) * Chair presented the strawperson language on CQ4. * WG initial reaction was generally positive. * Some WG members noted investigation should not exclude information provided in abuse reports. 5. Start deliberations on CQ5 (20min) 6. AOB (5min)

1 0