Applicant Information

Does or will this RSP have a publicly verifiable, third-party certification (e.g. ISO 27001) held directly by the organization and relevant to the registry services under application?

Yes

Does or will this RSP have processes and controls to manage physical access to infrastructure and systems, including building access controls, security cameras and/or other sensors, physical environmental monitoring and safety equipment, and alarm systems related to the physical infrastructure?

Yes

Does or will this RSP have processes and controls to manage non-physical access to infrastructure, including network access from both internal systems and external Internet systems, intrusion detection systems, security information and event management systems, network firewalls, network segmentation and isolation, user identification and authentication, and authorization schemes?

Yes

Does or will this RSP have processes and controls pertaining to the selection of vendors and equipment suppliers, management and maintenance of assets while in use, procurement of assets, and safe disposal of assets?

Yes

Does or will this RSP routinely renew and keep safe all cryptographic material necessary for the operation of the RSP?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) at-rest data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) in-transit data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

If applicable, does or will this RSP have security controls for data in virtualized environments, including controls relevant to both on-premises or private virtualization environments as well as public clouds, network isolation, memory isolation, process isolation, and hypervisor access controls?

Yes

Does or will this RSP have a senior executive primarily in charge of and responsible for security?

Yes

Does or will this RSP conduct background checks, both initial and on-going, of personnel and vendors relevant to the registry services under application?

Yes

Does or will this RSP comply with BCP 38?

Yes

Does or will this RSP implement routing security of some nature, such as automated route filters, RPKI route origin validation, or other operational practices defined by the Internet Society and Global Cyber Alliance’s Mutually Agreed Norms for Routing Security (MANRS)?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the secure development of software?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the development of software?

Yes

Does or will this RSP use Infrastructure-as-Code (IaC) to manage all systems relevant to operation of the registry services under application?

Yes

Does or will this RSP use automated orchestration to manage all systems relevant to the operation of the registry services under application?

Yes

Does or will this RSP have at least two Tier III (as defined here: https://uptimeinstitute.com/tiers) or equivalent data centers having no inter-dependencies?

Yes

Does or will this RSP use hardware security modules (HSMs) certified to at least FIPS 140-3 Level 3?

No - The decision not to use hardware security modules (HSM) dates back to the point in time the development of the TANGO REGISTRY SERVICES®, of which the signing component is an integral part, was commenced. The vision was to develop a shared registry system that is flexible as much as possible. Similarly as the high flexibility in respect to the registration operation as such was a requirement, the flexibility in respect to the deployment was also one. It should not matter whether the software is running under Linux or Microsoft Windows, whether it runs on dedicated systems, virtualized systems, in Docker containers and Kubernetes cluster or on third party cloud services. The use of HSMs was considered. While the products on the market back then all supported at least PKCS#11 and/or the Java Cryptography Architecture (JCA), each product would cause some kind of vendor lock-in. The intention is to stay with a software-based solution for now. The signing software uses the Bouncy Castle cryptography library for performing cryptographic operations and for handling key material. A special FIPS 140-3, level 1 certified version of Bouncy Castle exists, and this has been successfully tested with the signing software. This certified version will be used for all gTLD applications in the next round. Of course, the use of HSMs is not excluded in general. At the end, it is a matter of risk assessment and performance. From a security perspective, there are many threats, many attack vectors to the SRS, attacks to the DNSSEC being some of these. The performance question has been addressed by using an intelligent, continuous replacement of expiring RRSIG records. The approach provides enough reserves to migrate to an HSM-based solution in time, even in case of a "catastrophic success". As several details should not be made public, we have added more details and explanations to the answer to Question 3.8. Subsidiarily, in case a customer or other regulations (including ICANN) require us to use an HSM module, we will adjust the software accordingly to work with a hardware module instead of the software.

Does or will this RSP implement RFC 4033 (“DNS Security Introduction and Requirements”)?

Yes

Does or will this RSP implement RFC 4034 (“Resource Records for the DNS Security Extensions”)?

Yes

Does or will this RSP implement RFC 4035 (“Protocol Modifications for the DNS Security Extensions”)?

Yes

Does or will this RSP implement RFC 4509 (“Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)”)?

Yes

Does or will this RSP implement RFC 6840 (“Clarifications and Implementation Notes for DNS Security (DNSSEC)”)?

Yes

Does or will this RSP implement RFC 6781 (“DNSSEC Operational Practices, Version 2”)?

Yes

Does or will this RSP implement RFC 7583 (“DNSSEC Key Rollover Timing Considerations”)?

Yes

Does or will this RSP implement RFC 9276 (“Guidance for NSEC3 Parameter Settings”)?

Yes

