What Is DNS Abuse? A Clear Guide to ICANN DNS Abuse vs Non-DNS Abuse

From DNS Abuse Compliance to Industry Health: A Deep Dive into ICANN's New Guidelines by NiceNIC

In today's rapidly growing digital economy, the Domain Name System (DNS) has evolved beyond a simple "addressing tool" into a core pillar of the internet's trust infrastructure. As the landscape of online threats continues to grow in complexity, the risk of domain and DNS resource abuse for malicious activities remains high. To ensure a safer and more stable domain ecosystem, the Internet Corporation for Assigned Names and Numbers (ICANN) has updated new guidelines in the Advisory: Compliance With DNS Abuse Obligations in the Registrar Accreditation Agreement and the Registry Agreement.

As an ICANN-accredited registrar, NiceNIC not only provides reliable and secure domain registration and management services to clients around the world but also plays an active role in promoting DNS health and combating abuse. This article will provide a detailed breakdown of the core framework of DNS abuse compliance, the contractual responsibilities of registrars, and how to effectively implement these policies within operational strategies, all from an industry perspective.

What is DNS Abuse?
If you receive an abuse complaint, the first question is not "Who is right?" but "What kind of complaint is this?" Some reports involve DNS abuse as defined by ICANN. Others may involve illegal activity, content disputes, trademark issues, payment disputes, or platform-level problems that do not fall within ICANN's specific DNS abuse definition. ICANN's contractual framework for registrars focuses on DNS-level abuse handling, not on regulating all online content. This guide is designed to help registrants, reporters, and the public understand the difference.

NiceNIC is an ICANN-accredited registrar, and we handle abuse reports in line with ICANN's contractual requirements and abuse-handling rules. Our goal is not to shield abuse, but to review reports carefully, classify them correctly, and take appropriate action when required.

What counts as DNS Abuse under ICANN?
Under the Registrar Accreditation Agreement and ICANN's DNS Abuse framework, DNS Abuse means the following five categories:
Malware
Botnets
Pharming
Phishing
Spam, but only when the spam is used as a delivery mechanism for one of the four categories above

This definition matters because ICANN's abuse obligations for registrars are tied to these categories. Not every harmful, suspicious, or disputed website automatically falls within this DNS Abuse definition.

What is usually not "Non-DNS Abuse" in the ICANN sense?
Some complaints may still be serious, harmful, or unlawful, but they may fall outside ICANN's defined DNS Abuse categories. They are also called "Actionable Reports of DNS Abuse". Depending on the facts, examples can include:
Copyright disputes
Trademark or brand disputes
General fraud allegations without DNS Abuse evidence
Contract disputes between private parties
Product quality complaints
Defamation claims
Consumer disputes better handled by the merchant, payment provider, marketplace, or law enforcement
Website content concerns that do not involve phishing, malware, botnets, pharming, or qualifying spam

This distinction is important because ICANN's abuse-related obligations for registrars are specifically tied to DNS Abuse as defined under the Registrar Accreditation Agreement (RAA).
Under Section 3.18.2 of the RAA, as modified by the DNS Abuse Amendments, a registrar is required to take action when it has actionable evidence that a registered domain is being used for DNS Abuse. In such cases, the registrar must promptly take appropriate mitigation measures that are reasonably necessary to stop or disrupt the abuse, taking into account the severity of harm and the potential for collateral impact.
However, where a complaint does not involve ICANN-defined DNS Abuse, this specific contractual obligation does not apply in the same way. This is why proper classification of the complaint type is essential before determining the appropriate response path.
That does not mean such complaints are unimportant. It means they may need to be directed to the correct channel, such as a hosting provider, site operator, payment processor, platform, legal counsel, or relevant authority, depending on the nature of the issue.
ICANN has also made clear that its role is focused on DNS-level activities, and its Bylaws generally do not extend to regulating the content hosted on websites, except in limited circumstances.

What ICANN requires registrars to do?
Under the 2024 amendment to RAA Section 3.18, registrars must:
1. Maintain an abuse contact for reports involving registered names they sponsor. Publish an abuse email address or webform in a place that is conspicuous and readily accessible from the homepage
2. Confirm receipt of abuse reports
3. Take reasonable and prompt steps to investigate and respond appropriately
4. Promptly take appropriate mitigation action when they have actionable evidence that a domain is being used for DNS Abuse
5. Publish procedures for receipt, handling, and tracking of abuse reports
6. Keep records relating to abuse reports for the required retention period
These are real contractual duties. They are part of what it means to be an ICANN-accredited registrar.

What "actionable evidence" means?
ICANN's advisory makes an important point: the evidence must be sufficient to allow a reasonable determination that a domain is being used for DNS Abuse. A report may be incomplete on its face, but still become actionable if the registrar can verify additional relevant information through investigation. On the other hand, if there is not enough evidence, ICANN Contractual Compliance may treat the complaint as invalid.
In practice, helpful evidence often includes:
The exact domain name involved
The specific URL or subdomain involved
Screenshots
Full message headers for phishing emails, where available
The abusive email, SMS, or redirect behavior being reported
Timing details
Any technical indicators that help confirm the abuse
The more specific the evidence, the easier it is to evaluate whether the report concerns ICANN-defined DNS Abuse. ICANN also encourages abuse reporters to provide as much information as possible.

