gTLD	Full Legal Name	E-mail suffix	Detail
.gdn	Joint Stock Company ʺNavigation-information systemsʺ	nis-glonass.ru	View

Shared Regisration System (SRS) Performance: describe the plan for operation of a robust and reliable Shared Registration System. SRS is a critical registry function for enabling multiple registrars to provide domain name registration services in the TLD.

The registry is compliant to Specification 6 and Specification 10 in the Registry Agreement. The compliance table for Specification 6 is as attached.

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. A diagram of the system architecture is attached.

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 set of business logics. In other words, the processing of the request will be the same regardless the request comes from which interfaces. A diagram of the SRS data flow is attached.

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 attached 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. The stealth and primary DNS are located in the primary data center. DNS Resolution 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.

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. A diagram of the network is attached.

Interconnectivity
The main components in the systems are SRS, Data Escrow, WHOIS, DNS, Reporting, Registrar Systems, Accounting System and System Monitoring. A diagram of the interconnectivity is attached which explains the interconnectivity between these components.

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 secondary database cluster is configured using bidirectional geographical replication to replicate data from the main database in near real time. The secondary database will provide WHOIS query and data access for reports. The monitoring system will probe the services in the SRS in real time.

Synchronization Scheme
Interconnectivity between registry system components appear in 3 synchronization scheme:
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 mili seconds.

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 mili seconds.

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 transfer to primary using notify = yes. Once records changed in stealth DNS, the primary will be notified to transfer the zone. The transfer takes less than 1 second.

Source (Primary DNS) to Destination (Secondary DNS)
- The zone is transfer to secondary using notify = yes. Once records changed in primary DNS, the secondary 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 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 probing the services in near real time interval (every second).

Resource Plan
Qinetics will deploy the Registry Service of The registry using its existing system and infrastructure. During the implementation of The registry, new server hardware will be provisioned for SRS services. Our 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, our Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. Upon the testing is fully completed, the SRS system shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the functionalities of the system. The SRS setup shall be completed within a month.

The system will be in maintenance mode after the SRS is deployed. The SRS will be supported by general helpdesk support for enquiries. Any support issue related to SRS will be escalated to the Application Support Engineer for trouble shooting. System Administrator is tasked to monitor the SRS availability. Whenever there is a support ticket, Application Support Engineer and System Administrator will further escalate the support request base on severity. The emergency response team will be triggered whenever there is a catastrophe scenario at the highest severity.

Once a remedy is identified, Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, the outsourcing party 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. As part of on going policy changes, a team of software developer is available for any standards upgrade to the SRS and the changes will trigger the change request procedure in accordance to CMMI standards.

Service Level Agreement (SLA)
The 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 (WHOIS)
- 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

gTLD	Full Legal Name	E-mail suffix	Detail
.VIP	VIP Registry Pte. Ltd.	registryasp.com	View

VIP Registry is compliant to Specification 6 and Specification 10 in the Registry Agreement. The compliance table for Specification 6 is as attached.

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. A diagram of the system architecture is attached.

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 set of business logics. In other words, the processing of the request will be the same regardless the request comes from which interfaces. A diagram of the SRS data flow is attached.

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 attached 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. The stealth and primary DNS are located in the primary data center. DNS Resolution 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.

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. A diagram of the network is attached.

Interconnectivity
The main components in the systems are SRS, Data Escrow, WHOIS, DNS, Reporting, Registrar Systems, Accounting System and System Monitoring. A diagram of the interconnectivity is attached which explains the interconnectivity between these components.

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 secondary database cluster is configured using bidirectional geographical replication to replicate data from the main database in near real time. The secondary database will provide WHOIS query and data access for reports. The monitoring system will probe the services in the SRS in real time.

Synchronization Scheme
Interconnectivity between registry system components appear in 3 synchronization scheme:
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 mili seconds.

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 mili seconds.

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 transfer to primary using notify = yes. Once records changed in stealth DNS, the primary will be notified to transfer the zone. The transfer takes less than 1 second.

Source (Primary DNS) to Destination (Secondary DNS)
- The zone is transfer to secondary using notify = yes. Once records changed in primary DNS, the secondary 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 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 probing the services in near real time interval (every second).

Resource Plan
Qinetics will deploy the Registry Service of VIP Registry using its existing system and infrastructure. During the implementation of VIP Registry, new server hardware will be provisioned for SRS services. 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, our Test Engineer will perform rigorous testing procedures to ensure the system performs according to specifications. Upon the testing is fully completed, the SRS system shall be hand-over to System Administrator to perform deployment to production environment. Throughout the process, a Project Manager is assigned to perform project management and overall control on the implementation. The Project Manager will conduct training to the registry users on the functionalities of the system. The SRS setup shall be completed within a month.

The system will be in maintenance mode after the SRS is deployed. The SRS will be supported by general helpdesk support for enquiries. Any support issue related to SRS will be escalated to the Application Support Engineer for trouble shooting. System Administrator is tasked to monitor the SRS availability. Whenever there is a support ticket, Application Support Engineer and System Administrator will further escalate the support request base on severity. The emergency response team will be triggered whenever there is a catastrophe scenario at the highest severity.

Once a remedy is identified, Test Engineer will perform testing on the fixes before deployment by System Administrator. During maintenance, the outsourced party 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. As part of on going policy changes, a team of software developer is available for any standards upgrade to the SRS and the changes will trigger the change request procedure in accordance to CMMI standards.

Service Level Agreement (SLA)
VIP 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 (WHOIS)
- 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