Skip to main content
Resources

Registry System Testing (RST)

Overview

Registry System Testing (RST) ensures that a Registry Operator has the capacity to operate a new generic Top-Level Domain in a stable and secure manner. Every aspiring Registry Operator (RO) must demonstrate that it has established operations in accordance with the technical and operational criteria described in the Applicant Guidebook (Module 5: Transition to Delegation) prior to delegation into the root zone of the Internet. Additionally, once a TLD is delegated to the root zone, any changes to back-end operations may require a new RST test to ensure the stability of those services. For example, when an RO submits an RSEP, changes their RSP, modifies their IDN tables, or modifies their registry service in other ways that are described in the RA, the corresponding RST test type will be required.

Registry system testing covers the critical registry functions as described in the Registry Agreement (RA). There are several test elements (areas) that make up a test appointment. Below are the test elements that make up the majority of RST types.

Test Elements

  • DNS – Testing operability with the Domain Name System protocols.
  • WHOIS – Testing the records containing registration information about registered domain names.
  • EPP – Testing the implementation of the protocol used for electronic communication between a registrar and a registry for provisioning domain names.
  • Internationalized Domain Name (IDN) – Reviewing and/or testing domain names that include characters not written with the basic Latin alphabet (a - z).
  • Data Escrow – Testing to ensure that registries are able to make successful data deposits with their Data Escrow Agents.
  • Documentation – Review of self-certification documents (XML) to ensure required elements are accounted for.

RST Types

Registry System Testing requirements vary depending on the services they support. In pre-delegation change testing and RSP change testing all test elements are included in the test appointment. Other registry services may only require a subset of the test elements. The following is a list of current test types, as well as a description of when they apply.

Registry System Testing (RST)

This chart shows the general overview of the RST test types. These test types are broken down in more detail below:

Pre-Delegation Testing (PDT)

Pre-Delegation Testing ensures that a successful applicant to the New gTLD program has the capacity to operate their TLD in a stable and secure manner. Every new Registry must demonstrate that it has established operations prior to being introduced to the root zone.

Test Elements Required
Data Escrow DNS Doc EPP IDN Whois Seq One Seq Two Seq Three
Yes Yes Yes Yes Yes Yes -- -- --

For more detailed information regarding these test elements, please follow the links below:

RSP Change Testing

Similar to PDT (above), RSP testing is designed to ensure that a previously delegated TLD can continue to run successfully. Depending on the type of RSP change being made by the RO, the testing requirements may differ.

RSP Change Testing - Standard

The Standard RSP Change Test comprises the same elements as PDT, including the full suite of tests, and is required when an RO changes their RSP (Back-End).

Test Elements Required
Data Escrow DNS Doc EPP IDN Whois Seq One Seq Two Seq Three
Yes Yes Yes Yes Yes Yes -- -- --

For more detailed information regarding these test elements, please follow the links below:

SRS Gateway RSP Change

A SRS Gateway service is a SRS implementation that acts as a proxy between a subset of Registrars and the Registry. ROs interested in implementing an SRS Gateway service must validate the operability of their provider's SRS via an RSP Change Test.

Test Elements Required
Data Escrow DNS Doc EPP IDN Whois Seq One Seq Two Seq Three
-- -- -- -- -- -- Yes Yes Yes

For more detailed information regarding these test elements, please follow the links below:

IDN Review

For ROs wishing to make modifications to their Internationalized Domain Name (IDN) tables and service offerings, an IDN RST Review of the language and/or script tables is required.

Test Elements Required
Data Escrow DNS Doc EPP IDN Whois Seq One Seq Two Seq Three
-- -- -- -- Yes -- -- -- --

Note: RDAP is not yet included in any test

For more detailed information regarding these test elements, please follow the links below:

First-time RSP testing

This set of tests is performed when an RSP has not operated a gTLD before and the string for which they will provide services is already delegated and has registrants. This testing is done in addition to the relevant RSP change test listed above.

In this test, the RSP places simulated TLDs in the production environment, which is then monitored for compliance with the relevant DNS/DNSSEC specifications and the Service Level Requirements described in Specification 10 of the Base New gTLD Registry Agreement. The RSP is required to perform ZSK and KSK rollovers during the simulation period.

RST Resources

The following is a list of resources to help a registry complete Registry System Testing.

Documents

Please use these resources to help prepare your application/registry for RST. Resources will be updated periodically; it is important to use the most recent versions.

RST Materials Update Guide [PDF, 74 KB] (Published 1 August 2018)
Answers general questions about the RST process and requirements.

RST FAQ v.3.3 [PDF, 434 KB] (Published 28 July 2021)
Answers general questions about the RST process and requirements.

RST Input Data Instructions v.2.11 [PDF, 369 KB] (Published 26 May 2022)
Information on how to prepare for Registry System Testing.

RST Input Data Templates v.2.1.0 [ZIP, 802 KB] (Published 31 July 2017)
A collection of templates applicants are required to use to upload technical information to the RST system.

RST Test Specification Summary v.B [PDF, 327 KB] (Published 10 June 2021)

RST Test Specifications v.C [ZIP, 4.88 MB] (Published 10 June 2021)
Detailed test plans and cases that collectively make up Registry System Testing.

RST Test Specification Changes v.3.1 to v.3.2 [ZIP, 4.93 MB] (Published 10 June 2021)
Each test specification document with changes tracked from v.3.1 to v.3.2

Self-Test Tools

In order to assist ROs in advance of testing, self-test tools are available for the following test types:

Please note that inclusion of the above links does not imply ICANN's endorsement nor any guarantee of compliance with applicable requirements. Implementers should do their own research and contact the external sites for answers to questions regarding their content.


Previous Announcements

  • LOS ANGELES – 28 November 2018 – The Internet Corporation for Assigned Names and Numbers (ICANN) today announced an update to the WHOIS Self-Test Tool available as part of Registry System Testing (RST). The update now allows for Registry Service Providers to self-test WHOIS functionality for fields with redacted data.

    The new feature is a follow-up to the RST update announced on 1 August 2018, which allowed for the acceptance of redacted data responses during WHOIS testing, in accordance with the Temporary Specification for gTLD Registration Data adopted by resolution of the ICANN Board of Directors on 17 May 2018.

  • On 17 May 2018 the ICANN Board adopted a Temporary Specification for gTLD Registration Data. This page is under review and will be updated to address the Temporary Specification.
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."