Farzi,

Thank you for sharing the NCSG proposal. From the IPC’s perspective, we have concerns with a tiered approach to triggering Associated Domains Checks (ADC). 

First, the proposed tiers are inherently subjective. Distinctions such as “sophisticated” versus “generic” malware or phishing, or “large-scale DNS cache” lack clear, objective standards and would inevitably be applied inconsistently across registrars. That uncertainty undermines predictability and will lead to under‑enforcement, not proportionality. Obligations in this area need to be clear‑cut and operationally feasible if they are to be effective. 

Second, a tiered framework introduces unnecessary complexity at the point where speed and clarity matter most. DNS abuse is fast‑moving, particularly in light of botnets and domain generation algorithms, and requiring registrars to classify abuse into nuanced severity levels before conducting ADC will only delay response and create incentives to down‑rank harm.  The analysis should not be how “bad” an abuse is but whether the registration was malicious at inception. Waiting for a domain to reach a certain "severity" threshold before checking associated domains under common control gives attackers a head start and a manual to keep the abuse below the threshold. In DNS abuse, the goal is prevention, not just reaction.  Additionally, while the new language in the RAA states that the type of remediation action may vary depending on the circumstances, taking into account the cause and severity of the
harm from the DNS Abuse and the possibility of associated collateral damage, the obligation to take mitigation action itself is absolute once the registrar has actionable evidence of DNS Abuse.  The same should be required here – when the registrar has actionable evidence of DNS Abuse, it should have an obligation to conduct the ADC.  What it does after that is up to the registrar’s discretion unless the ADC uncovered actionable evidence of DNS Abuse in an associated domain, in which case the registrar would be obligated to take appropriate mitigation remeasures to disrupt the DNS Abuse pursuant to RAA 3.18.2.

Third, where there is a confirmed malicious domain name being used for DNS Abuse, if the goal is to reduce the incidence of DNS Abuse then it is objectively reasonable to check for other domains under common control.  Note that the compromised domain names are out of scope so the ADC would only be triggered when a registrant has intentionally used a domain name for DNS Abuse.  It is difficult to see how the ADC in this scenario would have any adverse impact – or any impact at all – on the human rights of the registrant who has intentionally used a domain name for DNS Abuse.  To be clear we are not of the view that a registrant who engages in DNS has no human rights or waives such human rights, but there is no human right we are aware of that protects the ability of a person to intentionally cause harm to others.  Furthermore, keep in mind that the ADC is being conducted by the registrar – not the government, the police or any third party.  Registrars already have access to this data and can already conduct ADC at any time whether there is actionable evidence of DS Abuse or not, so to the extent that there is any human rights impact on any registrant who registers and uses  a domain name for DNS Abuse being subject to ADC – which we vigorously dispute – this is no different from the situation they are already in.  Furthermore, it is unlikely that the registrar will take any further action against any associated domain unless there is actionable evidence that any associated domain is being used for DNS Abuse, and to the extent that a registrar would take any other action, they would already be able to do so regardless of the ADC.

Fourth, for a registrar, it is more efficient to run a query for all domains in the same account or using the same registration data or DNS data (or whatever the standard ends up being) based on actionable evidence of DNS abuse, rather than performing a complex qualitative analysis of how harmful that hit was. By making the check a standard response to any confirmed DNS abuse, the policy creates a stronger deterrent and a more robust safety net.

Ultimately, the ADC is a basic risk‑mitigation step for registrars and the public, not a punitive act toward innocent domain name registrants.  In short, tying ADC to a tiered “severity” model would weaken enforcement, increase inconsistency, and frustrate the PDP’s core objective of meaningfully addressing 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                         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@gtlaw.com | www.gtlaw.com  |  View GT Biography

I think Ching’s point doesn’t apply here. We are not arguing that ICANN does or doesn’t define abuse in terms of severity, we are arguing that when coming up with a mitigation mechanism, we need to consider severity of harm from the DNS abuse and the possibility of associated collateral damage when we want to obligate the registrar to take action (in this case to do ADC). We took this from ICANN contractual amendment language:  in ICANN contractual amendment that mitigation should take place "taking into account the cause and severity of the harm from the DNS Abuse and the possibility of associated collateral damage." Paragraph 3.18.2 https://itp.cdn.icann.org/en/files/accredited-registrars/registrar-accreditation-agreement-21jan24-en.pdf

Just because threat intelligence firms didn't focus on understanding severity doesn't mean our suggestion is void and has no backing. The fact that the industry hasn’t historically formalized severity of harm doesn’t make the concept invalid. It just reflects a gap. The threat intelligence industry probably didn't consider human rights either. 

