24 Shared Registration System (SRS) Performance

Prototypical answer:

Shared Registration System (SRS) Performance

Compliance:

Registry is in compliance to Specification 6 and Specification 10 of the Registry Agreement. Below is the Compliance table for Specification 6.

Compliance to Specification 10 is listed in the section of SLA.

Compliance table (specification 6)

Section ⁄ RFC ⁄ Compliance

1.1 ⁄ 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, 5966 ⁄ Yes
1.2 ⁄ 5910, 5730, 5731, 5732, 5733, 5734, 3915, 3735 ⁄ Yes
1.3 ⁄ 4033, 4034, 4035, 4509, 4641 ⁄ Yes
1.4 ⁄ 5890, 5891, 5892, 5893 ⁄ Yes
1.5 ⁄ 4472, 3912 ⁄ Yes
2.1 ⁄ NA ⁄ Yes
2.2 ⁄ 1034, 4592, 1035 ⁄ Yes
3.1, 3.2, 3.3 ⁄ NA ⁄ Yes
4.1, 4.2 ⁄ NA ⁄ Yes

SRS System Description

1. System Architecture

RegistryASP SRS application is designed with multiple control interfaces to allow access by different parties via defined user roles and matrixes. All components have been designed to be deployed in a distributed environment.

〈SEE ATTACHED FILE - EXPLANATORY IMAGE 1〉

Core Component of Registry SRS

The Registry SRS is split into multiple components to improve scalability. The Core SRS Component consists of presentation layer, application security framework, application layer and database layer. It supports HTTP, HTTPS and EPP protocols.

The application layer is used to handle the business flow, audits, messages, processes and the daily tasks in the system. It has a data logger, which stores the details of all requests and responses from the application. The database layer deals with raw data management and utilizes relational databases.

2. SRS Data Flow Diagram

The system architecture of the SRS is designed to allow the EPP, WHOIS, registry web panel and registrar web panel to share the same business logic. The processing of any request will be the same, regardless of its origin.

〈SEE ATTACHED FILE - EXPLANATORY IMAGE 2〉

3. SRS System Features

Business Process Configuration:

- Administration module to configure business rules, policies and practices;
- Utilization of extensions in EPP to store additional information, e.g. language tag etc;
- Control panels to validate pending transactions and facilitate the submission of documents;
- Control panels for black and white list coupled with a pragmatic system to restrict sensitive names;
- Policy manager panels allow registry staff to control access to products and adjust policies;
- Feature access controller panels allow registry and registrar staff to customize functionalities available at various channels; and
- User access controller panel allows registry and registrar staff to customize access level of different users.

Channel Marketing (Registrar Support):

- Web-based multi-tier administrative control panel;
- Ability to brand email templates and extensive email tracking;
- Built-in marketing features such as volume discount and period discount tools;
- EPP connection Software Development Kit (SDK) and toolkits (in Java, PERL);
- Documentation, registrar technical training and change management.

Billing and Payment:

- Reminder notification with configurable alerts, content including other parameters; and
- Billing Manager to manage offline payments, fund alert, incentive rebate calculation and online invoice.

Report Management:

- Comprehensive statistical and transaction reporting system; and real-time reports for channel management (transaction, balance, renewal, announcements etc).
- Registrars detail and summary monthly statements; and
- Transaction tracking and action audit logs

Network Diagram

The following diagram shows the network architecture and connectivity for all the components of the Registry SRS System. The Registry System infrastructure is located in 2 different data centers for redundancy and scalability purposes. The primary data center consists of the SRS, DNSSEC signing and Data Escrow. The secondary data center will be running the WHOIS services. DNS Services are fully AnyCast enabled and dispersed geographically.

The primary data center has full redundancy up to the node level. The network is separated into 2 segments. The first network segment is IP restricted area for registrars to access the SRS which is the DMZ zone. The second segment is for internal access which consist of the database.

All servers are protected by redundant firewall.

The Web and EPP services are load-balanced between multiple servers. This provides maximum reliability, and is highly extensible by adding more servers behind the load balancers. Each server has redundant components (Power supplies, hard disk RAID, fans, network interfaces). The presence of multiple servers, multiple facilities, and multiple network providers means that the services will be well protected against single points of failure.

