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 be currently providing registry services for a gTLD currently in order to apply to the Registry Service Provider (RSP) program?

No.

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. The Registry Service Provider (RSP) Evaluation Program is intended to reduce the cost and time involved in evaluating new gTLDs, and it is independent of processes related to operations of ccTLDs.

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

Yes, a ccTLD could be an RSP for a gTLD.

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 unsuccessfully evaluated, 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.

21. Why are there different versions of Label Generation Rules (LGRs) at ICANN site and New gTLD Program site?

ICANN org has published the Second-level Label Generation Rules (LGRs) called RSP Full Variant Set LGRs for RSP program to facilitate the RSPs. They are programmatically generated from the already published Second-Level Reference Label Generation Rules and Common-LGR to include the complete set of cross-repertoire variants applicable to each language or script LGR. These two LGR sets, i.e. RSP Full Variant Set LGRs and Second-Level Reference Label Generation Rules combined with Common-LGR, represent the same information.

22. Is it mandatory to use RSP Full Variant Set LGR for the RSP application?

No, the RSP evaluation program supports custom IDN tables generated by the RSP, and they can be submitted for review. Other IDN tables will be reviewed by ICANN org manually.

As the RSP Full Variant Set LGRs already incorporate the cross-script variant data in Common-LGR in each file, the RSP applicant can select the RSP Full Variant Set LGRs from a dropdown list in the RSP portal and this will expedite the evaluation process.

If the RSP Full Variant LGRs are not used, the manual process will be used for reviewing the customized IDN tables and will take additional time. If the Second-Level Reference Label Generation Rules are used, the manual process will still be used but will not take as long as using customized IDN tables.

23. For questions with a "Yes" / "No" answer, can we only pass evaluation if we answer "Yes".

If an applicant answers "No", to any question with a yes/no answer, the applicant will be given the opportunity to provide an explanation, describing what process they follow. A "Yes" answer would give the applicant an automatic pass, so an assessment will be looking for explanations that come as close to equivalence with the requirement being asked for.

24. A large number of the technical questions ask "Does or will …", implying it is acceptable that compliance is something that can be achieved in the future. If we answer "Yes", based on future compliance, when is the deadline to be compliant?

If an RSP answers "Yes" to any of these questions, in anticipation of being compliant in the near future, they must have achieved full compliance before a gTLD, they are a designated service provider for, can be delegated into the ROOT zone.

Notwithstanding the above, the RSP's infrastructure must be ready to pass Pre-Delegation Testing before starting Pre-Delegation Testing (PDT) for a gTLD.

25. Questions 1.12 (e.g MAIN.1.12) ask about "background checks" on employees. Can you clarify what is meant by this?

"Background checks" would refer to regular, typically annual, security screening of staff with access to sensitive data or systems, especially systems holding personally identifiable information.

If annual background checks or security screenings are not performed, please explain your company's ongoing monitoring and control procedures that guarantee that employees with access to sensitive data or systems have not become a threat to the organization since their last verification.

If an applicant answers "No", to any question with a yes/no answer, the applicant will be given the opportunity to provide an explanation, describing what process they follow. A "Yes" answer would give the applicant an automatic pass, so an assessment will be looking for explanations that come as close to equivalence with the requirement being asked for.

26. Technical question DNS.5.14 references RFC6186 "Use of SRV Records for Locating Email Submission/Access Services", is that correct?

No. This was a minor typing error. It should have referenced RFC6168, which is "Requirements for Management of Name Servers for the DNS".

If you are seeing the incorrect question, please answer question DNS.5.14 as if it reads

DNS.5.14. RFC 6168

Does or will this RSP operate DNS service according to RFC 6168 ("Requirements for Management of Name Servers for the DNS")?

Both the RSP interface and the Handbook have been updated to reflect this minor correction, so please ensure you obtain a copy of the Handbook v1.2.2 or above.

27. I've seen references to "Secondary Technical Screening" and "Eligibility to bypass secondary technical screening", but there's nothing about this in the Handbook. What do these mean?

The RSP portal is designed to support the concept of primary and secondary technical screening. However, as described in the RSP handbook, all RSP applicants will undergo Technical Screening in this round. All references to secondary technical screening in the system are not applicable for this round.

28. Why does the RSP Portal now collect the year-of-birth instead of the full-date-of-birth for individuals?

