The ICANN community is gearing up for the policy development on DNS abuse
With the latest contractual amendments, adopted in 2024, the ICANN community did not address all DNS abuse mitigation gaps. The DNS Abuse Small Team conducted a review of data to identify potential gaps in DNS abuse mitigation efforts. The team identified 'gaps' in DNS abuse mitigation efforts, noting areas where abuse prevention, reporting, response or obligations could be strengthened.
The Preliminary Issue Report from September 2025 identifies priority areas that the ICANN community can address in the upcoming DNS abuse policy development process (PDP). These are: 1) unrestricted application programming interface (API) access for high volume registrations; and 2) associated domain checks.
In the context of the API access, the ICANN community will discuss applying friction to ungated batch API tools that have been associated with a higher number of malicious registrations (as identified in ICANN’s INFERMAL study). Potential friction measures could include waiting periods, clean transaction history and additional abuse checks.
As the main target group for any potential policy development process on abuse and the party closest to the registrant, registrars ask for maximum flexibility in deciding on DNS abuse mitigation measures due to the different business models and practices already in place to address abusive registrations. Public Safety Working Group (PSWG) members, including European Commission representatives, emphasise the importance of adding legal entities' identity checks to the range of potential mitigation measures available to registrars (i.e. following the EU's NIS2 example of mandatory verification checks).
Associated domain checks are slightly more controversial, as both registrars and the Non-Commercial Stakeholder Group (NCSG) have raised legitimate concerns about the disproportionate impact on legitimate registrants if the outcome of the policy development process includes the automatic decision-making and takedowns of all domain names associated with a registrant whose registration details are linked to one abusive domain name. Questions regarding compromised domain names, identity theft and overzealous enforcement were raised at ICANN84 to inform the upcoming PDP on this issue.
One potential solution to ensure that any PDP process takes into account the potential disproportionate impact on registrants' fundamental rights, either privacy or freedom of expression, is to ensure that all PDPs are accompanied by a proper human rights impact assessment (HRIA). This would also address any concerns related to associated domain checks that may involve automatic decision-making or unwanted profiling of registrants. We hope that the NCSG’s call for mandatory HRIAs for all ICANN PDP will be heeded. As the DNS infrastructure is increasingly recognised as critical infrastructure with a strong public interest angle across regions, the lack of proper HRIAs when global DNS policies are discussed represents an important policy gap that needs to be addressed.
Notably, the principle of proportionality criteria, which has its roots in the human rights discourse, is already an important guideline for European ccTLDs when considering abuse mitigation action at a domain level. European ccTLDs are consistently considered the cleanest zones globally, with very low levels of abuse.
At the same time, the majority of European ccTLDs do not have an established definition of DNS abuse, as opposed to the ‘Big 5’ definition adopted by the ICANN community (i.e., phishing, malware, pharming, botnets, spam when used a delivery mechanism). As illustrated by the .ie presentation to the Governmental Advisory Committee (GAC), the .ie registry has a broader view of ‘abuse’ than ICANN’s official definition. Instead, the .ie registry is guided by the “appropriate technical & organisational measures” framework to mitigate any type of abuse. This includes assessing the proportionality of action at a domain level on a case-by-case basis, while considering any adverse outcomes for registrants and the rest of the local internet community, as well as establishing meaningful collaboration with the relevant competent public authorities.
Access to registration data: How to authenticate requestors?
Another key update from ICANN84 concerns the future of the Registration Data Request Service (RDRS). ICANN launched the RDRS in November 2023. The service provides a standardised format to submit requests to ICANN-accredited registrars for the disclosure of non-public registration data related to gTLDs. As the current RDRS pilot is running out in early November 2025, the ICANN community is discussing the way forward, given that the RDRS is considered an important tool for law enforcement and intellectual property rights communities.
One of the main topics of discussion at the ICANN84 was the potential for making the RDRS a mandatory mechanism, which would require all ICANN-accredited registrars to participate. Registrars were generally sceptical about the plans to make the RDRS mandatory, given that only ca 60% of registrars took part in the voluntary pilot. This means that the usage data and statistics on the tool’s usefulness are incomplete. Registrars also stressed that their existing disclosure mechanisms and platforms are much more efficient, as the RDRS is not a disclosure mechanism and should not become one due to jurisdictional complexities. Exploring API connections between existing registrar systems and the RDRS may allow for more seamless participation from registrars.
The GAC insisted on the participation of ccTLDs in the RDRS, which can only be voluntary, given that ccTLDs are outside the ICANN PDP and contractual remit. Another issue for the GAC is the authentication of law enforcement authorities in the context of the RDRS. The PSWG will lead a technical track exploring possible mechanisms for authenticating law enforcement requestors, with development work expected to begin in the first half of 2026.
On 30 October, the ICANN Board decided to continue the operation of the RDRS until December 2027, while the community continues to deliberate on the future of the service and related policy recommendations.Together with the Board resolution, ICANN published a “policy alignment analysis” to determine how current policy implementation, existing policies, new policies or a combination of all three could support a long-term solution for the RDRS. Regarding the authentication of law enforcement, potential policy changes may be necessary. For the technical work connecting existing registrar ticketing systems to the RDRS, no policy recommendation is required.
The authentication of law enforcement authorities remains a sticking point in all cross-border data access requests, both within and outside the ICANN community. In Europe, ccTLDs face similar issues regarding compliance with the e-Evidence Regulation, albeit the stakes are higher with legislative requirements than with a voluntary ticketing system at ICANN level. Service providers in the EU (including TLD registries) are awaiting the implementation of a decentralised IT system developed by the European Commission for processing all orders for access to and preservation of electronic evidence across the EU. The usefulness of the Commission’s IT system is clear, as it will significantly reduce the legislative compliance burden for all service providers within the scope of the e-Evidence Regulation, and provide reassurance to registries and registrars regarding the legitimacy of foreign authorities' data access requests.
However, in the context of the RDRS, it is unclear what the incentives are for registrars to participate in the system, even if participation is mandatory. The ability to send data access requests across the globe is definitely a useful tool for requestors. However, legislative frameworks, due diligence and human rights safeguards, as well as the jurisdictional competencies of different law enforcement authorities, vary greatly from one country to another. According to ICANN’s data, 66% of requests submitted to registrars via the RDRS were denied in the first year of the pilot, showing a discrepancy between the expectations of requestors and the compliance reality of registrars. As the latest usage report shows, the majority of disclosure requests could not be approved due to the legislation that registrars are subject to.
Although participating registrars only receive data access requests via the RDRS, they still have to check the legitimacy of the request and assess whether they can fulfil it, while disclosing the data via their own channels and systems. Perhaps it would be beneficial to limit the number of access requests that participating registrars receive via the RDRS by implementing some sort of pre-screening criteria for authenticating requestors. The community could agree on what type of criteria and evidence the requestor must submit to demonstrate their legitimacy.
Both discussions are progressing slowly but steadily. Certain constituencies (e.g. the GAC) are calling for them to be completed before the next round of gTLDs in Q2–Q3 of 2026. If they are considered best practice, focused mitigation measures on abuse and streamlined RDRS - when deployed with an appropriate HRIA - will have an industry-wide impact.
