Back

24 Shared Registration System (SRS) Performance

gTLDFull Legal NameE-mail suffixDetail
.RIPdotRIP LIMITEDrodenbaugh.comView
The KSregistry (KSR) system is a domain registry system capable of registering domain names managed by multiple registrars. In addition to the SRS system, KSR provides RFC conforming interfaces for EPP, RDDS (WHOIS), DNS, and DNSSEC. KSR is capable of running any IDN string as well as IPv6. KSR uses recognized and proven technologies such as MySQL database software and BIND DNS servers, as well as industry standard backup and monitoring solutions.

KSR uses a thick registry model wherein all contact details are stored in a central location by the registry. All services are set up as a fully redundant solution (n+1). Additionally, there are two geographically separate data centers (Tier 3, all components are available at least n+1), one active and one which is designed to function as a warm-standby solution to ensure a maximum of data security and business continuity. All SRS and DNS related information is replicated in real-time between the data centers.

KSRʹs modular design allows for quick and easy installation or removal of system components at any time. This ensures KSRʹs ability to react to any business needs or system loads in an appropriate manner at all times.

KSR is managed by trained personnel only. Its operations follow well-defined business and security processes which are based on the ITILv3 standard and in accordance with ISO 27001.

KSR has a NOC and support team available at two different locations (St. Ingbert, Germany and Munich, Germany) which allows 24 x 7 x 365 monitoring of all systems and provides customers with an easy way to reach KSR personnel regarding any issue they may have.

The SRS is protected against unauthorized access. Data integrity is ensured by both physical and software security and protection mechanisms.
All these measures together are the basis for running a robust and reliable SRS and are in compliance with Specification 6 and 10.


A. Detailed KSR Description

The following section refers to attachment Q24_Figure1.pdf.

Figure 1 contains a high level functional overview of all KSR components which are described below. All described services and functions are in compliance with Specification 6 and 10 based on their design and setup.

For all of the services listed below the following applies:

The application servers (e.g. EPP, DNS, and RDDS) are set up as a cluster to guarantee a high-availability solution. The sizing of the servers and the databases are calculated to meet the needs of each business case. Additionally, the system is set up to be scalable so that an increase of domains or registrars can be easily handled by installing additional hardware as needed.


A.1 Services Integrated into KSR

Domain Name System (DNS)

The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, and any other resource connected to the Internet or a private network. The registry will be set up with a mix of anycast and unicast name servers. This service is provided by an external provider called PCH.NET which has over 10 years of experience in this area. This partnership with PCH.NET ensures a 100% guaranteed uptime of the service and worldwide DNS coverage. DNS and zone file creation is performed periodically (every 15 minutes), uploaded to the primary hidden master name server, and spread to the anycast clouds (PCH.NET) within 180 seconds. The communication between the primary hidden master name server and the DNS cloud is facilitated by zone transfer {AXFR (Asynchronous Full Transfer Zone)⁄IXFR (Incremental Zone Transfer)} to the worldwide anycast net.

DNS Security Extensions (DNSSEC)

DNSSEC adds security to the Domain Name System. DNSSEC helps in preventing cache poisoning or man in the middle attacks. This helps to protect usersʹ personal and⁄or financial information from being compromised on the Internet. This additional security helps in protecting end users and the reputation of brands.

Extensible Provisioning Protocol (EPP)

The EPP gives registrars the ability to fully automate the management of their domain names. KSR uses EPP as a protocol for registering and managing domain names in a very standardized way. KSR is in compliance with RFCs 3735 and 5730-5734 as well as with Specifications 6 and 10 of the registry agreement. EPP compliance is ensured by technical validation (XML validator) and through the change management process which includes a quality assurance program.

Web Interface

The web interface provides the registrars the ability to manage their domain names through a comfortable user interface and grants access to reports and accounting information.

RDDS (WHOIS)

