RSP Evaluation Program Frequently Asked Questions

1. What is a Registry Service Provider (RSP)?

An RSP provides one or more of the critical technical services necessary for the operation of a generic top-level domain (gTLD) in a manner that provides for the security and stability of the Internet's Domain Name System (DNS). RSPs are often referred to as the "back-end" or back-end provider for a gTLD registry operation.

2. Does my organization need to provide registry services for a gTLD currently in order to apply to the Registry Service Provider (RSP) program?

No. Organizations do not have to currently provide back-end services for a gTLD, but they do need to be evaluated.

3. If my organization currently provides registry services for a gTLD, will it still need to be evaluated to become an RSP for the next round of new gTLDs?

Yes. If your organization wishes to offer services to applicants in the New gTLD Program: Next Round, it must be evaluated through the RSP Program.

4. How many types of RSPs are there?

There are four types of RSPs:

1. Main RSPs, which operate the registration database for a gTLD, undertake escrow of domain registration data, and operate the Extensible Provisioning Protocol and Registry Data Access Protocol services for a gTLD. A gTLD can only have one Main RSP.
2. DNS RSPs, which operate one or more DNS servers for a gTLD. A gTLD may use multiple DNS RSPs.
3. DNSSEC RSPs, which undertake the cryptographic operations necessary for DNS Security Extensions (DNSSEC). A gTLD's DNSSEC RSP may also be its Main RSP or one of its DNS RSPs.
4. Proxy RSPs, which perform registration validation to comply with applicable local law in a given jurisdiction. Note that this is an optional registry service that must be approved by ICANN. A gTLD may use multiple Proxy RSPs, each of which provides access to a different jurisdiction.

5. Does my organization need to apply to be every type of RSP? Can an RSP provide services to more than one gTLD?

An organization does not need to apply to be every type of RSP. Some organizations may opt to provide only one or several types of service to gTLDs. An RSP may provide services to more than one gTLD.
 

6. Can an RSP provide services to more than one gTLD?

Yes, an RSP may provide services to more than one gTLD.

7. Can an RSP provide services to a country-code top-level domain (ccTLD)?

There is no prohibition with RSPs providing services to ccTLDs.

8. Can a ccTLD operator apply to be an RSP?

Yes. Many ccTLD operators currently are RSPs for gTLDs.

9. Can a gTLD have more than one DNS RSP?

Yes, a gTLD may have more than one DNS RSP.

10. Can a gTLD be its own RSP?

Yes. A gTLD applicant may operate its own back-end services, but it will still need to be evaluated through the RSP program before their gTLD application can be approved.

11. If my organization is not successful in clearing evaluation, can I apply again?

Yes. Your organization may apply again to become an evaluated RSP and pay a new evaluation fee.

12. Will my organization be added to the list of evaluated RSPs if I cannot successfully clear evaluation before the first publication of the list on 9 December 2025?

Yes, ICANN org will add organizations to the list of RSPs as they clear evaluation, based on the Service Level Target described in the RSP Handbook.

13. Where can I find more information about becoming an RSP?

You can find more information about how to become an RSP in the RSP Handbook.

14. Are all new gTLD applicants required to use RSPs that have been successfully evaluated through the RSP Program?

Yes. Note that the RSP Program will have two evaluation periods: one before the gTLD application submission period and another during the gTLD submission period. New gTLD applicants are required to use RSPs that have been successfully evaluated during either of the evaluation periods.

15. What is the cost of the RSP Evaluation Program?

The RSP Program is funded by those seeking evaluation on a cost-recovery basis. Based on a conservative estimate of the number of RSP applicants. More information on the fee to apply as an RSP can be found here.

16. Is the RSP evaluation fee refundable, for example if the application is not successfully evaluated?

The RSP evaluation fee is non-refundable. However, the payment is only required after the organization has passed the Legal Compliance check (see section 4.1.4 of the RSP Handbook), so organizations not clearing Legal Compliance will not incur any fee.

17. Are the RSP and the gTLD Evaluation fees related?

No, the RSP and the gTLD Evaluation programs are independent programs with separate fees. If an organization plans to apply to become an evaluated RSP and operate gTLDs, it pays the RSP fee once and the gTLD application fee for every gTLD it chooses to apply for.

18. How can my organization apply to be an evaluated RSP?

Applications for the RSP Evaluation Program are required to be submitted through the RSP Portal. Information on the RSP Portal may be found here.

19. Does my organization need to pass all the questions on the RSP Technical Questionnaire to pass the RSP Evaluation?

All questions in the RSP technical questionnaire, for each RSP type, are considered an integral part of the RSP evaluation criteria. Because of this, an applicant must achieve a "pass" on all technical and non-technical question in any particular RSP type.

Per Section 4.1.9 of the RSP handbook, if an answer to a question is assessed to be not sufficiently complete, relevant, or appropriately responsive, ICANN will notify the RSP exactly which question is not satisfactory, at which point the RSP will have 30 days to provide a more satisfactory response.

