Updates on abuse mitigation efforts
In January 2026, the gNSO adopted the PDP Charter for Associated Domain Check, which effectively initiated policy development work on DNS abuse. This PDP is expected to introduce new requirements for registrars to proactively check domains associated with malicious activity. The PDP will define the associated domain check’s triggers, scope, timeline, reasonableness, safeguards, documentation, and compliance metrics.
Numerous abuse-related sessions and discussions at ICANN85 in Mumbai expressed hope, enthusiasm and excitement. This is especially notable given that the PDP1 on Associated Domain Check is expected to conclude within an unusually short timeframe for the ICANN environment: 18 months (in comparison, the Expedited Policy Development Process on gTLD Registration Data took approximately six years). This is due to the narrow scope and relatively non-controversial nature of the subject matter, as well as the ambitious work plan involving 'asynchronous' problem-solving between meetings.
Despite the timeframes already being remarkably compressed, certain voices across the ICANN community (e.g., GAC and CSG) called for an even shorter finalisation timeline for PDP1, in order to move more efficiently within the series of PDPs on abuse, such as PDP2 on bulk registrations. However, these calls were met with some resistance from other corners of the community (e.g., Registrars, NCSG and ICANN Org), as the outcomes must be subject to a reasonable public comment period.
Triggers for associated domain checks
Regarding the substance of the discussion, the community discussed when an associated domain check could be triggered.
In the case of maliciously registered domains, the situation is slightly clearer. If it is confirmed that a registrant's multiple domains are engaging in malicious activity that falls under ICANN's definition of DNS abuse (i.e., phishing, malware, pharming, botnets, and spam as a delivery mechanism for everything above), registrars can deactivate them based on their own investigations after receiving one substantiated and well-evidenced abuse report.
However, what if the domain name is compromised? Can a registrant be penalised and lose all their domains in an unfortunate event of being hacked? Additionally, registrars shared their experience of receiving a significant volume of incomplete or inadequate ‘abuse’ reports that cannot be used to trigger associated domain checks and further mitigation actions. This confirms that no automated decision-making can result from associated domain checks, and that confirmed cases of abuse do not necessarily indicate malicious intent on the part of the registrant.
As discussions evolve, the community would need to dot down clarity on the triggers and the appropriate action resulting from the associated domain check.
Domain Generating Algorithms
The community also discussed the potential policy gap between conducting an associated domain check and taking mitigating action to address abuse before further harm is caused. Domain generating algorithms (DGAs) are an example of this potential policy gap.
Cybercriminals use DGAs to frequently change the domains in order to launch malware and botnet attacks. This enables them to avoid the blocking of specific domain names and static IP addresses. The DGAs usually operate on a large scale, requiring only one domain to be registered at the right moment to regain control of a botnet. Consequently, blocking one domain quickly becomes futile as the algorithm can generate thousands more across TLDs. Criminals also do not need to register all domain names in advance, making it more difficult to pre-empt the harm caused by DGAs.
The Public Safety Working Group (PSWG) and the Registries Stakeholder Group (RySG) have produced a Framework on Domain Generating Algorithms (DGAs) Associated with Malware and Botnets. This voluntary, non-binding framework does not reflect any consensus policy affecting gTLD registries. It suggests two options for gTLD registries to disrupt DGAs: 1) Reserve DGA domains on the reserve list to prevent malicious actors from registering domain names; or 2) Register DGA domains to capture and redirect traffic, and identify potential victims.
However, a gTLD registry cannot register domain names of its own accord, as the ICANN contract requires that all domain name registrations must be carried out via an ICANN accredited registrar. Additionally, the ICANN contract requires a transaction fee to ICANN for all domains created. Some malware or botnet families can comprise tens of thousands of domains, which would quickly make this an expensive and burdensome endeavour for a registry willing to do the right thing.
The rise of the DGAs in the late 2000s prompted ICANN to establish the Expedited Registry Security Request (ERSR) process (now renamed to Security Response Waiver (SRW) Requests), which enables gTLD registries to inform ICANN of a present or imminent security incident to their TLD and/or the DNS and request a contractual waiver for actions taken or to be taken to mitigate or eliminate the incident.
However, as DGAs and cybercriminal activity evolve, ICANN policies and processes need to evolve too. The SRW Requests process requires improvements to make it more efficient, agile and straightforward for registries and registrars who wish to take action to mitigate large-scale DGAs.
There is also a need for greater cooperation and collaboration across TLDs and industries. Software vendors, cybersecurity companies and law enforcement all play a role in identifying, disrupting and remediating the harm created by DGAs and large-scale malware campaigns. Reverse engineering algorithms, creating blocklists and prosecuting perpetrators requires a collective effort, with technical operators, the private sector, law enforcement and judicial authorities each playing a unique role. Registries and registrars should not be considered the ultimate burden-bearers for the cybercrime disruption and should operate alongside other parties.
What role does ICANN have in this ecosystem? One place to start is facilitating the sharing of information between different parts of the community, especially with regard to DGA-based threat information. However, changes also need to be made to the contracts and financial arrangements. Registries and registrars should not be penalised for taking action to help identify victims. The ability to do the right thing should be the norm, not the exception.
Attention from and to the ccTLD community
ccTLDs operate within a different policy landscape to gTLDs. When it comes to establishing policies and rules within ICANN processes, the communities of the two types of TLDs do not mix.
However, the situation is unprecedentedly unique for the abuse PDPs, as PDP1 has attracted considerable attention from the ccNSO. Consequently, several ccTLD representatives from various regions will participate in PDP1, enabling the sharing of ccTLD expertise in abuse mitigation and supporting the multistakeholder model. This could potentially contribute to reducing abuse across the broader ecosystem. As ccTLDs have significantly lower levels of abuse, they can offer valuable insights into the practices and approaches that have contributed to this outcome.
One of the best practices adopted by the European ccTLD community to tackle abuse is to carry out data verification checks, which allow the registry to take action without judging the content or malicious behaviour connected to a particular domain name. If a domain holder fails to correct their registration data, the ccTLD registry can suspend all associated domains. This gives the operator flexibility and enables domain holders to stay in control of their domain names by verifying their legitimacy. However, it does not always work for all types of abuse.
For example, during the joint ccNSO and gNSO session in Mumbai, the .rs registry presented a case study involving an illegal marketplace connected to a .rs domain, where the domain holder was unusually responsive during the verification checks. This case could only be resolved through successful cooperation with the national authorities and the public prosecutor's office, who obtained an order against the illegal content and involved the .rs registry in suspending the domain name. As outlined by .rs in their case study, the registry must be procedurally supported by the relevant authorities, who must perform due diligence before involving a registry. Close cooperation with the authorities and respect for the rule of law in cases involving illegal activity is a well-established practice among many European ccTLDs, such as .rs.
In conclusion, the Mumbai meeting was rich in insight and cross-community collaboration, involving actors such as ccTLDs, who can contribute unique perspectives and demonstrate the strength of diversity. A diverse range of approaches is vital when it comes to tackling online abuse, as it keeps malicious actors on their toes.
