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 implement 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

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 DNSSEC RSP and IANA.

Registry Services, LLC d/b/a GoDaddy Registry conducts KSK rollovers in line with, and following, recommendations in RFC7583 along with guidance from the requirements of RFC4035. The method used for both emergency and non-emergency situations is Double-RRset, 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 the largest TTL in the zone, 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. Our internal teams 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, to ensure responses to IANA requests and approvals are expedited. Emergency Rollover In case of an emergency KSK rollover GoDaddy Registry follows a documented process for engaging IANA: * Initial Notification: root-mgmt@iana.org or emergency channel (phone) * Emergency DS Change Request: Submit via RZMS or secure email * Priority/Emergency Flag: Clearly indicate the emergency nature * Supporting Documentation: Provide evidence of compromise if applicable * Real-Time Communication: Request a call/bridge for direct coordination * Status Monitoring: Stay in close contact until change is live * Follow-up for DS/KSK Removal: Submit second change request post-propagation The required technical steps for generation of new key material, as well as communication with the Registry Operator are also included in the documented plan. External Parties GoDaddy Registry DNSKEYs are (only) managed by the GoDaddy Registry DNS Signer, which utilises BIND software, the KSKs are configured to require a manual trigger to roll the keys. GoDaddy Registry has also applied for DNSSEC accreditation. We do not use other third parties to manage DNSKeys or DS records. GoDaddy Registry has the ability to AXFR a zone to a third party – that is have the third party sign the zone – then have the signed zone ingested by our distribution server, in order to propagate the now DNSSEC signed zone to the edge. We do not have any TLDs that use this process. Coordination with IANA The relevant information/records are submitted directly to IANA and actively monitored for responses. GoDaddy Registry also engages the Registry Operators where required and seeks engagement on RZM change approvals.

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 have on-site backups of registration data?

Yes

Does or will this RSP have off-site backups of registration data?

Yes

Does or will this RSP practice data retention policies with regard to backups of registration data?

Yes

Does or will this RSP practice documented standards regarding media and data backups for registration data?

Yes

Does or will this RSP practice regularly scheduled validation of registration data backups, separately from recovery practices?

Yes

Does or will this RSP practice regularly scheduled recovery of registration data backups?

Yes

Does or will this RSP forbid the use of production data in testing and/or development environments?

Yes

Does or will this RSP encrypt registration data at-rest in the data store?

Yes

Does or will this RSP encrypt registration data in-transit to and from the data store?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP use modern and known-secure cryptographic algorithms for the encryption of registration data at-rest and in-transit with regard to the data store?

Yes

Does or will this RSP implement RFC 5730 (“Extensible Provisioning Protocol (EPP)”)?

Yes

Does or will this RSP implement RFC 5731 (“Extensible Provisioning Protocol (EPP) Domain Name Mapping”)?

Yes

Does or will this RSP implement RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)?

Yes

Does or will this RSP implement RFC 5910 (“Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If applicable, does or will this RSP implement RFC 5732 (“Extensible Provisioning Protocol (EPP) Host Mapping”)?

Yes

If applicable, does or will this RSP implement RFC 5733 (“Extensible Provisioning Protocol (EPP) Contact Mapping”)?

Yes

Does or will this RSP implement RFC 8334 (“Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If applicable, does or will this RSP implement RFC 8748 (“Registry Fee Extension for the Extensible Provisioning Protocol (EPP)”)?

Yes

Does or will this RSP forbid access to contacts via EPP to registrars other than the sponsoring registrar?

Yes

Provide a list of all EPP extensions to be used that are registered in the IANA EPP extensions registry, and an attestation that all EPP extensions to be used are registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”).

Registry Services, LLC d/b/a GoDaddy Registry, implements the following EPP extensions that are registered in the IANA EPP extensions registry: - RFC 3915 - Domain Registry Grace Period Mapping for EPP - RFC 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) - RFC 7451 - Extension Registry for the Extensible Provisioning Protocol - RFC 8334 - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) - RFC 8495 - Allocation Token Extension for the Extensible Provisioning Protocol (EPP) - RFC 8748 - Registry Fee Extension for the Extensible Provisioning Protocol (EPP) - RFC 9167 - Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) The EPP implementation is fully compliant with RFC 7451, which requires that any proprietary EPP extensions be registered with IANA. Our development team proactively monitors the IANA EPP extensions registry and proactively implements any relevant standardized extensions to ensure interoperability. GoDaddy Registry attests that all current and future EPP extensions used by GoDaddy Registry are and will be registered with IANA in accordance with RFC 7451. We are committed to maintaining an up-to-date and standards compliant EPP implementation through prompt implementation of registered IANA extensions.