Does or will this RSP implement any of RFC 6605 (“Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC”), RFC 5702 (“Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC“), and/or RFC 8080 (“Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC”)?

Yes

Describe the processes and procedures to be used to practice and ensure a successful KSK rollover for both emergency and non-emergency situations, including coordination with the MAIN RSP and IANA.

The signing process including all KSK rollovers (both planned and emergency) are handled by the DNSSEC RSP. The MAIN RSP is not involved in the signing of the TLD, therefore no additional coordination between those two are necessary. See DNSSEC 3.6, which explains in detail the mechanism the DNSSEC RSP notifies the MAIN RSP about a change in the signed zone file and thus triggers a republication of the zone to the DNS. The only communication necessary is between the DNSSEC RSP and the Registry contacts (technical and administrative) as they will need to accept those DS changes submitted to IANA. These contacts may be with the Main RSP, but they may also be completely independent contacts. The communication is ensured by calling those contacts via phone and raising awareness that IANA notifications will be received and must be approved. For the regular KSK rollover the Double-RRset mechanism is employed. This yields the maximum security by being able to validate the new DS record and KSK, while the old KSK is still active. In particular uploading a non-matching DS record to the Root Zone causes no outage and can be found and fixed easily. The process consists of the following steps. * The DNSSEC Ecosystem generated a new KSK. ** This can either be automatically (after e.g., one year has passed) or ** triggered manually to force a KSK rollover. * A new key is created and the DNSKEYs are re-signed using both old and new key * After the creation of the new key and commencement of the rollover process, the desired new DS record for the Root Zone (RZ) is reported by the signing software. * The MAIN RSP is informed about a newly signed zone, either via a poll message (internal MAIN RSP) or DNS NOTIFY (external MAIN RSP), see DNSSEC 3.6 for details * A manual check that the KSK is actually published in the TLD zone and matches the DS record is executed. * Wait for at least the TTL of the DNSKEY record set. * Submit the DS record to IANA via their portal for inclusion in the RZ. * Both the administrative and technical contact receive the IANA DS record change confirmation e-mail and need to accept the change (after validating the to be added DS record). After this, there are two valid KSK records and their respective DS records active for the TLD. Internal and external (like dnsviz) validation tools are used to validate and carry out sanity checks. This ensures that both KSK records are correct and their signatures can be validated. In case of any issues with the new KSK/DS pair, the old pair is still active and the TLD zone is still correctly signed. Once the new KSK/DS pair has been successfully validated, the old key can be removed. The process consists of the following steps. * Wait for at least the TTL of the RZ DS record set (if not already the case due to the time of the validation process). * Remove the old DS record from the RZ by submitting a corresponding request to IANA and having it confirmed by both the administrative and technical contact. * Trigger the DNSSEC Ecosystem to finalise the KSK rollover process by removing the old KSK key from the TLD zone. * Again the MAIN RSP is informed about an newly signed zone as described above. In case of an emergency KSK rollover the same process is used, but the initial TTL wait is omitted and the new DS record is directly submitted to IANA. Once the maximum TTL of the KSK and the RZ DS record set has passed (during which the above mentioned validations and sanity checks are executed), the old KSK and DS records are removed from the TLD zone and RZ, respectively.

Does or will this RSP compartmentalize (e.g. virtualization) the DNSSEC service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to DNSSEC (excluding system services such as monitoring, remote access NTP)?

Yes

Does or will this RSP regularly exercise DNSSEC service continuity actions?

Yes

Does or will this RSP be capable of transferring all applicable operations to another RSP as defined by the Material Subcontracting Arrangement Technical Questions?

Yes

Does or will this RSP participate in coordinated Emergency Back-end Registry Operator (EBERO) transitions, including but not limited to maintaining the DNSSEC chain of trust, of hosted gTLDs when the business relationship of this RSP and the Registry Operator is not in good standing?

Yes

Does or will this RSP monitor for faults inside its own network?

Yes

Does or will this RSP monitor for faults from a point outside any of its own networks?

Yes

Does or will this RSP have documented processes for aggregation and triage of faults?

Yes

Does or will this RSP have documented processes to mitigate faults once detected?

Yes

Does or will this RSP have processes to minimize faults during maintenance of systems, including both automated processes and manual change control processes?

Yes

Does or will this RSP have personnel capable of reacting to and mitigating faults 24 hours per day of every day of every year of service?

Yes

Provide documentation regarding any RSP functions currently being served for any gTLD, the domain names of the gTLDs, and all service disruptions for each gTLD in the past six months, where a service disruption is defined by Specification 10 of the ICANN Registry Agreement (2024).

* bauhaus * bayern * gmx * ifm * man * nrw * sap * tel * whoswho There have not been any service level agreement violations in the last 6 months.