The Whois is a data directory service which grants public free access regarding domain information. The RDDS (WHOIS) service is provided as a web-based directory service via port 43 in accordance with RFC 3912. This service provides different information depending on the request. The data this will offer includes, but is not limited to:

- Domain name
- Address information on the registrant, administration-, technical-, and billing contacts.
- IP addresses of the name servers
- The identity of the registrar
- Domain creation and expiration dates

There will be a searchable Whois accessible via the web interface. This service will only be available to registrars in respect to confidential data. In order to prevent any abuse of the provided data, additional limitations on the service include IP-based limitations and masking of critical customer data.

SFTP ⁄ SCP Access to the File Store

The SFTP area grants access to all reports which are available in the KSR. Communication is only possible over an encrypted connection, such as with SFTP or SSH, protecting registrars from unauthorized access to their data. In addition to command line access, KSR offers access through the https-based web interface.

Escrow

KSR generates two types of deposits: full and differential. The escrow data provides all SRS-related information to an escrow agent as required for running a registry in compliance with the approved registry services.

The escrow file is generated in compliance with the format specifications as described in Specification 2. The file will be transferred (SFTP) to the escrow agent as a compressed (ZIP RFC 4880) and encrypted file.

KSR is working with the escrow agent NCC Group.

The required data for generating the deposits are always stored in both data centers at all times. This enables the KSR to generate these files even in disaster scenarios.

Reports

The KSR system generates all ICANN reports on a monthly, weekly, or daily basis. In addition to the ICANN related reports, reports for the registrars are created which contain invoicing and domain portfolio information:

- Per-registrar transactions report (Specification 3)
- Registry functions activity report (Specification 3)
- Up-to-date registration data (escrow format as described in Specification 2)
- Thick registration data in case of a registrar failure, de-accreditation, court order, etc. (escrow format as described in Specification 2)
- Technical and operational reports describing performance specifications (Specification 10)
- Registrar based domain and contact reports
- Monthly invoicing reports
- Name server reports
- Data escrow (full and differential as required in Specification 2)


Internationalized Domain Name (IDN)

An IDN is an internet domain name that contains at least one label that is displayed in software applications, in whole or in part, in a language-specific script or alphabet.

KSR has fully integrated IDNs in the SRS and related DNS, DNSSEC, RDDS (WHOIS), and EPP services. The domain registration must be submitted in PUNY code (ascii-encoding) with the appropriate language tag. There is no different handling or billing between the IDN and ASCII domains.


B. Network Diagram

See attached fig. 2 in Q32_Figure1.pdf for the detailed network overview.

B.1 Hardware (Number of Servers)

Network Components:

- Two (2) or more firewalls (Vyatta) (load balanced) Vyatta 6.3
- Two (2) or more network switches frontend (Juniper), EX2200, EX4200
- Two (2) or more network switches transfer (Juniper), EX2200, EX4200
- Two (2) or more network switches backnet (Juniper), EX2200, EX4200
- Two (2) or more load balancer (Keepalived) and SUSE Linux Enterprise High Availability Extension

B.2 Server Components

Typical components for all servers:

Server: IBM compatible Linux server
Processor: INTEL 64bit multicore CPU
Memory: Up to 64 GB ECC DDR2 RAM modules
Disk: Internal RAID 5 for operating system and software, additional intern RAID 5 for data, iSCSI support
Network Adapter: Average 4 100⁄1000 mbit network interface

- Two (2) or more webservers for the web interface (load balanced)
- Two (2) or more EPP server (load balanced)
- Two (2) or more RDDS (WHOIS) servers (load balanced)
- Two (2) or more SFTP servers (load balanced)
- Two (2) or more tools servers (cron, batch) (n+1 redundant with failover)
- Two (2) or more database servers (load balanced)
- Two (2) or more storage servers (load balanced)
- One (1) BIND hidden master
- One (1) Generator
- One (1) Signer ⁄ HSM

Full detailed hardware description can be found in attached fig. Q32_Figure3.pdf.

