Skip to main content
Resources

Thick WHOIS Transition Policy for .COM, .NET and .JOBS

Please note that the English language version of all translated content and documents are the official versions and that translations in other languages are for informational purposes only.

News

As of 21 August 2025, the requirements under this Policy will be as set out in the Registration Data Policy.

On 7 November 2019, the ICANN Board passed a Resolution to defer contractual compliance enforcement. ICANN Contractual Compliance will defer enforcement of the Thick WHOIS Transition Policy until all of the following have occurred:

  • the gTLD Registration Data Policy Implementation Review Team (IRT) completes its review and establishes an implementation timeline estimate of the Expedited Policy Development Process (EPDP) Team's recommendations as adopted by the ICANN Board on 15 May 2019;
  • ICANN org and the IRT provide the GNSO Council with the required information on the impacts of the EPDP Team's recommendations on existing policies and procedures (including the Thick WHOIS Transition policy), and
  • the GNSO Council makes a determination on whether to take action on updates to relevant policies and procedures (which could include additional policy work, guidance, or other actions to be determined) impacting the Thick WHOIS Transition Policy.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119, which is available at http://www.ietf.org/rfc/rfc2119.txt.

  1. Scope:

    This Policy SHALL apply to the Registry Operators for the .COM, .NET and .JOBS gTLDs, as well as all Registrars sponsoring domain name registrations in the .COM, .NET or .JOBS gTLDs.

  2. Definitions:

    • Thin (Registration): domain name for which the Registry Operator maintains and provides only technical information (e.g., name servers, statuses, creation date) and the Sponsoring Registrar associated with the domain name. Contact information for the domain name is maintained by the sponsoring Registrar.
    • Thick (Registration): domain name for which the sponsoring Registrar provides a copy of the associated contact information to the Registry Operator. Registry Operator maintains the technical information (e.g., name servers, statuses, creation date) and the sponsoring Registrar associated with the domain name. Contact information for the domain name is maintained by the sponsoring Registrar.
    • Existing Domain Name: domain name created, or in pendingCreate status, before 1 May 2018.
    • Transition Progress Metrics: metrics created by Registry Operator and communicated regularly to Registrars and ICANN to allow measurement of progress of the transition from Thin to Thick, including at least the total number of domains managed by Registrar, number and percentage of domains with contact objects attached.
  3. Policy and Effective Dates:

    3.1 All new domain name registrations MUST be submitted as Thick starting on 1 May 2018 at the latest.

    3.2 All relevant registration data for Existing Domain Names MUST have been migrated from Thin to Thick by 1 February 2019.

  4. The following requirements apply to Registry Operators only:

    4.1 Registry Operator MUST deploy an EPP mechanism and an alternative bulk transfer mechanism by 1 August 2017 for registrars to migrate registration data for Existing Domain Names (i.e., transition from Thin to Thick).

    4.2 By 1 May 2017, Registry Operator MUST provide to applicable Registrars and ICANN, documentation reflecting the system changes necessary to support the requirements of Section 4.1.

    4.3 By 1 May 2017, Registry Operator MUST deploy an EPP mechanism and an alternative bulk transfer mechanism in relevant Operating Test Environments (OT&E) for Registrars to test the migration of registration data for Existing Domain Names (i.e., transition from Thin to Thick).

    4.4 By 1 August 2017, Registry Operator MUST support all contact commands specified in RFC5733 as described in this provision. The EPP contact fields <contact:id>, <contact:postalInfo type>, and <contact:authInfo> will be REQUIRED by the Registry Operator. Registry Operator MUST accept but MUST NOT require all other registration data elements until 1 February 2019 that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the "Base Registry Agreement approved on 9 January 2014" ("Base Registry Agreement") or subsequent amendments thereto and the Registry Registration Data Directory Services Consistent Labeling and Display Policy.

    4.5 Starting 1 May 2018, Registry Operator MUST require Thick Registration data for an EPP domain object <create> command as described in this provision. Registry Operator MUST require all registration data elements that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the "Base Registry Agreement approved on 9 January 2014" ("Base Registry Agreement") or subsequent amendments thereto and the Registry Registration Data Directory Services Consistent Labeling and Display Policy.

    4.6 Between 1 August 2017 and 1 February 2019, Registry Operator SHALL provide Transition Progress Metrics to each registrar at minimum, Monthly by 23:59 UTC of the first day of the next month.

    4.7 Between 1 August 2017 and 1 February 2019, Registry Operator SHALL provide to ICANN all Transition Progress Metrics for all registrars at minimum, Monthly by 23:59 UTC of the first day of the next month.

    4.8 Registry Operator MAY implement the requirements of the Registry Registration Data Directory Services Consistent Labeling and Display Policy ("CL&D Policy") in conjunction with Section 1 of Specification 4 of the "Base Registry Agreement approved on 9 January 2014" ("Base Registry Agreement") or subsequent amendments thereto by 1 August 2017.

    4.9 Registry Operator MUST comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the "Base Registry Agreement approved on 9 January 2014" ("Base Registry Agreement") or subsequent amendments thereto and the Registry Registration Data Directory Services Consistent Labeling and Display Policy by 1 May 2018 for new registrations and by 1 February 2019 for Existing Domain Names.

    4.10 Between 1 August 2017 and 1 February 2019, for Existing Domain Names, for the following RDDS Output fields where no data exists in the Shared Registration System (SRS), the Registry Operator MAY treat the following RDDS fields as Optional as described in clarification 1 of the "Advisory: Clarifications to the Registry Agreement, and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications":

    1. Registry Registrant/Admin/Tech ID
    2. Registrant/Admin/Tech Name
    3. Registrant/Admin/Tech Street
    4. Registrant/Admin/Tech City
    5. Registrant/Admin/Tech Country
    6. Registrant/Admin/Tech Phone
    7. Registrant/Admin/Tech Email

    4.11 The "Billing" contact, unless otherwise required by Registry Agreement, is optional. Registry Policy may define if it is required, optional or not supported. If supported the Billing contact information must be displayed as described in the "Advisory: Clarifications to the Registry Agreement, and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications" (section 22).

  5. The following requirements apply to Registrars only:

    5.1 Between 1 August 2017 and 1 February 2019, Registrars MUST migrate to the relevant Registry Operator all required fields of Existing Domain Names that are available in the Registrar database that enable the Registry Operator to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the "Base Registry Agreement approved on 9 January 2014" ("Base Registry Agreement") or subsequent amendments thereto and the Registry Registration Data Directory Services Consistent Labeling and Display Policy.

    5.2 Registrars MAY provide complete Thick Registration data to Registry Operator that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the "Base Registry Agreement approved on 9 January 2014" ("Base Registry Agreement") or subsequent amendments thereto and the Registry Registration Data Directory Services Consistent Labeling and Display Policy, upon creation of new domain name registrations starting 1 August 2017.

    5.3 Registrars MUST provide complete Thick Registration data to Registry Operator that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the "Base Registry Agreement approved on 9 January 2014" ("Base Registry Agreement") or subsequent amendments thereto and the Registry Registration Data Directory Services Consistent Labeling and Display Policy, upon creation of new domain name registrations starting 1 May 2018.

