24 Shared Registration System (SRS) Performance

Prototypical answer:

The Shared Registration System (SRS) will consist of an Extensible Provisioning Protocol (EPP) compliant gateway, a Web-based registrar portal, an operational test and evaluation environment (OT&E), domain release systems and associated billing and reporting systems. The SRS will manage the master data that supports a Domain Name System (DNS) and DNS Security Extensions (DNSSEC), Registration Data Directory Service (RDDS) (WHOIS Database Services), and Data Escrow services. (See Attachment 1 to the answer to Question 32 for a representative network diagram.)

DNS

Although the Registryʹs DNS will be on separate hardware from GoDaddy.com’s existing DNS, its architecture will be based on GoDaddy.com’s existing DNS infrastructure. The current system is the largest on the Internet, authoritative for over 37 million zones, and handles, on average, 9 billion DNS queries per day. Due to high levels of redundancy and monitoring, the existing system maintains 100% uptime, and the same is expected of the Registry DNS. One server cluster will be the active “master,” and the other will be in “hot-spare” mode; constantly replicated and in-sync, ready to take over master duties if the active master fails. (See Go Daddy’s answers to Question 35 for detail.)

Go Daddy’s DNS will comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the DNS and name server operations including, without limitation, RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966.

Go Daddy’s DNSSEC will comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 4641 and its successors. If Go Daddy implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it will comply with RFC 5155 and its successors. Go Daddy will accept public-key material from child domain names in a secure manner according to industry best practices. Go Daddy will also publish on its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. Go Daddy will publish its DPS following the format described in “DPS-framework” (currently in draft format, see http:⁄⁄tools.ietf.org⁄html⁄draft-ietf-dnsop-dnssec-dps-framework) within 180 days after the “DPS-framework” becomes an RFC.

EPP GATEWAY

Go Daddy’s EPP gateway will provide a connection-oriented EPP service. The EPP gateway will support synchronous mode connection: the client must receive a response to a command before sending another. Registry-defined connection limits will be configurable but limited equally for all registrars. Each connection will have a configurable inactivity timeout and lifetime timeout. Metrics will be captured for all transactions to allow for equal access and SRS stability. The EPP servers will be protected by firewalls. The actual IP of the servers will be hidden through a virtual IP from the load balancer. Registrars will be required to register their IP subnets with Go Daddy to be allowed access through the firewall. The server will perform mutual authentication on connections which will require a valid Secure Sockets Layer (SSL) certificate. The certificate must be signed from a trusted certificate authority. (See Go Daddy’s answers to Question 25 for detail.)

WEB-BASED REGISTRAR PORTAL

The registrar portal will provide the same functionality as the EPP gateway through a convenient Web interface. The registrar will be able to create and manage user sub accounts. These accounts will be configurable with independent access roles.

OPERATIONAL TEST & EVALUATION ENVIRONMENT

An isolated OT&E environment will be available for registrar testing prior to production operations. This environment will allow registrars to develop and test their client software systems with no risk to production systems.

SRS ARCHITECTURE

For the SRS to achieve and exceed the performance and reliability requirements as set forth in the Service Level Agreement Matrix (Registry Agreement, Specification 10), Go Daddy systems will be compartmentalized into functional areas. These individual areas will be comprised of hardware load balanced clusters of N+1 servers. Individual servers will be added or removed from the component cluster without negatively impacting normal activities or performance of the system component. The complete SRS will be deployed in each data center to provide active⁄passive redundancy. For any component server cluster, there will never be less than 2 servers, but there will be as many servers as necessary to meet Specification 10.

SRS DEVELOPMENT

The SRS will be a high volume On-line Transaction Processing (OLTP) system with a SQL server back end. The SRS will communicate with the database using stored procedures. Data-intensive business logic will be performed in the data tier while non data-intensive logic will be performed in the application tier. The SQL server will have a read-only mirror used for reporting.

SRS releases (“builds”) will be constructed from source control, and then deployed to the development environment for initial developer testing. Once developer testing is complete, the applications will be promoted to the test environment for formal Quality Assurance testing.

SRS SERVER BUILDS

All server builds will follow a standard build checklist. The checklist will manage the flow from server request to deployment. The checklist will include the following steps: inbound⁄outbound firewall access setup, inbound⁄outbound network access, security software setup, vulnerability scans, internal⁄external monitor setup, SRS software setup, disaster recovery plan, data backup plan, security scans, and QA testing.

SRS TESTING

Before each deployment, verification and validation tests will be executed against every build of the SRS. Testing will be performed throughout the development cycle in the form of unit testing, component testing, integration testing, and system testing. These tests will cover the following basic areas, which include EPP correctness, performance, reliability and security. In addition to the tests performed by automation, the QA staff also will perform exploratory testing.

1. EPP correctness: Data-driven known inputs will be used to generate and verify expected outputs.

2. Performance: Performance testing of the SRS will include resource usage, throughput, stimulus-response time, and queue lengths detailing the average or maximum number of tasks waiting to be serviced by selected resources. Some typical resources that will be monitored include network bandwidth, CPU cycles, disk space, disk access operations, and memory usage. The goal of this testing will be to identify potential performance bottlenecks and enable performance comparisons with historical build data.

3. Reliability: Stress or load testing will be used to test the whole system rather than the software alone. In these tests, the SRS will be exercised at and beyond the specified limits. Typical stress will include resource exhaustion, bursts of activities, and sustained high loads.

4. Security: The security testing of the SRS will include identifying and removing any software flaws that may potentially lead to security violations, and validating the effectiveness of security measures. The SRS will be scanned by tools such as Nessus by Tenable Network Security®. In addition, simulated security attacks will be performed by our QA staff to attempt to find vulnerabilities.

SRS MAINTENANCE

Any future protocol changes made to enhance functionality will be documented in Internet-Draft format as described in RFC 3735 and provided to ICANN prior to development. For all other changes including system enhancements, Go Daddyʹs Change Approval Board will internally assess hardware maintenance and routine software patching. Approved changes will be entered as a project in Go Daddy’s Change Management system. Once the project has been approved for deployment, the deployment will be scheduled. The change will first be scheduled and deployed to the OT&E environment. Only successful OT&E environment deployments will be promoted to the production SRS environment. All efforts will be taken to minimize the impact of deployments by scheduling for low traffic times as defined by historical data. Registrars will be notified in advance of any scheduled maintenance periods. The notice will contain detailed information on the change being deployed, maintenance window and systems that will be affected.

SRS OPERATIONS

Go Daddy’s operations staff will continuously monitor the SRS network, SRS servers and SRS health. These teams will be supported by 24⁄7 personnel. The system will provide metrics to aid in future upgrade decisions and detection of any potential failures.

RESOURCING PLAN

Resourcing will come from current staff throughout the parent organization: Software Development, Network Operations, IT, Security Operations, and Business Continuity Departments. Go Daddy will incorporate all new gTLDs added to the Go Daddy registry into existing workflows to obtain immediate workability. Go Daddy has anticipated additional headcount in the coming year for all affected departments. See the headcount estimate in the ʺCASH OUTFLOWSʺ section in Go Daddyʹs answer to Question 46.

Similar gTLD applications: (2)