- Gnso-dnsabuse-pdp - lists.icann.org

**7-MINUTE REMINDER** Meeting Invitation / DNS Abuse Mitigation PDP1 WG | Monday, 13 April 2026
by Julie Bisland April 13, 2026

April 13, 2026

**7-MINUTE REMINDER** Dear all, The next DNS Abuse Mitigation PDP1 WG call will take place on Monday, 13 April 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

REMINDER | Meeting Invitation / DNS Abuse Mitigation PDP1 WG | Monday, 13 April 2026
by Terri Agnew April 10, 2026

April 10, 2026

Dear all, The next DNS Abuse Mitigation PDP1 WG call will take place on Monday, 13 April 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: Threshold - one domain vs a tiered approach
by Nitin Walia April 8, 2026

April 8, 2026

7 10

As promised
by Volker Greimann April 8, 2026

April 8, 2026

Colleagues, Following up on my comments on today’s call, and without revisiting the underlying policy debate, I wanted to elaborate briefly on some of the processes we use already to identify associated domains using data and signals that are squarely within our operational control. In practice, this is not a question of discovering new data, but of correlating existing indicators across registrations and post-registration activity. Common triggers we use include: * One report referencing multiple domains: very often, we see reports where reporters report more than one domain that they have detected through technical monitoring providers. When we see such reports, we analyse these domains for common denominators to check whether other domains match the same patterns. * Multiple reports referencing multiple domains: very often, we see multiple reports of similar domains at the same time or over a short amount of time. Agents recall these reports and start identifying common patterns that can be investigated. * Account-level linkage: on the end-customer level, we can detect other associated domains through shared registrant accounts. Note, some end customers are mere service providers (de-facto resellers). * Fraudulent payment transactions: (limited to end customer services) notices of payment fraud usually tend to lead to investigation of the services purchased with those transactions. * Linked accounts: sometimes, multiple end-customer accounts are detected that share billing credentials, payment instruments, common credentials. * Technical commonalities: repeated use of specific name servers, hosting infrastructure, IP ranges, particularly where patterns persist across otherwise distinct registrations. * Behavioural signals: synchronised registration timing * Common naming patterns: naming patterns such as bankname-country.TLD, phish54.TLD that immediately suggest the existence of similarly named (and used domains) * Account monitoring: in rare cases, new registrations with reseller accounts that have been determined to suffer from persistent abuse of their services by a threat actor may be monitored on a regular basis for suspicious signals matching one of the above triggers. None of this requires speculative inference about intent; it is pattern recognition grounded in registrar-held data and already widely used for fraud prevention, AML-style controls, and contractual compliance. The key policy point, in my view, is therefore not whether associated domains can be detected, but how expectations around the use of these existing capabilities should be framed, documented, and made auditable without creating disproportionate obligations or legal exposure. I hope this clarification is helpful.

1 0

Action Items DNSAM PDP1 - 7 April 12:30 UTC
by Feodora Hamza April 7, 2026

April 7, 2026