The listed hardware satisfies the SLA requirements as described in Specification 10.


C. Description of Inter-Connectivity with Other Registry Systems

The modular design of the KSR solution has the advantage of being very flexible and highly scalable. The SRS, EPP, and RDDS (WHOIS) services communicate through an internal API which protects the system from direct database access while providing real-time information to all SRS related services.

The DNS and DNSSEC information is provided every 15 minutes to the primary hidden master name server and then spread to the anycast⁄unicast cloud within 180 seconds. The communication between the primary hidden master name server and the DNS cloud is facilitated by AXFR⁄IXFR.

The escrow data (full and differential deposit) is generated, zipped, and encrypted once a day and sent to the escrow agent in compliance with Specification 2.

The complete SRS database information is shared between both data centers (primary site, warm-standby). This is achieved by real-time data synchronization. In addition, the SRS program code and binaries are also shared between both data centers at any given time. Only one of the two data centers is actually running in production mode at a time, while the other one is always on standby but not active until needed.

The two data centers are connected through a VPN connection which is used for synchronization of the services described above. In the unlikely event of the complete loss of one data center, the KSR can be switched from one site to another within minutes and with no data loss. The DNS⁄DNSSEC is secure and highly available due to its worldwide setup.

The systemʹs complete inter-connectivity is integrated into the system monitoring and ensures the readiness of the failover locations at any time. In addition to monitoring, a controlled failover testing from the production data center to the warm-standby data center is performed once a year.

These measures ensure compliance with registry continuity in Specification 6.


D. Frequency of Synchronization Between Servers

The frequency of the server synchronization depends on the service being synchronized. Some services are synchronized in real-time while others are synchronized at fixed periods.

The database is set up as a cluster solution (with n+1 redundancy) in each data center. Since only one data center is running in production mode at a time, the other data center is connected to the production database by real-time replication. This guarantees a complete set of SRS⁄DNS information at all sites.

As the DNS⁄DNSSEC is generated from the database information, KSR always has the complete zone file information available at all data center sites. The zone file itself is generated every four minutes and uploaded to the primary hidden master name server. From there, the zone file is distributed to 95% of all DNS servers worldwide within 180 seconds.

The RDDS (WHOIS) is retrieved from the database in real-time and is available at both data center locations at all times.

Like RDDS, the EPP interface retrieves and submits its information in real-time and is also connected to the database.

In addition to storing the complete registry-related data in the database, KSR also distributes the complete SRS source and binary codes to both data center locations at all times. This is achieved by a central repository which is synchronized at every location.

The combination of synchronization of source and binaries of each SRS-related service and the centralized database allows the KSR solution to switch from one data center to the other within 30 minutes. During a failover, the DNS service remains unaffected by the switch.

The data escrow files are generated in accordance with the registry Specification 2.

- Full Deposit: Each Sunday by 23:59 UTC
- Differential Deposit: Monday through Saturday by 23:59 UTC

These measures ensure the compliance with registry continuity in Specification 6.


E. Synchronization Scheme (warm-standby)

The setup of the system includes two geographically separate data centers configured as a warm-standby system (one active, the other in warm-standby, see fig. 1 in attachment Q24_Figure1.pdf). If the production data center is hit by a disaster which results in the complete loss of the data center, the warm-standby system can be brought online within minutes to completely take over.

The complete SRS data (domains, contacts, DNS, etc.) is always available at both data centers at any given time, safeguarding the SRS data from being lost. This is achieved by the setup of the SRS databases as clusters and distributed over both data centers. The cluster is synchronized in real-time.

Using PCH.NET as a partner for DNS⁄DNSSEC, KSR always has ten different locations available worldwide.

These measurements ensure the compliance with Specification 6.


F. Project Resources and Roles

Key-Systems GmbH has gathered experience in various roles in the domain business for more than ten years and has access to extensive knowledge in the domain industry. This deep industry knowledge and experience has been transferred to KSregistry GmbH, the technical provider of the KSregistry system (KSR), and is evident in many trusted persons serving in different roles throughout the company.

