24 Shared Registration System (SRS) Performance

Prototypical answer:

24 Technical and Operational Capability

Atgron, Incʹs string, .WED, will be added to CoCCAʹs existing SRS, which currently has its primary Network Operations Centre (NOC) in Sydney Australia. The Sydney primary SRS is a single SRS instance currently hosting a dozen ccTLDs. CoCCAʹs Sydney SRS runs the latest versions of their ʺpamojaʺ TLD software application in a High Availability (HA) configuration. The Sydney SRS registry that will host .WED currently complies with the requirements of Specifications 4, 6 and 10 and will be scaled or modified to meet SLA requirements for any future ICANN gTLD specifications. Because of CoCCAʹs commercial model and technology, the primary SRS can be moved from one data center to another with only a few minutes outage.

From an Internet users perspective, trusted, secure and responsive DNS implementations are the ultimate objective of Atgron. To ensure this CoCCA will use PCHʹs DNSSEC and anycast infrastructure for offline storage, signing and resolving the .WED TLD, additional DNS resolution will be provided by the ISC SNS anycast platform and two CoCCA unicast DNS servers. Additional information and technical details on the DNSSEC and anycast DNS services can be found in the answers to questions 34, 35 and 43.

24.1 Scale of Operations

A decade of operational experience with TLDs that have implemented policies to discourage tasting or otherwise incentivize add-drop registrations confirms the widely held belief that SRS registry databases are largely static. Once registered, data associated with a domain is not frequently modified. More than 99% of the queries seen by CoCCA on a daily basis are WHOIS, EPP Domain:Info or Domain:Check queries (read queries) and do not tax an SRSʹs resources excessively. Direct experience and anecdotal evidence from other small and mid-sized registries suggest that between 2% and 5% of the records in the register change daily through db ʺwriteʺ operations - new registrations, renewals, name server changes, contact updates automated changes of status, transfers etc.

For a theoretical registry of 1 million domains, this equates to roughly 50,000 ʺwriteʺ transactions a day - or an average of 35 a min (50,000 ⁄ 1440 min⁄day). A recent test of CoCCAʹs SRS software on a single 8GB cloud server revealed that the pamoja software was able to process 4 million unique EPP registrations in a little over 5 hours. Performance tests can be designed in any number of ways, real world performance depends on a variety of factors- the specific policy and account settings for a given zone.

In terms of both transactional capability and storage, todayʹs ʺoff the rackʺ hardware and the open source PostgreSQL database used by CoCCA can easily cope with demands that a small to medium sized registry is ever likely to make on an SRS system. While the CoCCA SRS EPP and WHOIS infrastructure and platform may seem comparatively modest, a decade of experience confirms it is more than capable of meeting ICANNʹs gTLD SLA requirements and complies with the required RFCʹs.

If future demands require it, CoCCAʹs SRS can easily (and affordably) be scaled by adding additional load balanced application servers and bandwidth.

24.2 SRS | High Level Description

Comprehensive information on and descriptions of the CoCCA SRS and NOC may be found the answers to questions 25-42 that follow.

24.2.1 SRS Infrastructure ⁄ Architecture

The following describes the key features of CoCCAʹs current production SRS that will be utilized for the .WED TLD:

* Primary SRS is operated from Global Switch, a tier 3 + facility and one of the largest carrier-neutral data centers in the Southern Hemisphere.
http:⁄⁄www.globalswitch.com⁄en⁄locations⁄sydney-data-center

* Redundant links to the Internet through PIPE networks and Telstra.
http:⁄⁄www.pipenetworks.com⁄
http:⁄⁄www.telstra.com.au⁄

* DNSSEC Key storage (offline) in Singapore at a PCH facility hosted by the National University of Singapore, on behalf of the Singaporean Infocomm Development Agency (IDA). Failover storage at a facility is hosted in Zurich by SWITCH, the Swiss national research and education network and in the U.S. by Equinix in San Jose.

* .WED zones signed by PCH in Frankfurt or Palo Alto.

* SRS Escrow at tier three co-location facility (Magnet) in Auckland NZ and Failover at a tier four facility (Equinix) supported by PCH in Palo Alto, CA US. A fourth SRS ʺinstanceʺ is planned for Paris in early 2013.

* Dedicated, routable CoCCA Critical Infrastructure IPv4 and IPv6 address blocks.
IPv4 resources: 203.119.84.0⁄24 (crit-infra)
IPv6 resources: 2001:dd8:3::⁄48 (crit-infra)

* Routers, Firewalls, Switches and Load balancers all configured for failover.

* CoCCAʹs pamoja SRS application load balanced and configured for failover.

* PostgesSQL 9.1.3 database replicated synchronously to two secondary DB servers.

* DS Keys lodged by registrars via EPP or the CoCCA SRS GUI.

* Servers Virtualized (VMware vsphere v5).

* VM image-based replication for high availability and off-site disaster recovery. http:⁄⁄www.veeam.com⁄vmware-esx-backup.html

* Critical Data continuously replicated asynchronously to two off-site SRS instances - PCH, Equinix Palo Alto CA (pch.net) and CoCCA Data Escrow (NZ) Limited, Auckland NZ (maxnet.co.nz).