All services are setup in the secondary data center for emergency recovery in case of melt down in the primary data center. The services in the secondary data center can be online within 2 hours from the activation. Each site has at least 2 different network connections to the Internet. Our data centre belongs to a tier 1 provider with has four backbones peering to other tier 1 provider.

〈SEE ATTACHED FILE - EXPLANATORY IMAGE 3〉

The OTE server connects to the test database where the data resembles the production database. The Disaster Recovery Site (Secondary data center) is designed to replicate the primary site except the OTE environment. The OTE environment is not essential during a disaster. The DR site shall only be used to temporarily take over the registry operations while the primary site is being restored.

Interconnectivity

The main components in the systems are SRS, Data Escrow, WHOIS, DNS, Reporting, Registrar Systems, Accounting System and System Monitoring. The diagram below explains the interconnectivity between these components.

〈SEE ATTACHMENT - EXPLANATORY IMAGE 4〉

The system consists of a SRS system where the main database server resides. The interfaces in the SRS system are mainly web and EPP. The data are received from registrars through Web panel or automation from registrar system to the EPP server in real time. The central data will then be distributed to DNS, Accounting system and Data escrow agent through batch processing mode.

A bidirectional geographical replicated secondary database cluster is configured to replicate data from the main database in the SRS system. The secondary database will provide WHOIS query and data access for reports. The replication will be done using MySQL cluster bidirectional geographical replication feature which is near real time. The monitoring system will test the services in the SRS in real time.

Synchronization Scheme

Interconnectivity between registry system components appear in 3 synchronization schemes:

1. Replication Synchronization (Only for database)

Source (SRS) to Destination (WHOIS)

- A secondary database cluster will be installed for providing the WHOIS response. The synchronisation is done using bidirectional database replication. The data are replicated to secondary database within miliseconds.

Source (SRS) to Destination (Reporting Services)

- A secondary database cluster will be installed for providing reports. The synchronisation is done using bidirectional database replication. The data are replicated to secondary database within miliseconds.

2.Batch Processing

Source (SRS) to Destination (Stealth DNS)

- A DNS reconciliation and generation program is in place to regenerate the zones in the interval of 2 hours.

Source (Stealth DNS) to Destination (Primary DNS)

- The zone is transferred to primary DNS using notify = yes. Once records are changed in stealth DNS, the primary DNS will be notified to transfer the zone. The transfer takes less than 1 second.

Source (Primary DNS) to Destination (Secondary DNS)

- The zone is transferred to secondary using notify = yes. Once records are changed in primary DNS, the secondary DNS will be notified to transfer the zone. The transfer takes less than 1 second.

Source (SRS) to Destination (Data Escrow)

- A backend program will be running daily to deposit the data into Escrow agents SFTP server.

Source (SRS) to Destination (Accounting System)

- A backend program will be running daily to generate the data file in the accounting system data import format.

3. Real Time Access

Source (Registrar System) to Destination (SRS)

- All transactions will be processed in real time and response will be returned immediately after processing.

Source (System Monitoring) to Destination (SRS)

- The monitoring software will be testing the services in near real time interval (every second).


Operations plan: Registry has outourced the Registry Technical Operation to Qinetics Solutions Berhad. Qinetics has a long track record of operating Registries like .MY, .SG, .HK, .CD with excellent stability and performance. Full implementation and operational plans are provided further in the application. Furthermore, Qinetics and the applicant´s team have worked for a while on the provision of the Registry Gateway Service for .CO, MY.CO. Past operations structure of MY.CO will be implemented in the Registry to assure a flawless operation from the Registry side. Operations include Registrar Relations, ICANN Relations, policy supervision and compliance, administration, etc.

Plan of operations detail: Perform a series of activities that provide the Registry Services with specific Resources.

Activities:
- Maintain an available SRS system that allows Domain Registration Services to Registrars.
Achieved through: Technical Outsourcing with Qinetics. In depth description will be provided in later stages of the application.

- Maintain the DNS, Escrow, etc. services related to the extension in a stable and reliable manner.
Achieved through: Technical Outsourcing with Qinetics + Community DNS + NCC. In depth description will be provided in later stages of the application.

- Monitor the correct functioning of Registry Services
Achieved through: Technical Outsourcing with Qinetics. In depth description will be provided in later stages of the application.