All employees, contractors, and consultants that have access to or control of the KSregistry system are trusted persons.

Each role is staffed with multiple human resources for backup and capacity purposes.

Prior to commencement of employment in a trusted role, KSregistry GmbH performs the following background checks on a prospective candidate:

- Criminal records bureau check
- Verification of previous employment
- Check of professional references

F.1 Role Descriptions

All of the following roles have a backup available in each separate location in Germany (St. Ingbert and Munich).

Security Role

The Chief Security Officer (CSO) is dedicated to the security role. The CSO is the person responsible for the security of a companyʹs communications and other business systems. The CSO is involved in both the business (including people) and technical aspects of security. CSO responsibilities include training of personnel regarding security awareness, developing secure business and communication practices, purchasing security products, and ensuring that security practices are followed. The CSO has a stand-in backup available.

Designated Engineering Role

The designated engineering role includes the software developers of the entire SRS and all related interfaces such as EPP, RDDS (WHOIS), escrow, etc. All engineers are also integrated into 3rd level support of the SRS and related interfaces.

System Administration Role

The system administrators take care of the infrastructure of the SRS system. This includes the entire network, hardware and system installations as well as the cluster setup of the databases and all data backups which are made.

The NOC team is composed of system administrators. This team is responsible for clean, well-documented, and reliable data center operations. All access to the data center is restricted to members of the NOC team and persons accompanied by members of the NOC team only. There is an emergency team of at least two people at all times. This team is reachable 24 hours a day, 365 days a year.

Security Administrator

Members of this role define HSM domains⁄tokens and administer HSM users and the overall HSM policy. Security administrators guarantee a working HSM domain for DNSSEC signing.

Support Role

The support role covers the first and second levels of support (Service Desk). All registrars and SRS customers may contact the support role as the first line of contact. Requests can be submitted via email or phone and can be placed 24 x 7. The support role is located in two geographically separate locations, one in Germany and the other in Mexico. If problems are traced back to an erroneous system behavior as the cause, all available data are gathered and a problem report is generated and handed over to the change management team.

DNS⁄DNSSEC Role

The DNSSEC administrator role is staffed with at least two persons. Members of this role are responsible for the overall Open DNSSEC setup and maintenance. This includes the connection to the HSM cluster as well as compliance to the HSM policy for the DNSSEC domain.

Quality Management Role

The Quality Management (QM) role takes care of each software component which is integrated into the SRS system and related interfaces. After a development cycle is finished, the QM performs full integration testing of the entire system. The testing is performed entirely on a separate testing system (OT&E) which mirrors the production system. The QM ensures the production readiness of each and every software upgrade, including emergency software patches. No software or system change will be promoted to production without the explicit approval of the QM.

Change Management ⁄ Project Management Role (CM⁄PM)

The CM and PM role ensures that all steps in the development and system change processes are assessed, approved, implemented, and reviewed in a controlled manner. They also chair the Change Advisory Board (CAB) and the Emergency Change Advisory Board (ECAB). These boards are comprised of selected people from other functions within the company. The CM⁄PM reviews and closes requests for change and reports to management.

F.2 Project Resources

The table in (fig. 2 in attachment Q24_Figure2.pdf) shows how the roles described above are planned for the SRS system. The calculations differ between the project phase and the years after the operational start. The project phase requires more resources as there is much planning, management, and development required. All human resources are only engaged in the domain industry and are experts in their area.

However, as the resources are shared and are not dedicated exclusively to one SRS project, the columns contain the number of resources available for this role and the percentage of all people working for this specific TLD. This percentage is the guaranteed time the resources for this SRS project assure.


G. List of Attachments

