ICANN 85 Mumbai: DNS Abuse, DNS Abuse, DNS Abuse

Last week, ICANN held its community meeting in Mumbai. Rather than attempt a comprehensive recap of the full agenda, this post focuses exclusively on DNS Abuse Mitigation. There were 19 dedicated sessions on the topic across 6 days of policy work, which either reflects the community's commitment to solving the problem or its misunderstanding of what it is. Possibly both.

1. Online abuse is real, and criminals have gotten creative

The increase in online abuse is not a perception problem. Phishing, BEC fraud, QR code scams, SMShing: as our lives migrate further online, so do the people looking to exploit it. Criminals are adaptable, well-resourced, and demonstrably not intimidated by the domain industry's existing toolbox.

2. Registrars can pull one lever, and one lever only

This is worth repeating, because it keeps getting overlooked. When a registrar acts on a DNS abuse case, their only available tool is suspending the entire domain name. That means email, hosting, applications, all of it goes dark at once. There is no surgical option, no way to take down a single phishing page while leaving legitimate services intact.

That constraint matters because registrars are, paradoxically, among the most globally regulated actors in the stack. Every ICANN-accredited registrar operates under the same agreement, regardless of where they are based. That makes them an obvious target for anyone hoping to reduce online abuse.

For example, the host country of ICANN 85 is notably pushing to address content issues at the DNS level. Why this is a bad idea is explained far more eloquently than I could manage in this piece on CircleID.

3. The right venue matters

ICANN produces two types of legal instruments: consensus policy (developed through its multi-stakeholder model) and contractual amendments negotiated directly with registries and registrars. The DNS Abuse amendments that came into force recently took the latter route, and early results are encouraging. ICANN compliance is actively using its new auditing prerogatives, and registrars who previously ignored abuse reports are now more engaged. You can see the data for yourself on the ICANN compliance dashboard.

The contracted parties, having just been through that negotiation, have little appetite for going down that road again immediately. So the Registrar Stakeholder Group DNS Abuse Mitigation group (which I co-chair with the excellent Reg Levy) worked with our registry counterparts to identify gaps suitable for the policy development process. ICANN staff selected the Associated Checks on Domains (ACD) as the first topic in the series.

4. Death by PDP

Before getting to what ACD actually means, a word about process. 

The Policy Development Process (PDP) is ICANN's formal mechanism for turning community consensus into binding policy. It is thorough, inclusive, and sometimes immortal.

For a cautionary tale, look no further than the SSAD. After years of working groups, reviews, consultations, and every procedural variation ICANN could devise, the policy still had to be formally unadopted by the Board, who were understandably nervous about setting a precedent for overriding community work. 

The system has guardrails, but they cut both ways.

The ACD PDP Chair made it clear in Mumbai, across two two-hour sessions, that the scope must stay narrow. ICANN staff originally planned for the working group to meet for 4 hours per week. Given that working group members are volunteers with day jobs, this was wisely reduced to 90 minutes (every Monday at 12:30 if you wish to attend). The intended timeline has implementation landing in December 2027. The community is split: some find it rushed, while others think the scope is limited enough that 2027 is an eternity and an open invitation to scope creep. Both camps have a point.

5. Associated Checks on Domains: a sensible idea in need of careful boundaries

The ACD concept is straightforward. When a registrar confirms that one or more domain names in a customer account are being used solely for DNS abuse, it should not stop there. A brief look at adjacent registrations in the same account, think phishing1.com, phishing2.org, 1phishing.icu, costs very little and often reveals that suspending names one by one is operationally absurd. Most registrars already work this way.

The policy challenge is twofold. 

First, defining the scope of that investigation so registrars are doing a reasonable check rather than a fishing expedition (yes, I went there). 

Second, making sure the burden of proof stays where it belongs: with the reporter or ICANN compliance. If a registrar conducts an appropriate check and finds no associated abusive domains, they should not be required to prove a negative.

One nuance worth flagging here: the INFERMAL report places significant weight on the timing of domain registrations as an indicator of common ownership. That is not always reliable. Platforms often submit registrations in batches for technical reasons unrelated to the registrant placing a coordinated order. A policy that treats batch timing as presumptive evidence of associated ownership would be both technically unsound and operationally unfair.

6. What's next

The second PDP topic selected was API access. It will not run concurrently with the ACD work, but charter drafting should begin soon. The timing concern is real: the pool of qualified and willing contributors to these working groups is finite, and most will already be absorbed by the ACD PDP. Volunteer fatigue is not a hypothetical risk in ICANN policy work. It is a recurring feature.