Does or will this RSP forgo the use of any EPP extensions which are not registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”)?

Yes

Does or will this RSP implement and operate EPP according to the performance requirements defined in the standards established in Specification 10 of the ICANN Registry Agreement (version 2024)?

Yes

Does or will this RSP have controls to prevent EPP misuse and ensure all registrars have fair and equal access to EPP per the standards established in Specification 9 of the ICANN Registry Agreement (version 2024)?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) notwithstanding RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)? Note: while RFC 9325 covers TLS and DTLS, EPP only uses TLS.

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure EPP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure EPP communication in accordance with industry best common practices?

Yes

Does or will this RSP meet the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to EPP?

Yes

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

Yes

Does or will this RSP implement RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 7481 (“Security Services for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all currently operated gTLDs?

Yes

Does this RSP plan to continue to implement RFC 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all gTLDs operated in the future?

Yes

Does or will this RSP implement RFC 9082 (“Registration Data Access Protocol (RDAP) Query Format”)?

Yes

Does or will this RSP implement RFC 9083 (“JSON Responses for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all currently operated gTLDs?

Yes

Will this RSP implement RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all gTLDs operated in the future?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Technical Implementation Guide?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Response Profile?

Yes

Provide a list of all RDAP extensions to be used.

Registry Services, LLC d/b/a/ GoDaddy Registry offers a Registration Data Access Protocol (RDAP) service using the following RDAP profile extensions registered by ICANN: - icann_rdap_response_profile_1 - icann_rdap_technical_implementation_guide_1 - redacted (if responses are redacted as per the Registration Data Policy)

Does or will this RSP forgo the use of any RDAP extensions which are not registered with the IANA as per RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP meet the standards established in the Service Level Agreements specified in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP?

Yes

Does or will this RSP implement methods to prevent mining of registration data via RDAP?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) with respect to RDAP?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure RDAP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure RDAP communication in accordance with industry best common practices?

Yes

Does or will this RSP meet the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to RDAP?

Yes

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

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv6?

Yes

Will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv6 if requested by a registrar?

Yes

Will this RSP provide tools and mechanisms to Registry Operators for the purposes of automated processing and identification of abusive domain registrations.

Yes

Describe the EPP and RDAP status values as they relate to domain name registrations considered to be abusive registrations and those not considered to be abusive registrations.

Registry Services, LLC d/b/a GoDaddy Registry receives reports identifying abusive registrations from several sources, including the following but not limited to: - Trusted Notifiers: an organization that is trusted by the Registry to report domain names that fit into one or more categories or abusive behavior. Examples include URS providers (Asian Domain Name Dispute Resolution Centre, MFSD srl, National Arbitration Forum) and the Internet Watch Foundation. - Law Enforcement: orders from a law enforcement agency or court order. - Public Reports: Cases of abuse reported directly to the Registry Operator by the public. - Self-identified by the Registry Operator: domain names that fail to comply with the Registry Operator’s registration policy where the criterion for abuse is met. If a domain name is judged to be an abusive registration, one or more (or all) of the following statuses may be applied: * EPP serverUpdateProhibited/RDAP server update prohibited * EPP serverDeleteProhibited/RDAP server delete prohibited * EPP serverTransferProhibited/RDAP server transfer prohibited * EPP serverRenewProhibited/RDAP server renew prohibited * EPP serverHold/RDAP server hold The prefix "server" indicates that the application of the status is performed by the Registry Operator, or a process endorsed by the Registry Operator. However, the application of one or more of the above status does not always indicate an abusive domain name registration. Each restriction that is implied by each status may be a result of a certain business requirement. For example, the Registry may block the transfer of domain names for up to 60 days from the date of creation or most recent transfer by applying an EPP serverTransferProhibited/RDAP server transfer prohibited status. This does not mean the domain name registration is abusive, even though a status applied in cases of identified abuse was used. For each of the EPP statuses listed above, it is possible to include a "reason" for each status set. This reason carries human readable text that describes why the status has been set and if it was due to a category of "abuse" Registrars have the ability to read the reason. Server prefixed status indicates that the status has been set by the Registry and Client prefixed status indicates that the status has been set by the Registrar. Public view of status reasons is not displayed in WHOIS or RDAP however future development may indicate that a domain name is considered an abusive registration or is under review by include message in the WHOIS footer or an RDAP remark for the status array based on an internal classification in the Registry. For domain names that are not considered abusive, there is no set of statuses that imply normal operation, although the absence of one or more of the above server restrictions indicates the domain name is operating normally. All statuses applied and shown in both EPP and RDAP meet the definitions listed on ICANN’s EPP Status Codes page at the following link: https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en

Describe the EPP and RDAP status values and their applicability to Uniform Rapid Suspension (URS).

Registry Services, LLC d/b/a/ GoDaddy Registry systems complies with the technical requirements described in ICANN’s "URS High Level Technical Requirements for Registries and Registrars" document (https://newgtlds.icann.org/sites/default/files/tech-requirements-21feb24-en.pdf). The statuses that are shown under the following conditions for both EPP and RDAP are: - Domain placed under URS Lock: * EPP: serverUpdateProhibited, serverTransferProhibited, serverDeleteProhibited * RDAP: server update prohibited, server transfer prohibited, server delete prohibited - Domain placed under URS Suspension: * EPP: serverUpdateProhibited, serverTransferProhibited, serverDeleteProhibited * RDAP: server update prohibited, server transfer prohibited, server delete prohibited The above EPP and RDAP statuses are mapped as specified by ICANN which can be found at the following link: https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en The RDAP statuses are registered values which appear on IANA’s "RDAP JSON Values" page which can be found at the following link: https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml

Does or will this RSP implement the Registry Operator-related elements of RFC9361

Yes

Describe all potential registration lifecycle(s) of domain names supported in the system.

Registry Services, LLC d/b/a GoDaddy Registry has implemented a standard domain lifecycle that can be described as follows: TLDs generally have two main stages: 1. Launch Phase; and 2. General Availability During the launch of a TLD, a Registry Operator may define one or multiple phases to start-up their TLD, during which domain name registrations are accepted in the form of applications prior to the General Availability period. Applications are inherently tied to the launch phase of a TLD, including: 1. Sunrise phase, when an application MUST include a valid Signed Mark Data (SMD) file issued by the Trademark Clearinghouse (TMCH) through Trademark Database (TMDB) to trademark owners. 2. An optional “post-Sunrise phase”, when a Registrar can submit applications on behalf of non-trademark holders or parties with specific eligibility criteria, or members of a particular industry or community. 3. Landrush phase, when registration is opened to a broader audience, allowing any interested party to apply for domain names. If more than one application is submitted by Registrars for the same domain name, a contention resolution process is invoked where eventually only one application gets allocated resulting at a domain creation in Registry. The rules of the contention resolution processes are determined by the Registry Operator. Once the Launch is completed, the TLD moves onto the General Availability where Registrars can create domain names on a “first-come first served” basis. Once a domain name is successfully registered, the Registrar becomes the domain’s sponsor and can perform various allowed operations including update, renew, and delete. When there is a domain transfer requested by other Registrar, the sponsoring Registrar can approve or reject. This lifecycle is consistent with the lifecycle in use by other major TLD Registries and is consistent with the “Life Cycle of a Typical gTLD Domain Name” (https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en). Please refer to the following in Attachment MAIN.10.1 – Registration Lifecycle. They provide detail listing of domain states and the grace periods the apply between the states: - Fig 1: Domain status with grace period - Fig 3: Domain state transition mapping with EPP and RDAP status - Fig 5: Grace Periods The Registry also supports the domain name state of Pending Create as well. If required by the Registry Operator, all domain name create requests during General Availability will enter Pending Create (https://datatracker.ietf.org/doc/html/rfc5731#section-2.3). In this state, no other create requests for the domain will be accepted and the Registry Operator is required to either approve or reject the request based on their registration policy. The domain name will remain in the Pending Create state for the number of days set by the Registry Operator (generally less than 30 days). The Registry Operator is able to specify the number of days which a domain name can remain in pending create from the create date. If the Registry Operator does not approve or reject the domain then the Registry will auto reject after the period is lapsed and is accompanied by a service message sent to both Registrar’s involved to inform them of the auto-approval by the Registry.

Describe the registration lifecycle(s) of domain names with respect to EPP status values and RDAP status values.

Registry Services, LLC d/b/a GoDaddy Registry has adopted what would be considered the "Life Cycle of a Typical gTLD Domain Name" which is described at a high level at the following link: https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en A diagram showing the transition between states and the applicable grace periods that apply has been included as an attachment. Please see Attachment MAIN.10.2 – Domain Registration Values, Fig 1: Domain status with grace period. The domain name lifecycle supported is in compliance with RFC 5731 (Extensible Provisioning Protocol (EPP) Domain Name Mapping) and RFC 3915 (Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)). As an extension of this, the RDAP service is compliant with RFC 8056 (Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping) which is further detailed at the following link: https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en The attachment shows a table with each domain state and the respective status in EPP and RDAP. Please see Attachment MAIN.10.2 – Domain Registration Values, Fig 2: Domain state mapping with EPP and RDAP status. The attachment shows the transition of a domain’s state based on the Domain Lifecycle Model (described in MAIN.10.1) in Please see Attachment MAIN.10.2 – Domain Registration Values, Fig 3: Domain state transition mapping with EPP and RDAP status. A domain may have zero or more Registry Grace Period status (RFC 3915 - Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)). The attachment shows a domain’s EPP and RDAP status be set by the Sponsoring Registrar (client) or by the Registry (server) in Fig 4: Client and Server status setting Attachment MAIN.10.2 – Domain Registration Values. TLD launches are also supported including Sunrise and Landrush applications (RFC 8334 - Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)) which are not directly part of the domain name lifecycle.

