Skip to main content
Resources

Additional Whois Information Policy

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.

On 21 February 2024, an updated version of the Policy was published to reflect changes required to implement the Registration Data Policy. Click here to view the updated version of this Policy. You may view the changes in the redline.

ICANN-accredited registrars and gTLD registries are obligated pursuant to their respective agreements with ICANN to provide query-based access to certain registration data via web pages and at port 43. This Additional Whois Information Policy additionally requires registrars and registries to include in their Whois output information to help Whois users better identify a registration's sponsoring registrar and understand the status codes used by registries and registrars, as follows:

  1. Registrars and registries who include domain name registration statuses in Whois output must:1
    1. only refer to the statuses by their respective EPP status codes;
    2. provide a link or URL next to each EPP status code that directs to an ICANN web page describing and defining the respective EPP status code. A list of URLs is available at https://www.icann.org/resources/pages/epp-status-codes-list-2014-06-18-en; and
    3. include in their Whois output the following message: "For more information on Whois status codes, please visit https://icann.org/epp" *

      * Please note that the longer form of the above link that was previously included in section 1(c), i.e., https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en is also compliant under the AWIP.
  2. Registrars shall not remove the links and message described above when providing Whois data from its own or another registrar or registry's Whois service.
  3. Registries must include the ICANN-issued Globally Unique Registrar Identification number (GURID, commonly known as the IANA ID) in their Whois output in the form of:
    Sponsoring Registrar IANA ID: 99999

Notes: The Additional Whois Information Policy (AWIP) was adopted by ICANN as a consensus policy on 6 May 2012. The effective date of this policy is 31 January 2016. All ICANN-accredited registrars and gTLD registries must comply with the AWIP with respect to registrations they sponsor in all top-level domains, which they are accredited for or administer, beginning on the effective date.

The purpose of this policy is to clarify the meaning of EPP status codes in Whois data and require the consistent identification of registrars by their GURID in Whois.

Background: On 24 June 2009, the GNSO Council launched a Policy Development Process (PDP) in connection to the Inter-Registrar Transfer Policy (IRTP) (http://gnso.icann.org/en/council/resolutions#200906 - resolution 20090624-2) and the PDP working group (IRTP Working Group B) submitted its Final Report on 30 May 2011 with a set of recommendations (http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf [PDF, 971 KB]), including Recommendation #8: to standardize and clarify Whois status messages regarding "Registrar Lock" status. On 22 June 2011, the GNSO Council resolved that prior to the consideration of approval of the recommendation regarding the standardizing and clarifying Whois status messages regarding Registrar Lock status, the GNSO Council would request ICANN staff to provide a proposal designed to ensure a technically feasible approach can be developed to meet this recommendation. In response to this request, ICANN staff developed a proposal in consultation with the working group which was posted for public comment and subsequently adopted by the GNSO Council on 16 February 2012 (http://gnso.icann.org/en/council/resolutions#20120216-1). Following another public comment forum on the recommendation and proposal (http://www.icann.org/en/news/public-comment/irtp-b-rec8-21feb12-en.htm) the ICANN Board adopted these on 6 May 2012. (https://www.icann.org/en/groups/board/documents/resolutions-06may12-en.htm#1.5)

An additional GNSO working group (IRTP Working Group C) was tasked on 22 September 2011 to consider three questions related to the IRTP, including whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs (https://community.icann.org/display/gnsoirtppdpwg/3.+WG+Charter). The working group issued an initial report that was the object of a public comment and subsequently a final report that was adopted by the GNSO Council on 17 October 2012. Following another public comment forum, the ICANN Board adopted the recommendations of the final report on 20 December 2012 (http://www.icann.org/en/groups/board/documents/minutes-20dec12-en.htm#2.a).


1 This requirement is not intended to require any registrar or registry to include domain name statuses in its Whois output if it is not already obligated to do so. But for those registrars and registries who do include a domain's status in Whois, the status must be in the form of the respective EPP code and conform to the other requirements of this policy.

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