- Q24_Figure1.pdf
- Q24_Figure2.pdf
- Q32_Figure1.pdf
- Q32_Figure3.pdf
gTLDFull Legal NameE-mail suffixDetail
.immoSTARTING DOTjwgroupe.comView
Question 24: Shared Registration System (SRS) Performance

The KSregistry (KSR) system is a domain registry system capable of registering domain names managed by multiple registrars. In addition to the SRS system, KSR provides RFC conforming interfaces for EPP, RDDS (WHOIS), DNS, and DNSSEC. KSR is capable of running any IDN string as well as IPv6. KSR uses recognized and proven technologies such as MySQL database software and BIND DNS servers, as well as industry standard backup and monitoring solutions.

KSR uses a thick registry model wherein all contact details are stored in a central location by the registry. All services are set up as a fully redundant solution (n+1). Additionally, there are two geographically separate data centers (Tier 3, all components are available at least n+1), one active and one which is designed to function as a warm-standby solution to ensure a maximum of data security and business continuity. All SRS and DNS related information is replicated in real-time between the data centers.

KSRʹs modular design allows for quick and easy installation or removal of system components at any time. This ensures KSRʹs ability to react to any business needs or system loads in an appropriate manner at all times.

KSR is managed by trained personnel only. Its operations follow well-defined business and security processes which are based on the ITILv3 standard and in accordance with ISO 27001.

KSR has a NOC and support team available at two different locations (St. Ingbert, Germany and Munich, Germany) which allows 24 x 7 x 365 monitoring of all systems and provides customers with an easy way to reach KSR personnel regarding any issue they may have.

The SRS is protected against unauthorized access. Data integrity is ensured by both physical and software security and protection mechanisms.
All these measures together are the basis for running a robust and reliable SRS and are in compliance with Specification 6 and 10.


A. Detailed KSR Description

The following section refers to attachment Q24_Figure1.pdf.

Figure 1 contains a high level functional overview of all KSR components which are described below. All described services and functions are in compliance with Specification 6 and 10 based on their design and setup.

For all of the services listed below the following applies:

The application servers (e.g. EPP, DNS, and RDDS) are set up as a cluster to guarantee a high-availability solution. The sizing of the servers and the databases are calculated to meet the needs of each business case. Additionally, the system is set up to be scalable so that an increase of domains or registrars can be easily handled by installing additional hardware as needed.


A.1 Services Integrated into KSR

Domain Name System (DNS)

The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, and any other resource connected to the Internet or a private network. The registry will be set up with a mix of anycast and unicast name servers. This service is provided by an external provider called PCH.NET which has over 10 years of experience in this area. This partnership with PCH.NET ensures a 100% guaranteed uptime of the service and worldwide DNS coverage. DNS and zone file creation is performed periodically (every 15 minutes), uploaded to the primary hidden master name server, and spread to the anycast clouds (PCH.NET) within 180 seconds. The communication between the primary hidden master name server and the DNS cloud is facilitated by zone transfer {AXFR (Asynchronous Full Transfer Zone)⁄IXFR (Incremental Zone Transfer)} to the worldwide anycast net.

DNS Security Extensions (DNSSEC)

DNSSEC adds security to the Domain Name System. DNSSEC helps in preventing cache poisoning or man in the middle attacks. This helps to protect usersʹ personal and⁄or financial information from being compromised on the Internet. This additional security helps in protecting end users and the reputation of brands.

Extensible Provisioning Protocol (EPP)

The EPP gives registrars the ability to fully automate the management of their domain names. KSR uses EPP as a protocol for registering and managing domain names in a very standardized way. KSR is in compliance with RFCs 3735 and 5730-5734 as well as with Specifications 6 and 10 of the registry agreement. EPP compliance is ensured by technical validation (XML validator) and through the change management process which includes a quality assurance program.

Web Interface

The web interface provides the registrars the ability to manage their domain names through a comfortable user interface and grants access to reports and accounting information.

RDDS (WHOIS)

