Back

24 Shared Registration System (SRS) Performance

gTLDFull Legal NameE-mail suffixDetail
.topJiangsu Bangning Science & Technology Co.,Ltd.55hl.comView
24. Shared Registration System(SRS)
24.1. Overview
The Applicant provides Registrars with a registration interface for the domain “.STRING” through KSRP provided by the Back-End Service Provider. The SRS provided by KSRP complies with the requirements of ICANN and IANA as well as relevant RFCs and other technical standards. It is designed and implemented to provide highly available, secure, scalable and high performance services.
24.1.1. System Architecture
The SRS consists of the domain registration system (EPP server) and other subsystems for domain name registration. Please refer to Figure 24-1 in Q24_attachment for the system architecture of SRS. Below is the detailed description.
a) EPP Server
The EPP server provides Registrars with domain registry services such as the creation, modification, deletion and other key functions of domain, contact and host objects. It also provides support for the redemption grace period and DNSSEC as specified in relevant RFCs.
b) Registrar Business Support System
The registrar business support system provides supporting functions to Registrars concerning domain registration. Upon successful authentication, a Registrar may perform a real-time check of account balance, monthly bill report, and domain operation records. It may also check its payment and usage details within a year. The Registrar can also use the system to report any problem to online customer support staff for solutions. In addition, Registrars may retrieve specifications, FAQs and other technical documents concerning ʺ.STRINGʺ TLD domain name registration in the knowledge base.
Registrars may also access the business support system via FTP to download historical data such as domain operation records and billing reports upon successful authentication.
c) Registry Business Support System

Please refer to Figure 24-2 in Q24_attachment for the system architecture of the Registrar business support system.
The Registry business support system provides business staff of the Applicant with the support services concerning domain registration, including auditing of newly registered domains, recharging of registrarsʹ accounts, and locking⁄unlocking of domains.
The registry business support system will regularly compile the registered domain data and zone file into a data file with specified type and formatting of content as described in ICANNʹs Registry Agreement, and uploads the data file on specified SFTP for ICANN and its designee to access and download.
In addition, the registry business support system will regularly generate a data file with specified type and formatting of content as described in ICANNʹs Escrow Agreement, and uploads the data on specified SFTP of the escrow service provider NCC Group for its service provision.
d) Zone File Synchronization Service
The zone file synchronization service is responsible for synchronizing changes made to the SRS database to the master DNS nodes, and through which all global DNS nodes are subsequently updated.
e) Databases
The SRS database is the master database that stores information about domains, contacts and hosts submitted by the EPP server. It is replicated to the Whois database using the Oracle Advanced Replication. The Registrar & Registry (hereafter referred to as R&R) business support database stores the data relating to the support business, such as billing reports, and historical auditing records, etc..
24.1.2. Physical Architecture
Please refer to Figure 24-3 in Q24_attachment for physical architecture of SRS.
The SRS system and the R&R business support system are deployed in multiple servers that are clustered and load balanced via F5s; both the SRS master database and R&R business support database achieve high availability via Oracle Veritas. A disk array is deployed at the back-end for data storage redundancy and for high throughput database access.
24.1.3. Equipment List
Please refer to Table 24-1 in Q24_attachment for a list of equipment of the SRS (excluding any hardware shown in the topological diagram of the primary data center, such as routers or firewall).
24.2. Operations Plan
24.2.1. Availability
The SRS of the KSRP is able to provide 99.9% availability, ensuring the monthly down time not exceeding 43.2 minutes, therefore fully meets the 98% availability requirement specified in ICANNʹs Specification 10. In addition, the SRS is also redundantly deployed at the backup data center. If the primary data center goes off-line, registry services are switched over to the backup data center within 30 minutes to ensure high availability of the services.
Specifically, SRS ensures high availability in the following aspects:
a) The SRS software has been built via rigorous engineering disciplines such as code review, unit testing and daily builds. Any SRS build must pass the thorough integration testing, system testing and acceptance testing prior to deployment in production.
b) Both the hardware and software systems are redundantly deployed. Load balancers (F5) are deployed to distribute requests to server clusters to mitigate unplanned server hardware and software failures. For example, the EPP server is deployed on multiple servers as a cluster behind the load balancer so that even if one of the servers goes down, F5 will automatically distribute the requests to the rest of functioning servers, to ensure the registry services continuity.
c) The database of the SRS achieves high availability via Oracle Veritas to prevent any unplanned outages of the database backend.
24.2.2. Performance
The KSRP is designed to scale up to 30 million domains, and the performance test result shows that it is able to handle 3000 transactions per second. Hence KSRP is able not only to meet the current needs of the Applicant, but also to scale for future demand of the Applicant as the business grows.
Comparison with SLR Indicators
Please refer to the Table 24-2 in Q24_attachment for the contrast between the test results of the SRS and the SLR indicators specified in Specification 10.
24.2.3. Scalability
SRS is developed and deployed using distributed technology that is able to scale both vertically and horizontally as follows:
a) Support vertical scalability by upgrading the hardware of online servers;
b) Support horizontal scalability by deploying server hardware and software systems in a cluster;
c) When the system load reaches the maximum capacity of the SRS system, it can be upgraded by adding more servers and bandwidth to meet the performance and throughput capacity needs
24.2.4. Security
In order to ensure the security of the SRS, the KSRP has taken the following measures:
a) SSL⁄TLS protocol is used for connection between the SRS and the clients. When connecting the SRS, a Registrar is required to be authenticated with SRS using its user name, password, IP address and the digital certificate authorized by the KSRP; if the Registrar fails the ID authentication 3 times, it has to wait for 30 minutes before another attempt;
b) SRS has put a strict restriction on the number of connections created by Registrars as well as the idle time in TCP;
c) SRS is deployed in the DMZ in order to prevent unauthorized network access to the backend database.
24.2.5. Data Synchronization
Data synchronization between the master database of SRS and the Whois database is realized via Oracle Advanced Replication at an interval of 5 minutes.
Data synchronization between the primary and the backup data center is realized via Oracle Dataguard at an interval of 5 minutes.
24.2.6. Operations and Maintenance
The following operations and maintenance measures have been established to guarantee the quality of services.
a) SRS is being monitored and protected on a 7×24 basis. With the monitoring system, KSRP keeps track of the performance of the whole system so that it can take timely measures to address any emergency;
b) The Applicant and KSRP have established a thorough emergency response mechanism to effectively handle emergency situations. The mechanism provides handling and upgrading procedures for different types of failures based on pre-classified severity levels.
24.3. Compatibility
SRS fully complies with EPP and supports RFCs mentioned in Specification 6, including RFCs 5730~5734, RFC 3735 and RFC 3915.
KSRP supports IDN based on IETF RFC 3454 and RFCs 5890~5892. When the user registers a domain name under ʺSTRINGʺ, SRS will store the domain data and its corresponding Punycode into the SRS database.
Regarding support for DNSSEC, KSRP has designed its interfaces according to RFC 5910. A plan is in place for smooth transition to DNSSEC in KSRP once DNSSEC-related tests are completed on the platform.
The Back-End Service Provider has dedicated R&D personnel who closely follow the DNSSEC work in IETF and the industry, so that the platform can be timely upgraded to meet the requirements of ICANN in case there are changes in the future.
24.4. Resourcing Plan
The development and test work for SRS has been completed. See Table 31-11 in Q31_attachment for the overall human resource planning of KSRP. The human resource in Table 31-11 can be allocated for other systems at the same time. Please refer to Table 24-3 in Q24_attachment for the resourcing plan of SRS system and the above 24.1.3 for equipment resource planning.
gTLDFull Legal NameE-mail suffixDetail
.网店Zodiac Libra Limitedzodiac-corp.comView
24. Shared Registration System(SRS)
24.1. Overview
The Applicant provides Registrars with a registration interface for the domain “.STRING” through KSRP provided by the Back-End Service Provider. The SRS provided by KSRP complies with the requirements of ICANN and IANA as well as relevant RFCs and other technical standards. It is designed and implemented to provide highly available, secure, scalable and high performance services.
24.1.1. System Architecture
The SRS consists of the domain registration system (EPP server) and other subsystems for domain name registration. Please refer to Figure 24-1 in Q24_attachment for the system architecture of SRS. Below is the detailed description.
a) EPP Server
The EPP server provides Registrars with domain registry services such as the creation, modification, deletion and other key functions of domain, contact and host objects. It also provides support for the redemption grace period and DNSSEC as specified in relevant RFCs.
b) Registrar Business Support System
The registrar business support system provides supporting functions to Registrars concerning domain registration. Upon successful authentication, a Registrar may perform a real-time check of account balance, monthly bill report, and domain operation records. It may also check its payment and usage details within a year. The Registrar can also use the system to report any problem to online customer support staff for solutions. In addition, Registrars may retrieve specifications, FAQs and other technical documents concerning ʺ.STRINGʺ TLD domain name registration in the knowledge base.
Registrars may also access the business support system via FTP to download historical data such as domain operation records and billing reports upon successful authentication.
c) Registry Business Support System

Please refer to Figure 24-2 in Q24_attachment for the system architecture of the Registrar business support system.
The Registry business support system provides business staff of the Applicant with the support services concerning domain registration, including auditing of newly registered domains, recharging of registrarsʹ accounts, and locking⁄unlocking of domains.
The registry business support system will regularly compile the registered domain data and zone file into a data file with specified type and formatting of content as described in ICANNʹs Registry Agreement, and uploads the data file on specified SFTP for ICANN and its designee to access and download.
In addition, the registry business support system will regularly generate a data file with specified type and formatting of content as described in ICANNʹs Escrow Agreement, and uploads the data on specified SFTP of the escrow service provider NCC Group for its service provision.
d) Zone File Synchronization Service
The zone file synchronization service is responsible for synchronizing changes made to the SRS database to the master DNS nodes, and through which all global DNS nodes are subsequently updated.
e) Databases
The SRS database is the master database that stores information about domains, contacts and hosts submitted by the EPP server. It is replicated to the Whois database using the Oracle Advanced Replication. The Registrar & Registry (hereafter referred to as R&R) business support database stores the data relating to the support business, such as billing reports, and historical auditing records, etc..
24.1.2. Physical Architecture
Please refer to Figure 24-3 in Q24_attachment for physical architecture of SRS.
The SRS system and the R&R business support system are deployed in multiple servers that are clustered and load balanced via F5s; both the SRS master database and R&R business support database achieve high availability via Oracle Veritas. A disk array is deployed at the back-end for data storage redundancy and for high throughput database access.
24.1.3. Equipment List
Please refer to Table 24-1 in Q24_attachment for a list of equipment of the SRS (excluding any hardware shown in the topological diagram of the primary data center, such as routers or firewall).
24.2. Operations Plan
24.2.1. Availability
The SRS of the KSRP is able to provide 99.9% availability, ensuring the monthly down time not exceeding 43.2 minutes, therefore fully meets the 98% availability requirement specified in ICANNʹs Specification 10. In addition, the SRS is also redundantly deployed at the backup data center. If the primary data center goes off-line, registry services are switched over to the backup data center within 30 minutes to ensure high availability of the services.
Specifically, SRS ensures high availability in the following aspects:
a) The SRS software has been built via rigorous engineering disciplines such as code review, unit testing and daily builds. Any SRS build must pass the thorough integration testing, system testing and acceptance testing prior to deployment in production.
b) Both the hardware and software systems are redundantly deployed. Load balancers (F5) are deployed to distribute requests to server clusters to mitigate unplanned server hardware and software failures. For example, the EPP server is deployed on multiple servers as a cluster behind the load balancer so that even if one of the servers goes down, F5 will automatically distribute the requests to the rest of functioning servers, to ensure the registry services continuity.
c) The database of the SRS achieves high availability via Oracle Veritas to prevent any unplanned outages of the database backend.
24.2.2. Performance
The KSRP is designed to scale up to 30 million domains, and the performance test result shows that it is able to handle 3000 transactions per second. Hence KSRP is able not only to meet the current needs of the Applicant, but also to scale for future demand of the Applicant as the business grows.
Comparison with SLR Indicators
Please refer to the Table 24-2 in Q24_attachment for the contrast between the test results of the SRS and the SLR indicators specified in Specification 10.
24.2.3. Scalability
SRS is developed and deployed using distributed technology that is able to scale both vertically and horizontally as follows:
a) Support vertical scalability by upgrading the hardware of online servers;
b) Support horizontal scalability by deploying server hardware and software systems in a cluster;
c) When the system load reaches the maximum capacity of the SRS system, it can be upgraded by adding more servers and bandwidth to meet the performance and throughput capacity needs
24.2.4. Security
In order to ensure the security of the SRS, the KSRP has taken the following measures:
a) SSL⁄TLS protocol is used for connection between the SRS and the clients. When connecting the SRS, a Registrar is required to be authenticated with SRS using its user name, password, IP address and the digital certificate authorized by the KSRP; if the Registrar fails the ID authentication 3 times, it has to wait for 30 minutes before another attempt;
b) SRS has put a strict restriction on the number of connections created by Registrars as well as the idle time in TCP;
c) SRS is deployed in the DMZ in order to prevent unauthorized network access to the backend database.
24.2.5. Data Synchronization
Data synchronization between the master database of SRS and the Whois database is realized via Oracle Advanced Replication at an interval of 5 minutes.
Data synchronization between the primary and the backup data center is realized via Oracle Dataguard at an interval of 5 minutes.
24.2.6. Operations and Maintenance
The following operations and maintenance measures have been established to guarantee the quality of services.
a) SRS is being monitored and protected on a 7×24 basis. With the monitoring system, KSRP keeps track of the performance of the whole system so that it can take timely measures to address any emergency;
b) The Applicant and KSRP have established a thorough emergency response mechanism to effectively handle emergency situations. The mechanism provides handling and upgrading procedures for different types of failures based on pre-classified severity levels.
24.3. Compatibility
SRS fully complies with EPP and supports RFCs mentioned in Specification 6, including RFCs 5730~5734, RFC 3735 and RFC 3915.
KSRP supports IDN based on IETF RFC 3454 and RFCs 5890~5892. When the user registers a domain name under ʺSTRINGʺ, SRS will store the domain data and its corresponding Punycode into the SRS database.
Regarding support for DNSSEC, KSRP has designed its interfaces according to RFC 5910. A plan is in place for smooth transition to DNSSEC in KSRP once DNSSEC-related tests are completed on the platform.
The Back-End Service Provider has dedicated R&D personnel who closely follow the DNSSEC work in IETF and the industry, so that the platform can be timely upgraded to meet the requirements of ICANN in case there are changes in the future.
24.4. Resourcing Plan
The development and test work for SRS has been completed. See Table 31-11 in Q31_attachment for the overall human resource planning of KSRP. The human resource in Table 31-11 can be allocated for other systems at the same time. Please refer to Table 24-3 in Q24_attachment for the resourcing plan of SRS system and the above 24.1.3 for equipment resource planning.