- Perform Registry operational non technical activities:

Achieved through: Registry will have a team that will handle:

- Administrative control, billing, accounting, etc.
- Relationship with Registrars
- Relationship with ICANN
- Relationship with providers such as Qinetics, etc.
- Policy monitoring and Management

Registry team will perform these tasks as detailed later in the application to adequately attend the operation requirements of the service. This team will be comprised of experienced people that work in the domain registration business through Central Comercializadora de Internet (ICANN Accredited Registrar).


Resource Plan

On-hand resources:

- Qinetics has served domain registration services for .HK, .SG, .MY, .CD, etc. with a long track record of success. Technical resources are on hand for the full implementation of the proposed Registry.
- Registry team has run for almost 3 years Domain Registration Services that have been very successful in Colombia and in more than 10 countries around the world. Registry team will be comprised of experienced executives in the domain registration business from Central Comercializadora de Internet (ICANN Accredited Registrar). Resources are on hand for all the non technical operations of the Registry. On hand operational non technical resources include:

- Project manager
- Two support specialists
- Technical leader

These resources are currently part of the team that runs Central Comercializadora de Internet (ICANN Accredited Registrar).

Resource activity plan:

Qinetics will deploy the Registry Service of Registry using its existing system and infrastructure. During the implementation of Registry, new server hardware will be provisioned for SRS services.

The following human resources will be used:

- Qinetics Project Manager
- Registry Technical leader
- Datacenter Engineer
- System Administrator
- Database Administrator
- Software Developer⁄Application support
- Test Engineer

The Data Center Engineer will perform the server provisioning and installation of OS. Once the hardware is provisioned, System Administrator shall continue to install the required software and perform security configurations. On the other hand, the Database Administrator will create the required schemas. The assigned Software Developer will configure the rules and policies into the SRS system. Once done, the Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. When the testing is completed, the SRS system shall be handed-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager and the Registry Technical leader will be assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to all the Registry users on the functionalities of the system. The SRS setup shall be completed within a month.

After deployment

The system will be in maintenance mode after the SRS is deployed. The SRS will be supported by the general helpdesk support team for enquiries. Any technical support issues related to SRS will be escalated to the Application Support Engineer for troubleshooting. System Administrator is tasked to monitor the SRS availability. Whenever there is a support ticket, Application Support Engineer and System Administrator will escalate the support request based on the severity of the situation. The emergency response team will be triggered whenever there is a catastrophic scenario at the highest severity.

From the Registry side, Project manager, support specialists, and Technical Leader will handle issues related to administrative control, non technical relationship with Registrars, relationship with ICANN, relationship with providers such as Qinetics, Policy monitoring and Management, etc.

Bug tracking

After an issue has been attended, and once a remedy has been identified, Test Engineer will perform testing on the fixes before deployment by System Administrator. For deployment the system will enter maintenance mode. During and after maintenance, Qinetics has committed 4 resources for the 24 x 7 helpdesk, 4 data center engineers, 2 application support engineers, 1 support manager, 1 test engineer and 2 system administrators.

Ongoing upgrades and policy tracking

As part of the ongoing policy changes, a team of software developers is available for any standard upgrades to the SRS and the changes will trigger the change request procedure in accordance to CMMI standards.

Service Level Agreement (SLA)

Registry is committed to provide SLA according to the parameters below in accordance to Specification 10:

DNS

- DNS service availability: 0 min downtime = 100% availability
- DNS name server availability: ≤432 min of downtime (≈99%)
- TCP DNS resolution RTT: ≤1500 ms, for at least 95% of the queries
- UDP DNS resolution RTT: ≤500 ms, for at least 95% of the queries
- DNS update time: ≤60 min, for at least 95% of the probes

RDDS

- RDDS availability: ≤864 min of downtime (≈98%)
- RDDS query RTT: ≤2000 ms, for at least 95% of the queries
- RDDS update time: ≤60 min, for at least 95% of the probes

EPP

- EPP service availability: ≤864 min of downtime (≈98%)
- EPP session-command RTT: ≤4000 ms, for at least 90% of the commands
- EPP query-command RTT: ≤2000 ms, for at least 90% of the commands
- EPP transform-command RTT: ≤4000 ms, for at least 90% of the commands

Similar gTLD applications: (2)