Back

24 Shared Registration System (SRS) Performance

gTLDFull Legal NameE-mail suffixDetail
.bostonThe Boston Globe Newspaper Company Inc.boston.comView
1. Overview
The Shared Registration System (SRS) is a computer system for managing a domain name Registry, and allows for the registration, by authorized Registrars, of domain names and modification of information associated with that domain name on the Registry level.
The SRS has two matching subsystems: an Extensible Provisioning Protocol (EPP) server and a Registrar web interface.

2. High-Level SRS System Description

2.1. Infrastructure
The SRS platform consists of several services. These services provide the Registrar with access to the database. Registrarʹs access is limited to objects created and maintained by the Registrar. No other means than the SRS are provided to the Registrar to modify objects. The SRS system runs on a virtualized and strictly separated infrastructure to maintain consistency and security and provide for scalability and availability. For more information, reference is made to the relevant sections in question 31 (Technical Overview of the Proposed Registry), question 32 (System & Network Architecture) and Q33 (Database Capabilities).

2.2. Extensible Provisioning Protocol
As required by Specification 6 (section 1.2) and as detailed in the answer on Question 25 on the Extensible Provisioning Protocol (EPP), the Registry Operator will comply with the relevant existing RFCs. The Registry Operator will also, if applicable, implement the relevant RFCs published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in compliance with RFCs 5910, 5730, 5731, 5732, 5733 and 5734.
Extensive testing will verify that the software performs according to the performance specifications as required by Specification 10 for EPP.
The response to question 25 provides full details on the EPP implementation.

2.2.1. Security
Access to the EPP server system is restricted in three ways:
1) Access control to the production EPP server is restricted by IP address filters;
2) SSL encryption is required for the communication channels between the Registrarʹs client system and the OT&E (Operation Test & Evaluation) and Production EPP servers;
3) Authentication by means of a user name and a strong password is required for session establishment.
The EPP server requires that all three mechanisms must be correctly adhered to before access is granted.
The IP addresses from which the Registrar wants to connect to the EPP server must be registered through the Registrar web interface (maximum 5 IP addresses per Registrar, subject to evaluation).

2.3. Registrar Web Interface
The Registry Operator will, in addition to the EPP server system, also run a Registrar web interface. This web interface can be used besides or instead of the EPP server interface to manage the registration and modifications of domain names and the information associated with those names.
The web interface has two parts: managing the objects in the domain name Registry database, and managing the Registrarʹs business account information.

2.3.1. Managing Objects in the domain name Registry Database
The management of the objects in the database via the web interface is based on the same software code as for the EPP server implementation. The different subparts of managing the objects in the database are: maintaining domain names, maintaining contacts and maintaining hosts.
1) Maintain Domain: The interface allows to easily find, check, query, add, update, renew, transfer or delete domain names from the Registrar account. As an extra feature, the history of the domain name can be explored (if the domain name resides in the Registrarʹs account).
2) Maintain Contact: The interface allows to easily find, check, query, add, update or delete contact information. Also the history of the contact can be listed (if the contact stays in the Registrarʹs account).
3) Maintain Host: The interface allows to simply find, check, query, add, update or delete host information from the Registrar account. Also the history of the host object can be viewed (if the host object is in the Registrarʹs account).

2.3.2. Managing the Registrar Account
The Registrar Profile page allows the Registrar to
1) View, add and update own contact information for administrative, technical, commercial and financial purposes;
2) Add and update the IP addresses required for access to the EPP server (see above);
3) Add and update the different email addresses of the Registrar where he can be reached by the Registry Operator for administrative, technical and financial purposes;
4) View hitpoints (attributed when the EPP client software behaves erratically), and resume the Registrar account (when hitpoints reach a defined threshold, the Registrar account is suspended temporarily).
The financial information pages reveals
1) Account balance overview;
2) Overview of invoices and payments, with details;
3) Overview of possible renewals in coming months.
The reports page provides customized reports on gained and lost domain names (via transfers), on nearly expired domain names and on the latest transactions (per object type and transaction type).
The export page offers downloads of full exports of contacts, domain names and hosts in different formats (CSV, XLS, XML), to allow the Registrar to consolidate and cross-check his own data.

