gTLD	Full Legal Name	E-mail suffix	Detail
.boston	The Boston Globe Newspaper Company Inc.	boston.com	View

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.

gTLD	Full Legal Name	E-mail suffix	Detail
.LTD	C.V. TLDcare	tvision.nl	View

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.