Thanks for providing the Preliminary Issue Report on the policy development process regarding DNS abuse. Since the primary objective is to identify gaps in the DNS abuse mitigation process, I focus on the first two recommended gaps and proposed potential solutions based on both my personal and professional experience. It is important to emphasize that the following document represents solely my personal views on the published report and does not reflect the opinions of my employer or relate to my current professional role.

[FROM THE REPORT]

1. Unrestricted Access to Application Programming Interface (APIs) allowing for high-volume registrations (Page 12)

>> Description: Malicious actors use ungated access to APIs to register large volumes of domains in a matter of minutes, enabling large-scale phishing, smishing, and botnet operations. Many registrars require some sort of friction before a new customer account has access to an API where it can create thousands of names at once…..

My Comment:

What does the term “large volumes” mean in this context? Do we have a case study demonstrating a malicious actor (or group of actors) registering thousands of domain names at once?

I have observed cases involving a few hundred (approximately 200–500) domain name registrations in a single day, but not thousands. The choice of words is important because, if this argument is accepted as a gap and addressed as an issue, the next step would be to establish a threshold for API usage.

And then:

- How long would it take for registrars to implement the new threshold?

- What would the new threshold for bulk registrations be—5 domains, 500 domains, or another number?

- How could ICANN audit and ensure that registrars are correctly implementing this threshold?

- What if this new limitation gives rise to an underground business model, such as “bulk domain registration as-a-service”? In that scenario, the problem could become even harder to address, as the domain registrations would be distributed across multiple registrant accounts or even different registrars, making it more challenging for security vendors to detect large-scale DNS abuse.

[FROM THE REPORT]

2. No Requirement to Check for Associated Domains (page 24)

>> Description: Malicious domains are often part of broader campaigns involving dozens or hundreds of related domains. When a registrar finds that one domain is malicious, there is no contractual requirement that the registrar must investigate whether the same registrant or account has other active domains that are also being used for similar abuse.

>> Potential Solution: This gap was noted as high-priority for a consensus policy by the 2025 DNS Abuse Small Team. The Netbeacon White Paper proposes for a PDP to ….. by the same registrant. This “pivot” approach could help identify and mitigate related DNS Abuse more effectively, particularly in organized campaigns (including those registered in bulk to conduct such campaigns).

My Comment:

Interestingly, the solution proposed for the second identified gap conflicts with the first. If a policy is implemented to limit bulk registrations, there will be no bulk registrations to perform the “Associated Domains” check.

This check must rely on registrant’s email address, customer ID, payment method, or any other type of identifiable information. Some registrars are already performing these checks voluntarily. Introducing restrictive API access could spread domain registrations across multiple customer accounts or email addresses, potentially undermining the efforts of registrars who are currently conducting these checks voluntarily.

Another challenge with the “associated domain check” procedure is accurately distinguishing between maliciously registered domains and compromised ones. This can be very difficult, even for experienced security experts (see COMAR). In practice, most DNS abuse cases are handled by personnel with minimal training—sometimes just a few days (for example, a registrar refused to take down the malicious domain “ups[.]DOMAIN_NAME[.]top” because the screenshot did not include the UPS logo!). If a compromised domain is mistakenly flagged as malicious, checking associated domains could result in the take-down of several legitimate domains registered by the same account. For a real-world example, see this discussion: NamePros thread

Final Thoughts:

Putting both proposed solutions in place at the same time could make DNS abuse mitigation much harder. It might work better if ICANN suggests them only for registrars that have a high rate of abuse (as a recommendation or best practice), rather than applying them to all registrars.

The attached document provides several suggestions for improving current DNS abuse mitigation policies.

The attached document provides several suggestions for improving current DNS abuse mitigation policies including RA and RAA.

Important Considerations Based on My Personal Experience with DNS Abuse Mitigation and Reporting.