The Whois is a data directory service which grants public free access regarding domain information. The RDDS (WHOIS) service is provided as a web-based directory service via port 43 in accordance with RFC 3912. This service provides different information depending on the request. The data this will offer includes, but is not limited to:

- Domain name
- Address information on the registrant, administration-, technical-, and billing contacts.
- IP addresses of the name servers
- The identity of the registrar
- Domain creation and expiration dates

There will be a searchable Whois accessible via the web interface. This service will only be available to registrars in respect to confidential data. In order to prevent any abuse of the provided data, additional limitations on the service include IP-based limitations and masking of critical customer data.

SFTP ⁄ SCP Access to the File Store

The SFTP area grants access to all reports which are available in the KSR. Communication is only possible over an encrypted connection, such as with SFTP or SSH, protecting registrars from unauthorized access to their data. In addition to command line access, KSR offers access through the https-based web interface.

Escrow

KSR generates two types of deposits: full and differential. The escrow data provides all SRS-related information to an escrow agent as required for running a registry in compliance with the approved registry services.

The escrow file is generated in compliance with the format specifications as described in Specification 2. The file will be transferred (SFTP) to the escrow agent as a compressed (ZIP RFC 4880) and encrypted file.

KSR is working with the escrow agent NCC Group.

The required data for generating the deposits are always stored in both data centers at all times. This enables the KSR to generate these files even in disaster scenarios.

Reports

The KSR system generates all ICANN reports on a monthly, weekly, or daily basis. In addition to the ICANN related reports, reports for the registrars are created which contain invoicing and domain portfolio information:

- Per-registrar transactions report (Specification 3)
- Registry functions activity report (Specification 3)
- Up-to-date registration data (escrow format as described in Specification 2)
- Thick registration data in case of a registrar failure, de-accreditation, court order, etc. (escrow format as described in Specification 2)
- Technical and operational reports describing performance specifications (Specification 10)
- Registrar based domain and contact reports
- Monthly invoicing reports
- Name server reports
- Data escrow (full and differential as required in Specification 2)


Internationalized Domain Name (IDN)

An IDN is an internet domain name that contains at least one label that is displayed in software applications, in whole or in part, in a language-specific script or alphabet.

KSR has fully integrated IDNs in the SRS and related DNS, DNSSEC, RDDS (WHOIS), and EPP services. The domain registration must be submitted in PUNY code (ascii-encoding) with the appropriate language tag. There is no different handling or billing between the IDN and ASCII domains.


B. Network Diagram

See attached fig. 2 in Q32_Figure1.pdf for the detailed network overview.

B.1 Hardware (Number of Servers)

Network Components:

- Two (2) or more firewalls (Vyatta) (load balanced) Vyatta 6.3
- Two (2) or more network switches frontend (Juniper), EX2200, EX4200
- Two (2) or more network switches transfer (Juniper), EX2200, EX4200
- Two (2) or more network switches backnet (Juniper), EX2200, EX4200
- Two (2) or more load balancer (Keepalived) and SUSE Linux Enterprise High Availability Extension

B.2 Server Components

Typical components for all servers:

Server: IBM compatible Linux server
Processor: INTEL 64bit multicore CPU
Memory: Up to 64 GB ECC DDR2 RAM modules
Disk: Internal RAID 5 for operating system and software, additional intern RAID 5 for data, iSCSI support
Network Adapter: Average 4 100⁄1000 mbit network interface

- Two (2) or more webservers for the web interface (load balanced)
- Two (2) or more EPP server (load balanced)
- Two (2) or more RDDS (WHOIS) servers (load balanced)
- Two (2) or more SFTP servers (load balanced)
- Two (2) or more tools servers (cron, batch) (n+1 redundant with failover)
- Two (2) or more database servers (load balanced)
- Two (2) or more storage servers (load balanced)
- One (1) BIND hidden master
- One (1) Generator
- One (1) Signer ⁄ HSM

Full detailed hardware description can be found in attached fig. Q32_Figure3.pdf.

