Internet Corporation for Assigned Names and Numbers

Domain Name Dispute Resolution Policies

The following policies apply to various types of disputes between registrants and third parties over the registration and use of domain names. Disputes under these policies may be filed with one of the approved dispute-resolution service providers for the given policy.

The Uniform Domain-Name Dispute Resolution Policy (below) is applicable across all gTLDs. Additional dispute resolution policies may apply to specific circumstances only in individual TLDs. These are also listed below.

Note: For customer-service complaints about a registrar of domain names, please see the Registrar Problem Reports Page.

Uniform Domain-Name Dispute Resolution Policy

The Uniform Domain-Name Dispute Resolution Policy (UDRP) has been adopted by ICANN-accredited registrars in all gTLDs (.aero, .asia, .biz, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net, .org, .pro, .tel and .travel). Dispute proceedings arising from alleged abusive registrations of domain names (for example, cybersquatting) may be initiated by a holder of trademark rights. The UDRP is a policy between a registrar and its customer and is included in registration agreements for all ICANN-accredited registrars.

Charter Eligibility Dispute Resolution Policy

The Charter Eligibility Dispute Resolution Policy (CEDRP) is followed by the sponsored TLDs .aero, .coop, .museum, and .travel for challenges to registration of a domain name on the grounds that the registrant does not meet the eligibility requirements (set forth in the sponsored TLD charter) for registration of a domain name in the given TLD. Any person or entity may bring a challenge to a registered name under the CEDRP.

Eligibility Reconsideration Policy

The Eligibility Reconsideration Policy (ERP) is incorporated in agreements with registrants concerning domain name registrations in .aero. It sets out the terms and conditions in connection with any challenge to a decision by the sponsor concerning eligibility to register in .aero. This policy was developed by the sponsor of .aero. It is not an ICANN policy and is provided here for reference only. More information can be found on the sponsor's website.

Eligibility Requirements Dispute Resolution Policy

The Eligibility Requirements Dispute Resolution Policy (ERDRP) is followed by the unsponsored restricted TLD .name. Registrations in .name must consist of an individual's own personal name or the personal name of a fictional character (provided the registrant holds trademark or service mark rights in that character's personal name). Numeric characters may also be used in combination with either type of personal name above. Challenges to a registration in .name on the grounds that it does not meet the eligibility requirements are filed under the ERDRP. Defensive registrations and second level domain e-mail address registrations are also subject to challenge under the ERDRP. Any person or entity may bring a challenge to a registration under the ERDRP.

.ASIA Charter Eligibility Requirements Policy

The .ASIA Charter Eligibility Requirements Policy (.ASIA CERP) applies to domain names registered in the .ASIA sponsored TLD. Registrations in .ASIA are restricted to members of the Pan-Asia and Asia-Pacific Internet community. Challenges to a registration in .ASIA on the grounds that it does not meet the eligibility requirements are filed under the CERP. Further information can be found on the .ASIA website.