* OT&E Environment for Registrars.

* Primary and Secondary hidden master DNS ( failover masters ).

* CoCCA operated unicast DNS in Sydney Australia and Auckland New Zealand.

* Two anycast solutions operated by PCH and ISC - over 80 DNS nodes.

24.2.2 Specification 6, Section 1.2 Compliance

The .WED TLD will be added to CoCCAʹs production SRS that currently hosts 12 ccTLDs under a single RFC 5730-5743, RFC 5910 and 3915 compliant EPP interface.

A list of the Registrars that currently connect to the CoCCA SRS for one or more ccTLDs is attached.

24.3 EPP Interface

The port 700 EPP interface for .WED will listen on the same IP and port as the EPP server for the other TLDs hosted by CoCCA - currently ʺproduction.coccaregistry.net:700ʺ. On launch the production EPP interface for .WED will be branded as epp.nic.WED.

24.4 WHOIS Interface (port 43 and 443)

The WHOIS Interface(s) for .WED will listen on the same IP and port as the WHOIS server for the ccTLDs and prospective gTLDs to be hosted by CoCCA - currently ʺwhois.coccaregistry.net:43⁄443ʺ. On launch the interface for .WED will be branded as ʺwhois.nic.WEDʺ. Each TLD ( ccTLD⁄ gTLD ) in the CoCCA SRS may have different WHOIS disclosure settings based on the TLD policy. The .WED TLD will comply with the ICANN gTLD disclosure requirements.

24.5 GUI Interface (port 443)

The GUI Interface for .WED will listen on the same IP and port as the GUI server for ccTLDs and prospective gTLDs to be hosted by CoCCA - currently https:⁄⁄production.coccaregistry.net:443. On launch, the interface for .WED will be branded as ʺregistry.nic.WEDʺ.

24.6 Hidden Master DNS (s) (port 53)

There are two hidden master servers. CoCCA will transfer the .WED zone from the ʺsignature masterʺ to PCH for DNSSEC signature using TSIG IXFR ⁄ AXFR and IP restrictions at the OS and firewall level. PCH will sign the Zone and transfer it back to CoCCA using TSIG and IXFER⁄ AXFER. CoCCA will then load the zone on a second ʺdistribution masterʺ which allows distribution to the PCH and ISC anycast transfer points and the CoCCA unicast DNS servers.

24.7 CoCCA Public Unicast DNS

DNS servers on virtual machines running BIND in the Sydney NOC and NZ SRS will pull and resolve the .WED TLD zones.

24.8 Public anycast DNS

CoCCAʹs distribution master notifies the anycast providers (PCH and ISC) and .WED TLD zones are transferred to the respective providerʹs transfer point IPs (hidden IPS for DNS transfers only) using TSIG IXFER ⁄ AXFR and then propagated by PCH and ISC across their respective anycast networks.

24.9 ftp Server

Server to distribute zone files as required under Specification 4, Section 2.

24.10 Escrow Server

Server used to deposit TLD data with NCC and transfer data to CoCCAʹs Failover and Escrow SRS. Uses Secondary IP range.

24.11 Number of Servers

There are seven physical server appliances in the Sydney NOC configured such that they host 17 virtual machines.

24.12 High Availability (HA) Configuration

The Sydney NOCʹs network appliances are configured for failover and HA in either hot or warm standby mode. The PostgreSQL databases are locally replicated using 9.1.3ʹs synchronous replication and asynchronously over the WAN to the Failover facilities. The status of the local and off-site replication is continuously monitored by the CoCCA NOC. CoCCA also ships WAL files so that in the event of an extended WAN outage, the offsite SRS can be updated using Point in Time Recovery (PITR).

RDDS and EPP services are load balanced between two different application servers at the primary SRS (more application servers can easily be added). Public read-only RDDS may also be load balanced by simply having the nagios monitoring software automatically modify resource records and send traffic to either of the secondary ⁄ failover SRSʹs for near-real time WHOIS. When the primary becomes available or SLA issues (DoS etc) are resolved, RDDS services are automatically switched back to the primary SRS.

The public IPs at the NOC used for EPP, WHOIS and GUI are on routable critical infrastructure ranges assigned to CoCCA by APNIC. In the event of an issue with the primary Internet link at the Sydney NOC (PIPE networks) CoCCA may either modify A and AAA records for GUI ⁄ RDDS and EPP services to the local failover link, or the entire IP range can be re-routed using BGP routing to a COCCA failover SRS. If the entire Sydney NOC suffers an extended outage, the traffic can be routed to the failover SRS (Palo Alto) or Escrow SRS (Auckland) as conditions dictate by either modification of resource records (A, cname) or BGP of the AS.

VMware images of all virtual machines are made daily using Veeam Backup & Replication software.

In addition to streaming replication, SRS data is sent to CoCCAʹs failover SRS and Escrow sites every 10 minutes (or sooner depending on activity) via SCP in the form of postgresql PITR files, and daily in the form of compressed database dumps and vm images.

Similar gTLD applications: (0)