24 Shared Registration System (SRS) Performance

Prototypical answer:

24 SRS Performance

All core registry services for .amsterdam will be provided by .amsterdam’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD.

The Shared Registration System for .amsterdam is cloned from SIDN’s registration system for .NL and offers an EPP-interface and a web interface. Both interfaces are available to all accredited registrars and offer the same functionality.

Access to the SRS for both interfaces is restricted to registrars through a username and password and connections are only allowed for registered networks (IP-whitelisting). The web interface is secured by HTTPS. The EPP interface uses TLS for encryption of the transport layer.

Both interfaces are available through IPv6 and the SRS supports IPv6 AAAA Resource Records in all relevant information fields.

The EPP interface is based on the following standards:
- Guidelines for Extending the Extensible Provisioning Protocol (EPP) - RFC3735 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3735.txt),
- Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) – RFC 3915 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3915.txt),
- Extensible Provisioning Protocol (EPP) - RFC5730 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5730.txt),
- Extensible Provisioning Protocol (EPP) Domain Name Mapping - RFC5731 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5731.txt),
- Extensible Provisioning Protocol (EPP) Host Mapping - RFC5732 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5732.txt),
- Extensible Provisioning Protocol (EPP) Contact Mapping - RFC5733 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5733.txt),
- Extensible Provisioning Protocol (EPP) Transport over TCP - RFC5734 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5734.txt) and
- Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) - RFC5910 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5910.txt)

The EPP interface maximizes the amount of simultaneous connections per registrar to eight. Only SIDN-authorized networks⁄interfaces can connect to the EPP interface. Connections will be closed:
- After being idle for 10 minutes;
- After being open for 24 consecutive hours;
- Upon receiving a ‘logout’ command.

Per session, multiple XML forms may be sent (containing one command per form, pipelining not possible). EPP commands are processed by the SRS in the sequence in which they are received. All commands are executed immediately and an immediate response containing the execution result is returned.
For more information regarding EPP, please see the answer provided to Evaluation Question #25 ‘EPP’.

