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

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

May 4, 2026

Dear all, All recordings for the DNS Abuse Mitigation PDP1 WG call held on Monday, 04 May 2026 at 12:30 UTC can be found on the agenda wiki page <https://icann-community.atlassian.net/wiki/x/KYDJNw> (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, 11 May 2026
by Julie Bisland May 4, 2026

May 4, 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

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

May 4, 2026

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

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

May 4, 2026

Dear DNSAM PDP1, Please find below the proposed agenda for our call on Monday, 4 May at 12:30 UTC. 1. Welcome (5min) 2. PDP Updates (10min) 3. Refine strawperson on CQ3 (20min) 4. Discussion on strawperson CQ4 (30min) 5. Start deliberations on CQ5 (20min) 6. AOB (5min) Please also note the below Action Item for the WG: Collaboration Document for review and feedback on CQ1-4: https://docs.google.com/document/d/1GxM-Yrgv6sZPEYU8ikW4cRM5YqWsJuWGiQyO39p… The main adjustments include (highlighted in green text or in suggestion mode): * Adjusted language to CQ1 – CQ3 based on last week’s discussion * Added preliminary language to CQ4 * Some language has been moved as it might fit better to other CQs based on last week’s discussion Please provide your input directly into the document and be ready to discuss it during the next WG call. Kind regards, Feodora on behalf of Support Staff

5 4

ADC detection strategy - define association (Q2)
by Ching Chiao May 1, 2026

May 1, 2026

Dear colleagues, Recently my research team completed an analysis of ~4.3 million domains spanning 2025-12-01 to 2026-03-31, identifying approximately *1.25 million potential clusters (i.e. associated domain groups)*. Here's our cluster breakdown by detection strategy: - Prefix + TLD clustering (Strategy A): ~469K clusters — domains sharing a fixed alphanumeric prefix with variant suffixes under the same TLD. (example below) - Exact apex clustering (Strategy B): ~726K clusters — identical second-level domain registered across multiple TLDs. - N-gram fuzzy clustering (Strategy C): ~50K clusters — near-duplicate apex names detected via trigram locality-sensitive hashing. [image: image.png] Happy to share the original report / ADC group file offline once it's available. Hope this further helps shape the answers to Charter Question 2. Thanks! Best, Ching *Ching Chiao * *Head of APAC & Corporate Development* Check our latest *Internet Abuse Signal* research: https://main.whoisxmlapi.com/blog/to-cache-a-predator-ilovepoop-toolkit-rea… *WhoisXMLAPI.com <http://WhoisXMLAPI.com>* *中文：https://zh.main.whoisxmlapi.com/ <https://zh.main.whoisxmlapi.com/>* *日本语：https://ja.main.whoisxmlapi.com/ <https://ja.main.whoisxmlapi.com/>* LinkedIn : https://www.linkedin.com/in/chiao/ Book a meeting now: https://calendar.app.google/9neWrkwvhPHRqGZ86

2 1

Another numbers request.
by Naoum MENGOUDIS May 1, 2026

May 1, 2026

Dear all, Following the numbers being thrown around in the recent emails, It would be of interest to know the average number of domains an end customer holds. And maybe also the maximum number of domains an end customer holds, to have an idea of the extreme case scenario. This would give us a better estimate of the work needed to be done when doing ADC. [End customer means actual registrants, excluding Resellers and Privacy & Proxy Services] Having 100.000 abusive reports in total says nothing about the overhead of a possible ADC. Maybe ADC would actually help because the reports would be handled in groups instead of one by one (because, as you know, when you are "in the zone" you get more work done compared to starting and stopping and constantly switching contexts). For example, if the average ownership is 100 domains per end customer, you would have to check an additional 99 domains of that customer when one of his domains is reported. Better do it as a group, instead of waiting to do it 100 times in total at some point. PLUS, you can use heuristics, like, if you verify that 20 of the 100 domains of the customer are abusive, and using other available information and indicators (e.g. everything being registered via API and on the same day), you can just deactivate all 100 of the domains and nobody will complain about it (without even having to check further, saving lots and lots of resources). On the contrary, acting on each of the reports that will come in the future is way more resource intensive. And can we have some examples of real scenarios when an ADC would be detrimental to the resource use of the Registrar? So we can validate or not this argument, or any other related argument, or plan appropriate safeguards, instead of dismissing a good practice (i.e. the ADC triggered every time). Regards, Naoum ΜΕΓΓΟΥΔΗΣ Ναούμ Αστυνόμος Α' Διεύθυνση Δίωξης Κυβερνοεγκλήματος Τμήμα Διαδικτυακής Προστασίας Ανηλίκων Λ. Αλεξάνδρας 173, 115 22, Αθήνα<https://www.google.com/maps/place/%CE%94%CE%B9%CE%B5%CF%8D%CE%B8%CF%85%CE%B…> MENGOUDIS Naoum Police Major Cyber Crime Directorate Online Child Protection Department Alexandras Avenue 173, 115 22, Athens<https://www.google.com/maps/place/%CE%94%CE%B9%CE%B5%CF%8D%CE%B8%CF%85%CE%B…> T: (+30) 2106476475 E: n.mengoudis(a)cybercrimeunit.gov.gr<mailto:n.mengoudis@cybercrimeunit.gr> ------------------- Email Disclaimer This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Think green before printing

11 27

Re: RrSG Explainer Documents: Registrar Models and Malicious vs. Compromised Domains
by Tan Tanaka, Dennis May 1, 2026

May 1, 2026

