How the next round addresses DNS abuse reporting automation

As ICANN prepares for the next round of new gTLD applications, one of the most technically and policy-critical areas undergoing reform is the approach to DNS abuse reporting, specifically the automation of abuse detection, notification, and response workflows. The escalation of malicious activities such as phishing, malware distribution, botnet command-and-control domains, and domain name spoofing has intensified the pressure on registry operators and registrars to implement faster, more standardized, and more transparent methods for responding to abuse. DNS abuse has shifted from being an isolated issue to a systemic vulnerability, and the future of new gTLDs will depend heavily on the credibility of their operational practices in this area. In response, ICANN’s upcoming round introduces new expectations and frameworks that aim to drive automation into the core of abuse reporting processes.

DNS abuse reporting has traditionally been fragmented and reactive. Abuse notifications often arrived via email from trusted notifiers or researchers, with varying formats, evidence standards, and levels of urgency. Many registry operators relied on manual triage, limited tooling, and inconsistent criteria for what constituted actionable abuse. This lack of uniformity created delays, inconsistent remediation times, and sometimes left abuse unaddressed altogether. The situation became especially acute for gTLDs with high registration volumes or lax registration restrictions, some of which became magnets for bad actors seeking to exploit cheap, low-friction domain spaces.

In the next round, ICANN is expected to enforce a stronger, data-driven approach by requiring applicants to articulate a plan for DNS abuse reporting automation as part of their Registry Services Evaluation Process (RSEP) and pre-delegation testing. This includes specifying how abuse complaints will be received, parsed, validated, escalated, and resolved, using machine-readable formats and automated decision frameworks where feasible. Registries must describe the integration of these processes into their operational software, whether via API-driven ticketing systems, abuse detection feeds, or third-party security data partnerships. The emphasis is on reducing human bottlenecks and enabling rapid, consistent response to known threat signatures.

One of the key developments underpinning this shift is the adoption of structured reporting protocols such as the Abuse Reporting Format (ARF) and IODEF (Incident Object Description Exchange Format). These standards enable abuse reporters—such as anti-phishing coalitions, browser vendors, and CERTs—to submit detailed, machine-parseable reports that include contextual data such as log extracts, malware hashes, redirect chains, and timestamps. Registries receiving these reports can integrate them into SIEM systems, automated abuse scoring engines, or case management platforms that assess the severity, confidence level, and repeat offender status of each domain. This allows for prioritized remediation actions ranging from temporary suspensions to full takedowns.

Automation also extends to evidence correlation and threat intelligence enrichment. In many cases, a single domain flagged for phishing may be linked to dozens of others via common registrant information, name server patterns, or hosting infrastructure. Automated abuse systems can cross-reference domains against blocklists, DNS query telemetry, and passive DNS databases to surface related threats in real time. Registries with such capabilities can take preemptive action on entire clusters of abusive domains, rather than reacting piecemeal as individual reports arrive. This proactive capacity is seen as a mark of operational maturity and will be increasingly expected of applicants in the next gTLD round.

ICANN’s contractual framework is also being updated to support this model. Specification 11 of the Registry Agreement, which governs Public Interest Commitments, will be revised to include more concrete obligations around automated abuse handling. This may include required response time thresholds, evidence retention policies, and metrics reporting. Registry operators will be expected to publish transparency reports that detail abuse volume, remediation rates, average response times, and the effectiveness of automated systems. These reports must be generated on a recurring basis and submitted to ICANN for compliance audits, creating an accountability loop that reinforces investment in automation.

The role of the DNS Abuse Institute and its associated tools, such as NetBeacon, will also be amplified. NetBeacon provides a centralized platform for abuse reporters to submit standardized complaints, which are then routed to the relevant registry or registrar with structured data and verification steps already performed. In the next round, ICANN may encourage or require new gTLD operators to integrate with platforms like NetBeacon at the API level, enabling automated intake of verified abuse complaints and immediate response workflows. This integration not only increases efficiency but also minimizes false positives and enhances trust among stakeholders.

From a technical implementation standpoint, registries will be expected to deploy abuse reporting APIs that allow authorized entities to submit and track abuse complaints programmatically. These APIs can be used by law enforcement agencies, threat researchers, and ICANN’s own compliance team to file and monitor the status of cases in a scalable, non-email-based format. Registries that can demonstrate robust API capabilities, with documented endpoints and access control mechanisms, may receive favorable consideration during application evaluation and post-delegation reviews.

For registrar partners, the automation of abuse workflows presents both a compliance obligation and an operational benefit. Many registrars already use abuse management platforms that track complaints, enforce thresholds for abuse volumes per customer, and suspend or remove high-risk registrations. In the next round, registry operators will be encouraged to align with these registrar systems through shared data pipelines and synchronized enforcement actions. For example, when a registry suspends a domain for malware distribution, the associated registrar can be notified in real time to lock the domain, freeze account access, or initiate refund prevention mechanisms. This kind of registry-registrar coordination is central to a holistic DNS abuse mitigation strategy.

Finally, abuse automation intersects with emerging policy discussions around privacy, transparency, and trust. With much of WHOIS data now redacted under privacy laws such as GDPR, automated systems must balance the need for efficient abuse mitigation with data protection requirements. This has led to the growth of pseudonymized abuse correlation models and tiered access frameworks, where registries share minimal necessary data with trusted notifiers while ensuring due process and registrant notification. ICANN will likely encourage applicants in the next round to address these concerns explicitly in their abuse response policies, detailing how automation will be governed by privacy and security principles.

In summary, DNS abuse reporting automation is moving from a best practice to a baseline expectation for new gTLD registry operators. The next round will require applicants to demonstrate operational readiness not just in technical availability, but in scalable, repeatable, and transparent abuse handling processes powered by automation. This shift reflects the broader evolution of the internet’s security infrastructure—toward systems that are not only faster and more intelligent but are built for a world where domain names can be weaponized at scale and must be defended just as swiftly. For gTLD applicants who embrace this model, automation will be both a compliance enabler and a strategic differentiator in an increasingly risk-aware DNS ecosystem.

As ICANN prepares for the next round of new gTLD applications, one of the most technically and policy-critical areas undergoing reform is the approach to DNS abuse reporting, specifically the automation of abuse detection, notification, and response workflows. The escalation of malicious activities such as phishing, malware distribution, botnet command-and-control domains, and domain name spoofing…