***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. Action(s) may vary
depending on the circumstances, taking into account the cause and severity of the
harm from the DNS Abuse and the possibility of associated collateral damage.

Farzaneh 

On Mon, Apr 6, 2026 at 3:14 PM Reg Levy via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> wrote:

Agreed, Farzaneh, I think the specific levels are quibbles we can all have, but that the general idea is good.

 

To Ching’s point, ICANN does not define severity, which is why it should be reasonably determined by the registrar.

 

/R

 

--
Reg Levy | Associate General Counsel – Domains
+1 (323) 880-0831
Tucows #MakingTheInternetBetter

UTC -7

On Apr 6, 2026, at 11:44, Ching Chiao via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> wrote:

 

Hi Farzaneh, 

 

Thanks for the proposed idea. However, I am not in favor of this approach due to :

-- DNS abuse, as defined by ICANN, does not define severity.  

-- The "tier" has no industry reference or backing --  keep in mind there's broader Threat Intelligence service vendors that provide abuse reports and there are standards ( i.e. MITRE / STIX) that these vendors share the intelligence with each other / downstream customers. 

 

Best,

 

Ching 

 

 

On Mon, Apr 6, 2026 at 1:48 PM farzaneh badii via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> wrote:

Thank you, Reg. Yes we just wanted to show how we can do it with qualitative indicators instead of focusing solely on quantity. We can discuss measuring severity and appreciate your insights on that. 

Farzaneh 

 

 

On Mon, Apr 6, 2026 at 1:40 PM Reg Levy via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> wrote:

I like the idea of hanging review of additional domains on severity of [DNS] Abuse but I have some quibbles with regard to what qualifies as severe (there are some mass phishing attacks that could qualify as quite high, for example, and often the indicia are there to allow that determination).

 

/R

 

--
Reg Levy | Associate General Counsel – Domains
+1 (323) 880-0831
Tucows #MakingTheInternetBetter

UTC -7

On Apr 6, 2026, at 07:18, farzaneh badii via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> wrote:

 

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@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                         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@gtlaw.com | www.gtlaw.com  |  View GT Biography

<image001.png>

<image002.png>

 

From: Volker Greimann <volker.greimann@centralnic.com>
Sent: Thursday, April 2, 2026 2:51 PM
To: Trachtenberg, Marc H. (Shld-ASP-IP-Tech) <trachtenbergm@gtlaw.com>; steve.chan@icann.org; ching.chiao@whoisxmlapi.com
Cc: gnso-dnsabuse-pdp@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@centralnic.com
Office: +49-172-6367025
Web: www.teaminternet.com

Team Internet Group PLC (AIM:TIG). Registered Office: 4th Floor, Saddlers House, 44 Gutter Lane, London, United Kingdom, EC2V 6BR. Team Internet is a company registered in England and Wales with the company number 8576358.

 

---

From: trachtenbergm@gtlaw.com <trachtenbergm@gtlaw.com>
Sent: 02 April 2026 7:03 PM
To: Volker Greimann <volker.greimann@centralnic.com>; steve.chan@icann.org <steve.chan@icann.org>; ching.chiao@whoisxmlapi.com <ching.chiao@whoisxmlapi.com>
Cc: gnso-dnsabuse-pdp@icann.org <gnso-dnsabuse-pdp@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                         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@gtlaw.com | www.gtlaw.com  |  View GT Biography

<image001.png>

<image002.png>

 

From: Volker Greimann via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org>
Sent: Thursday, April 2, 2026 9:26 AM
To: Steve Chan <steve.chan@icann.org>; Ching Chiao <ching.chiao@whoisxmlapi.com>
Cc: gnso-dnsabuse-pdp@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@centralnic.com
Office: +49-172-6367025
Web: www.teaminternet.com

Team Internet Group PLC (AIM:TIG). Registered Office: 4th Floor, Saddlers House, 44 Gutter Lane, London, United Kingdom, EC2V 6BR. 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@icann.org>
Sent: 02 April 2026 5:35 PM
To: Steve Chan <steve.chan@icann.org>
Cc: gnso-dnsabuse-pdp@icann.org <gnso-dnsabuse-pdp@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 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@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/Community+Input
• 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) 

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536


                                                                  

Email: steve.chan@icann.org

Mobile: +1.310.339.4410

_______________________________________________
Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org
To unsubscribe send an email to gnso-dnsabuse-pdp-leave@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@gtlaw.com, and do not use or disseminate the information.

_______________________________________________
Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org
To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org

_______________________________________________
Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org
To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org

 

_______________________________________________
Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org
To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org

_______________________________________________
Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org
To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org

_______________________________________________
Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org
To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org

 

_______________________________________________
Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org
To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org