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 TASS Crypto Engine product complies with the international standard of FIPS 140-2 Level 3, has passed the FIPS 140-3 tests, and will be listed in the certification directory soon.

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.

We have formulated and implemented a comprehensive KSK (Key Signing Key) rollover process that not only meets the business continuity requirements for both scheduled replacement (non-emergency) and emergency replacement (in case of critical failures or key compromise) scenarios, but also aligns with the rules for root zone trust anchor changes by IANA (Internet Assigned Numbers Authority) and the data consistency requirements with the primary RSP (Registry Service Provider). Technically, we leverage the Key Policy Engine (Enforcer) of OpenDNSSEC v1.4.9 and standardized operating procedures for key rolling; organizationally, we have established approval and critical change authorization management mechanisms to ensure the security, operability, and audit compliance of the process. In non-emergency situations, i.e., scheduled KSK rollover, we follow the best practices outlined in RFC 5011 and RFC 6781 to set the valid lifecycle of KSKs (typically 12 months) and implement smooth rollover using the "Double DS record mechanism (Double DS)". The process involves the Enforcer policy configuring the periodic generation of new KSK key pairs, which are set to standby state and not used immediately. Administrators determine the activation timing of the new KSK based on the ds-seen prompt status output by OpenDNSSEC. At the appropriate time, the public key (DNSKEY) of the new KSK is uploaded to the primary RSP for the generation of new DS records, which include fields such as keytag, digest, and digest type. The RSP then submits a task to IANA for updating the DS record changes. Once the DS record is successfully published, we mark the new KSK as active, and OpenDNSSEC begins using this new KSK to sign the ZSK (Zone Signing Key). This process is designed with a buffer period and relies on the change windows of the primary RSP and IANA for overall scheduling, ensuring that the DS records in the root zone remain consistent with our DNSKEYs. Additionally, the previous KSK is retained for a period for cross-validation, after which it is marked as retire and removed through subsequent OpenDNSSEC tasks. In emergency scenarios—such as suspected KSK compromise, key loss, or hardware/software system intrusion—we perform emergency rollover via rapid key generation and manual intervention to prevent trust chain disruption or the construction of forged signatures by malicious actors. First, a temporary new KSK is generated and manually set to ready state; the old KSK in the HSM (Hardware Security Module) is immediately revoked or set to dead state; the Enforcer configuration pauses the automatic rolling function to prevent the system from entering additional automatic states. Administrators then coordinate with the primary RSP and submit DS record updates to IANA. During this process, we ensure that multiple unvalidated DNSKEYs are not published, and simultaneously control cache impacts by temporarily reducing the TTL (Time to Live) of DNSKEY and DS records. To ensure data credibility, we use status review scripts to verify the consistency of BIND zone fields, DNSKEYs, and RRSIGs (Resource Record Signatures). In summary, we have implemented a complete technical and procedural system for KSK rollover. Whether it is the lifecycle management of scheduled keys or the response to emergency security incidents, we possess the capability for rapid response and restoration of signature integrity. Meanwhile, in accordance with the coordination mechanisms required by ICANN (Internet Corporation for Assigned Names and Numbers) and IANA, we ensure the seamless connection between root DS record updates and trust chain integrity. This solution fully complies with the maturity model for registry-level DNSSEC security operations.

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).

As defined by Specification 10 of the ICANN Registry Agreement (2024 Edition), a service outage refers to the unavailability of critical functions provided by the registry, such as DNS resolution, registration data access, and DNSSEC management. The following summarizes relevant information on gTLD service outages: 1.Current gTLD Functions Teleinfo provides the following core functions for gTLDs: DNS resolution services: Ensuring global domain name resolvability. Registration data management: Maintaining WHOIS/RDAP data for public query. DNSSEC support: Providing Domain Name System Security Extensions. EPP (Extensible Provisioning Protocol) services: Supporting domain registration, renewal, transfer, etc. Data escrow：Periodically backing up registration data to independent third parties as required by Specification 2. 2.No Service Outages Recorded in the Past Six Months No service outages affecting the above functions have been recorded for any gTLD managed by the RSP during this period.