X
NiceNIC Abuse H??ling Manual
1. Purpose
NiceNIC maintains this Abuse H??ling Manual to ensure that abuse complaints involving ????? names spons??ed by NiceNIC are received, assessed, tracked, investigated, ?? addressed in a consistent, documented, ?? risk-based manner.
This manual is designed to achieve four outcomes at the same time:
1.protect Internet users ?? affected parties from ongoing harm;
2.meet NiceNIC's contractual obligations as an ICANN-accredited registrar;
3.provide fair, predictable, ?? documented h??ling f?? registrants ?? resellers;
4.demonstrate a clear, defensible, ?? auditable abuse response process.
NiceNIC will investigate abuse rep??ts promptly ?? will take mitigation actions that are reasonably necessary based on the quality of the evidence, the nature of the rep??ted activity, the likelihood of ongoing harm, ?? the risk of collateral damage to legitimate ????s. This approach is aligned with Section 3.18 of the 2013 RAA ?? ICANN's 2024 DNS Abuse Advis??y.
2. Scope
This manual applies to:
3. Definitions
3.1 ICANN Contractual DNS Abuse
F?? NiceNIC's contractual compliance purposes, DNS Abuse means:
3.2 NiceNIC Exp??ed High-Risk Abuse Categ??ies
NiceNIC may also classify certain matters as Exp??ed High-Risk Abuse Categ??ies under its own abuse ?? risk rules, even w???? they are not automatically ICANN-defined DNS Abuse. These may include:
3.3 ????n-DNS Abuse / Other Complaints
These commonly include:
4. Guiding Principles
NiceNIC h??les abuse rep??ts acc??ding to the following principles:
5. Rep??ting Channels
NiceNIC shall maintain:
6. Minimum Inf??mation Required in a Complaint
?? ??? be processed efficiently, a complaint should include:
7. Evidence St??ards
7.1 ????????able Evidence
Evidence is actionable when the inf??mation reasonably available to NiceNIC is sufficient to determine that the spons??ed ????? name is being used f?? DNS Abuse ?? other enf??ceable abuse activity.
??????s include:
7.2 Insufficient Evidence
Evidence is insufficient w???? the complaint contains only:
7.3 Third-Party Intelligence
NiceNIC may consider third-party signals such as:
8. Case Pri??ity ?? Internal SLA
NiceNIC adopts the following internal operating targets. These are NiceNIC internal SLAs, not statements of ICANN-m??ated fixed deadlines.
Pri??ity 0 - Emergency / Active Harm
??????s:
Pri??ity 1 - High-Risk ????????able Abuse
??????s:
Pri??ity 2 - ????n-DNS Abuse with Sufficient Evidence
??????s:
Pri??ity 3 - Incomplete / Low-Quality Rep??ts
Target:
9. W??kflow
9.1 Intake
Every rep??t receives:
9.2 Triage
The case is classified by:
9.3 Investigation
The reviewer checks:
9.4 Decision
Possible outcomes:
9.5 ????tifications
F?? clear, actionable, ongoing DNS Abuse, NiceNIC may suspend first ?? notify after action.
F?? likely compromise scenarios ?? non-DNS matters, NiceNIC may notify first w???? that is consistent with risk control ?? does not materially increase harm.
This distinction is consistent with ICANN's position that mitigation may vary depending on the harm ?? the risk of collateral damage.
10. ??????-Specific Rules
10.1 Drugs / kra / slon / mega ??????
Keyw??d presence alone is not enough f?? DNS-Abuse classification.
Treat as:
10.2 Crypto Scam
Treat as:
10.3 CSAM / Child Exploitation
Treat as immediate high-risk abuse. Escalate internally without delay. Preserve rec??ds, avoid unnecessary customer back-??-f??th, ?? escalate to the appropriate auth??ity ?? registry if required.
10.4 DMCA / ????????
Do not auto-suspend purely on large content lists ?? unsupp??ted bulk allegations.
F??ward proper notices w???? appropriate, require a compliant notice f??mat, ?? allow the ????? holder to address the claim unless a court ??der, registry rule, ?? other stronger basis requires m??e immediate action.
This is also broadly consistent with how maj?? registrars separate copyright/trademark processing from phishing/malware h??ling.
10.5 Trademark / Br?? Complaints
Trademark disputes are not automatically DNS Abuse.
W???? the issue is a ?????-name rights dispute, complainants should generally be directed toward UDRP, URS, ?? court process as appropriate, unless the evidence also shows phishing, impersonation, ?? other abuse. ???????? publicly distinguishes abuse h??ling from UDRP/URS h??ling in the same way.
11. Registrant / ?????? Communication Rules
11.1 Retail Customers
F?? clear DNS Abuse with sufficient evidence:
11.2 ??????s
NiceNIC may choose to notify the reseller rather than any downstream sub-user.
However, reseller status does not delay urgent mitigation w???? actionable evidence exists.
11.3 Reconsideration / Reactivation
NiceNIC will not lift a hold based on unsupp??ted denials such as "content removed" ?? "it was already deleted" alone.
Reconsideration requires new, verifiable evidence such as:
12. Complainant Communication Rules
NiceNIC should always send:
13. Trusted Rep??ter Program
NiceNIC may maintain a trusted-rep??ter list f?? sources that consistently provide accurate, well-f??med, ?? actionable rep??ts.
Trusted-rep??ter status may provide:
14. Rec??dkeeping ?? Audit Readiness
NiceNIC must document:
15. Compliance Controls
NiceNIC should perf??m:
16. Metrics
NiceNIC should track at least:
17. External-Facing Positioning
NiceNIC should describe its abuse system publicly in language like this:
1. Purpose
NiceNIC maintains this Abuse H??ling Manual to ensure that abuse complaints involving ????? names spons??ed by NiceNIC are received, assessed, tracked, investigated, ?? addressed in a consistent, documented, ?? risk-based manner.
This manual is designed to achieve four outcomes at the same time:
1.protect Internet users ?? affected parties from ongoing harm;
2.meet NiceNIC's contractual obligations as an ICANN-accredited registrar;
3.provide fair, predictable, ?? documented h??ling f?? registrants ?? resellers;
4.demonstrate a clear, defensible, ?? auditable abuse response process.
NiceNIC will investigate abuse rep??ts promptly ?? will take mitigation actions that are reasonably necessary based on the quality of the evidence, the nature of the rep??ted activity, the likelihood of ongoing harm, ?? the risk of collateral damage to legitimate ????s. This approach is aligned with Section 3.18 of the 2013 RAA ?? ICANN's 2024 DNS Abuse Advis??y.
2. Scope
This manual applies to:
- ????? names spons??ed by NiceNIC;
- abuse rep??ts submitted by individuals, companies, security researchers, trusted rep??ters, registries, law enf??cement, ?? other auth??ities;
- retail customers ?? reseller-managed names;
- both DNS Abuse ?? non-DNS abuse ?? illegal-activity complaints.
3. Definitions
3.1 ICANN Contractual DNS Abuse
F?? NiceNIC's contractual compliance purposes, DNS Abuse means:
- malware
- botnets
- phishing
- pharming
3.2 NiceNIC Exp??ed High-Risk Abuse Categ??ies
NiceNIC may also classify certain matters as Exp??ed High-Risk Abuse Categ??ies under its own abuse ?? risk rules, even w???? they are not automatically ICANN-defined DNS Abuse. These may include:
- child sexual abuse material (CSAM) ?? child exploitation content;
- illicit drug sales ?? high-risk narcotics content;
- crypto fraud schemes;
- content creating imminent risk of serious harm;
- other illegal activity w???? urgent action is justified by law, registry policy, competent auth??ity request, ?? clear risk evidence.
3.3 ????n-DNS Abuse / Other Complaints
These commonly include:
- trademark disputes;
- DMCA / copyright claims;
- adult content;
- gambling ?? gaming content;
- misleading ?? fraudulent content without technical DNS-abuse evidence;
- pharmacy / drug content without qualifying DNS-abuse indicat??s;
- general policy violations.
4. Guiding Principles
NiceNIC h??les abuse rep??ts acc??ding to the following principles:
- Evidence first. NiceNIC does not take DNS-level action based on keyw??ds, assumptions, ?? unsupp??ted allegations alone.
- Risk-based response. Faster ?? stronger action applies w???? the evidence is actionable ?? the harm is ongoing ?? severe.
- Least necessary disruption. NiceNIC may choose a mitigation method other than immediate suspension w???? the evidence indicates a compromise scenario ?? a full hold would create disprop??tionate collateral damage.
- Consistency ?? documentation. Every case must be categ??ized, tracked, ?? rec??ded.
- Clear separation of roles. NiceNIC is a registrar. In many cases, the hosting provider, platf??m operat??, payment process??, ?? law enf??cement may also be a relevant ?? m??e effective action point.
5. Rep??ting Channels
NiceNIC shall maintain:
- a public abuse contact email on its website homepage ?? designated abuse page;
- a published description of how abuse rep??ts are received, h??led, ?? tracked;
- a dedicated 24/7 monit??ed abuse contact point f?? law enf??cement ?? similar auth??ities as required under the RAA.
- abuse mailbox;
- supp??t ticket system;
- webf??m;
- trusted-rep??ter channel;
- registry escalation;
- law-enf??cement / government channel.
6. Minimum Inf??mation Required in a Complaint
?? ??? be processed efficiently, a complaint should include:
- the rep??ted ????? name;
- the specific abusive URL, if any;
- a clear description of the alleged abuse;
- screenshots showing the content ?? the full URL;
- full email headers w???? email abuse, phishing, ?? fraud is involved;
- supp??ting evidence such as invoices, logs, malware analysis, blocklist results, ?? impersonation details;
- complainant contact inf??mation;
- proof of auth??ization w???? the complainant acts on behalf of a br?? ?? victim entity.
7. Evidence St??ards
7.1 ????????able Evidence
Evidence is actionable when the inf??mation reasonably available to NiceNIC is sufficient to determine that the spons??ed ????? name is being used f?? DNS Abuse ?? other enf??ceable abuse activity.
??????s include:
- a phishing page screenshot showing the full URL ?? impersonated br??;
- a phishing email with full headers ?? linked malicious URL;
- malware ?? exploit delivery from the rep??ted ????? ?? URL;
- reputation/blocklist data that supp??ts the rep??ted conduct;
- evidence of wallet-drainer code, seed-phrase theft, fake login harvesting, ?? credential capture;
- multiple consistent signals from trusted ?? recognized sources.
7.2 Insufficient Evidence
Evidence is insufficient w???? the complaint contains only:
- a ????? name with no abusive URL;
- keyw??ds only;
- allegations without screenshots, headers, logs, ?? other supp??t;
- general statements that a name "looks suspicious";
- pure br?? conflict allegations without abuse evidence.
7.3 Third-Party Intelligence
NiceNIC may consider third-party signals such as:
- reputable blocklists / RBLs;
- malware ?? phishing feeds;
- reputation ????s;
- pri?? internal case hist??y.
8. Case Pri??ity ?? Internal SLA
NiceNIC adopts the following internal operating targets. These are NiceNIC internal SLAs, not statements of ICANN-m??ated fixed deadlines.
Pri??ity 0 - Emergency / Active Harm
??????s:
- active phishing harvesting credentials ?? payment data;
- malware delivery;
- botnet / comm??-??-control use;
- CSAM;
- law-enf??cement emergency notice;
- wallet-drainer ?? seed-phrase theft infrastructure.
- first review immediately;
- decision as fast as reasonably possible;
- w???? actionable, mitigation n??mally within 24 hours, ?? no later than 48 hours absent exceptional facts.
Pri??ity 1 - High-Risk ????????able Abuse
??????s:
- clear impersonation fraud;
- repeat abuse linked to the same registrant/account;
- ?????s already flagged by reliable third-party sources with c??rob??ating evidence.
- review within 1 business day;
- mitigation ?? documented ???? step within 48 hours.
Pri??ity 2 - ????n-DNS Abuse with Sufficient Evidence
??????s:
- DMCA with proper notice;
- trademark complaints;
- illegal pharmacy ?? content complaints lacking qualifying DNS-abuse indicat??s.
- ack???ledge promptly;
- notify registrant/reseller w???? appropriate;
- request remediation ?? additional documentation.
Pri??ity 3 - Incomplete / Low-Quality Rep??ts
Target:
- ack???ledgment ?? request f?? additional evidence;
- no suspension solely on this basis.
9. W??kflow
9.1 Intake
Every rep??t receives:
- case ID;
- timestamp;
- source classification;
- ????? linkage;
- abuse categ??y;
- evidence status.
9.2 Triage
The case is classified by:
- DNS Abuse vs non-DNS abuse;
- evidence sufficient vs insufficient;
- auth??ity / trusted-rep??ter status;
- reseller vs retail account;
- current ????? status;
- repeat-offender / repeat-case hist??y.
9.3 Investigation
The reviewer checks:
- rep??ted URL ?? content;
- RDAP / WHOIS / creation timing / nameservers / MX;
- internal account hist??y;
- pri?? complaints;
- blocklists / third-party intelligence;
- whether the issue appears intentional ?? caused by compromise;
- whether the abuse is occurring at second-level ?????, sub?????, web content, ?? email layer.
9.4 Decision
Possible outcomes:
- no action / insufficient evidence;
- request m??e evidence from complainant;
- notify registrant ?? reseller f?? remediation;
- clientHold;
- transfer lock in conjunction with mitigation w???? appropriate;
- referral to registry, host, law enf??cement, payment provider, ?? other relevant party;
- maintain existing hold;
- deny reactivation.
9.5 ????tifications
F?? clear, actionable, ongoing DNS Abuse, NiceNIC may suspend first ?? notify after action.
F?? likely compromise scenarios ?? non-DNS matters, NiceNIC may notify first w???? that is consistent with risk control ?? does not materially increase harm.
This distinction is consistent with ICANN's position that mitigation may vary depending on the harm ?? the risk of collateral damage.
10. ??????-Specific Rules
10.1 Drugs / kra / slon / mega ??????
Keyw??d presence alone is not enough f?? DNS-Abuse classification.
Treat as:
- non-DNS illegal activity review if only keyw??ds ?? product content are present;
- DNS Abuse / urgent abuse if the evidence shows fake login, fake payment collection, credential theft, malicious redirection, malware, ?? other qualifying technical abuse.
10.2 Crypto Scam
Treat as:
- non-DNS fraud review w???? the site is only a dubious investment ?? false-profit promotion;
- DNS Abuse / urgent abuse w???? the evidence shows wallet connection theft, seed phrase collection, private key theft, drainer code, impersonated exchange login, ?? malicious scripts.
10.3 CSAM / Child Exploitation
Treat as immediate high-risk abuse. Escalate internally without delay. Preserve rec??ds, avoid unnecessary customer back-??-f??th, ?? escalate to the appropriate auth??ity ?? registry if required.
10.4 DMCA / ????????
Do not auto-suspend purely on large content lists ?? unsupp??ted bulk allegations.
F??ward proper notices w???? appropriate, require a compliant notice f??mat, ?? allow the ????? holder to address the claim unless a court ??der, registry rule, ?? other stronger basis requires m??e immediate action.
This is also broadly consistent with how maj?? registrars separate copyright/trademark processing from phishing/malware h??ling.
10.5 Trademark / Br?? Complaints
Trademark disputes are not automatically DNS Abuse.
W???? the issue is a ?????-name rights dispute, complainants should generally be directed toward UDRP, URS, ?? court process as appropriate, unless the evidence also shows phishing, impersonation, ?? other abuse. ???????? publicly distinguishes abuse h??ling from UDRP/URS h??ling in the same way.
11. Registrant / ?????? Communication Rules
11.1 Retail Customers
F?? clear DNS Abuse with sufficient evidence:
- ????? may be suspended immediately;
- the first customer-facing reply should state the basis, the self-???? path to view the case summary, ?? the evidence st??ard required f?? reconsideration.
11.2 ??????s
NiceNIC may choose to notify the reseller rather than any downstream sub-user.
However, reseller status does not delay urgent mitigation w???? actionable evidence exists.
11.3 Reconsideration / Reactivation
NiceNIC will not lift a hold based on unsupp??ted denials such as "content removed" ?? "it was already deleted" alone.
Reconsideration requires new, verifiable evidence such as:
- false-positive proof;
- evidence of compromise ?? remediation;
- clean current review results;
- third-party reputation recovery w???? applicable.
12. Complainant Communication Rules
NiceNIC should always send:
- ack???ledgment of receipt;
- case ID ?? equivalent reference;
- request f?? m??e evidence if needed;
- status update when action is taken ?? declined;
- no unnecessary substantive discussion w???? the ????? is already suspended ?? pending suspension ?? the key outcome is final.
13. Trusted Rep??ter Program
NiceNIC may maintain a trusted-rep??ter list f?? sources that consistently provide accurate, well-f??med, ?? actionable rep??ts.
Trusted-rep??ter status may provide:
- pri??ity intake;
- structured data submission;
- simplified evidence f??matting;
- API ?? fast-lane h??ling.
14. Rec??dkeeping ?? Audit Readiness
NiceNIC must document:
- complaint receipt;
- evidence received;
- internal classification;
- investigation steps;
- decision;
- action taken;
- notifications sent;
- follow-up ?? final disposition.
15. Compliance Controls
NiceNIC should perf??m:
- periodic QA review of case decisions;
- staff training on DNS Abuse definitions ?? evidence thresholds;
- testing of abuse mailbox ?? webf??m operability;
- review of template accuracy;
- monit??ing of repeat err??s ?? reopened cases;
- monthly review of ?????s with repeated complaints.
16. Metrics
NiceNIC should track at least:
- total complaints received;
- DNS Abuse vs non-DNS abuse split;
- sufficient vs insufficient evidence rate;
- time to first ack???ledgment;
- time to first human review;
- time to mitigation f?? actionable DNS Abuse;
- number of holds issued;
- number of reconsiderations granted ?? denied;
- repeat-abuse ?????s;
- repeat-abuse accounts;
- trusted-rep??ter accuracy rate;
- complaints already resolved bef??e manual review.
17. External-Facing Positioning
NiceNIC should describe its abuse system publicly in language like this:
- NiceNIC investigates abuse rep??ts promptly.
- NiceNIC distinguishes between ICANN-defined DNS Abuse ?? other types of complaints.
- NiceNIC acts based on evidence, risk, ?? applicable policy.
- NiceNIC may suspend immediately w???? t???? is clear actionable evidence of ongoing DNS Abuse.
- NiceNIC may request m??e inf??mation ?? direct the complainant to a m??e appropriate action point w???? the registrar is not the sole effective responder.
- NiceNIC keeps case rec??ds ?? can demonstrate its h??ling process if reviewed by ICANN ?? registry partners.
??? ?????? ?? ????? ???? ??? ????? ???.
???? ??? ????
- ????? ??????
- ??????? ?????
- ?????? ?????
- SSL Certificates
- ?????????? ????
- ????? ?????????
- NiceNIC ?? ???? ???
- ????? ??????
- ?????? ????
- ??????
- ?????? ??????
- ?????? ??????
- ???? ??? ????
- ???? ?????? ????
- ???????? ?? ??????? ????
???????? ? 2006-2026 NICENIC INTERNATIONAL GROUP CO., LIMITED ?????????? ????????