Describe the nameserver host lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names. This should include a description of nameservers as either attributes of domains or as host objects.

Registry Services, LLC d/b/a GoDaddy Registry’s host lifecycle is as follows. Hosts represent Internet host names. Depending on its name, a Host Object could have a subordinate relationship to a superordinate domain name. For example, assuming the System runs the .example registration zone but not the .com zone, the host name ns1.example.com is an 'external' host because the name of the host does not belong to the namespace of the System; and ns1.domain1.example is an internal host. A Host Object for which no superordinate Domain Object exists in the System is called an 'external host'. An external Host Object is always sponsored by the System, because IP Address information cannot be associated, nor can hosts be renamed. An ‘Internal Host’ Object is a host name which belongs to the namespace of the System. The domain name, to which the host is subordinate to, is also known as the internal host’s parent domain. The system will always assign the sponsorship of an internal host to the same Registrar who sponsors its parent domain A host can be used by a Domain Object as its nameserver. Once it is associated with the domain, the host is “linked” to the domain. Lifecycle wise, only ‘internal host’ could have lifecycle transitions, between “Registered” and “Pending Transfer”, when operations like transfer request/cancel/approve/reject are performed on its parent domain (described in MAIN.Q10.2). A host may have one or more of the following EPP / RDAP statuses associated with it. EPP STATUS / RDAP STATUS - pendingTransfer / pending transfer - ONLY applies to internal hosts. A transfer request has been made on the superordinate domain of the host which is pending approve/reject or cancel. EPP STATUS / RDAP STATUS - clientUpdateProhibited / client update prohibited - The host’s sponsor has requested that the details of the host cannot be updated. EPP STATUS / RDAP STATUS - clientDeleteProhibited / client delete prohibited - The host’s sponsor has requested that the host cannot be deleted. EPP STATUS / RDAP STATUS - serverUpdateProhibited / server update prohibited -The System has requested that the details of the host cannot be updated. EPP STATUS / RDAP STATUS - serverDeleteProhibited / server delete prohibited - The System has requested that the host cannot be deleted. EPP STATUS / RDAP STATUS - ok / active - If the host does not have any of the above statuses. EPP STATUS / RDAP STATUS - linked / associated - If host is associated with a domain. If an internal host is linked to at least one domain name, the deletion of that host is disallowed. In the case where a domain name is deleted, and that domain name is a superordinate domain (parent) to one or more internal subordinate hosts where one or more of them are assigned as a NS record for one or more domain names, the following will occur: * When the parent domain name is purged from the database as a result of completing the redemption and pending delete stage, all internal subordinate hosts are deleted as well. * The result of the above means that any domain name that had a deleted internal subordinate host will have that link (host to domain as a NS) removed. * Because the domain is no longer associated with the deleted internal hosts, the NS record will be removed from the zone file. A Registrar can at any time delink a host of any type (internal or external) from any of their registered domain names which will result in corresponding NS record being removed from the domain name in the TLD zone file, assuming of course that the domain name is in a state that permits DNS delegation/publication.

