Reporting DNS abuse: what a registrar must and must not do
On 5 April 2024, amendments to ICANN's Registrar Accreditation Agreement took effect, imposing for the first time a binding duty on accredited registrars to act against well-evidenced DNS abuse. The change matters to anyone whose domain has been weaponized – or who suspects a competitor's domain is being used to deliver malware, run a phishing page, or operate a botnet. Knowing what a registrar must do, and where its duty stops, is now essential before you decide whether to report, litigate, or file a UDRP.
The April 2024 amendments define DNS abuse as malware, botnets, phishing, pharming, and spam where spam is a delivery vector for those four threats. Registrars must take "prompt, reasonable and appropriate action" to stop or disrupt confirmed abuse – but this is a mitigation duty, not an adjudication of trademark rights. A DNS-abuse report will not transfer a domain to you, and it does not replace a UDRP complaint or a court action where the underlying issue is cybersquatting.
This page covers what a well-evidenced report looks like, what mitigation means in practice, and when you need a different route entirely.
What changed on 5 April 2024 – and what did not
Before April 2024, registrars operated under contractual terms that addressed DNS abuse inconsistently. The amendments embedded a uniform, enforceable standard across all ICANN-accredited registrars for the first time. The duty is to mitigate; it is not to adjudicate who should own a domain.
The defined categories matter. A parked page monetizing a brand name does not meet the definition. Neither does a domain that passively redirects traffic for commercial gain at the expense of a trademark owner. Those are cybersquatting scenarios, and cybersquatting remains a matter for the UDRP or the courts. The amendments explicitly limit the technical-abuse duty to malware, botnets, phishing, pharming, and spam as a delivery mechanism for those threats. Mapping the complaint to the right category before you file anything is therefore the first practical step.
What did not change: the UDRP's three-element test under Paragraph 4(a), the available remedies of transfer or cancellation, and the filing fees at WIPO or the Forum. A DNS-abuse report that gets a phishing domain suspended is a different outcome from a UDRP transfer order – and one does not substitute for the other.
How does a registrar respond to a DNS abuse report?
A registrar's obligation is to take "prompt, reasonable and appropriate action" – a standard that leaves meaningful discretion. In practice, confirmed technical abuse can trigger a registrar lock, suspension of DNS resolution, or outright deletion of the domain. None of these outcomes returns the domain to you; they remove it from operation.
What the registrar is not required to do: transfer the domain to the reporting party, identify the registrant, or make any finding on trademark rights. If you need the domain transferred, you need a UDRP complaint, a ccTLD proceeding, or a court order. The registrar's mitigation response is a separate track running in parallel, not a shortcut through the dispute system.
Timing is not guaranteed either. "Prompt" is not defined in hours or days. A complex technical-abuse case involving a botnet spanning multiple domains may take longer than a clear-cut phishing page. For a brand owner whose customers are actively being misdirected to a fraudulent site, the speed differential between a registrar report and an emergency court application can be decisive. We regularly advise clients on the sequencing of those two routes when a live phishing attack is in progress.
What makes a DNS abuse report well-evidenced?
A vague allegation of abuse will not move a registrar. The amendments tie the duty to "well-evidenced" reports. Building that evidence base before submitting is where the practical work sits.
A useful report typically documents:
- The exact domain name, the registrar of record (from an RDAP lookup), and the date the abuse was first observed.
- Screenshots or automated scan results showing the malicious content – a phishing page, a malware download, or command-and-control traffic indicators.
- The harm: which users were targeted, which legitimate site or system was impersonated, and any evidence of actual compromise.
- Third-party technical evidence where available – threat-intelligence feed data, anti-phishing consortium reports, or your own security team's findings.
- Any prior correspondence with the registrar or registry and the responses received.
One practical note on registration data: as of 28 January 2025, ICANN no longer requires registrars to operate a WHOIS service. RDAP is the current standard for registration lookups, and personal data for individual registrants is routinely redacted. Identifying who is behind the abusive domain usually requires a separate disclosure request through ICANN's Registration Data Request Service (RDRS) – and the registrar's decision on that request is not automatic. Allow time, and build the technical evidence you can gather independently.
When is a DNS abuse report the wrong tool?
The most common mistake we see is treating a DNS-abuse report as a substitute for a domain-dispute proceeding when the real problem is cybersquatting, not technical abuse. The distinction is important and not always obvious.
Consider two scenarios. In the first, someone registers a domain that closely resembles your brand and points it at a parking page or a competing site to divert your traffic. That is cybersquatting. No registrar is obliged to act under the DNS-abuse amendments, because no malware, phishing, or botnet is involved. Your route is a UDRP complaint – all three elements of Paragraph 4(a), a USD 1,500 WIPO filing fee for a single-member panel covering one to five domains, and a decision in roughly two months.
In the second scenario, your own domain was stolen – the account credentials at your registrar were compromised, the registration was transferred without your consent, and the domain is now being used to serve phishing pages impersonating your business. That is both domain theft and DNS abuse simultaneously. The DNS-abuse report addresses the live phishing threat. Recovering the domain itself requires a separate escalation path: registrar-level transfer reversal, a UDRP (if the thief is a third party and the three elements are met), or a court action where arbitration is unavailable or insufficient.
We have managed matters where both tracks ran in parallel – the abuse report to stop the immediate harm, the recovery proceeding to reclaim the domain. Sequencing them correctly, and not letting one delay the other, is where specialist advice makes a practical difference.
What about WHOIS, RDAP, and identifying the registrant?
Identifying who controls an abusive domain is harder than it was five years ago, and that difficulty has procedural consequences across every route – DNS-abuse report, UDRP, and court alike.
RDAP replaced WHOIS as the standard on 28 January 2025. Public lookups frequently return a redacted record: the registrar, the registration date, and the status flags are visible, but the registrant's identity is not. To obtain non-public data, a party must submit a request through ICANN's Registration Data Request Service. As of 20 November 2025, that pilot was extended while ICANN decides next steps – confirm the current status before relying on it as a disclosure channel. The registrar assesses each request individually, and disclosure is not guaranteed.
For a DNS-abuse report, the identity gap is less critical: you are reporting technical conduct attached to the domain, not making a claim against a named respondent. For a UDRP or court action, it matters more. Panels can proceed against a registrant identified only by registration data, but building a strong record of bad faith is easier when the person behind the registration is known. Factor in the RDRS lead time when planning a UDRP filing.
What to do now
If your domain stopped resolving and the registration record changed without your consent, treat that as a domain-theft incident first. Start the registrar escalation immediately – registrar-lock reversal requests are time-sensitive, and delay can allow a further transfer. Document every step: the account-compromise indicators, the timestamp of the unauthorized transfer, and any communications with the registrar.
If a third-party domain is being used to abuse your brand technically – phishing, malware, impersonation – build the evidence package described above and submit it to the registrar. Do not wait for the UDRP to reach a decision before reporting, and do not assume the DNS-abuse report will resolve the underlying registration dispute.
For a cybersquatting situation with no technical-abuse element, go directly to the UDRP or the relevant ccTLD procedure. A DNS-abuse report in that scenario may produce no registrar response at all, because the registrar has no duty to act. The cost of misfiling is the time lost while the real proceeding waits.
For an assessment of your domain dispute – whether the issue is theft, technical abuse, cybersquatting, or all three – contact info@cognomenlaw.com.
COGNOMEN is an independent boutique focused exclusively on domain-name disputes. We recover, defend, and transact internet domains across generic and country-code zones, before WIPO, the Forum, CAC, ADNDRC, and national procedures, and in court where arbitration cannot reach. We act for brand owners, domain investors, and registrants – including respondent-side defense and reverse domain name hijacking. COGNOMEN focuses only on domain-name disputes – recovery, defense, and transactions. To discuss a domain, contact info@cognomenlaw.com.
Related at COGNOMEN
Frequently asked questions
What changed and when?
Amendments to ICANN's Registrar Accreditation Agreement took effect on 5 April 2024, binding all accredited registrars to take "prompt, reasonable and appropriate action" against well-evidenced DNS abuse – specifically malware, botnets, phishing, pharming, and spam as a delivery mechanism for those threats. That was the first time a uniform, enforceable mitigation duty existed across the registrar system. The amendments did not change the UDRP, its fees, or its three-element test.
Who does this affect?
Anyone who holds a domain registered with an ICANN-accredited registrar, and anyone who discovers that such a domain is being used to harm them technically. Brand owners facing phishing or malware campaigns, domain holders whose registrations were stolen and repurposed, and security teams dealing with botnet infrastructure will encounter this framework most directly. Registrars themselves now bear an enforceable duty they did not have before April 2024.
What should I do now?
Map the problem to the right route before acting. Technical abuse – phishing, malware, botnets – warrants a well-evidenced registrar report and, where the domain was stolen, an immediate registrar-escalation for transfer reversal. Cybersquatting without technical abuse goes straight to the UDRP or the applicable ccTLD procedure. If both are present, run the tracks in parallel. For a read on which route fits your situation, contact info@cognomenlaw.com.
Author: Adrian Harland — Court anticybersquatting and domain theft recovery. Meet the team.
Speak with Cognomen Law
For a scoped view of your domain matter, contact info@cognomenlaw.com. Discuss your matter
This publication is general information and does not constitute legal advice. For advice on your situation, contact info@cognomenlaw.com.