2.3.3. Security
Access to the Registrar web interface is restricted in three ways:
1) HTTPS encryption is required for the communication between the Registrar and the OT&E and production Registrar web interfaces;
2) Authentication by means of a user name and password is required;
3) Extra passphrase authorization to confirm transactional commands (create⁄modify⁄delete).
All communication is encrypted and secured using the SSL⁄TLS protocol. The main idea of HTTPS is to create a secure channel over an insecure network. Adding a trusted and verified server certificate ensures reasonable protection from eavesdroppers and man-in-the-middle attacks.
Security is augmented by requiring an extra passphrase authorization to complete all transactional commands on the SRS system.

2.3.4. Redundancy & Scalability
The SRS system runs on a mini-cloud virtualizing all machine infrastructures needed (for further information on, for instance the number of servers, see question 32). Not only does this improve high-availability and scalability, it also allows for very fine grained access control improving security and mitigating network cross connections. The cloud can be distributed over the two sites allowing for a full hot-standby mirror site. Using network based traffic mirroring, resources are scaled and load balancing and fail-over are implemented.
The synchronization scheme for the Registry database, which contains all information used by the Shared Registration System, is described in full detail in the response to question 33 (Database Capabilities). The database is continuously synchronized.
Dynamic updates are implemented on the nameserver infrastructure. All changes to the database are immediately synchronized to the worldwide nameserver infrastructure, with an average delay of 10 seconds.

3. Resourcing Plan

3.1. Technical Resources

3.1.1. Network
The Registry Platform is based on a full redundant network setup, based on different technologies that together form a reliable setup. The network setup is greatly detailed in the answer on Question 32 on Network & System Architecture, and consists of:
1) Multi-homed network with own IP-range and Autonomous System number (AS) announce via Border Gate Protocol (BGP);
2) Redundant routers and firewalls;
3) Fully redundant internal network for interconnection between the Registry Services.
Network security measures include:
1) Traffic shaping (on SYN packets) on the routers to minimize impact of (Distributed) Denial Of Service attacks;
2) Stateful firewall to limit access to service ports only;
3) Limiting source IP addresses per Registrar to connect to EPP server system;
4) Network separation using VLAN (IEEE802.1q) technology to separate service and data plane;
5) Private firewall on every server.

3.1.2. Servers
The EPP server and the Registrar web interface are running on their own respective machines. Virtualization is used to make the service machines independent of the underlying hardware.

3.1.3. Interconnectivity with other Registry Services
The Shared Registration System (SRS) maintains the objects in the core database from a Registrarʹs perspective. All other Registry systems such as the WHOIS service, the data escrow system, the (dynamic) zone file generator,... all use the core database.
The Registry Operator implements a thick Registry model, and as such the full data are present in the core database. There is no need to synchronize the data from different source databases into the master database.
As detailed in the answer on Question 33 on Database Capabilities, the Registry Operator is using hot-standby database replication for redundancy and fail-over, and if the load on the system should require so, the WHOIS system can be off-loaded to another hot-standby read-only copy of the core database, which is near-synchronous with the main database.
Note that the network and system setup on the primary site is duplicated on a mirror site.
(View attachment for Figure 1: Interplay of Registry Services)
Other services such as the dynamic updates of the zone file, zone file generation and escrow use the database or a trigger mechanism to update the relevant resources when the Registrar updates objects in the database.
All changes to the database are tagged and linked to a transaction description also specifying the relevant time stamp, user and IP address. The information can be used to provide a full audit trail or to pinpoint invalid or illegal behavior.

3.2. Personnel
With regards to resourcing, reference is made to the global resourcing scheme as part of response to Question 31 (Technical Overview of the Proposed Registry). Implementation and maintenance of the Shared Registration System is under the authority of the Software Developer, under control of the Operations Manager. The technical infrastructure is implemented and maintained by the Network & System Administrator.
gTLDFull Legal NameE-mail suffixDetail
.medHEXAP SAShexap.comView
1. OVERVIEW

The Shared Registration System (SRS) is a computer system for managing a
domain name Registry, and allows for the registration, by authorized
Registrars, of domain names and modification of information associated with
that domain name on the Registry level.