Should the final assessment still be that the application has not cleared technical screening, the applicant may opt for an "Extended Evaluation" (Section 4.1.9), where they will be given a further opportunity to provide more satisfactory answers to questions that did not pass.

20. What are the rules around partners or suppliers having to be evaluated in the RSP Evaluation Program?

An RSP may have a business relationship with other organizations; for example, an RSP may use a cloud provider for infrastructure needs. 

A gTLD applicant needs to disclose all the RSPs supporting the critical functions, and those RSPs must be successfully evaluated in the RSP program. The different types of RSP can be found in question 4 of this FAQ.

Organizations, such as connectivity or hosting providers, do not need to apply separately in the RSP program, but they may need to be included based on the criteria of the questions.

For example, third-party suppliers of infrastructure, software or personnel may need to be included based on the criteria of the questions. If an applicant runs a registry system in-house but developed by another organization, information about such a system will need to be included in their application based on the criteria of the questions. However, if another organization is running the registry system, the third-party organization must be independently evaluated in the RSP program as a Main RSP.

1. What is the difference between questions MAIN 1.1 and MAIN 1.2 in Appendix A of the RSP Handbook?

Though MAIN 1.1 references ISO 27001, and ISO 27001 describes requirements for an information security management system which is the subject of MAIN 1.2, these are not duplicative questions.

MAIN 1.1 is a Yes or No question asking for attestation of a publicly verifiable, third-party security certification. One such certification may be acquired through ISO 27001 compliance, but there are others.

MAIN 1.2 requires a description of the information security management system, whether or not it is compliant with ISO 27001.

2. What does the term "cryptographic material" mean in question MAIN 1.6 and other questions of Appendix A of the RSP Handbook?

Although this term can be interpreted broadly to encompass physical devices, with respect to the RSP Evaluation Program, this term has the narrow meaning of cryptographic keys and other sensitive data used for cryptographic operations such as DNSSEC signing.

3. What is meant by "at-rest data" or "data at-rest" in Appendix A of the RSP Handbook?

This is a common term used to describe data that is stored. For more information on this topic, please see this webpage from the National Cyber Security Centre.

4. What is meant by "in-transit data" or "data in-transit" in Appendix A of the RSP Handbook?

This is a common term used to describe data as it is being transferred between computing elements. For more information on this topic, please see this webpage from the National Cyber Security Centre.

5. What is the difference between the maintenance of hardware and life cycle of hardware in questions MAIN 2.6 and MAIN 2.8 of Appendix A of the RSP Handbook?

For these questions, maintenance refers to the upkeep and continued operation of hardware after it is provisioned. The life cycle of hardware refers to the acquisition, commissioning, and decommissioning of hardware.

6. What is the difference between the maintenance of software and the development of software in questions MAIN 2.7 and MAIN 2.9 of Appendix A of the RSP Handbook?

Similar to the above question, maintenance refers to the upkeep and ongoing operations of software while development refers to the life cycle of software.

7. What does "automated orchestration" mean in the RSP Handbook?

This is a broad industry term that encompasses software and systems that configure and coordinate the deployment of computer systems. See this Wikipedia entry.

8. Question MAIN.4.11 - Can ICANN clarify what "sustained throughput" means and how long that is?

The period of sustained throughput should be relative to the total capacity the RSP applicant expects to be able to meet. Put simply, if the RSP applicant states that total system capacity is 10K domains, then the period of sustained throughput would be quite different from a system capable of 10M or 100M domains. RSP applicants should include all the information related to their test methodology and describe their reasoning.

Generally, for performance measurements ICANN would expect to see information such as:

1. Methodologies: A description of the methodology for making the capacity estimates (bandwidth & server) as well as the methodologies for creating the test data.
2. Bandwidth Capacity: A description of bandwidth capacities and how that correlates to performance capacity.
3. Server Capacity: A description of how server capacity is measured, the locations of potential bottlenecks, and how those could be mitigated.
4. Measurements: A description of how the RSP applicant measured the server and bandwidth usage during their test, for example what software and/or equipment was used for measuring, e.g. Prometheus/Grafana, Checkmk, Zabbix, etc.

9. Question MAIN.4.11 - Can ICANN clarify what is being referred to for "raw and materialized data"?

The terms "raw and materialized data" refers to the number of records processed (i.e. number of domains, contacts, hosts) and the total space required to process and store them. The total processing space should include things like data rows, indexes, transaction journal, system logs, etc. This exact list will vary according to the RSP applicant's software choices.

1. What does DNS Registry Service mean in question DNS 4.2 of Appendix A of the RSP Handbook?

This term means the service answering DNS queries.

2. What does question DNS 8.9 of Appendix A of the RSP Handbook mean?

This question is asking for a description of the methods used to assure the proper data is in the DNS zone.

1. Are Proxy RSPs required to integrate with ICANN's Zone File Access (ZFA), as mentioned in question PROXY 7.6 of Appendix A of the RSP Handbook?

This is only applicable to Proxy RSPs offering a differentiated or specialized DNS service. Currently no RSP offers such a service, but ZFA is asked in this question should a Proxy RSP propose such a service.