Implementation Note

Where a conflict exists between local privacy laws and requirements included in this Policy, ICANN Procedure for Handling WHOIS Conflicts with Privacy Law is available for Registry Operators and Registrars

Background

The ICANN Board of Directors adopted consensus policy recommendations of the GNSO Thick WHOIS Working Group regarding the use of Thick WHOIS by all gTLD registries on 7 February 2014, after the recommendations were approved by the GNSO Council. Recommendation #1 states that "The provision of Thick WHOIS services, with a consistent labeling and display as per the model outlined in specification 3 of the 2013 [Registrar Accreditation Agreement], should become a requirement for all gTLD registries, both existing and future." See ICANN Board resolutions 2014.02.07.08 - 2014.02.07.09 at http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm#2.c).

ICANN worked with a team of community members (i.e. Implementation Review Team) to implement the policy recommendations. As part of implementation, and prior to their adoption, ICANN sought community input on the proposed policy recommendations and the language included in this Policy. (See https://www.icann.org/public-comments/proposed-implementation-gnso-thick-rdds-whois-transition-2016-10-26-en).

The Final Report [PDF, 1.23 MB] of the Thick Whois Policy PDP WG further included in its Section 7.2 'Implementation Considerations' guidance related to the timeline and requirements for implementing the transition from thin to thick Whois. It specifically notes that "The WG does emphasize that implementation of one part of the recommendation (for example, transition of existing thin gTLD registries to thick model) should not unnecessarily delay the implementation of another part of the recommendation (for example, the consistent labeling and display of such data)".

As a consequence, ICANN organization worked with the Implementation Review Team on parallel implementation paths for transitioning thin Whois registrations to thick and consistent labeling and display of Whois data. For additional details, see https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en

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."