Dear DNSAM PDP1, please see below the high-level notes and action items from todays call. The session recording can be found here: https://icann.zoom.us/recording/detail?meeting_id=T7r3Qf8yTNm0QjfqG5q2Lg%3D… Our next meeting is scheduled for Monday, 13 April at 12:30 UTC. Kind regards, Feodora Action Items: * Staff to update straw person incorporating discussion on Q1 and 2 * WG to Review updated straw person and propose language adjustments toward convergence as well as rationale * WG to provide input on business models and potential impact/considerations e.g. Clarify direct vs. reseller models and any others to inform association criteria. Important Documents: * Collaboration Document: https://docs.google.com/document/d/1GxM-Yrgv6sZPEYU8ikW4cRM5YqWsJuWGiQyO39p… * WG wiki/ Session Slides: https://icann-community.atlassian.net/wiki/spaces/DAMP1/pages/935755777/202… * Recording: https://icann.zoom.us/recording/detail?meeting_id=T7r3Qf8yTNm0QjfqG5q2Lg%3D… High Level Notes: 1. Welcome (2 min) 2. Decision on WG Meeting Schedule & holidays (3 min) * Meeting schedule and holiday adjustments are “locked in”. Meetings to continue Mondays at 12:30 UTC. Some meeting conflicting w major holidays have been moved to Tuesday 12:30. Meeting invites have been updated. Please check your inbox. 1. Update on Workplan (5 min) · Work plan submitted to Council; expected to be discussed/acknowledged on 16 April. · Board liaisons confirmed: Jim Galvin, Chris Buckridge 4. Updates on CQ 1 (25 min) * Preliminary recommendation (strawperson): When a registrar has actionable evidence and has taken mitigation under 3.18.2, registrar must perform an associated domain check. * No convergence seems to exist on the following areas: · Disagreement on whether action must occur before conducting ADC. · Whether one abusive/malicious domain is sufficient trigger/threshold. · Some noted the risk of potentially low threshold, workload, and “guilt by association”. · Please see link to collaboration document for more details on proposed language: https://docs.google.com/document/d/1GxM-Yrgv6sZPEYU8ikW4cRM5YqWsJuWGiQyO39p… 5. Continue Deliberations to CQ 2 and CQ 3 (50 min) * Seems to be alignment on: · Association criteria should be flexible, non-prescriptive, and adaptable. · Avoid a fixed checklist, prefer examples/best practices. · Recognize variation across registrar models and evolving threat behaviour. · Further discussion needed on the relationship between “indicators” and contractual requirements? 6. AOB (5 min)

1 0

Post Call / DNS Abuse Mitigation PDP1 WG / Tuesday, 07 April 2026
by Julie Bisland April 7, 2026

April 7, 2026

