Additional Registration Data Directory Services (RDDS) 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.
Updated 21 February 2024 to reflect changes required to implement the Registration Data Policy. This policy was previously known as the Additional Whois Information Policy. Contracted parties may implement this updated Policy beginning on 21 August 2024 and must implement no later than 21 August 2025.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Section 1 of this policy details technology-agnostic requirements that apply to all Registration Data Directory Services.
Section 2 of this policy details implementation requirements pertaining to WHOIS (available via port 43) and web-based Whois directory services only.
ICANN-accredited registrars and generic top-level domain (gTLD) registries are obligated pursuant to their respective agreements with ICANN to provide query-based access to certain Registration Data. This Additional RDDS Information Policy additionally requires registrars and registries to include in their RDDS output information to help RDDS users better identify a registration's sponsoring registrar and understand the status codes used by registries and registrars, as follows:
- Registry Operators and Registrars SHALL implement the following requirements:
1.1 include in their RDDS output the following message: "For more information on domain 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 with this Policy.
1.2 Registries MUST use the ICANN-issued Globally Unique Registrar Identification number (GURID, commonly known as the IANA ID) in their RDDS output.
- Registry Operators and Registrars SHALL implement the following requirements for WHOIS (available via port 43) and web-based WHOIS directory services:
2.1 status(es) MUST be displayed using their respective EPP status codes;
2.2 a link or URL MUST be shown 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;
2.3 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.
Notes: The Additional Whois Information Policy (AWIP), renamed as Additional Registration Data Directory Services (ARIP), 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 ARIP with respect to registrations they sponsor in all gTLDs, 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 RDDS data and require the consistent identification of registrars by their GURID in RDDS.
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 RDDS 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 RDDS 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).