The Shared Registry System is an in-house developed system. Software updates and releases are subject to the Change Management Process, which is based on ITIL (see the answers provided to Evaluation Question #30 ‘Security Policy’ for more details).

Quality of software is controlled through external auditing by SIG (Software Improvement Group - http:⁄⁄www.sig.eu⁄en). The SRS application (DRS 5.0) is certified with 4 stars out of 5 on maintainability by SIG⁄Tüvit (see attachment ‘Q24-Tuvit’).

SIDN deploys a fully redundant infrastructure. All systems supporting registry services (with the exception of the public DNS services) are located at two geographically separated production sites that together form one logical network.
Both data centres hosting the production locations are certified and offer high quality security and support services. For a more detailed description, please see the answers provided to Evaluation Question #34 ‘Geographic Diversity’.
Contracts with both data centre providers are available and added as an attachment to Evaluation Question #39 ‘Registry Continuity’.

Although these locations are marked as ‘primary’ and ‘secondary’, there is no active⁄passive location setup. Both locations provide active services and have accurate (mirrored) data. All registration data in use by registry services is maintained in a database that is synchronized over both production locations. At both locations an additional standby database is present. This makes it possible to switch between locations without loss of data for committed transactions. Both production sites have active systems for all applications needed to provide SRS and WHOIS-services and the hidden primary name server. With this setup, the Recovery Point Objective for registry services is negligible.
Testing for recovery of services is done at least once a year. During the last test SIDN performed, the recovery time for all registry services was less than 10 minutes. This is far below the required Recovery Time Objective of 4 hours.

Both production locations are connected through a Dense Wavelength Division Multiplexing (DWDM) based dark fibre ring, owned and operated by SIDN. This fibre ring is designed so that fibres never share the same physical path or the same duct. This setup provides the locations with active connections, even in the event of a fibre cut. Connectivity to the internet is also set up redundantly, through multiple connections and via different network operators, both commercial and non-commercial. These connections are terminated on separate routers and geographically separated locations. Furthermore all network equipment is fully redundant. This applies to routers, switches, firewalls and load balancers and even network interface cards in a number of servers (by means of link aggregation aka bonding or ‘NIC teaming’).

Bottlenecks in the systems-design and –infrastructure are avoided by making sure that there is always a surplus in capacity, calculated over peak-times and monitored on a constant basis. This is handled by the ITIL ‘capacity management process’ (see answers provided to Evaluation Question #30 ‘Security Policy’ for more information).
Our Test Department conducts load- and performance tests regularly on software that is developed or in use, in order to detect issues early on. The standards for these tests are set quite high. Soft- and hardware will not pass the testing, if it is not able to deal with multiple times the load that is expected to have under predicted peak-conditions. Trend analysis is performed on all systems to support these predictions.
In the exceptional event of needing to handle unusual large amounts of traffic, systems for traffic-shaping are present. Traffic-shaping provides the abilities to cut off or limit access to specific abusive users, while keeping the services available for others.

Diagrams depicting SRS systems are enclosed in the attachment ‘Q24-SRSdiagrams’ and include:
- Production location diagram ⁄ access layer
- Registry Application Server Diagram
- Registry Services Systems

The SRS is based on diskless Linux systems, with separate storage servers containing the file systems. Management of the database file systems on the storage layer is done by Oracle Enterprise Manager⁄Grid Control (http:⁄⁄www.oracle.com⁄us⁄products⁄enterprise-manager⁄index.html). One of both locations runs the primary database. All mutations on the primary database are directly shipped to all standby databases. Every transaction that is committed on the primary database is secured on the standby database. Therefore no committed data can ever be lost in a disaster scenario where the primary database gets lost.
Both production locations contain additional standby databases, configured with fast-start failover, available for production. One standby database is used as the current standby database for production; the other one is used for cloning of a production database in order to investigate incidents that require a database with production data in it. In case of a server malfunction, it’s easy to switch over to a standby database. However, this is no resolution for data corruption. Therefor a daily backup is made of the production databases. This backup is copied to the central backup server and put on tape.
Database replication puts high demands on network latency and packet-loss. The dark fibre ring and the selection of the locations for our data centres allow for extremely short round-trip times, often less than 1 ms and generally not above 5 ms. Packet-loss baselines are set to 0% for ‘normal’ operations and cannot exceed 1%. Exceeding of this threshold leads to closer investigation via the ‘Incident Management Process’ (see answers provided to Evaluation Question #30 ‘Security Policy’ for details on this process).
Monitoring of the connections to the public internet depend on network-distances and show round-trip times well below 300 ms in general. Packet-loss for public internet connections is very low as well, way below 10%, due to carefully selected network-operators and tight monitoring.

SIDN is researching cost-efficient alternatives for the current Oracle database management system setup. Requirements for any alternative solution include matching of all functionalities and service levels for database management and reporting capabilities as described in the answers to the Evaluation Questions. If a feasible solution is found and tested, it will be implemented for .amsterdam’s registry services. Details of such implementation will be available to ICANN for evaluation and testing before implementation.

Currently, SIDN operates SRS services for .NL that are well in range of the SLA’s described in Specification 10 of the Base Agreement. Measurements based upon the definitions in this Specification show the following performance for current SRS services:

EPP Service availability
- SL SIDN: 99,955% (Q4 2011)
- SLR Specification 10: 〈= 864 min of downtime (˜ 98%)
EPP session command RTT
- SL SIDN: 〈= 360 ms, for at least 90% of the commands
- SLR Specification 10: 〈= 4000 ms, for at least 90% of the commands
EPP query command RTT
- SL SIDN: 〈= 350 ms, for at least 90% of the commands
- SLR Specification 10: 〈= 2000 ms, for at least 90% of the commands
EPP transform command RTT
- SL SIDN: 〈= 750 ms, for at least 90% of the commands
- SLR Specification 10: 〈= 4000 ms, for at least 90% of the commands

Performance for SRS services for .amsterdam will be in line with current performances for .NL.

Resources
SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed, most of them entirely dedicated to .nl services. As back end registry operator of .amsterdam SIDN will provide all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.

For the services to .amsterdam the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.

SIDN therefore has all necessary resources on hand to provide all services described in this answer.

Similar gTLD applications: (2)