.cat Eligibility Requirements Dispute Resolution Policy (Política de Resolució de Conflictes sobre Requisits d'Admissibilitat del .cat)

The .cat Eligibility Requirements Dispute Resolution Policy (.cat ERDRP) applies to domain names registered in the sponsored TLD .cat. Registrations in .cat are restricted to members of the Catalan linguistic and cultural community. Challenges to a registration in .cat on the grounds that it does not meet the eligibility requirements are filed under the ERDRP. Further information can be found on the .cat website.

Intellectual Property Defensive Registration Challenge Policy

The Intellectual Property Defensive Registration Challenge Policy (IPDRCP) applies to intellectual property defensive registrations in the .pro TLD, which is restricted to use by certified practicing members of certain professions (currently the medical, legal, and accounting professions). An intellectual property defensive registration may be registered only by the owner of an eligible trademark or service mark registration. The IPDRCP provides an avenue for challenges to Intellectual Property Defensive Registrations concerning whether such registrant meets the Registration Qualifications. Any person or entity may initiate an IPDRCP proceeding by submitting a challenge in accordance with the rules.

Qualification Challenge Policy

The Qualification Challenge Policy (QCP) is followed by the unsponsored restricted TLD .pro, which is limited to use by licensed members of certain professions. Challenges to a registration on the grounds that the registrant did not meet the registration qualifications are filed under the QCP. A challenge to a registration under the Qualification Challenge Policy may be brought by any interested party.

Restrictions Dispute Resolution Policy

The Restrictions Dispute Resolution Policy (RDRP) applies in the unsponsored restricted TLD .biz. Registrations in the .biz TLD must be used or intended to be used primarily for bona fide business or commercial purposes. Challenges to a registration or use of a given domain name on the grounds that it is not being or will not be used primarily for a bona fide business or commercial purpose are filed under the RDRP. Challenges under the RDRP may be initiated by any party filing a complaint with an approved dispute resolution service provider.

Start-Up Trademark Opposition Policy

The Start-Up Trademark Opposition Policy (STOP) was available only to intellectual property owners who enrolled in the IP Claim Service during the Start-up phase of the .biz registry (June 25-September 21, 2001). STOP is no longer available as a dispute resolution policy for .biz domain names. Disputes can be brought under the UDRP, RDRP or available courts of law. For more information, see the registry operator's site.

Sunrise Challenge Policy

The Sunrise Challenge Policy (SCP) was applied only during the sunrise period for the .info TLD. Challenges under the Sunrise Challenge Policy were administered by the registry operator (Afilias). As the one hundred twenty (120) day sunrise period has closed, parties disputing the validity of a sunrise registration may utilize the UDRP or available courts of law. For more information, see the registry operator's site.

Transfer Dispute Resolution Policy

The Transfer Dispute Resolution Policy (TDRP) applies to transactions in which a domain-name holder transfers or attempts to transfer a domain name to a new registrar. The TDRP concerns registrar disputes under the Inter-Registrar Transfer Policy, which is followed by the .biz, .com, .info, .name, .net, .org, and .pro TLDs. Proceedings under the TDRP may be filed with the appropriate registry operator or with an independent dispute resolution provider. Any ICANN-accredited registrar may initiate a TDRP proceeding against another registrar by submitting a complaint in accordance with the selected registry operator or dispute resolution providers' supplemental rules.

Proceedings

ICANN does not maintain a current centralized index of domain name dispute resolution proceedings. Search tools for UDRP proceedings can be found at the individual dispute resolution proceedings sites of ICANN's approved dispute-resolution service providers, which can be found at the following link:

List of Approved Dispute Resolution Service Providers

Limited indexes of past UDRP proceedings are archived in the following link:

Archived Indexes and Statistics for UDRP Proceedings

Approval Process for Dispute Resolution Service Providers

ICANN is not currently soliciting additional dispute resolution service providers; however, interested parties may contact ICANN on an individual basis to express their interest. The procedures used for approving providers in the past are provided for reference below.

Organizations seeking provisional approval as service providers under any of ICANN's dispute resolution policies should take the following steps:

  1. Become familiar with the relevant policy and associated rules.
  2. Submit an application by email to (icann@icann.org) and by postal mail:

    Dispute Resolution Service Provider Applications
    Internet Corporation for Assigned Names and Numbers
    4676 Admiralty Way, Suite 330
    Marina del Rey, CA 90292-6601 USA

Applications should contain:

  1. An overview of the applicant's capabilities and background in providing alternative dispute-resolution (ADR) services, including a description of the applicant's track record of handling the clerical aspects of expedited ADR proceedings.
  2. A list of the names and qualifications of the panelists the applicant proposes to include on its published list and a description of the screening requirements applicant has used in selecting panelists to be included on its list.
  3. A description of training and educational measures the applicant proposes to employ for listed panelists with respect to domain-name disputes, the relevant policy, and the associated Rules.
  4. A commitment by the applicant not to prevent or discourage any of its listed panelists from serving as panelists for domain-name disputes administered by other approved providers.
  5. A copy of the applicant's proposed supplemental rules (including fee schedule).
  6. Documentation of applicant's proposed internal operating procedures. If requested, ICANN will hold this documentation in confidence.
  7. A proposed schedule for applicant's implementation of its program for administering proceedings under the policy, including a statement of applicant's administrative capacity in terms of number of proceedings initiated on a monthly basis.
  8. A statement of any requested limitations on the number of proceedings that applicant handles, either during a start-up period or on a permanent basis.
  9. A description of how the applicant proposes to administer proceedings, including its interactions with parties, registrars, ICANN, and other approved providers.
  10. Description of how the applicant intends to publish decisions of panels in proceedings it administers and a commitment to provide ICANN with copies of all portions of decisions of panels not published.

In general, ICANN examines the applications to determine whether the applicant has demonstrated its ability to handle proceedings in an expedited, global, online context in an orderly and fair manner. Attributes that are especially important include:

  1. Applicant should have a track record in competently handling the clerical aspects of ADR proceedings. ICANN considers proper review of pleadings for administrative compliance and reliable and well-documented distribution of documents to the parties and panels to be essential capabilities for providers. In the absence of a well-established track record in handling the clerical function, a detailed plan for providing those abilities ordinarily must be submitted.
  2. Applicant should propose a list of highly qualified neutrals who have agreed to serve as panelists. Applicant's list should include at least twenty persons. Applicants are expected thoroughly to train the listed neutrals concerning the policy and rules, the technology of domain names, and the basic legal principles applicable to domain-name disputes. Accordingly, excessively long lists of neutrals are discouraged. The applicant should either present a list of panelists from multiple countries or, if the applicant initially presents a single-country list, propose a plan to expand its list to become multinational.
  3. Applicant's supplemental rules and internal procedures should demonstrate that applicant understands the workings of the policy and associated rules.

Stay Connected

  • News Alerts:
  • Newsletter:
  • Compliance Newsletter:
  • Policy Update: