24 Shared Registration System (SRS) Performance

Prototypical answer:

24 Shared Registration System (SRS) Performance
24.1 SRS Summary
SRS is one of the five critical functions. In full compliance with requirements in Specification 6 and Specification 10 of the Registry Agreement, CONAC’s SRS system fulfills the following functions. It receives data from registrars concerning domain name and name server registrations through Extensible Provisioning Protocol (EPP), which ensures that the registrars are capable of providing services to the public for “.公益” domain names. It provides registrars with status information relating to domain names. It supports data synchronization to the WHOIS mirror database and WHOIS database through data synchronization interface, and enables WHOIS function. It provides DNS resolution system with zone files through DNS update application. It provides zone file data for the third party’s access through download interface. It provides bulk registration data access to ICANN through ICANN registration data interface. It also provides data to data escrow application through data escrow interface.

SRS is developed by a highly experienced third-party software developer. CONAC selects the third-party developer based on ISO27000 and ISO9000 certificates and Capability Maturity Model Integration (CMMI). CONAC and the third-party developer develop software in strict compliance with Software Development Life Cycle (SDLC), review and audit software products and development activities on the basis of Software Quality Assurance (SQA) to ensure all software meet relevant standards. During the planning phase, CONAC signs an agreement with the third-party developer, stipulating development scope, schedule, cost, confidentiality as well as conditions for acceptance. During the demand analysis phase, CONAC proposes business demands and performance demands based on Service Level Agreement (SLA) to the third-party developer. During software designing, programming and software testing, CONAC participates in reviewing and auditing the software products and development activities to ensure the quality of the software. At the end of the project, the third-party developer shall submit the development outcomes including design document, source code, testing report, user guide and so on to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems. The software that has passed the testing will be deployed in the production environment for operation, and maintained by the third-party developer.

CONAC’s SRS system can be divided into the core database, the core function zone, the extended function zone, internal and external interfaces, and a system administration zone. The core database implements registration data storage via Storage Area Network (SAN) equipments. The core function zone fulfills domain name registrations. The extended function zone extends domain name registration functions, and responds to future requirements. External interfaces connect SRS with the external applications. Internal interfaces assist the implementation of core functions. System administration zone performs the function of authorization and system log management.

24.1.1 The Core Function Zone
The core function zone mainly performs the following functions.

Domain name registration operation: It fulfills domain object operations like check, info, create, update, delete, renew and transfer. The system supports the registration of simplified Chinese domain names and traditional Chinese domain names.

Host operation: It fulfills host object operations like check, info, create, update and delete.

Contact operation: It fulfills contact object operations like check, info, create, update, delete and transfer.

Domain name lifecycle management: It defines and manages the domain name lifecycle, and triggers domain name state transitions.

Registrar management: It adds, modifies or deletes registrars.

24.1.2 The Extended Function Zone
Rapid suspension module: It quickly locks the domain name in question, and cancels its resolution. For details, please refer to the response to Question 28.

Orphan glue records processing module: It detects the orphan glue records in the core database, alerts the monitoring system if orphan glue records are found, and enables the system to remove them.

24.1.3 Internal and External Interfaces
Internal Interfaces:
EPP interface: Through the interface, CONAC communicates with registrars about operations to domain name, contact and host including create, delete, update, check, renew and transfer and so on, on the basis of section 1.2 of Specification 6 of Registry Agreement. CONAC provides registrars with an EPP client SDK (Software Development Kit) so that the registrars can use the Application Programming Interface (API) to enable EPP client-server communication. The EPP client SDK and EPP server are developed pursuant to RFC3735, RFC3915, RFC5910, RFC5730, RFC5731, RFC5732, RFC5733, and RFC5734. For details, please refer to Question 25. The EPP interface supports the domain name grace period policy in accordance with CONAC registration lifecycle policy and RFC3915.

Billing interface: Through the interface, registrars may recharge their account, either online or offline.

Notification interface: Through the interface, CONAC notifies registrars of low account balance or other billing issues by emails or telephones.

Web query interface: SRS provides registrars with a web-based query interface, where the registrars can conveniently query a balance of their account and access reports of domain name registration operations.

External Interfaces:
Interface for the data escrow agent: The interface exports the domain name registration data and other associated data from the core database, in the format prescribed in Specification 2 of the Registry Agreement. For details, please refer to Question 38.

Zone file download interface: The interface generates zone file data from the SRS database in the format prescribed in section 2.1.4 of Specification 4 of the Registry Agreement, and sends it to the directory managed by SFTP that provides zone file download function to third parties.

Interface for registration data access to ICANN: The interface extracts up-to-date registration data from SRS database in accordance with section 3 of Specification 4 attached to the Registry Agreement, sends it to the directory managed by SFTP that provides registration data download function to ICANN.

Reporting interface: In compliance with Specification 3 of the Registry Agreement, the reporting interface generates a Per-registrar Transactions Report and a Registry Functions Activity Report, and sends the reports to ICANN monthly.

WHOIS data synchronization interface: According to section 1.8 of Specification 4 of the Registry Agreement, the interface extracts WHOIS data from SRS database, and provides the data to WHOIS instances in the core database and WHOIS instances in WHOIS mirror database.

24.1.4 System Administration Zone
Authorization module: It defines and administers system users, their roles and access permission. Each user can assume many roles, with a particular role mapping to a set of access permissions. To prevent unauthorized operations, the system has tools to administrate users’ access and specify administrators’ operation permissions.

System log module: The system log mainly records the key operations to SRS, including users’ log-in operations, operations automatically triggered by other systems, and interactions with registrars. The system administrators use the system log for review and auditing.

24.2 SRS Network Architecture
SRS is deployed in the primary operations center and the backup operations center, a hot standby of the primary operations center. The primary operations center and the backup operations center can provide registrars with IPv4⁄IPv6 based SRS services, meeting the service levels prescribed in Specification 10 of the Registry Agreement.

24.2.1 Deployment Structure of SRS in the Primary Operations Center
SRS system is deployed using a redundancy and load balancing strategy, with the purpose to improve EPP response time and EPP service availability. In the application service area of the primary operations center, 4 SRS servers are deployed to provide SRS service at the same time, and load balancing is also implemented using load balancing equipments. Each SRS server accesses the core database located in core data area for registration data. Using an Oracle database, the core database deploys 2 database servers with Real Application Clusters (RAC) to provide data service to SRS servers in application service area. Data of the core database are stored in the disk array. The application service area and the core data area are separated by firewalls and switches. The deployment structure of SRS in the primary operations center is shown in Figure 1 of Q24_attachment. For detailed network architecture, please refer to Figure 3 of Q32_attachment in attachment to Question 32.

The primary operations center is separated into functional zones of different tiers by routers, switches and firewalls. All these network devices have redundant connections. Such a deployment structure can ensure the availability of SRS services in case of SRS single point of failure, and supports horizontal scaling of SRS servers for heavy processing loads.

24.2.2 SRS Deployment in the Backup Operations Center
SRS in the backup operations center is basically identical to that in the primary operations center. The backup operations center has 2 SRS servers (instead of 4 SRS servers in the primary operations center) implementing load balancing and 2 database servers using RAC, and its database data are stored in the disk array. Data are synchronized between the primary operations center and the backup operations center in a quasi-real time manner.

24.2.3 SRS Security Measures
CONAC adopts the following strategies to ensure the security of SRS operations pursuant to RFC5734.

1. SRS is implemented using Transmission Control Protocols (TCP). SRS servers in the production environment listen at port 700. SRS servers in the test environment listen at port 3121. Server connections are initiated by clients.

2. SRS server limits one TCP connection corresponding to one session. The idle time for a session is no longer than 5 minutes. Only two connections are allocated to each registrar. The system does not respond to connections beyond the time limit.

3. EPP session uses a text password for authentication. The server limits the number of login attempts for each session to no more than 3 attempts.

4. Transport Layer Security Protocol is adopted. Both CONAC and registrars are required to check the validity of the certificates, including the validity periods and digital signatures. Connection is allowed only if all the verifications are successful.

5. In response to attacks over the Internet like DDoS, firewalls are deployed between tiers to monitor and mitigate attack to the greatest extent.

6. Registrar IP verification. Only client requests from specified IP addresses are responded to.

24.3 The Number of Servers and System Performance
24.3.1 The Number of Servers
4 SRS servers are deployed using load balancing in the primary operations center to provide services to the users. 2 rack-mount Oracle database servers constitute RAC.

2 SRS servers are deployed using load balancing in the backup operations center to provide services to the users. 2 rack-mount Oracle database servers constitute RAC.

As required, SRS is designed to be horizontally scalable. Additional servers can be added to support growth.

24.3.2 System Performance
CONAC’s SRS system can support at least 30 registrars. CONAC is committed to provide continued SRS service within less than 864 min downtime per month. Furthermore, CONAC has developed a continuity plan, and proposed China Internet Network Information Center (CNNIC) as our backup registry operations provider. An annual continuity test plan has also been worked out.

CONAC has implemented multiple measures to improve SRS availability and performance. As to hardware deployment, redundancy and load balancing are used for EPP servers, RAC deployment is used for the core database, and the backup operations center is built to take over the primary operations center if necessary. As to software, high-performance connection pool technology is adopted in database access, and efficient multi-threads technology is used in EPP server Daemon. As to database storage, according to the recommendation of Oracle DBA, table space is planned, by which index and data are stored separately; Oracle system parameters are adjusted based on the real operations; statistical reports are generated regularly to reduce and control massive statistical queries to the core database; and up to 1 year worth of data are put into archives.

4 EPP servers are deployed using load balancing in the primary operations center, to provide EPP service. Even if two of the four servers fail, the other two still have the capacity to meet the demand at the registration peak. CONAC has conducted operational tests of the SRS performance.

Test Condition: 30 EPP Clients
Numbers of commands of login, logout, create, update, delete, renew and transfer are 500,000 respectively. Numbers of query commands of check, info, poll and transfer are 500,000 respectively.

The test results for one EPP server are 566 ms for query-command RTT, 118 ms for session-command RTT, and 1029 ms for transform-command RTT.

The test results for two EPP servers are 430 ms for query-command RTT, 69 ms for session-command RTT, and 782 ms for transform-command RTT.

The test results indicate that the performance of EPP service can meet the requirements in section 2 Service Level Agreement Matrix of Specification 10 of the Registry Agreement.

With the deployment of DNSSEC, the communication between the EPP client and EPP server will carry information relevant to public key of a child zone. In comparison with the amount of information transmitted before DNSSEC deployment, the amount of newly added information is small. Therefore, the impact of DNSSEC deployment on the performance of EPP server is limited.

24.4 Interconnectivity and Synchronization with Other Registry Systems
24.4.1 Interconnection to WHOIS System
Within the primary operations center, SRS connects to WHOIS system through an internal network, and provides data to the WHOIS system for WHOIS query through data synchronization interface. Once registration is valid, SRS updates data to WHOIS database within 15 minutes, which completely complies with the Registration Data Directory Services (RDDS) update time requirements in section 2 Service Level Agreement Matrix of Specification 10 of the Registry Agreement. The update process can ensure data completeness and accuracy.

24.4.2 Interconnection to DNS
Within the primary operations center, SRS connects to the server generating DNS zone file through an internal network. The DNS incremental update servers constantly read newly updated data from the SRS database, and update the zone file of the shadow incremental update primary DNS servers every 5 minutes. The shadow incremental update primary DNS servers synchronize the data to each resolution site to provide resolution service to users. The implementation completely complies with the DNS update time requirements in section 2 Service Level Agreement Matrix of Specification 10 of the Registry Agreement. In addition, the system provides a full update as a backup to the incremental update. The DNS full update server regularly (twice a day) reads full data from SRS, generates a full DNS zone file, and updates to the shadow full update primary DNS server.

24.4.3 Interconnection with Data Escrow System
Within the primary operations center, SRS connects to the server for data escrow through an internal network. SRS data are deposited from the data escrow server to the data escrow agent through a data escrow interface.

24.5 Synchronization among Servers
Within the primary operations center, once a registration is valid, the new registration data in SRS are synchronized in a timely manner to the WHOIS mirror database and DNS system as incremental update. The system also provides DNS full update as a backup for the incremental update. The server for data escrow obtains differential data and full data from SRS through independently developed interface, and deposits it to the data escrow agent. The backup operations center is connected to the primary operations center by a 10 Mb dedicated line. Oracle DataGuard is used for data synchronization from SRS in the primary operations center to SRS in the backup operations center. There are also backup systems in the primary operations center, which backs up the SRS and core data as the cold backup. For detailed backup strategies, please refer to Question 37.

24.6 Synchronization Frequency among Servers
Once a registration is valid, the new registration data in SRS are synchronized to the WHOIS mirror database in 15 minutes. The DNS incremental update server synchronizes the incremental data to DNS system every 5 minutes. DNS full update server synchronizes full DNS data to the DNS system twice a day. The data escrow server extracts differential data from SRS and makes deposits to data escrow agent once a day, and extracts full deposit data from SRS and deposits to data escrow agent once a week. SRS data are remotely synchronized between the primary operations center and the backup operations center in a quasi-real time manner. The interconnection of systems within the backup operations center and their synchronization frequency mirror those in the primary operations center, except that the backup operations center does not provide services to the public in normal situation.

24.7 Resourcing Plan
To maintain the stable and reliable operation of SRS, CONAC allocates 13 staff in terms of technology, marketing, and customer support to this area. They provide 7X24X365 operational service and system monitoring services. Detailed human resource allocation is as follow.
2 software engineers (software engineer role A: 2 staff), responsible for software development and maintenance;
1 system engineer (system engineer role A: 1 staff), responsible for system monitoring;
1 Database Administrator (DBA) (DBA role A: 1 staff), responsible for managing database operation;
1 system administrator, responsible for planning and managing system equipments;
2 financial staff (financial staff role B: 1 staff, financial staff role C: 1 staff), responsible for accounting and fund management;
1 marketing staff (marketing staff role A: 1 staff), responsible for communication and outreach for “.公益” TLD;
2 legal affairs staff (legal affair staff role A: 1 staff, legal affair staff role B: 1 staff), responsible for arbitration and litigation;
2 customer support staff (customer support role A: 2 staff), responsible for answering phones and clients’ questions;
1 registration manager (registration management role A: 1 staff), responsible for managing registration and registrars.

All the aforementioned staff are currently in place. Detailed skillset requirements on the staff can be found in section 31.3.3 in the response to Question 31.

CONAC uses 6 servers to provide SRS application services, 4 servers in the primary operations center and 2 servers in the backup operations center. Details for software and hardware can be found in the response to Question 32.

These resources are sufficient for the initial implementation and ongoing maintenance.

Costs of resources allocation are detailed in costs and capital expenditure of Question 47a and 47b.

Similar gTLD applications: (1)