Skip to main content
Resources

Registry Registration Data Directory Services Consistent Labeling and Display 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.

Registry Operators, with the exception of .com, .jobs and .net1, SHALL implement these requirements 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 in order to comply with WHOIS (available via port 43) and web-based directory services requirements. The Registry Operators of.com, .jobs and .net MAY implement sections of this policy in conjunction with Section 1 of Specification 4 of the Base Registry Agreement that are relevant to a thin Registry.

  1. In responses to domain name object queries the below fields MUST be included either (1) immediately after the "Registrar IANA ID" field or (2) immediately before the last field ("URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/") in the following order:
    • Registrar Abuse Contact Email
    • Registrar Abuse Contact Phone
  2. In responses to domain name object queries the following fields are considered optional and should be treated 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" ("WHOIS Advisory"):
    • Registrar Registration Expiration Date
    • Reseller
  3. If shown, the "Reseller" field MUST appear immediately before the "Domain Status" field.
  4. If shown, the value of the "Reseller" field MUST be the name of the organization, in the case where the Reseller is a legal entity, or the name of a natural person.
  5. If shown, the "Registrar Registration Expiration Date" field MUST appear immediately after the "Registry Expiry Date" field.
  6. The value section (i.e., right-hand side of the colon) of the following fields MUST follow the below format specifications:
    1. "Registrar Abuse Contact Email" (as defined in the EPP RFCs for email fields)
    2. "Registrar Abuse Contact Phone" (as defined in the EPP RFCs for phone fields)
    3. "Reseller" is defined as token (see Extensible Markup Language 1.1)
    4. "Registrar Registration Expiration Date" (as defined in the EPP RFCs for date fields)
  7. Registry Operator MUST update the name of keys in the output of the domain name, name server, and registrar objects as follows. The following table shows keys that are renamed from their original version in Specification 4 of the Base Registry Agreement. All other specifications (e.g. format specifications of the value section) remain unchanged.
    Original key in Specification 4 of the Base Registry Agreement New key name Object query where the key appears
    Domain ID Registry Domain ID domain name
    WHOIS Server Registrar WHOIS Server domain name, registrar, nameserver
    Referral URL Registrar URL domain name, registrar, nameserver
    Sponsoring Registrar Registrar domain name
    Sponsoring Registrar IANA ID Registrar IANA ID domain name
    Registrar Name Registrar registrar
    Registrant ID Registry Registrant ID domain name
    Admin ID Registry Admin ID domain name
    Tech ID Registry Tech ID domain name
  8. If the "Billing Contact" is shown, Registry Operator MUST update the name of the key in the output of the domain name as defined below. All other specifications (e.g. format specifications of the value section) continue to apply.
    Original key in the WHOIS Advisory New key name Object query where the key appears
    Billing ID Registry Billing ID domain name
  9. In responses to domain name object queries the following field2 MUST be included before the footer ">>> Last update of Whois database: <date and time> <<<".
  10. A Registry Operator that is permitted to provide redacted RDDS output in its registry agreement MAY treat the following fields as optional regardless of the existence of data in the Registry's Shared Registration System (SRS) as described in clarification 1 of the WHOIS Advisory. The redacted RDDS output MUST be consistent with the relevant RDDS provisions in the Registry Operator's registry agreement
    • Registry Registrant/Admin/Tech ID
    • Registrant/Admin/Tech Name
    • Registrant/Admin/Tech Organization
    • Registrant/Admin/Tech Street
    • Registrant/Admin/Tech City
    • Registrant/Admin/Tech State/Province
    • Registrant/Admin/Tech Postal Code
    • Registrant/Admin/Tech Country
    • Registrant/Admin/Tech Phone
    • Registrant/Admin/Tech Phone Ext
    • Registrant/Admin/Tech Fax
    • Registrant/Admin/Tech Fax Ext
    • Registrant/Admin/Tech Email
  11. The fields "Registry Admin/Tech/Billing/Registrant ID:" refer to the Repository Object Identifier (ROID) for the contact object as specified in RFC 5733 (called Admin/Tech/Registrant ID in Specification 4 of the Base Registry Agreement).
  12. Registry Operator MAY output additional RDDS fields, as defined in the WHOIS Advisory, without further approval by ICANN. The key and the value of each additional field MUST NOT: include browser executable code (e.g., Javascript); provide confidential information of any sort; or cause a negative impact to the security, stability, or resiliency of the Internet’s DNS or other systems. Prior to deployment, Registry Operator SHALL provide the list of all additional RDDS fields to ICANN. Registry Operator SHALL provide to ICANN any changes to the list of additional RDDS fields prior to deploying such changes.

Effective Date: 1 August 2017

Implementation Notes

  1. On 27 April 2015, ICANN published an Advisory in response to questions from both registries and registrars regarding the applicable Registration Data Directory Services (commonly known as WHOIS) specifications. Registry Operators should continue to consult this Advisory to be in compliance with their registry agreement.
  2. The following section describes example outputs for the query objects:

Domain Name Data:

  • Query format: whois EXAMPLE.TLD
  • Response format:
    Domain Name: EXAMPLE.TLD
    Registry Domain ID: D1234567-TLD
    Registrar WHOIS Server: whois.example-registrar.tld
    Registrar URL: http://www.example-registrar.tld
    Updated Date: 2009-05-29T20:13:00Z
    Creation Date: 2000-10-08T00:45:00Z
    Registry Expiry Date: 2010-10-08T00:44:59Z
    Registrar Registration Expiration Date: 2010-10-08T00:44:59Z
    Registrar: EXAMPLE REGISTRAR LLC
    Registrar IANA ID: 5555555
    Registrar Abuse Contact Email: email@registrar.tld
    Registrar Abuse Contact Phone: +1.1235551234
    Reseller: EXAMPLE RESELLER1
    Domain Status: clientDeleteProhibited
    Domain Status: clientRenewProhibited
    Domain Status: clientTransferProhibited
    Registry Registrant ID: 5372808-ERL
    Registrant Name: EXAMPLE REGISTRANT
    Registrant Organization: EXAMPLE ORGANIZATION
    Registrant Street: 123 EXAMPLE STREET
    Registrant City: ANYTOWN
    Registrant State/Province: AP
    Registrant Postal Code: A1A1A16
    Registrant Country: AA
    Registrant Phone: +1.5555551212
    Registrant Phone Ext: 12347
    Registrant Fax: +1.5555551213
    Registrant Fax Ext: 4321
    Registrant Email: EMAIL@EXAMPLE.TLD
    Registry Admin ID: 5372809-ERL
    Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
    Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
    Admin Street: 123 EXAMPLE STREET
    Admin City: ANYTOWN
    Admin State/Province: AP
    Admin Postal Code: A1A1A1
    Admin Country: AA
    Admin Phone: +1.5555551212
    Admin Phone Ext: 1234
    Admin Fax: +1.5555551213
    Admin Fax Ext: 1234
    Admin Email: EMAIL@EXAMPLE.TLD
    Registry Tech ID: 5372811-ERL
    Tech Name: EXAMPLE REGISTRANT TECHNICAL
    Tech Organization: EXAMPLE REGISTRANT LLC
    Tech Street: 123 EXAMPLE STREET
    Tech City: ANYTOWN
    Tech State/Province: AP
    Tech Postal Code: A1A1A1
    Tech Country: AA
    Tech Phone: +1.1235551234
    Tech Phone Ext: 1234
    Tech Fax: +1.5555551213
    Tech Fax Ext: 93
    Tech Email: EMAIL@EXAMPLE.TLD
    Name Server: NS01.EXAMPLE-REGISTRAR.TLD
    Name Server: NS02.EXAMPLE-REGISTRAR.TLD
    DNSSEC: signedDelegation
    URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
    >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

Registrar Data:

  • Query format: whois "registrar Example Registrar, Inc."
  • Response format:
    Registrar: Example Registrar, Inc.
    Street: 1234 Admiralty Way
    City: Marina del Rey
    State/Province: CA
    Postal Code: 90292
    Country: US
    Phone Number: +1.3105551212
    Fax Number: +1.3105551213
    Email: registrar@example.tld
    Registrar WHOIS Server: whois.example-registrar.tld
    Registrar URL: http://www.example-registrar.tld
    Admin Contact: Joe Registrar
    Phone Number: +1.3105551213
    Fax Number: +1.3105551213
    Email: joeregistrar@example-registrar.tld
    Admin Contact: Jane Registrar
    Phone Number: +1.3105551214
    Fax Number: +1.3105551213
    Email: janeregistrar@example-registrar.tld
    Technical Contact: John Geek
    Phone Number: +1.3105551215
    Fax Number: +1.3105551216
    Email: johngeek@example-registrar.tld
    >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

Nameserver Data:

  • Query format: whois "nameserver (nameserver name)", or whois "nameserver (IP Address)"
  • Response format:
    Server Name: NS1.EXAMPLE.TLD
    IP Address: 192.0.2.123
    IP Address: 2001:0DB8::1
    Registrar: Example Registrar, Inc.
    Registrar WHOIS Server: whois.example-registrar.tld
    Registrar URL: http://www.example-registrar.tld
    >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

Background:

This Consensus Policy is a product of policy implementation directed by ICANN Board resolutions 2014.02.07.08 - 2014.02.07.09, which adopted the GNSO Council Policy Recommendations for a new Consensus Policy on Thick Whois.

Recommendation #1 of the Thick Whois Policy Development Process (PDP) Working Group (WG), adopted by the GNSO Council on 31 October 2013, states: "The provision of thick Whois services, with a consistent labelling and display as per the model outlined in specification 3 of the 2013 RAA, should become a requirement for all gTLD registries, both existing and future."

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 staff and the Implementation Review Team (IRT) agreed that consistent labeling and display could be decoupled from the implementation of the transition from thin to thick.

ICANN submitted a draft proposal for implementation of the consistent labeling and display requirement for Public Comment on 3 December 2015. After considering the community's feedback and in collaboration with the Thick Whois IRT, ICANN revised its proposal as reflected in this Consensus Policy.

It should be noted that ICANN’s objective in implementing the GNSO Policy recommendations has been to minimize the impact to registrants, end users, contracted parties and to the overall Registration Data Directory Services (RDDS) systems by seeking to synchronize, where appropriate, this implementation with other related initiatives such as the adoption of the Registration Data Access Protocol (RDAP).


1 The Registry Operators of .com, .jobs and .net are expected to be required to implement the requirements set forth in this Policy as part of their transition from thin to thick registries pursuant to the implementation of the Thick Whois GNSO PDP Recommendations adopted by the ICANN Board on 7 February 2014.

2 Please note that this field updates the terminology and URL currently in use in Specification 3 of the 2013 RAA (as approved by the ICANN Board on 17 September 2013)

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