If applicable, describe the contact lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names and nameservers. Include a description of the deletion of orphaned contacts.

Registry Services, LLC d/b/a GoDaddy Registry systems are set up so that contacts may be associated with Domain Objects in the form of registrant, administrative, billing and technical contacts. Depending on the policy of a TLD, the contact association type can be set to mandatory, optional or disallowed. An example would be a TLD that is required to be "thin" (PII collected) and therefore a domain name registration in such a TLD will not require any contacts linked to the domain name for any association type. A contact consists of several data elements, which are collected by the Registrar as part of the registration data and then sent to the Registry system. The data elements include: - Contact ID - Auth Info - Postal information (International and Local) - Contact Email - Contact Phone and Ext - Contact Fax and Ext A contact must have international postal information and may also have local postal information. The System enforces protocol restrictions that international postal information must be able to be represented in ASCII. Local postal information is converted to a canonical form using Unicode canonical composition form (NFC) prior to storage. A domain transfer does not change the ownership of any contact that is associated with the domain. Contact ownership can change when a non-sponsoring Registrar requests a transfer of a contact. The Registrar who requests the transfer is referred to as the gaining Registrar and obtains ownership of the contact, while the Registrar who was the original sponsor is referred to as the losing Registrar, if the transfer is successful. Once a contact transfer is successfully requested, it transitions to “Pending Transfer”. When the transfer is cancelled, approved, or rejected, the contact becomes “Registered” again. The sponsoring Registrar (client) or the Registry system (server) can set EPP status on a contact, to prohibit certain operations (update/delete/transfer). - A transfer request has been made on the contact / EPP Status: pendingTransfer - The contact’s sponsor has requested that the details of the contact cannot be updated / EPP Status: clientUpdateProhibited - The contact’s sponsor has requested that a transfer request cannot be created for the contact / EPP Status: clientTransferProhibited - The contact’s sponsor has requested that the contact cannot be deleted / EPP Status: clientDeleteProhibited - The System has requested that the details of the contact cannot be updated / EPP Status: serverUpdateProhibited - The System has requested that a transfer request cannot be created for the contact / EPP Status: serverTransferProhibited - The System has requested that the contact cannot be deleted / EPP Status: serverDeleteProhibited - When none of the above EPP statuses are set on a contact / EPP Status: ok - When a contact is associated with one or more domains, as the domain's registrant, admin, billing, or technical roles / EPP Status: linked Contact Object lookups via RDAP ("entity" lookup using the contact handle) will show the status "removed" and redact Contact data to prevent unauthorized access, as outlined in section 10.2.2 of RFC7483. The Contact Object's sponsor can securely access the data through EPP with their Registry-issued credentials. The Registry system tracks the last datetime of contact usages, such as: when a contact was created; the last time when the contact was linked to a domain as registrant/tech/billing/tech; etc. A contact that becomes orphaned, no longer linked to any Domain Object, won't be immediately deleted. The Registry system specifies how many days after its last usage an orphaned contact can be deleted, which is configurable. The system checks orphaned contacts periodically. They will be deleted if: 1. the contact is not pending transfer; and 2. the contact’s last used datetime is older than the configured number of days ago.