What "prompt" means under ICANN rules?
ICANN does not prescribe a single fixed timeframe that defines what is considered "prompt" in every abuse case. Instead, the appropriate timing depends on the specific circumstances, including the nature of the abuse, the severity of harm, and the potential for collateral impact.
ICANN's guidance and examples under the Registrar Accreditation Agreement (RAA) illustrate that "prompt" action is evaluated based on whether the registrar acts reasonably, proportionately, and without unnecessary delay after receiving actionable evidence of DNS Abuse.

For example:
In a phishing case involving a newly registered domain with clear indicators of abuse, a registrar may investigate and suspend the domain within two business days, applying appropriate status controls to stop the abuse.
In another case involving a long-established domain where abuse occurs at the subdomain level (and may result from a compromise rather than intentional misuse), the registrar may determine that immediate suspension of the entire domain could cause significant collateral damage. In such cases, the registrar may instead notify the registrant and require remediation within a reasonable timeframe, such as within three business days, to disrupt the abuse without unnecessarily affecting legitimate services.

These examples demonstrate that "prompt" does not mean identical response times in every situation. Rather, it reflects whether the registrar:
Initiates investigation in a timely manner
Assesses the available evidence carefully
Takes mitigation actions that are appropriate to the specific context
Acts as soon as reasonably possible after confirming DNS Abuse
In this context, compliance is not measured by a fixed number of hours, but by whether the registrar can demonstrate that its response was timely, reasonable, and aligned with the requirements of Section 3.18 of the RAA.

Why immediate suspension is not always the right answer?
ICANN's advisory specifically explains that the appropriate mitigation may vary. For example, when a legitimate domain is compromised without the registrant's knowledge, direct suspension of the whole second-level domain may create collateral damage by cutting off legitimate website content, email, and other services. This is also relevant when the abuse involves a subdomain or specific URL, because registrars and registries generally act at the second-level domain level.
In those situations, notifying the registrant, site operator, or hosting provider may sometimes be the more proportionate way to disrupt the abuse. ICANN's own examples include both full suspension in a phishing case and notice-based disruption in a compromised-domain case.
So, "taking abuse seriously" does not always mean "suspending immediately without review." It means taking proportionate action based on evidence and context.

How NiceNIC reviews abuse handling?
As an ICANN-accredited registrar, NiceNIC follows a compliance-based approach to abuse handling.
Our handling process is guided by several principles:
1. We classify the complaint first.
We first assess whether the report appears to involve ICANN-defined DNS Abuse, other illegal activity, or a matter better handled by another party. This helps reduce misrouting and improves response accuracy. The classification logic reflects ICANN's DNS Abuse definition and its DNS-level focus.
2. We review the evidence.
We evaluate whether the report contains actionable evidence or whether more information is needed. ICANN's framework requires investigation and appropriate response, not blind action based on unsupported allegations.
3. We respond in line with the circumstances.
Where DNS Abuse is reasonably confirmed, appropriate mitigation may include suspension or other measures reasonably necessary to stop or disrupt the abuse. Where the case involves a compromised legitimate domain or a narrower abuse vector, the right step may involve notice, remediation, or coordination with the relevant operator instead of immediate blanket suspension.
4. We do not support abusive use of domains.
Nothing in this guide should be read as support for phishing, malware, botnets, pharming, qualifying spam, or other unlawful conduct. The purpose of this article is to help customers understand how complaints are categorized and why different types of complaints may follow different compliance paths. This is consistent with ICANN's abuse-handling framework.

If you are a registrant and you received an abuse complaint
Start by asking:
Is the complaint about phishing, malware, botnets, pharming, or spam used to deliver those harms?
Does the complaint identify a specific URL, subdomain, message, or technical indicator?
Could your site or account have been compromised without your knowledge?
Is this actually a hosting issue, content issue, payment dispute, or trademark issue instead?
If the issue is a compromise, act quickly to secure the affected service, remove the abusive material, and preserve evidence.

If you are a reporter submitting an abuse complaint
To help a registrar assess the matter efficiently, provide clear and specific evidence. ICANN's framework works best when the report is complete enough to support a reasonable determination. General accusations without verifiable evidence are harder to process and may not be actionable.

Conclusion
Under ICANN's rules, DNS Abuse has a specific meaning. It is not a catch-all label for every online dispute or every kind of harmful content. That distinction protects both abuse victims and legitimate registrants by helping ensure that the right problem is sent to the right response channel.
NiceNIC is an ICANN-accredited registrar and follows ICANN's abuse-handling requirements, including maintaining abuse contacts, reviewing reports, and taking appropriate action when actionable evidence of DNS Abuse is present. Our position is straightforward: we support compliance, we do not support abuse, and we believe abuse handling should be evidence-based, proportionate, and consistent with ICANN's framework.