Dear all, All recordings for the DNS Abuse Mitigation PDP1 WG call held on Tuesday, 07 April 2026 at 12:30 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/AYDGNw> (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

Meeting Invitation / DNS Abuse Mitigation PDP1 WG / Monday, 13 April 2026
by Julie Bisland April 7, 2026

April 7, 2026

Dear all, The next DNS Abuse Mitigation PDP1 WG call will take place on Monday, 13 April 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 * Check your time zone: Event Time Announcer - DNS Abuse Mitigation PDP1 WG call<https://tinyurl.com/mr3m4tc6> 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) * Staff will promote members, participants, and alternates to Panelist once joined. The prompt MUST be accepted to be moved to a Panelist. * 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…>. 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

**15 MINUTE REMINDER** Meeting Invitation / DNS Abuse Mitigation PDP1 WG | Tuesday, 07 April 2026
by Julie Bisland April 7, 2026

April 7, 2026

**15 MINUTE REMINDER** Dear all, The next DNS Abuse Mitigation PDP1 WG call will take place on Tuesday, 07 April 2026 at 12:30 UTC for 90 minutes (moved from Monday, 06 April, holiday). Check your timezone.<https://tinyurl.com/dzwh626t> 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…>

2 1

SME, weighing in (fork)
by Reg Levy April 7, 2026

April 7, 2026

I’d like to respond to Ching’s request for data: > It would be very helpful if the SMEs (such as NetBeason or NetCraft) & the Registrars could kindly share the following information (i.e. as required by by RAA <https://itp.cdn.icann.org/en/files/accredited-registrars/registrar-accredit…> 3.18.4) which will help ascertain to the level of effort that will actually be needed to conduct ADC: > Number of complaints received in 2025 > Number of complaints that were valid > Number of complaints that were actioned I would submit that the number of complaints received by reporters is less relevant than those received by registrars, since we are the ones acting (and upon whom the onus of the new policy or best practices will fall). I’d also like to note that we are required to maintain records but not create them; what follows should not be understood to be readily available to any registrar and is only available to me because of an unrelated internal project. In 2025, IANA 69, one of the four registrars my team manages, received just under 100k abuse complaints marked as “phishing” through our online forms. Note that this does not include any other type of DNS Abuse or other abuse and does not include phishing reported through different means. Fewer than 10,000 were legitimate phishing complaints. We have to sift through 90% chaff to even get to the phishing reports—and that doesn’t look at the validity of the reports in the first place. ────────────────────────────┼───────── │ Category │ Tickets │ ├────────────────────────────┼─────────┤ │ TOTAL │ 98,212 │ ├────────────────────────────┼─────────┤ │ Noise │ 39,267 │ ├────────────────────────────┼─────────┤ │ Legitimate (all others) │ 58,945 │ ├────────────────────────────┼─────────┤ ├────────────────────────────┼─────────┤ │ MISROUTED REQUESTS │ 12,298 │ ├────────────────────────────┼─────────┤ │ Support request │ 6.142 │ ├────────────────────────────┼─────────┤ │ Sales inquiry │ 3,133 │ ├────────────────────────────┼─────────┤ │ Technical support │ 1,569 │ ├────────────────────────────┼─────────┤ │ Complaint, all other │ 1,454 │ ├────────────────────────────┼─────────┤ ├────────────────────────────┼─────────┤ │ DOMAIN DISPUTES │ 13,609 │ ├────────────────────────────┼─────────┤ │ Domain ownership │ 6,120 │ ├────────────────────────────┼─────────┤ │ Registry compliance │ 4,243 │ ├────────────────────────────┼─────────┤ │ UDRP │ 1,828 │ ├────────────────────────────┼─────────┤ │ Whois issues │ 841 │ ├────────────────────────────┼─────────┤ │ Whois inaccuracy │ 577 │ ├────────────────────────────┼─────────┤ ├────────────────────────────┼─────────┤ │ CONTENT CONCERNS │ 15,062 │ ├────────────────────────────┼─────────┤ │ Hosting (non-DMCA) │ 7,833 │ ├────────────────────────────┼─────────┤ │ DMCA │ 3,888 │ ├────────────────────────────┼─────────┤ │ Law enforcement │ 3,341 │ ├────────────────────────────┼─────────┤ ├────────────────────────────┼─────────┤ │ Phishing │ 8,291 │ ────────────────────────────┴───────── I hope this is helpful context for the conversation. Servus, Reg -- Reg Levy | Associate General Counsel – Domains +1 (323) 880-0831 Tucows #MakingTheInternetBetter UTC -7

5 7

Threshold - one domain vs a tiered approach
by farzaneh badii April 7, 2026

April 7, 2026

Hi At NCSG we don’t think one abusive domain should automatically trigger ADC for every domain name that is in the account or the portfolio. We want to think about other ways that can be proportional and rights respecting. The below is a draft tier based approach that considers “severity of harm” and might not be too resource intensive (thats to be seen) . Within ICANN’s defined DNS abuse scope malware, phishing, botnets, pharming, and spam where used as a delivery mechanism we can consider four tiers: • Critical (e.g. botnet C2, ransomware delivery, large-scale DNS cache poisoning or ISP-level resolver hijacking): assess report; mandatory ADC • High (e.g. phishing with active evasion, sophisticated malware, targeted router or home resolver hijacking): assess the severity ADC might be required • Medium (e.g. generic malware, low-sophistication phishing): assess, ADC recommended where a pattern is suspected. • Low (e.g. spam with no malware payload, dormant or historical abuse, resolved pharming): monitoring only; ADC at discretion where serial abuse is suspected. Investigation should also be proportionate. If somebody steals a pen from a store we won’t search their whole house. Farzaneh On Thu, Apr 2, 2026 at 6:24 PM trachtenbergm--- via Gnso-dnsabuse-pdp < gnso-dnsabuse-pdp(a)icann.org> wrote: > Volker, > > > > What I am not understanding is how exactly registrars will know which > domain names which they have actionable evidence are being used for DNS > Abuse are likely to have high yield or low yield of associated domains > being used for DNS Abuse simply by looking at the abusive domain and > without conducting the Associated Domain Check. Even for the sake of > argument if your personal experience in reviewing abuse complaints would > give you a better idea about which domain names being used for abuse are > likely to have associated domains also being used for abuse just by looking > at the single domain without conducting the ADC (which is doubtful), you > would not be right every time and a significant number of associated > domains that are being used for DNS Abuse would be missed. But even if you > were right every time, that is not scalable and most people reviewing abuse > complaints do not have your experience. The policy can’t be designed for > the most experienced reviewer of abuse complaints but rather has to account > for that regular people reviewing abuse complaints which may not have your > experience. > > > > > > Best regards, > > > > *Marc H. Trachtenberg * > Shareholder > > Chair, Internet, Domain Name, e-Commerce and Social Media Practice > Greenberg Traurig, LLP > > *Aspen Chicago* > > 411 E. Main Street > <https://www.google.com/maps/search/411+E.+Main+Street?entry=gmail&source=g> > 360 North Green Street > > Suite 207 | Aspen, CO 81611 Suite 1300 | Chicago, IL 60607 > > T +1.970.300.5313 T +1.312.456.1020 > > M +1.773.677.3305 M +1.773.677.3305 > trac(a)gtlaw.com <trachtenbergm(a)gtlaw.com> | www.gtlaw.com | View GT > Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> > > [image: Greenberg Traurig Logo] > > [image: Greenberg Traurig Logo] > > > > *From:* Volker Greimann <volker.greimann(a)centralnic.com> > *Sent:* Thursday, April 2, 2026 2:51 PM > *To:* Trachtenberg, Marc H. (Shld-ASP-IP-Tech) <trachtenbergm(a)gtlaw.com>; > steve.chan(a)icann.org; ching.chiao(a)whoisxmlapi.com > *Cc:* gnso-dnsabuse-pdp(a)icann.org > *Subject:* Re: [Gnso-dnsabuse-pdp] Re: Outcomes, Action Items, and Notes > - 23 March 2026 - Meeting #6 > > > > Marc, I think you may be misunderstanding. Some will have low yield, some > will have high yield. In many cases, those actioning the reports on a daily > basis will have some experience in recognizing which is which. Why waste > time on those with a high likelihood of low yield when we could spend that > time by focussing on those with high yield? > > > > That is what I am looking for in our trigger: A clear guide that adds a > new obligation there where it can do good, but doesn't where it won't. > > > > Criminals will always be a step ahead. Lets not make their "job" easier by > burdening those that are tasked with mitigating their "work" with > additional processes that will ultimately make them less effective when we > could be focussing on enabling them to work better? > > > > > > Sincerely, > > *Volker Greimann* > *General Counsel & Head of Policy and Compliance - Online Division* > > volker.greimann(a)centralnic.com > Office: +49-172-6367025 > Web: www.teaminternet.com > <https://urldefense.com/v3/__http:/www.teaminternet.com__;!!DUT_TFPxUQ!CHs_F…> > > Team Internet Group PLC (AIM:TIG). Registered Office: 4th Floor, Saddlers > House, 44 Gutter Lane, London, United Kingdom, EC2V 6BR > <https://www.google.com/maps/search/44+Gutter+Lane,+London,+United+Kingdom,+…>. > Team Internet is a company registered in England and Wales with the company > number 8576358. > > > ------------------------------ > > *From:* trachtenbergm(a)gtlaw.com <trachtenbergm(a)gtlaw.com> > *Sent:* 02 April 2026 7:03 PM > *To:* Volker Greimann <volker.greimann(a)centralnic.com>; > steve.chan(a)icann.org <steve.chan(a)icann.org>; ching.chiao(a)whoisxmlapi.com < > ching.chiao(a)whoisxmlapi.com> > *Cc:* gnso-dnsabuse-pdp(a)icann.org <gnso-dnsabuse-pdp(a)icann.org> > *Subject:* RE: [Gnso-dnsabuse-pdp] Re: Outcomes, Action Items, and Notes > - 23 March 2026 - Meeting #6 > > > > Volker, > > > > I would point out that you are making an assumption that running an ADC on actioned > reports will have a low likelihood of yielding further results. It could > yield significant actionable results that could have a meaningful impact on > reducing DNS Abuse. > > > > Best regards, > > > > *Marc H. Trachtenberg * > Shareholder > > Chair, Internet, Domain Name, e-Commerce and Social Media Practice > Greenberg Traurig, LLP > > *Aspen Chicago* > > 411 E. Main Street > <https://www.google.com/maps/search/411+E.+Main+Street?entry=gmail&source=g> > 360 North Green Street > > Suite 207 | Aspen, CO 81611 Suite 1300 | Chicago, IL 60607 > > T +1.970.300.5313 T +1.312.456.1020 > > M +1.773.677.3305 M +1.773.677.3305 > trac(a)gtlaw.com <trachtenbergm(a)gtlaw.com> | www.gtlaw.com | View GT > Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> > > [image: Greenberg Traurig Logo] > > [image: Greenberg Traurig Logo] > > > > *From:* Volker Greimann via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org> > > *Sent:* Thursday, April 2, 2026 9:26 AM > *To:* Steve Chan <steve.chan(a)icann.org>; Ching Chiao < > ching.chiao(a)whoisxmlapi.com> > *Cc:* gnso-dnsabuse-pdp(a)icann.org > *Subject:* [Gnso-dnsabuse-pdp] Re: Outcomes, Action Items, and Notes - 23 > March 2026 - Meeting #6 > > > > **EXTERNAL TO GT** > > Thank you Ching, but I think it should be noted that that distinction does > not make a practical difference. Reporters usually tend to report actual > abusive registrations, so the number of additional steps to be taken for > each such report will add up to a significant number of tickets that cannot > be actioned in that time and will thus have to wait until later. > > > > Managing the abuse queues is at times like drinking from the firehose and > to be able to keep on to of the inflow, the processes employed have to be > perfectly tuned to make the most efficient use of the capacity available. > Adding additional steps that lead nowhere is ultimately detrimental to our > shared goals. On the other hand, adding additional steps where it makes > sense and brings the added actual benefit of reducing the overall volume of > abuse on our platforms is something all registrars should strive for. > > > > It is my firm belief that this WG should make sure that we find a way to > find the right balance between not having to perform kabuki on actioned > reports that have a low likelihood of yielding further results on the one > hand and ensuring that there is an obligation to conduct such checks where > there is potential value. > > > > Not doing that is taking the easy way out and just dumping the > responsibility on our feet. Lets aim for a constructive approach instead. > > > > I also must note that I am a little disappointed by the lack of any > response from any group besides the registrars with regard to my suggestion > to put forward ideas what your own groups could contribute. > > > > > > Sincerely, > > *Volker Greimann* > *General Counsel & Head of Policy and Compliance - Online Division* > > volker.greimann(a)centralnic.com > Office: +49-172-6367025 > Web: www.teaminternet.com > <https://urldefense.com/v3/__http:/www.teaminternet.com__;!!DUT_TFPxUQ!EMcb8…> > > Team Internet Group PLC (AIM:TIG). Registered Office: 4th Floor, Saddlers > House, 44 Gutter Lane, London, United Kingdom, EC2V 6BR > <https://www.google.com/maps/search/44+Gutter+Lane,+London,+United+Kingdom,+…>. > Team Internet is a company registered in England and Wales with the company > number 8576358. > > > ------------------------------ > > *From:* Ching Chiao via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org> > *Sent:* 02 April 2026 5:35 PM > *To:* Steve Chan <steve.chan(a)icann.org> > *Cc:* gnso-dnsabuse-pdp(a)icann.org <gnso-dnsabuse-pdp(a)icann.org> > *Subject:* [Gnso-dnsabuse-pdp] Re: Outcomes, Action Items, and Notes - 23 > March 2026 - Meeting #6 > > > > Hi Steve, all, > > > > Thanks very much for the meeting notes. BC has the opportunity to review > them, and provide follow-up thoughts below : > > > > Re: Concern that if the trigger requires action every single time, it > represents costs and efforts for the registrars, impacting the ability of > registrars to effectively combat DNS Abuse. > > > > BC would like to emphasize that ADC is only required when the complaint of > the initial domain is VALID (as defined in RAA) AND is found to be abusive > / malicious. We don't believe every complaint received by a registrar > qualifies and hence won't require an ADC. Meanwhile, performing ADC > increases a registrar's ability to cost effectively combat DNS abuse. Each > ADC should take very little time (i.e. a few minutes) and often results in > the suspension of multiple malicious domains / accounts. By suspending > other (unreported) domains of known bad actors and their accounts, a > registrar proactively prevents those domains and the account(s) from > continuing to be used for DNS Abuse, thereby driving down the # of > individual domain reports that will be received. The ADC proactive approach > reduces the overall cost of mitigating abuse. > > > > It would be very helpful if the SMEs (such as NetBeason or NetCraft) & the > Registrars could kindly share the following information (i.e. as required > by by RAA > <https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/accredited-re…> > 3.18.4) which will help ascertain to the level of effort that will actually > be needed to conduct ADC: > > o > > o > > o Number of complaints received in 2025 > > o > > o > > o > > o Number of complaints that were valid > > o > > o > > o > > o Number of complaints that were actioned > > o > > > > We understand that generally larger registrars receive more abuse reports, > but they also have more staff to handle those reports and investigations. > That said, we are aware that the additional ADC execution may potentially > impact the workload / cost consequences for registrars with smaller DUMs. > > > > Best regards, > > > > Ching > > > > > > > > > > > > On Mon, Mar 30, 2026 at 11:13 AM Steve Chan via Gnso-dnsabuse-pdp < > gnso-dnsabuse-pdp(a)icann.org> wrote: > > Dear DNSAM PDP 1, > > > > Please see the attached outcomes, action items, and notes from Meeting #6. > > > > Best, > > Steve > > > > > > *[OUTCOMES]* > > - Nick Wenban-Smith elected vice-chair > > > > *[ACTION ITEMS]* > > - Staff to post election results and onboard Nick to the leadership > team. > - Leadership and staff to provide a path forward for the WG meeting > schedule, taking into account Monday holidays. > - WG members to provide further input on the proposed updated work > plan, no later than 3 April [updated work plan attached]. > - Jennifer Chung, as Council liaison to the WG, to submit work plan to > the Council no later than 6 April. > > > > *[NOTES]* > > > > *1. Welcome* > > - None > > > > *2. Update on VC Chair Selection* > > - Nick Wenban-Smith elected vice-chair > > > > *Action Item: Staff to post election results and onboard Nick to the > leadership team.* > > > > *3. Meeting Cadence/Public Holidays* > > - With so many meetings on Monday, leadership is proposing to move the > meetings to the second most common acceptable day based on Doodle poll > results. > - Suggestion from many to leave on Monday and only move to Tuesday if > there are “enough” WG members that cannot attend, but don’t cancel. > > > > *Action Item: Leadership and staff to provide a path forward for the WG > meeting schedule, taking into account Monday holidays.* > > > > *4. Update on Workplan* > > - Leaders and staff have taken into consideration input and has > suggested changes to shorten the timeline. Key changes are initial > deliberations and time between Initial and Final Report. Some appreciation, > but also some discomfort for the shortened work plan. > - The initial proposal for the work plan was potentially too > conservative; the updated work plan is still designed to be achievable. > - Next step is for the work plan to go to Council for acknowledgement > via the Council liaison, Jennifer Chung. > > > > *Action Item: WG members to provide further input on the proposed updated > work plan, no later than 3 April [updated work plan attached].* > > *Action Item: Jennifer Chung, as Council liaison to the WG, to submit work > plan to the Council no later than 6 April.* > > > > *5. Continue Deliberation* > > - Early input received from the BC, GAC, IPC, ISPCP, NCSG, RrSG – > input is aggregated and stored on the Wiki. Each piece of input will be > added into the collaboration tool, relative to the Charter question. > - Reviewed Overarching Themes so far from WG discussions, both verbal > and on email. Also included relevant sections from Early Input, though full > comments should be reviewed on the Wiki: > https://icann-community.atlassian.net/wiki/spaces/DAMP1/pages/983433230/Com… > <https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/space…> > - Concern that if the trigger requires action every single time, it > represents costs and efforts for the registrars, impacting the ability of > registrars to effectively combat DNS Abuse. Noted that we still have a > question to determine what the investigation will look like. > - Suggestion/reminder to define a maliciously registered domain name > based on RAA 3.18.2. > > > - “When Registrar has actionable evidence that a Registered Name > sponsored by Registrar is being used for DNS Abuse, Registrar must promptly > take the appropriate mitigation action(s) that are reasonably necessary to > stop, or otherwise disrupt, the Registered Name from being used for DNS > Abuse.” > > > - Reminder that we need to allow for some flexibility in the solutions > as bad actors will change their methods. However, the requirements still > ultimately need to be enforceable. > - The GAC early input talks about how to perform the ADC, as in what > represents association – this input connects to a later Charter question. > We are blending the charter questions a bit. > - If the trigger is not a single maliciously registered domain name > based on RAA 3.18.2, what would be the alternative? > - Caution from some to avoid listing all ways to identify associated > domain names engaging in DNS Abuse as defined by 3.18.2. > - Question about proportionality in respect of initial trigger versus > ADC – answer from those that are particularly concerned about > proportionality, is both. > - Reminder from ISPCP early input that the ADC should also be based on > the same standard as in 3.18.2. Are there any members suggesting to go > beyond these limitations? Seems to be alignment to stick with the RAA > definition. > - A balance is needed to avoid listing every ADC action, but also not > to leave so vague that bad actors can exploit the holes. > - Several mentions of a “reasonableness” standard for the ADC, in > terms of what needs to be looked at. Continued caution against creating a > prescriptive matrix. > - Suggestion to create an advisory to help guide what the ADC should > include, which can be updated from time to time. Question about how > advisories are updated – answer is that there are a multitude of ways to > update advisories. > - Several members reminded that proportionality is important. However, > question about potential harms from investigating whether other DNS Abuse > is occurring. > - Noted that reasonableness is already a component of the RAA, > including for RAA 3.18.2. There is a difference between “what” > reasonableness represents for initial trigger versus the reasonableness of > “how” the ADC is performed. The advisory notion is more relevant to the > latter of “how”. > - Some discussion about compromised domains, which are not within > scope of this PDP. Question about whether a compromised domain should > trigger investigation of the account. > - We have not yet discussed what the ADC itself should involve, other > than it should not be prescriptive. This aspect is when proportionality > will be more relevant. > - Reasonableness of the ADC will vary based on the circumstances. And > question about how that should be passed on to the reseller. > > > > *6. AOB* > > - Planning to have 4 sessions during the standard meetings days for > ICANN86. Will try to avoid conflicts to the extent possible. > - There will also be a prep-week webinar to provide an update on the > progress of this PDP. > - Will need to confirm work plan – get it to Council by the 6th. > - Staff will continue to update the collaboration tool and the WG > should continue to review and provide feedback. > > > > > > *Steven Chan* > > VP, Policy Development Support & GNSO Relations > > > > Internet Corporation for Assigned Names and Numbers (ICANN) > > <https://www.google.com/maps/search/12025+Waterfront+Drive,+Suite+300+%0D%0A…> > > 12025 Waterfront Drive, Suite 300 > <https://www.google.com/maps/search/12025+Waterfront+Drive,+Suite+300+%0D%0A…> > > Los Angeles, CA 90094-2536 > <https://www.google.com/maps/search/12025+Waterfront+Drive,+Suite+300+%0D%0A…> > > > > Email: steve.chan(a)icann.org > > Mobile: +1.310.339.4410 > > _______________________________________________ > Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp(a)icann.org > To unsubscribe send an email to gnso-dnsabuse-pdp-leave(a)icann.org > > ------------------------------ > > If you are not an intended recipient of confidential and privileged > information in this email, please delete it, notify us immediately at > postmaster(a)gtlaw.com, and do not use or disseminate the information. > _______________________________________________ > Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp(a)icann.org > To unsubscribe send an email to gnso-dnsabuse-pdp-leave(a)icann.org >

6 11