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 - No HSM is in use, please see further details in DNSSEC.3.8.

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.

Registry Services, LLC d/b/a GoDaddy Registry conducts KSK rollovers in line with, and following recommendations in RFC7583 “DNSSEC Key Rollover Timing Considerations” along with guidance from the requirements of RFC4035 “Protocol Modifications for the DNS Security Extensions”. The method used for both emergency and non-emergency situations is Double-RR set, signing the zone with both old and new KSKs, ensuring continuity with validating resolvers as the DS records are updated within the root. The DNSKEYs are managed by our DNS Signer software (BIND), with KSKs configured to require a manual trigger to roll the keys. When a key-roll is to be executed: 1. The Signer is instructed to create a new KSK for the zone. 2. The DNSKEY RR set will be signed with both the current and new KSKs. 3. In-house key management and validation tools ensure the validity of each KSK and appropriate signing of the zone with the two KSKs. 4. DS records for the new KSK are supplied to IANA and requested to be added to the root. 5. After the new DS records are confirmed to be present in the root zone, the Signer is instructed to stop signing with the old KSK. 6. Following a period of at least two times TTL, the Signer will remove the old KSK from the zone, and a request will be submitted to IANA to remove corresponding old DS records. All zones pass through a DNSSEC validation process before being published to the edge, to ensure that only correct zone data is released. As the provider of backend technical Registry and DNS services for many TLDs, annual KSK rollovers are done in bulk and coordinated with IANA to ensure timing is optimal for all parties. Notice is given to Registry Operators about the upcoming rollover and what steps will be taken. Step 3 of the process above is conducted and supply the new DS records to IANA to be bulk processed and added to the specified TLDs. Teams at GoDaddy then work with the Registry Operators and nominated technical contacts for the TLD to confirm the change requested to IANA and guide the IANA approvals required. At step 5 of the process, we confirm the list of DS records to be removed from the specified TLDs with IANA for bulk processing. In case of an emergency KSK rollover being required, contact is made with the TLD Registry Operator and IANA to ensure awareness of the requirement, so as to ensure rapid responses to IANA requests and approvals are expedited.

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

Registry Services, LLC d/b/a GoDaddy Registry currently provides the following RSP functions: - EPP - WHOIS - RDAP - DNS - DNSSEC - Registry Data Escrow These RSP functions serve all our TLDs. In the past six months we have had no service disruptions. Where possible, code updates are done with services remaining online. These upgrades were made on the following dates: - 2024-11-19 – Registry Software Upgrade - 2024-10-22 – Registry Software Upgrade - 2024-09-24 – Registry Software Upgrade - 2024-07-16 – Registry Software Upgrade A summary of these functions can be found below, please see the attached documents for detailed technical information. EPP The EPP application server is a proprietary GoDaddy Registry daemon and business logic engine, which is responsible for receiving EPP requests, validating the request and responding back to the client. This daemon is a proprietary GoDaddy Registry Java daemon and uses an event-driven, threaded architecture. EPP application servers also run a host-based firewall and only accepts EPP requests from a predetermined list of IP Addresses that provide valid credentials and SSL keys. EPP is also restricted to accredited Registrars only, enforced by allowlisting and firewalls at the front-end. Upon de-accreditation, the Registrar and associated client IP Addresses are removed from the active configuration, and EPP becomes uncontactable for that Registrar. WHOIS The WHOIS application servers consist of a proprietary GoDaddy Registry Java daemon and business logic engine that converts standard WHOIS protocol requests over port 43 into data access requests to the database. WHOIS service is available at both the Active and Standby Registry Regions and interacts with the read-only standby database. WHOIS is also a public service and runs on a heavily protected demilitarized zone (DMZ), independent of the EPP and Registry Web-based Interface front-ends, providing a read-only connection into the Registry database. RDAP The F5 web application firewall locks down access to specific URLs provided for this service, which is also protected by a ‘captcha’ and query limits to prevent abuse. This service is limited in access to the database, and is provided a read-only application account, restricted to key tables and columns. The data is queried and displayed on the reply web page. This service is available by both HTTP and HTTPS. DNS Our DNS service provides the ultimate in stability, security and availability, utilizing a total of 30 sites distributed across the globe. The DNS service provides a high degree of robustness and diversity through a platform that is scaled for the demands of the Internet core. The DNS service is deployed in redundant sites throughout the globe, across all continents except Antarctica. It has strong manageability through automated build processes and configuration management, as well as fully automated monitoring for DDoS mitigation. The DNS platform’s capabilities and capacity are continually assessed to ensure that it evolves with the needs of our customers and the changing Internet landscape. DNSSEC GoDaddy Registry’s DNSSEC platform includes input from various technical experts. GoDaddy Registry’s current DNSSEC Practice Statement (DPS) describes how GoDaddy Registry manages DNSSEC for the zones under our control. It is important to note that the DPS is intended to be a public document and, as such, details are deliberately left at a high level to avoid unnecessarily exposing sensitive information or providing a potential attacker with information that might help them in executing an attack. Please see Question DNSSEC.4.1. DPS.