The SRS has two matching subsystems: an Extensible Provisioning Protocol
(EPP) server and a Registrar web interface.

2. HIGH-LEVEL SRS SYSTEM DESCRIPTION

2.1. INFRASTRUCTURE

The SRS platform consists of several services. These services provide the
Registrar with access to the database. Registrarʹs access is limited to
objects created and maintained by the Registrar. No other means than the SRS
are provided to the Registrar to modify objects. The SRS system runs on a
virtualized and strictly separated infrastructure to maintain consistency
and security and provide for scalability and availability. For more
information, reference is made to the relevant sections in question 31
(Technical Overview of the Proposed Registry), question 32 (System & Network
Architecture) and Q33 (Database Capabilities).

2.2. EXTENSIBLE PROVISIONING PROTOCOL

As required by Specification 6 (section 1.2) and as detailed in the answer
on Question 25 on the Extensible Provisioning Protocol (EPP), the Registry
Operator will comply with the relevant existing RFCs. The Registry Operator
will also, if applicable, implement the relevant RFCs published in the
future by the Internet Engineering Task Force (IETF) including all successor
standards, modifications or additions thereto relating to the provisioning
and management of domain names using the Extensible Provisioning Protocol
(EPP) in compliance with RFCs 5910, 5730, 5731, 5732, 5733 and 5734.

Extensive testing will verify that the software performs according to the
performance specifications as required by Specification 10 for EPP.

The response to question 25 provides full details on the EPP implementation.

2.2.1. SECURITY

Access to the EPP server system is restricted in three ways:

- Access control to the production EPP server is restricted by IP address
filters;

- SSL encryption is required for the communication channels between the
Registrarʹs client system and the OT&E (Operation Test & Evaluation) and
Production EPP servers;

- Authentication by means of a user name and a strong password is required
for session establishment.

The EPP server requires that all three mechanisms must be correctly adhered
to before access is granted.

The IP addresses from which the Registrar wants to connect to the EPP server
must be registered through the Registrar web interface (maximum 5 IP
addresses per Registrar, subject to evaluation).

2.3. REGISTRAR WEB INTERFACE

The Registry Operator will, in addition to the EPP server system, also run a
Registrar web interface. This web interface can be used besides or instead
of the EPP server interface to manage the registration and modifications of
domain names and the information associated with those names.

The web interface has two parts: managing the objects in the domain name
Registry database, and managing the Registrarʹs business account
information.

2.3.1. MANAGING OBJECTS IN THE DOMAIN NAME REGISTRY DATABASE

The management of the objects in the database via the web interface is based
on the same software code as for the EPP server implementation. The
different subparts of managing the objects in the database are: maintaining
domain names, maintaining contacts and maintaining hosts.

- Maintain Domain: The interface allows to easily find, check, query, add,
update, renew, transfer or delete domain names from the Registrar account.
As an extra feature, the history of the domain name can be explored (as
long as the domain name resides in the Registrarʹs account).

- Maintain Contact: The interface allows to easily find, check, query, add,
update or delete contact information. Also the history of the contact can
be listed (as long as the contact stays in the Registrarʹs account).

- Maintain Host: The interface allows to simply find, check, query, add,
update or delete host information from the Registrar account. Also the
history of the host object can be viewed (as long as the host object is in
the Registrarʹs account).

2.3.2. MANAGING THE REGISTRAR ACCOUNT

The Registrar Profile page allows the Registrar to:

- View, add and update own contact information for administrative,
technical, commercial and financial purposes;

- Add and update the IP addresses required for access to the EPP server (see
above);

- Add and update the different email addresses of the Registrar where he can
be reached by the Registry Operator for administrative, technical and
financial purposes; and

- View hitpoints (attributed when the EPP client software behaves
erratically), and resume the Registrar account (when hitpoints reach a
defined threshold, the Registrar account is suspended temporarily).

The financial information pages reveals:

- Account balance overview;

- Overview of invoices and payments, with details;

- Overview of possible renewals in coming months.

The reports page provides customized reports on gained and lost domain names
(via transfers), on nearly expired domain names and on the latest
transactions (per object type and transaction type).

