Industry

ICANN: 56% of Abusive Domains Are Registered in Batches

2026-10-07 · OSIR Team

ICANN's Office of the Chief Technology Officer published OCTO-044, Associated Domain Analysis Using Public Data, on 6 October. It sets out a reproducible way to find domains registered alongside ones already reported for abuse, using nothing but public data.

The headline number: 56.4% of reported malicious gTLD domains in the sample had at least one associated domain. Over half of abusive registrations did not arrive alone.

Fine, you might think, criminals buy in bulk. The reason to keep reading is what the method uses to spot them.

What the study did

The researchers took every newly registered gTLD domain that appeared on a reputation blocklist during a seven-day window, 24 to 30 September 2025, and worked outwards from each one looking for neighbours. Roughly 4,000 newly registered gTLD domains were added to those blocklists per day. Every day, for a week.

The blocklists were Spamhaus, SURBL, PhishTank, Urlscan, the APWG and Abuse.ch's URLhaus, covering phishing, malware distribution and botnet command-and-control.

Three techniques pivot from a flagged domain to its neighbours:

Each candidate group is then filtered a second time on how similar the domain strings are, using a random forest model, so that coincidence alone is not enough to call two domains related.

Crucially, the inputs are only: registrar name and IANA ID, authoritative nameservers, creation timestamp, and resolved IPv4 address. No registrant contact details, no payment data, no account identifiers. Everything is available through RDAP or WHOIS, though ICANN used its own bulk registration data access feed to avoid hammering RDAP endpoints.

The part that should make API users pay attention

Look at what those signals actually describe. Same registrar, same nameservers, registered within seconds or hours of each other, names that resemble each other. An agency buying forty variations of a client's brand on a Tuesday afternoon throws off all four. So does a developer scripting a portfolio purchase, a reseller importing a batch, and an agent registering a shortlist of candidates in one go. None of that is evidence of anything except a batch, and most batches are somebody doing their job.

The study is careful about this. The lexical filtering stage exists precisely because shared infrastructure alone produces too many coincidences, and the authors note the public-data approach "requires a process of inference and filtering to achieve high-confidence results". They also seed every search from a domain already reported for abuse, so an ordinary batch is never the starting point.

Still, the direction of travel matters. ICANN explicitly ties this to the DNS Abuse Mitigation policy work started in 2025, and says associated-domain checks by registrars "are likely to be an effective strategy for proactive identification of domains at high risk of abuse".

ICANN names API policy directly

One line in the discussion is aimed squarely at registrars like us:

Results are consistent with the importance of policies and practices put in place by individual registrars (e.g., regarding API availability and restrictions) for limiting high-volume registrations.

We sell API and agent access to domain registration. We are not going to pretend that sentence is about somebody else.

The report also argues that registrars are better placed than ICANN to do this work, because a registrar can see its own account data and does not have to infer relationships from public records: "In-house pivot analysis performed by registrars would bypass many of these constraints, leading to faster detection times." Public-data analysis is positioned as complementary to what registrars can do internally, not a replacement.

Where this leaves automated registration

Here is how we read it.

Counting domains tells you about a workflow, not about intent. If volume alone were treated as suspicious, the people inconvenienced would be resellers, brand protection teams, portfolio managers and anyone using an agent, while a campaign with any patience would just register more slowly and sail through. That trade is a bad one.

The more useful number in the report is the one about timing. Under 5% of these domains could have been caught any earlier by this method, perhaps 10% with the data delays stripped out. For the rest, the abuse was already running by the time the blocklist caught up. The lesson there is about acting on signals you already hold rather than waiting for someone else's feed, which is close to what ICANN says itself.

What we do about it is less exciting than it sounds. Registrations through our API, CLI or an agent all belong to an authenticated account. Anything costing money stops for a confirmation first. It all goes in an audit trail. None of that slows down ordinary work, and none of it is a silver bullet, but a campaign that needs a few thousand throwaway domains is looking for anonymity and speed, and this is a poor place to find either.

One last thing worth being clear about, because research papers have a habit of being reported as rules: OCTO-044 does not require anything of anyone. No registrar or registrant has a new obligation today. It feeds the GNSO policy process, and that is where a requirement would come from if one ever does.

Worth reading if

You run a reseller or an agency, register in volume through an API, work on abuse or policy, or just want to see how domain abuse is actually organised. It runs to 24 pages, the method is reproducible, and the appendices give the clustering algorithm and the model features if you want to try it yourself.

OCTO-044, Associated Domain Analysis Using Public Data by Sam Cheadle, Siôn Lloyd, Carlos Hernández-Gañán and Samaneh Tajalizadehkhoob, ICANN OCTO, dated 18 September 2026 and announced 6 October 2026.

FAQ

What is an associated domain?

A domain linked to another by how it was registered or where it is hosted, rather than by who owns it. In OCTO-044 the links are shared registrar and nameservers with close registration timing, or a shared IP address with close resolution timing, confirmed by similarity between the domain names themselves.

Does registering many domains at once get them flagged?

Not by this method. Every search starts from a domain that has already been reported to a blocklist for phishing, malware or botnet activity, then looks outward. An ordinary batch is never the seed. The study measures how often reported abuse arrives in batches, which is a different question from whether batches are abusive.

Will this change the rules for registrars?

No. OCTO-044 is a research publication from ICANN's technology office with no obligations attached. It feeds the DNS Abuse Mitigation policy development process begun in 2025, and any actual requirement would come from that process, not from this report.

Does the method use registrant personal data?

No. It uses registrar name and IANA ID, authoritative nameservers, creation timestamp and resolved IPv4 address. No contact details, payment data or account identifiers. The authors note that some technical identifiers may still relate to personal data depending on jurisdiction, and say the method is designed to minimise that.

What does 56.4% actually mean?

Of the reported malicious gTLD domains in the seven-day sample, 56.4% had at least one associated domain found by one or more of the three techniques. It does not mean 56.4% of all domains are abusive, or that over half of batch registrations are malicious.

Could my domains be caught by mistake?

The design limits it. Two filters apply: the search begins only from a confirmed abuse report, and candidates must then pass a similarity check on the domain strings. The authors are also open that public-data inference misses some real associations, which is the trade-off of not touching private data.

What should a registrar take from this?

That watching your own registration patterns in real time beats waiting for a blocklist. ICANN says as much: a registrar can see its own account relationships and act faster than any external analysis of public records can.

Image generated with AI (Higgsfield).