The listed hardware satisfies the SLA requirements as described in Specification 10.


C. Description of Inter-Connectivity with Other Registry Systems

The modular design of the KSR solution has the advantage of being very flexible and highly scalable. The SRS, EPP, and RDDS (WHOIS) services communicate through an internal API which protects the system from direct database access while providing real-time information to all SRS related services.

The DNS and DNSSEC information is provided every 15 minutes to the primary hidden master name server and then spread to the anycast⁄unicast cloud within 180 seconds. The communication between the primary hidden master name server and the DNS cloud is facilitated by AXFR⁄IXFR.

The escrow data (full and differential deposit) is generated, zipped, and encrypted once a day and sent to the escrow agent in compliance with Specification 2.

The complete SRS database information is shared between both data centers (primary site, warm-standby). This is achieved by real-time data synchronization. In addition, the SRS program code and binaries are also shared between both data centers at any given time. Only one of the two data centers is actually running in production mode at a time, while the other one is always on standby but not active until needed.

The two data centers are connected through a VPN connection which is used for synchronization of the services described above. In the unlikely event of the complete loss of one data center, the KSR can be switched from one site to another within minutes and with no data loss. The DNS⁄DNSSEC is secure and highly available due to its worldwide setup.

The systemʹs complete inter-connectivity is integrated into the system monitoring and ensures the readiness of the failover locations at any time. In addition to monitoring, a controlled failover testing from the production data center to the warm-standby data center is performed once a year.

These measures ensure compliance with registry continuity in Specification 6.


D. Frequency of Synchronization Between Servers

The frequency of the server synchronization depends on the service being synchronized. Some services are synchronized in real-time while others are synchronized at fixed periods.

The database is set up as a cluster solution (with n+1 redundancy) in each data center. Since only one data center is running in production mode at a time, the other data center is connected to the production database by real-time replication. This guarantees a complete set of SRS⁄DNS information at all sites.

As the DNS⁄DNSSEC is generated from the database information, KSR always has the complete zone file information available at all data center sites. The zone file itself is generated every four minutes and uploaded to the primary hidden master name server. From there, the zone file is distributed to 95% of all DNS servers worldwide within 180 seconds.

The RDDS (WHOIS) is retrieved from the database in real-time and is available at both data center locations at all times.

Like RDDS, the EPP interface retrieves and submits its information in real-time and is also connected to the database.

In addition to storing the complete registry-related data in the database, KSR also distributes the complete SRS source and binary codes to both data center locations at all times. This is achieved by a central repository which is synchronized at every location.

The combination of synchronization of source and binaries of each SRS-related service and the centralized database allows the KSR solution to switch from one data center to the other within 30 minutes. During a failover, the DNS service remains unaffected by the switch.

The data escrow files are generated in accordance with the registry Specification 2.

- Full Deposit: Each Sunday by 23:59 UTC
- Differential Deposit: Monday through Saturday by 23:59 UTC

These measures ensure the compliance with registry continuity in Specification 6.


E. Synchronization Scheme (warm-standby)

The setup of the system includes two geographically separate data centers configured as a warm-standby system (one active, the other in warm-standby, see fig. 1 in attachment Q24_Figure1.pdf). If the production data center is hit by a disaster which results in the complete loss of the data center, the warm-standby system can be brought online within minutes to completely take over.

The complete SRS data (domains, contacts, DNS, etc.) is always available at both data centers at any given time, safeguarding the SRS data from being lost. This is achieved by the setup of the SRS databases as clusters and distributed over both data centers. The cluster is synchronized in real-time.

Using PCH.NET as a partner for DNS⁄DNSSEC, KSR always has ten different locations available worldwide.

These measurements ensure the compliance with Specification 6.


F. Project Resources and Roles

Key-Systems GmbH has gathered experience in various roles in the domain business for more than ten years and has access to extensive knowledge in the domain industry. This deep industry knowledge and experience has been transferred to KSregistry GmbH, the technical provider of the KSregistry system (KSR), and is evident in many trusted persons serving in different roles throughout the company.