I find this useful information, Natalie. Thank you for sharing. From: Natalie Howatson via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp(a)icann.org> Reply-To: Natalie Howatson <natalie.howatson(a)comlaude.com> Date: Thursday, April 30, 2026 at 10:04 AM To: "gnso-dnsabuse-pdp(a)icann.org" <gnso-dnsabuse-pdp(a)icann.org> Subject: [EXTERNAL] [Gnso-dnsabuse-pdp] RrSG Explainer Documents: Registrar Models and Malicious vs. Compromised Domains 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. Hello ADC PDP WG members, As a result of the ongoing WG discussions, the RrSG has prepared two explainer documents on Registrar Models and Data Availability and Malicious vs. Compromised Domains. Please find them attached. Furthermore, both documents are also published on the RrSG website: Registrar Models and Data Availability<https://secure-web.cisco.com/1orXpqo6a0G0Vf_VoxmWqiyssELqB0aeiXE3tG5Gk6PT9O…> - Showcases our different business models/relationships, along with types of data we have available to us. Malicious vs Compromised<https://secure-web.cisco.com/1j2kuRQCxIOXvAewbwzFDxuYLVnXEyx34j33VPTkwIrtTQ…> - Definitions related to malicious and compromised domain activity, including examples of each. We hope these help with the continuing discussions on ADC. Natalie Natalie Howatson She/Her Domain Strategist [image]<https://secure-web.cisco.com/1xnXB4RuDUFlV-D3W3oL1P4lrLzvr-CiQ-Chy4KJTSZGm_…> Suite 332, Securities Building, 1904 Third Ave, Seattle, 98101, USA D +1 689 240 5542 comlaude.us<http://secure-web.cisco.com/1Ch0U-IKdvmNWcvv6kTS_Q7zLbci6zWF_rLWdj_jPzl6gEg…> Out of hours emergency helpline: UK +44 20 8213 5922; USA +1 2064877683 Follow us on LinkedIn<https://secure-web.cisco.com/14g4CrG9Q0UWA1VZImqAonk80M82x_JHE1wEMDeWA2PKrX…> and Youtube<https://secure-web.cisco.com/1SeEvWezIK0BZbyQnCxdS80O1l12tcrwayUFhFgd4VI_F2…> [image]<https://secure-web.cisco.com/1CEObgunedsQZxjDaKUaOexcjwZskArjL0baOFmc6DPQhA…> [image] <https://twitter.com/comlaude?lang=en> [image] <https://www.facebook.com/ComLaude/> [image] <https://www.youtube.com/@comlaude> [image] ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com<https://secure-web.cisco.com/1xnXB4RuDUFlV-D3W3oL1P4lrLzvr-CiQ-Chy4KJTSZGm_…>

1 0

**REMINDER** Meeting Invitation / DNS Abuse Mitigation PDP1 WG | Monday, 04 May 2026
by Julie Bisland May 1, 2026

May 1, 2026

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

RrSG Explainer Documents: Registrar Models and Malicious vs. Compromised Domains
by Natalie Howatson April 30, 2026

April 30, 2026

Hello ADC PDP WG members, As a result of the ongoing WG discussions, the RrSG has prepared two explainer documents on Registrar Models and Data Availability and Malicious vs. Compromised Domains. Please find them attached. Furthermore, both documents are also published on the RrSG website: Registrar Models and Data Availability<https://rrsg.org/wp-content/uploads/2026/04/RrSG-Explainer_-Registrar-Model…> - Showcases our different business models/relationships, along with types of data we have available to us. Malicious vs Compromised<https://rrsg.org/wp-content/uploads/2026/04/RrSG-Explainer_-Malicious-vs-Co…> - Definitions related to malicious and compromised domain activity, including examples of each. We hope these help with the continuing discussions on ADC. Natalie Natalie Howatson She/Her Domain Strategist [image]<https://comlaude.com/> Suite 332, Securities Building, 1904 Third Ave, Seattle, 98101, USA D +1 689 240 5542 comlaude.us<http://comlaude.us/> Out of hours emergency helpline: UK +44 20 8213 5922; USA +1 2064877683 Follow us on LinkedIn<https://t-uk.xink.io/Tracking/Index/pRkAAKdfAADQDxUA0> and Youtube<https://t-uk.xink.io/Tracking/Index/ZxkAAKdfAADQDxUA0> [image]<https://www.linkedin.com/company/com-laude> [image] <https://twitter.com/comlaude?lang=en> [image] <https://www.facebook.com/ComLaude/> [image] <https://www.youtube.com/@comlaude> [image] ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the "Com Laude Group") does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com<https://comlaude.com/>

1 0

ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain
by farzaneh badii April 29, 2026

April 29, 2026

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 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 (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> 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* > Check our latest *Internet Abuse Signal* research: > https://main.whoisxmlapi.com/blog/to-cache-a-predator-ilovepoop-toolkit-rea… > > *WhoisXMLAPI.com <http://WhoisXMLAPI.com>* > *中文：https://zh.main.whoisxmlapi.com/ <https://zh.main.whoisxmlapi.com/>* > *日本语：https://ja.main.whoisxmlapi.com/ <https://ja.main.whoisxmlapi.com/>* > > LinkedIn : https://www.linkedin.com/in/chiao/ > Book a meeting now: https://calendar.app.google/9neWrkwvhPHRqGZ86 > _______________________________________________ > Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp(a)icann.org > To unsubscribe send an email to gnso-dnsabuse-pdp-leave(a)icann.org >

4 3