Skip to main content
Resources

About gTLD Compliance Program

The following overview of the gTLD Compliance Program [PDF, 880 KB] serves as a guide only. Contracted parties must continue to review and comply with all requirements in their agreements with ICANN and the applicable ICANN policies.

The gTLD Compliance Program was developed by dividing the contractual provisions of the gTLD registry agreement into general Compliance Areas. Those areas are implemented through a combination of internal monitoring efforts, processing of complaints and monitoring of external resources, such as industry news. A new service or a change in protocol or policy may trigger additional compliance monitoring in that area.

The gTLD registry agreements share a common basic structure, although the specific requirements may vary. Listed below are some of the gTLD Compliance Areas and the relevant provisions in the new gTLD registry agreement. Registries not on the form of the new gTLD registry agreement may have different requirements. For details, please visit the registry agreement specific to each gTLD.

ICANN does not have contractual authority to take compliance action against ccTLD operators.

Compliance Areas

  1. Functional & Performance Specifications

    Functional specifications are how a registry's technical systems work, such as DNS, EPP and RDDS. Performance specifications set standards for availability, outages, processing times, and update frequencies. To determine compliance in these areas, ICANN implements internal technical monitoring, where available. Additionally, monthly registry reports provided by registry operators are used to compare Service Level Agreement requirements with actual performance measures obtained from internal technical monitoring for the reporting month.

    Relevant provisions include Specifications 6 and 10 of the new gTLD registry agreement. Complaints regarding a registry operator's Service Level Agreement requirements can be submitted using the Registry Complaint Form at https://www.icann.org/resources/pages/performance-2013-06-28-en .

  2. Registration Data Directory Service (Whois) & Bulk Whois Access

    Registries that have executed the form of the new gTLD registry agreement are required to provide a public Whois service via port 43 and a web-based Directory Service containing required data elements in a specified format. They must also provide access to the bulk registration (Whois) data to ICANN on a weekly basis. ICANN reviews whether a registry is providing appropriate access to the Whois data, presenting the Whois data in a manner consistent with requirements, meeting update frequency requirements and following bulk access provisions.

    Relevant provisions include Specifications 4 and 10 of the new gTLD registry agreement and ICANN's Advisory: Clarifications to the Registry Agreement and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications.

  3. Data Escrow

    All registries are to select an ICANN-approved Data Escrow Agent (DEA) for the provision of data escrow services. Compliance reviews whether valid deposits have been made by the DEA and if the registry has submitted escrow notifications to ICANN.

    Relevant provisions include Specification 2 of the new gTLD registry agreement.

  4. Use of Registrar Data

    Registries that have executed the form of the new gTLD registry agreement must take reasonable steps to protect the registration data collected from registrars. Registries must inform registrars of the ways they use the information and may not use it for any undisclosed reason. Compliance reviews registry communications to registrars concerning their practices for handling personal data and processes complaints submitted through ICANN's complaint forms.

    Relevant provisions include Sections 2.14 and 2.18 and Specification 9 of the new gTLD registry agreement.

  5. Equivalent Access to Registry Services & Code of Conduct

    This area includes the obligation of registries that have executed the form of the new gTLD registry agreement to provide equivalent and non-discriminatory access to all registrars and use a uniform, non-discriminatory agreement with all registrars. Additionally, if a registry also operates as a provider of registrar or registrar-reseller services, it is required to conduct internal reviews under the Code of Conduct and provide the results of such review with an executed compliance certificate to ICANN (absent an exemption). ICANN monitors these provisions through complaint processing and external resources and reviews required annual certifications.

    Relevant provisions include Section 2.9a and Specifications 9 and 13 (where applicable) of the new gTLD registry agreement. Complaints regarding the Code of Conduct requirements can be submitted using the Code of Conduct Complaint Form at https://www.icann.org/resources/pages/code-of-conduct-2014-01-29-en .

  6. Registration Restrictions

    Certain gTLDs are restricted by registration policies or, if a sponsored gTLD, by restrictions in its Charter (Appendix S). For example, community gTLDs must follow registration restrictions related to the relevant community. Restricted registries have dispute policies in place to provide standards for resolving disputes over inappropriate registrations.

    Through the Registry Restriction Dispute Resolution Procedure (RRDRP), ICANN allows for the submission of an initial report claiming that a registry that has executed the form of the new gTLD registry agreement is not complying with its mandatory registration restrictions, as stated in Specification 12 of its registry agreement. ICANN also ensures that the registry has the proper dispute resolution mechanisms available to registrants.

    Relevant provisions include Section 2.19 and Specification 12 of the new gTLD registry agreement. Complaints regarding a registry operator's Specification 12 registration restrictions can be submitted using the Registration Restriction Dispute Resolution Procedure Complaint Form at https://www.icann.org/resources/pages/rrdrp-2013-10-31-en .

  7. Sunrise and Claims Services

    Registries that have executed the form of the new gTLD registry agreement, and their contracted registrars, are required to work with the Trademark Clearinghouse (TMCH) to provide Sunrise and Claims services. These services are rights protection mechanisms for trademark holders that have recorded their marks with the TMCH. Sunrise Services allow trademark holders an opportunity to register domain names corresponding to their marks before names are generally available to the public. During the Claims Services period, registrars must provide a trademark claims notice to anyone attempting to register a domain name matching a mark that is recorded in the TMCH. If the notified party registers the domain name, the TMCH will notify the trademark holder of the registration.

    ICANN accepts complaints regarding violations of Claims Services, as well as violations of Sunrise Services after remedies through the registry's published Sunrise Dispute Resolution Policy (SDRP) have been exhausted.

    Relevant provisions include Specification 7 of the new gTLD registry agreement and the Trademark Clearinghouse Rights Protection Mechanism Requirements. Complaints after a SDRP has been exhausted can be submitted using the Sunrise Processes & Procedures Report Form at https://www.icann.org/resources/pages/sdrp-2013-10-31-en and complaints regarding a registry operator's Claims Services requirements can be submitted using the Claims Services Form at https://www.icann.org/resources/pages/claims-2014-01-29-en .

  8. Reserved Names

    All registries must reserve the names specified by the registry agreement. To determine compliance, ICANN performs internal technical monitoring and addresses external complaints. Registries that have executed the form of the new gTLD registry agreement may activate up to 100 names (including their IDN variants, where applicable) that are necessary for the operation or the promotion of the gTLD. There are no numeric restrictions on the number of names that a registry can reserve in the gTLD, so long as all other requirements of the registry agreement are met.

    Relevant provisions include Appendix 6 and Specification 5 of the new gTLD registry agreement. Complaints regarding a registry operator's reserved names or blocked SLDs can be submitted using the Reserved and Blocked SLDs Complaint Form at https://www.icann.org/resources/pages/reserved-2013-06-28-en .

  9. Name Collision

    Contingent upon each gTLD's delegation date (before, on or after 18 August 2014 00:00 UTC), registries that have executed the form of the new gTLD registry agreement must (1) either block the List of Second Level Domains (SLDs) to Block or implement Controlled Interruption (CI) or Wildcarded SLDs CI for at least 90 days before activating such names or (2) implement Wildcarded CI for at least 90 days before activating any name under the TLD. ICANN monitors and times the implementation of CI primarily using the zone files that are transferred to ICANN after delegation. Other registry obligations remain while CI is implemented (e.g., DNSSEC, providing RDDS services at whois.nic.tld).

    Relevant provisions include Specification 6 of the new gTLD registry agreement, Name Collision Occurrence Management Framework and related documents.

  10. Third Party Access to Zone Files

    All registries are required to provide third parties access to its zone file. The registry's Zone File Agreement must take the form specified in the registry or sponsorship agreement and where applicable, includes use of the agreement in the Centralized Zone Data Service (CZDS). ICANN will check whether a registry has altered the agreement or imposed extra conditions by reviewing the registry zone file agreements and processing complaints from third parties using the CZDS for zone file access.

    Relevant provisions include the terms and conditions of the CZDS and Specification 4 of the new gTLD registry agreement. Complaints regarding a registry operator's provision of zone file access to third parties can be submitted using the Zone File Access Complaint Form at https://www.icann.org/resources/pages/zfa-2013-06-28-en .

  11. Abuse Contact Data

    Registries that have executed the form of the new gTLD registry agreement are required to provide ICANN and publish on its website a valid email address, a valid mailing address and a primary contact for handling inquiries related to abuse or malicious conduct in the gTLD. ICANN will review the registry's website to determine if the required contacts are published.

    Relevant provisions include Specification 6 of the new gTLD registry agreement. Complaints regarding a registry operator's abuse contact data can be submitted using the Abuse Contact Data Complaint Form at https://www.icann.org/resources/pages/abuse-contact-2014-01-29-en .

  12. Public Interest Commitments

    Registries that have executed the form of the new gTLD registry agreement are required to perform certain mandatory and voluntary (if any) public interest commitments. Mandatory provisions include having certain provisions in the Registry-Registrar Agreement (RRA) and conducting periodic technical analysis. These obligations are enforceable through the Public Interest Commitment Dispute Resolution Process (PICDRP). ICANN monitors compliance with these requirements through complaint processing and external resources.

    Relevant provisions include Specification 11 of the new gTLD registry agreement and the PICDRP. A PICDRP complaint can be submitted using the PICDRP Form at https://www.icann.org/resources/pages/picdrp-2013-10-31-en .

  13. Uniform Rapid Suspension System (URS)

    Through the URS Procedure, ICANN offers a low-cost, expedited path to relief for rights holders experiencing clear-cut cases of infringement caused by domain name registrations. ICANN's role is to ensure that registries that have executed the form of the new gTLD registry agreement adhere to the requirements of the URS procedure during and after the processing of a URS complaint by a URS Provider.

    Relevant provisions include the URS High Level Technical Requirements for Registries and Registrars, the URS Procedure and Rules and Specification 7 of the new gTLD registry agreement. A URS complaint regarding a registry operator's failure to implement a URS decision can be submitted using the URS Form at https://www.icann.org/resources/pages/urs-2013-10-31-en .

  14. Wildcard Prohibition

    Registries that have executed the form of the new gTLD registry agreement are prohibited from using DNS wildcard Resource Records, any method for synthesizing DNS Resources Records or using redirection at all levels within the DNS for domain names that are either not registered or valid NS records have not been supplied. When querying such domain names, the authoritative name servers must return a "Name Error" response (also known as NXDOMAIN), RCODE 3 as described in RFC 1035 and related RFCs. To determine compliance, ICANN performs internal technical monitoring. A temporary waiver of this prohibition is granted in the terms of the Name Collision Occurrence Assessment.

    Relevant provisions include Specification 6 of the new gTLD registry agreement. Complaints regarding a registry operator's wildcard prohibition can be submitted using the Wildcard Prohibition (Domain Redirect) Complaint Form at https://www.icann.org/resources/pages/wildcard-prohibition-2014-01-29-en .

  15. Payments to ICANN

    All registries are required to pay fees to ICANN. Data on registry payment records is available from ICANN Accounting. Warnings and notices on late payment that are currently in use are integrated into the compliance program in coordination with accounting staff.

    Relevant provisions include Article 6 of the new gTLD registry agreement.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."