All employees, contractors, and consultants that have access to or control of the KSregistry system are trusted persons.

Each role is staffed with multiple human resources for backup and capacity purposes.

Prior to commencement of employment in a trusted role, KSregistry GmbH performs the following background checks on a prospective candidate:

- Criminal records bureau check
- Verification of previous employment
- Check of professional references

F.1 Role Descriptions

All of the following roles have a backup available in each separate location in Germany (St. Ingbert and Munich).

Security Role

The Chief Security Officer (CSO) is dedicated to the security role. The CSO is the person responsible for the security of a companyʹs communications and other business systems. The CSO is involved in both the business (including people) and technical aspects of security. CSO responsibilities include training of personnel regarding security awareness, developing secure business and communication practices, purchasing security products, and ensuring that security practices are followed. The CSO has a stand-in backup available.

Designated Engineering Role

The designated engineering role includes the software developers of the entire SRS and all related interfaces such as EPP, RDDS (WHOIS), escrow, etc. All engineers are also integrated into 3rd level support of the SRS and related interfaces.

System Administration Role

The system administrators take care of the infrastructure of the SRS system. This includes the entire network, hardware and system installations as well as the cluster setup of the databases and all data backups which are made.

The NOC team is composed of system administrators. This team is responsible for clean, well-documented, and reliable data center operations. All access to the data center is restricted to members of the NOC team and persons accompanied by members of the NOC team only. There is an emergency team of at least two people at all times. This team is reachable 24 hours a day, 365 days a year.

Security Administrator

Members of this role define HSM domains⁄tokens and administer HSM users and the overall HSM policy. Security administrators guarantee a working HSM domain for DNSSEC signing.

Support Role

The support role covers the first and second levels of support (Service Desk). All registrars and SRS customers may contact the support role as the first line of contact. Requests can be submitted via email or phone and can be placed 24 x 7. The support role is located in two geographically separate locations, one in Germany and the other in Mexico. If problems are traced back to an erroneous system behavior as the cause, all available data are gathered and a problem report is generated and handed over to the change management team.

DNS⁄DNSSEC Role

The DNSSEC administrator role is staffed with at least two persons. Members of this role are responsible for the overall Open DNSSEC setup and maintenance. This includes the connection to the HSM cluster as well as compliance to the HSM policy for the DNSSEC domain.

Quality Management Role

The Quality Management (QM) role takes care of each software component which is integrated into the SRS system and related interfaces. After a development cycle is finished, the QM performs full integration testing of the entire system. The testing is performed entirely on a separate testing system (OT&E) which mirrors the production system. The QM ensures the production readiness of each and every software upgrade, including emergency software patches. No software or system change will be promoted to production without the explicit approval of the QM.

Change Management ⁄ Project Management Role (CM⁄PM)

The CM and PM role ensures that all steps in the development and system change processes are assessed, approved, implemented, and reviewed in a controlled manner. They also chair the Change Advisory Board (CAB) and the Emergency Change Advisory Board (ECAB). These boards are comprised of selected people from other functions within the company. The CM⁄PM reviews and closes requests for change and reports to management.

F.2 Project Resources

The table in (fig. 2 in attachment Q24_Figure2.pdf) shows how the roles described above are planned for the SRS system. The calculations differ between the project phase and the years after the operational start. The project phase requires more resources as there is much planning, management, and development required. All human resources are only engaged in the domain industry and are experts in their area.

However, as the resources are shared and are not dedicated exclusively to one SRS project, the columns contain the number of resources available for this role and the percentage of all people working for this specific TLD. This percentage is the guaranteed time the resources for this SRS project assure.


G. List of Attachments

- Q24_Figure1.pdf
- Q24_Figure2.pdf
- Q32_Figure1.pdf
- Q32_Figure3.pdf