Does or will this RSP be capable of removing orphaned glue in accordance with the standards established in Specification 6 of the ICANN Registry Agreement (version 2024)?

Yes

Describe how this RSP will meet the standards established in Specification 2 of the ICANN Registry Agreement (version 2024), and describe any other data escrow processes. This includes escrow extensions for data related additional registry services.

Registry Services, LLC d/b/a/ GoDaddy Registry adheres to the standards in the specification 2 of the ICANN Registry Agreement (version 2024) by implementing a robust data escrow process. Registry events related to Contacts, Domains, Hosts, and Registrars are stored in a NoSQL database and a daily snapshot is generated. The snapshot process ensures that all data is securely backed up and can be recovered in case of failure. The data contained within this snapshot is created for all TLD’s in a standardized format as specified by ICANN in RFC8909 and RFC9022 (DNDE Specification) to ensure consistency, reliability and portability as intended by the mentioned RFCs. In addition to the standard data escrow requirements, GoDaddy Registry has also implemented escrow extensions for data related to additional Registry services. This includes any supplementary data generated by value-added services provided by the Registry, such as DNSSEC keys, and domain transfer information. The escrow files are compiled and named using the following naming convention: - gTLD_ 2025-02-02_full_S1_R0.ryde: where ‘gTLD’ is the TLD and the ‘.ryde’ file is the deposit itself. - gTLD_ 2025-02-02_full_S1_R0.sig): where ‘gTLD’ is the TLD and per the ICANN Data Escrow Specification, deposit must be signed using detached signatures, therefore the ‘.sig’ file is paired with/accompanies the ‘.ryde’ file. The files are encrypted using PGP/GnuPG and uploaded to the respective Escrow Agent using their documented method. As part of the Specification 2 requirements for Escrow, Part A, GoDaddy Registry provides a daily Full Deposit for all gTLDs, as described in reference 1.1, to the Escrow Agent with which we have the agreement for each specific TLD. Escrow Agents that are currently served are DENIC, NCC (Iron Mountain / Escode), Escrow4All, CNNIC and CONAC. In Registry, we can configure all other Escrow Agents as accredited by ICANN. Each TLD is configured within the Registry for the specific Escrow Agent the contract is held with. A monitoring platform is deployed to monitor the escrow service to ensure compliance and operation where the following is conducted: - Show the overall state of the service. - The current processing step. - The number of TLDs processed. - A list of any TLD’s that may have failed which will invoke a regeneration. - Monitor the return codes of each Escrow Agent following the upload of an escrow deposit to ensure they have been received and processed correctly.

Does or will this RSP regularly exercise registry 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 (version 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. 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 receives XML requests, parses them, and passes data access and change requests to the PostgreSQL database. 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 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.