ICANN org is asking for the minimum set of data required to complete due diligence consistently across all applicants. Please see the Terms and Conditions of the RSP Program regarding how ICANN processes personal data.

ICANN org updated its data collection requirements on 26 March 2025 and now requires applicants to provide the Year of Birth instead of the full Date of Birth for individuals to further minimize the personal data collected and with the understanding that further information may be requested in the application process, if needed.

In addition, ICANN org continues to require the Country of Residence for individuals; however, the address of the organization may be provided in place of the individual's address if it's not possible to provide the individual's address.

29. The RSP Pre-Evaluation period closes on 20 May 2025, can I create new applications after this date?

20 May 2025 is the deadline for an organization to submit its application during the RSP Program pre-evaluation application submission period.

Organizations that have not submitted their organization's application by 20 May 2025 will be deleted from the system as they are considered draft applications.

Organizations that did not submit an application during the pre-evaluation application submission period will have another opportunity to do so during the second RSP Program application submission period that runs concurrently with the gTLD application submission period. More information about the timeline of the periods of the next-round may be found here: https://newgtldprogram.icann.org/en/application-rounds/round2

Confirmed organizations, meaning that they have paid the RSP fee and passed background screening, can submit RSP applications for the types of RSPs (i.e., Main, DNSSEC, DNS and Proxy) until the end of the second RSP Program application submission period.

Confirmed organizations that have applied for Main RSP can submit RSP applications or change requests for IDN Services, IDN Tables, and additional Registry Services at any time during the round.

It's recommended that you have your organization confirmed and RSP applications submitted before 20 May 2025 so that if you are successfully evaluated, your organization is in the best place to be included in the first version of the list of successfully evaluated RSPs.

For the avoidance of doubt, if you submit your organization's application before 20 May 2025, ICANN org will continue processing it even if the application submission period has closed and the organization has yet to be confirmed.

Regarding the RSP fee and the two evaluation periods:

Per the RSP handbook:

The evaluation fee covers all required reviews, evaluations, and testing for all RSP applications and IDN service applications, and is a singular fee for all applicants That is, all applicants will pay only one fee even when applying for one or multiple types of RSPs, Registry Services, or IDN services. Note, that if a Registry Service application requires the evaluation by a third-party panel, an additional fee will be incurred for this specific review.

For avoidance of doubt, the RSP fee is paid once for the current round of the RSP program, and can be paid either during the pre-evaluation period or during the second evaluation period.

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.

10. Do RSPs need to integrate with and support the functionality of the Trademark Database (TMDB) for RSP Evaluation?

At the point that you provide services as a Main RSP for a delegated gTLD, you need to be onboard with the TMDB (https://marksdb.org).

In the case of the RSP program, RST v2.0 will be used to verify that the RSP applicant's platform is capable of supporting the Rights Protection Mechanisms. You don't need to connect to the TMDB for purposes of the RSP program as testing material will be used. The testing material can be found here: https://newgtlds.icann.org/sites/default/files/new-smd-test-repository-22nov22-en.pdf

The definition of the structure of the testing material can be found in Section 6 of RFC9361, and the definition of an Signed Mark Data (SMD) file may be found in RFC7848.

More information about the RPM test cases may be found here: https://icann.github.io/rst-test-specs/rst-test-specs.html#Test-Suite-MinimumRPMs

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.

1. Can I add more users after I have submitted my Organization, even after it is confirmed?

Yes. Users are created by inviting Contacts to be users. If the users you want to add are not yet Contacts, you will first need to add them as Contacts.

Once your Organization has been submitted, to add more Contacts, you will need to create a change-request to be manually approved by ICANN. It is unlikely that there would be any issue for just adding more Contacts. Adding more Contacts will not change your Organization's status, even if you are "Confirmed" and it will not cost you any extra to make this change.

In the RSP Portal, do the following:

• Upper left of your landing page, select "View My Organization"
• In the Organization, top right, click "REQUEST CHANGE"
• Go to the "Applicant Entity Stakeholders" page
• Scroll to the bottom section also called "Applicant Entity Stakeholders"
• To the far right of the section header "Applicant Entity Stakeholders", click the "Edit" icon and the "(+) Add New Contact" option will appear at the very bottom (you may need to scroll to see it).

Once you have added the new Contacts, submit the Change Request for approval.