|
||
|
||
Interisle Consulting Group’s new report on malicious domain registrations is generating significant attention. The headline finding—that 10% of all gTLD domains created in 2025 were blocklisted—is striking, and the underlying research on bulk registration patterns is genuinely useful. But the report combines several distinct measurement questions into a single dataset, something policymakers and industry observers should understand before drawing conclusions about registry and registrar accountability.
Interisle counts every domain listed by its reputation blocklist sources as a problem domain, including listings that blocklist providers themselves do not attribute to a specific abuse type. This sweeps in suspected scam and fraud sites, domains advertised in spam, and undifferentiated listings, including web pages hosting dangerous or unwanted content.
That is a legitimate research scope, but it is not “DNS Abuse” as ICANN’s contractual framework defines it: malware, botnets, phishing, pharming, and spam where it serves as a delivery mechanism for those harms. This distinction matters enormously for what can actually be done about it.
Registries and registrars cannot delete content. They cannot target a specific web page. Their tools are domain-level instruments: suspension, deletion, transfer-lock. Harmful content on a legitimate website is a matter for the hosting provider, or for law enforcement—not for the domain registrar. ICANN itself is specifically prohibited from creating policy on content, a restriction that reflects the importance of maintaining the neutral operation of a global, interconnected Internet.
When the report compares its domain counts with those of measurement platforms like NetBeacon MAP, which uses the ICANN definition, the difference in numbers reflects fundamentally different measurement objectives rather than a gap in detection. The two approaches are asking different questions and therefore produce different results.
The report’s more consequential conflation is treating presence on a reputation blocklist as equivalent to evidence that a domain should be suspended or deleted by a registry or registrar.
Reputation blocklists are excellent at what they are designed for: fast, low-risk, reversible decisions at the network edge. An email gateway or DNS resolver can block a domain on moderate suspicion because the cost of a false positive is small and quickly corrected. Domain suspension operates very differently.
Suspending a domain removes everything attached to it: every website, every mailbox, every subdomain, every service associated with that name. It is difficult to reverse in practice; and by the time it is reversed, the collateral damage may already be done. The evidentiary standard required for that action is correspondingly higher. It is not enough to establish that abuse occurred somewhere on a domain; the registration itself needs to be attributable to a bad actor, and domain-level action needs to be the proportionate remedy.
A related question is whether the abuse being measured remained active at the time of observation and whether remediation efforts had already occurred. Reports that seek to inform operator accountability should consider not only the presence of abuse signals, but also the extent to which registries, registrars, hosting providers, and other actors have already acted to address them.
A measurement framework intended to inform registry and registrar accountability should ask those questions. Many of the domains in a broadly-scoped blocklist dataset are not ones for which registrar-level mitigation is appropriate—including, critically, cases involving dynamic DNS and subdomain providers.
Services like dynamic DNS and free subdomain providers operate thousands of independent users under a single registered domain. Abuse on these platforms is real and significant. But it is subdomain service abuse: the registered domain is legitimate, the registrant is a legitimate business, and the correct mitigation path runs through the service provider, not the registrar.
Suspending the registered domain would harm thousands of innocent users to stop one bad actor. Interisle’s methodology counts only the second-level domain, which avoids inflating raw totals—but it means such domains can appear in TLD and registrar abuse counts despite being exactly the cases where registrar-level action would be wrong.
This is not a reason to ignore subdomain abuse. It is a reason to route mitigation appropriately and to be cautious about using broad blocklist counts to assess the performance of registries and registrars.
The report notes that its methodology draws on more blocklist feeds than some measurement platforms. More feeds yield more listings. They do not yield a more accurate count of domains for which DNS-level action is warranted.
The relative weighting of sources is also relevant. According to the report, Spamhaus DBL contributes 9.77 million domains, and SURBL contributes 6.54 million domains against a total deduplicated dataset of 14.86 million domains. While multiple feeds are incorporated, the resulting dataset remains heavily influenced by a small number of sources and their respective detection methodologies.
Every feed added to a measurement system imports that provider’s detection philosophy, risk tolerance, and false-positive profile. When the output is used to characterize named operators—with reputational and potentially contractual consequences—the provenance and quality of each signal matters. The right question for a policy-informing measurement framework is not how many feeds it ingests, but how well its output maps to actionable situations.
None of this negates the report’s genuine contributions. The analysis of bulk registration patterns—large volumes of domains registered quickly, often sharing infrastructure or payment patterns—adds useful texture to what the industry already knows about how malicious actors operate.
The report also rightly highlights the relationship between certain registration processes and abuse. Published research has identified correlations between malicious registrations and factors such as bulk registration activity and reduced friction in the registration process. These findings have direct relevance to the ongoing Policy Development Processes at ICANN, including the current DNS Abuse Policy Development Process examining Associated Domain Checks and future discussions around risk-based friction at the point of registration.
The pricing and payment methods observations are also worth pursuing, though carefully and in the context of existing academic research. ICANN’s INFERMAL study has found that registration discounts are particularly strongly associated with malicious registrations—more so than base price alone. INFERMAL also found that while registrars accepting cryptocurrency had a higher volume of abuse overall, payment method did not significantly distinguish malicious from benign registrations. The question of how criminals actually pay remains open—and can only be answered with operator data.
Understanding the total universe of potentially harmful domains has value for threat intelligence, consumer protection, and security research. Broad reputation datasets can help illuminate the scale and diversity of online harms.
The challenge arises when datasets optimized for understanding harm are used to evaluate the performance of actors whose available mitigation tools operate at a different layer of the Internet stack.
If the policy question is “How much potentially harmful activity exists online?” then broad reputation datasets may be appropriate.
If the policy question is “How effectively are registries and registrars mitigating harm that is proportionate and appropriate to tackle at the DNS level?”, then measurements must account for attribution, evidentiary standards, operational realities, and whether DNS-level intervention is the appropriate remedy.
Both are legitimate questions. They simply require different methodologies.
The Interisle report is a useful addition to the research landscape. Policymakers should read it with two questions in mind.
First: does the abuse being described fall within the scope of what registries and registrars can actually do something about? Broad blocklist counts, undifferentiated by harm type, can create pressure for DNS-level action in situations where DNS-level action is either unavailable or inappropriate.
Second: is the measurement framework asking whether a domain is one for which DNS-level mitigation is the right remedy? Counts that include subdomain service abuse, content-only harms, and broadly defined scam and fraud categories will always be larger than counts confined to contractually-scoped DNS Abuse. Larger is not necessarily more useful for informing operator accountability.
Interisle is answering one legitimate question. Policymakers should be careful not to treat it as the answer to a different one.
The long-term need is convergence: a shared taxonomy that distinguishes harm types and the appropriate mitigation layer for each, common evidentiary standards, and greater transparency regarding data sources, methodologies, and outcomes.
The Internet infrastructure industry should not be satisfied merely by pointing out the limitations of existing measurement approaches. If policymakers, researchers, and the public are asking increasingly sophisticated questions about abuse, mitigation, and accountability, the industry has a responsibility to help develop more transparent and actionable measurement frameworks and a deeper understanding of how online threats evolve.
The next generation of abuse measurement should focus not only on identifying harm, but also on understanding how the threat landscape is evolving. As malicious actors adapt to existing defenses, policymakers and industry alike need better insight into emerging tactics, evasion techniques, the role of AI in abuse campaigns, and which interventions are most effective at targeting bad actors while minimizing impacts on legitimate users. Those are ultimately the questions that matter for improving security and informing effective policy.
The objective should not be smaller numbers; it should be better answers.
Sponsored byIPv4.Global
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byDNIB.com
Sponsored byRadix
Sponsored byVerisign
Sponsored byVerisign