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

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

Action Item: DNSAM PDP1 Review of updated Collaboration Document
by Feodora Hamza April 28, 2026

April 28, 2026

Dear DNSAM PDP1, Please find below the updated collaboration document for your review/feedback and suggested changes. Collaboration Document: https://docs.google.com/document/d/1GxM-Yrgv6sZPEYU8ikW4cRM5YqWsJuWGiQyO39p… Please note the main changes 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 Our next meeting is scheduled for Monday 4 May at 12:30. Please provide your input directly into the document and be ready to discuss it during the next WG call. Thank you. Kind regards, Feodora on behalf of Support Staff

1 0

Re: ]ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain
by farzaneh badii April 27, 2026

April 27, 2026

Hi Nick, just to be clear we are not saying don’t start any kind of investigation. We are saying before you go to ADC check based on one abuse report, check these other signals. In order to do ADC you need to have access to registrar backend or database. These other signals I mentioned don't need access to backend it's public information. are not (I managed to gather the signals without being a registrar, I am only a detective) So in effect, to find out about those signals you don’t have to do ADC as your first action as I demonstrated. Those signals along with abusive domain could establish the trigger for ADC. Farzaneh On Wed, Apr 22, 2026 at 11:02 AM Nick Wenban-Smith < Nick.Wenban-Smith(a)nominet.uk> wrote: > 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> 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… > <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/ > 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 > To unsubscribe send an email to gnso-dnsabuse-pdp-leave(a)icann.org > >

5 6

Call for Presentations Hybrid TechDay ICANN 86 Sevilla
by Dr Eberhard W Lisse April 22, 2026

April 22, 2026

All, please note the below. While one or both session may clash with our own F2F, we are very interested in hearing about technical solutions being implemented by Registrars and Registries. If you or some enterprising youngling within your organization would like to present, please respond to me directly. The presentations will be mainly for a technical audience, usually 20 minutes, but we can accommodate one lighting talk of 10 minutes, or a more in depth one of 30. The slides will be posted on the ccNSO web site later, as usual, and we obviously do not look for a blueprint as to how to circumvent your measures. The use of AI would be very interesting or a "policy engine" and so forth. greetings, el On 2026/04/21 21:18, Dr Eberhard W Lisse via Cctldworld wrote: > > > vTechDay > at ICANN 86 > (Sevilla) > > The ICANN Tech Working Group is again planning a technical workshop > at the ICANN 86 meeting (Sevilla) > > As the meeting will be hybrid so will be vTechDay which is currently > penciled in for Monday, 2026-06-08 for blocks: > > > Block 1 10:00 - 11:15 (75 minutes) > Block 2 11:45 - 13:15 (90 minutes) > > > All times are local (Sevilla) time. > > We shall try to accommodate the time zone of virtual presenters in > setting the agenda. > > The TechDay workshop has been a part of ICANN meetings since 2006 > and has provided a forum for both experienced and new people to > meet, present and discuss technical topics related to registry and > DNS work and security. > > We are specially interested in: > > 1. DNS Abuse Prevention and Mitigation Tools > > 2. Best (security) management practices, lines of defense, to > protect Registries from bad actors, attacks or malware, or even > reports of failures > > 3. Open Source Tools that have been found helpful > > a) We would in particular like to hear about git based DNS zone > management, especially simple setups usable as example for other > (smaller) (cc|g)TLDs. > > b) We would also like to hear about further RDAP client > implementations in particular for the command line, devices and > libraries, and novel uses for/of same. > > If there are enough proposals we might have round tables. > > 4. In addition, we welcome suggestions for additional topics > > If you are interested in presenting on any other topic, please email > us at ccNSO-techday(a)icann.org or reply to this email. > > We hope that you can join us and request that you disseminate this > Request to other lists where it might of interest. > > greetings, el -- Eberhard W. Lisse \ /Obstetrician & Gynaecologist (retired) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht\ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply

1 0

Re: Another numbers request.
by Eberhard W Lisse April 21, 2026

April 21, 2026

Becky, you are the lawyer, I am not. I just mean a concept. Can you take down a Registered Name, just because (at least) another Name registered by same Registrant has been mitigated? If a single Registrant has 5 Names, 1 reported, investigated, proven as phishing, and mitigated accordingly, ADC done, and 3 of the others are mitigable, I still don't like that the 5th one would or could be mitigated as well. However as Marc wrote, you act against the Registrant (for violating the Terms and Conditions). How would that work? Can you really unilaterally decide to take Names down, or do you have to give notice of termination of the Registrant agreement (0 to n days notice)? So they transfer the Name elsewhere, and perhaps even register the mitigated Names again. Now you take a Reseller which has a Million Names. ADC finds 50, 500 or even 5000 in need of mitigation. Do you take the 50, 500 or 5000 names down or do you cancel the agreement with the Reseller (for violation the Terms and Conditions). What happens then to the Names left? Or if the Reseller is just irritated enough that they transfer significant Revenue elsewhere? There are enough accredited Registrars around, after all. The obviously even more difficult question is how to prevent them from becoming wise to the Policy and transferring the rest of a portfolio to another Registrar, when a single one is taken down, ie before the ADC can be done? We have not thought through the consequences of our considerations, and/or the cost. el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (retired) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply On Apr 14, 2026 at 18:50 +0200, Becky Burr <bburr(a)pir.org>, wrote: > I am confused by the use of the term “guilt by association” here. That usually means you consider one person guilty of some bad act because that person is associated with someone else who is a known bad guy. And yes, in that context, there are significant human rights concerns. > > Here, we are just saying that if a registrant/account holder is known to be using one domain for DNS abuse then we are going to check to make sure the same registrant/account holder isn’t using other domains for DNS abuse. And, if the answer is no, then nothing happens to the associated domains. So, unless you are arguing that domains themselves have human rights, I don’t see what the guilt by association issue is. > > Am I missing something? > > Becky Burr