The export page offers downloads of full exports of contacts, domain names
and hosts in different formats (CSV, XLS, XML), to allow the Registrar to
consolidate and cross-check his own data.

2.3.3. SECURITY

Access to the Registrar web interface is restricted in three ways:

- HTTPS encryption is required for the communication between the Registrar
and the OT&E and production Registrar web interfaces;

- Authentication by means of a user name and password is required; and

- Extra passphrase authorization to confirm transactional commands
(create⁄modify⁄delete).

All communication is encrypted and secured using the SSL⁄TLS protocol. The
main idea of HTTPS is to create a secure channel over an insecure network.
Adding a trusted and verified server certificate ensures reasonable
protection from eavesdroppers and man-in-the-middle attacks.

Security is augmented by requiring an extra passphrase authorization to
complete all transactional commands on the SRS system.

2.3.4. REDUNDANCY & SCALABILITY

The SRS system runs on a mini-cloud virtualizing all machine infrastructures
needed (for further information on, for instance the number of servers, see
question 32). Not only does this improve high-availability and scalability,
it also allows for very fine grained access control improving security and
mitigating network cross connections. The cloud can be distributed over the
two sites allowing for a full hot-standby mirror site. Using network based
traffic mirroring, resources are scaled and load balancing and fail-over are
implemented.

The synchronization scheme for the Registry database, which contains all
information used by the Shared Registration System, is described in full
detail in the response to question 33 (Database Capabilities). The database
is continuously synchronized.

Dynamic updates are implemented on the nameserver infrastructure. All
changes to the database are immediately synchronized to the worldwide
nameserver infrastructure, with an average delay of 10 seconds.

3. RESOURCING PLAN

3.1. TECHNICAL RESOURCES

3.1.1. NETWORK

The Registry Platform is based on a full redundant network setup, based on
different technologies that together form a reliable setup. The network
setup is greatly detailed in the answer on Question 32 on Network & System
Architecture, and consists of:

- Multi-homed network with own IP-range and Autonomous System number (AS)
announce via Border Gate Protocol (BGP);

- Redundant routers and firewalls;

- Fully redundant internal network for interconnection between the Registry
Services.

- Network security measures include:

- Traffic shaping (on SYN packets) on the routers to minimize impact of
(Distributed) Denial Of Service attacks;

- Stateful firewall to limit access to service ports only;

- Limiting source IP addresses per Registrar to connect to EPP server
system;

- Network separation using VLAN (IEEE802.1q) technology to separate service
and data plane;

- Private firewall on every server.

3.1.2. SERVERS

The EPP server and the Registrar web interface are running on their own
respective machines. Virtualization is used to make the service machines
independent of the underlying hardware.

3.1.3. INTERCONNECTIVITY WITH OTHER REGISTRY SERVICES

The Shared Registration System (SRS) maintains the objects in the core
database from a Registrarʹs perspective. All other Registry systems such as
the WHOIS service, the data escrow system, the (dynamic) zone file
generator, etc. use the core database.

The Registry Operator implements a thick Registry model, and as such the
full data are present in the core database. There is no need to synchronize
the data from different source databases into the master database.

As detailed in the answer on Question 33 on Database Capabilities, the
Registry Operator is using hot-standby database replication for redundancy
and fail-over, and if the load on the system should require so, the WHOIS
system can be off-loaded to another hot-standby read-only copy of the core
database, which is near-synchronous with the main database.

Note that the network and system setup on the primary site is duplicated on
a mirror site.

(View attachment for Figure 1: Interplay of Registry Services)

Other services such as the dynamic updates of the zone file, zone file
generation and escrow use the database or a trigger mechanism to update the
relevant resources when the Registrar updates objects in the database.

All changes to the database are tagged and linked to a transaction
description also specifying the relevant time stamp, user and IP address.
The information can be used to provide a full audit trail or to pinpoint
invalid or illegal behavior.

3.2. PERSONNEL

With regards to resourcing, reference is made to the global resourcing
scheme as part of response to Question 31 (Technical Overview of the
Proposed Registry). Implementation and maintenance of the Shared
Registration System is under the authority of the Software Developer, under
control of the Operations Manager. The technical infrastructure is
implemented and maintained by the Network & System Administrator.