9 16

DNS Abuse Mitigation PDP1 WG (Associated Domain Checks) work plan received by GNSO Council
by Jennifer Chung April 20, 2026

April 20, 2026

Dear All, A note that the GNSO Council in its April meeting last week has confirmed and acknowledged receipt of the DNS Abuse Mitigation PDP1 WG (Associated Domain Checks) work plan. A brief high-level update on current status was shared with Council as well as planned work ahead before ICANN 68. GNSO Council appreciates the efforts the WG undertook, incorporating community feedback received, to find efficiencies and adjustments that streamline the workplan by 4-5 months from the initial draft. Best, Jen GNSO Council Liaison to the DNS Abuse Mitigation PDP1 WG

1 0

Meeting Invitation / DNS Abuse Mitigation PDP1 WG | Monday, 04 May 2026
by Julie Bisland April 20, 2026

April 20, 2026

Reminder: The call for 27 April was cancelled due to the CP Summit. The next team call is 04 May: 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…>

2 1

High-Level Notes and AIs DNSAM PDP1 20 April 12:30 UTC
by Feodora Hamza April 20, 2026

April 20, 2026

Dear DNSAM PDP1, Please find below the high-level notes and Action Items from today’s meeting, Out next meeting is scheduled for Monday, 4 May 2026 at 12:30. There is no meeting on 27 April due to the CP Summit. Safe Travels and a good time to all travelling to Manchester. Kind regards, Feodora on behalf of Support Staff 2026-04-20 DNS Abuse Mitigation PDP1 WG<https://icann-community.atlassian.net/wiki/spaces/DAMP1/pages/935952385/202…> Action Items: WG Members · Review preliminary language for Charter Questions 3 and provide alternative language/changes/suggestions/etc. · Add comments and specific drafting suggestions for all “preliminary language/ CQ1-3” were relevant. · Review early input for Charter Questions 4 and 5 and provide comments and feedback to be discussed during next meeting. Leadership/Staff * Update collaboration document, develop preliminary language with today’s comments. Important documents/links: * Collaboration document: https://docs.google.com/document/d/1GxM-Yrgv6sZPEYU8ikW4cRM5YqWsJuWGiQyO39p… * Wiki space/slides: https://icann-community.atlassian.net/wiki/spaces/DAMP1/pages/935952385/202… * Recording: https://icann.zoom.us/rec/share/g9IUiTa38Sh-KUIzBeSMewHH70lrvVTQyHgHf_0Txki… [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/rec/share/g9IUiTa38Sh-KUIz…> High Level Notes: 1. Welcome (5 min) · Farzaneh Badi noted she joined an organization as part of Digital Medusa work called Future of Freedom of Speech, based in Nashville. · Reminder given on ICANN standards of behaviour, anti-harassment policy, and code of conduct. · Zoom settings have been updated and no Email will be asked to join the webinar. This was an unintentional setting change and has been addressed during the meeting. 2. Update ICANN86 planning (5 min) · Prep-Week webinar: Wed, 20 May 15:00 - 16:00 UTC · ICANN86: 4 DNS Abuse sessions (local time) planned for ICANN86. · 2 on Monday 8 June - 11:45 to 13:15 and 14:45 to 16:00 · 1 on Wednesday 10 June - 10:00 - 11:15 · 1 on Thursday 11 June - 11:45 - 13:15. 3. Continue discussion on strawperson CQ2 (20 min) · Chair presented revised text with new green-highlighted language reflecting prior working group comments and mailing list input. · General support for language allowing registrars to use a flexible set of criteria rather than a fixed checklist. · Discussion focused on whether there should be: · a minimum baseline expectation of checks using reasonably available information, while · preserving flexibility across different registrar business models. · Some WG members suggested, if registrars are given flexibility in methods, there should be some transparency around what factors are used. Could be periodic reports (6-month or annual), not necessarily incident-by-incident. · Some WG members noted obligations should be business model agnostic. · Other WG members noted, this could give threat actors a roadmap to evade detection. · Transparency reporting is not currently required under the RAA. · May be broader than this PDP and outside scope of Question 2. · Chair noted to include the Transparency topic as “interesting topic” to the list of topics to keep in mind and potentially communicate to Council. · Some WG Members linked transparency to Charter Question 5. 4. Discussion on preliminary language on CQ3 (25 min) * Chair presented preliminary language on CQ3. * Some WG Members objected to wording requiring a “reliable” internal data point due to ambiguity. * Also objected to language that could imply mandatory purchase/use of third-party intelligence feeds. * Split language into: · Must check one internal data point. · May use additional technical or abuse intelligence signals. · WG members noted one abusive domain should clearly be enough to trigger ADC and wording should not retreat from that. · WG members noted noted potential inconsistency in CQ1 and CQ3: · Earlier language suggested ADC would occur after mitigation. · Preliminary language in CQ3 noted flexible ADC before/during/after mitigation. 5. Deliberation on CQ4 (20 min) * WG members said registrars already must comply with: RAA, GDPR where applicable, National/local privacy laws * Investigations must follow evidence where it leads. “Strictly necessary” is too restrictive and unclear. * Better wording might be reasonable or reasonably necessary. * WG members noted raised distinction between: · Investigations yielding no result · Investigations leading to mitigation · Data needed for compliance etc. · Others noted against creating new retention rules where RAA already covers record retention. 6. AOB (5 min)

1 0

Post Call / DNS Abuse Mitigation PDP1 WG / Monday, 20 April 2026
by Julie Bisland April 20, 2026

April 20, 2026

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