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.

Google Cloud DNS (Cloud DNS) manages DNSSEC keys and record signing automatically for Google's Registry Service Provider (RSP). In normal operation, there is no need to rotate the Key Signing Key (KSK) as Cloud DNS encrypts and secures all private keys using secure shared key management infrastructure. While KSK Rollover is an exceptional process, the procedure follows normal operations and procedures of Cloud DNS. During the process, RSP personnel coordinate with Cloud DNS to facilitate and supervise the rollover. The basis of a KSK Rollover is to perform a Double-DS KSK Rollover Operator Transfer as described in RFC 6781 Appendix D Alternative Rollover Approach for Cooperating Operators with Cloud DNS as both losing and gaining operator. 1. Google Registry communicates with the Cloud DNS team (over chat, email, or videoconference, whichever is most convenient) to have them create a special non-serving replica of the DNS hosting resource signed with a new KSK and ZSK. 2. The RSP software is updated to populate this DNS resource simultaneously with the main, live serving DNS resource. This process also populates all existing records so that the two resources are kept synchronized as mirrors of one another with different keys. 3. The RSP, in coordination with the Cloud DNS team, performs the Double-DS KSK Rollover Pre-Publish steps following Cloud DNS procedures[1] with the non-serving replica representing the gaining operator and the serving replica representing the losing operator. Summary of steps: a) Change both replicas' DNSSEC mode to Transfer b) Add DNSKEYs from the non-serving replica to the serving replica c) Add DNSKEYs from the serving replica to the non-serving replica d) Retrieve the DS record of the non-serving replica e) Submit a root zone request through the IANA Portal at rzm.iana.org to publish DS records for both KSKs f) Wait for the root zone to publish the DS record change g) Wait for the TTL expiration of cached copies of root zone referral records and DNSKEY record sets 4. The RSP performs verification to read back and confirm that the records in both the serving and non-serving resources match. 5. Once confirmed that all replicas have the correct data, the RSP submits a request to Cloud DNS to execute a special procedure that accomplishes the same effects as the Re-Delegation step of the RFC 6781 Appendix D procedure. Once completed, the non-serving replica becomes the serving replica and vice versa. 6. The RSP performs verification over a period of time that confirms that Cloud DNS is responding correctly with the new resource. a) In the event of a problem, the RSP submits a request to Cloud DNS to revert the effects of the special procedure which restores the original serving replica. 7. Once proven, the RSP performs the Double-DS KSK Rollover Post-Migration steps following Cloud DNS procedures[1]: a) Remove obsolete DNSKEYs from the serving replica b) Change the serving replica DNSSEC mode to On c) Submit a root zone request through the IANA Portal at rzm.iana.org to remove the DS records for the old KSK d) Wait for the TTL expiration of cached copies of root zone records 8. The RSP software is restored to its nominal, non-rollover configuration The emergency rollover process is conducted the same way as the standard process, just with more urgency and verification periods shortened to optimize for speed. The practice process is also the same as above, except without publishing changes to the root zone through IANA. We do not use an external DNSSEC provider and are unlikely to ever do so, but our procedure for performing a KSK rollover with a different provider would be the same as above (starting the process by populating a new resource). [1] Cloud DNS publishes full details of how to perform a Double-DS KSK Rollover for operator transfer at https://cloud.google.com/dns/docs/dnssec-migrate

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

LAUNCH_EXTENSION_1_0 – Registered? Y – Note: RFC 8334. Namespace: urn:ietf:params:xml:ns:launch REDEMPTION_GRACE_PERIOD_1_0 – Registered? Y – Note: RFC 3915. Namespace: urn:ietf:params:xml:ns:rgp-1.0 SECURE_DNS_1_1 – Registered? Y – Note: RFC 5910. Namespace: urn:ietf:params:xml:ns:secDNS-1.1 FEE – Registered? Y – Note: RFC 8748. Namespace: urn:ietf:params:xml:ns:epp:fee-1.0

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.

Icann_rdap_response_profile_0 Icann_rdap_response_profile_1 Icann_rdap_technical_implementation_guide_0 Icann_rdap_technical_implementation_guide_1 We will be collecting the Minimum Dataset and will not receive or store contact data on our domains. Therefore, we will not be redacting any data, and we will not be using the “redacted” extension.

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.

Registrars are notified of possible abusive domains and apply the clientHold (or "client hold") EPP / RDAP status, which disables DNS publishing, as specified in RFC 8056. In the event suspension at the registry level is deemed appropriate due to DNS Abuse or violation of registry policies, serverHold EPP and RDAP status is applied. All other statuses, applicable to non-abusive registrations, are applied and shown according to RFC 8056.

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

Domains suspended through Uniform Rapid Suspension are given the EPP / RDAP status values serverDeleteProhibited (server delete prohibited), serverTransferProhibited (server transfer prohibited), and serverUpdateProhibited (server update prohibited). These prevent renewals/updates/transfers of the domain until the case is resolved. When a URS lock is requested, we apply the following EPP statuses to the domain in question: - serverUpdateProhibited - serverTransferProhibited - serverDeleteProhibited These correspond, respectively, to the RDAP status values that are also applied to the domain in question concurrently: - server update prohibited - server transfer prohibited - server delete prohibited These statuses prevent updates, transfers, or deletes of the domain in question. If the URS Complaint is successful and the domain should be URS Suspended, the nameserver data and dsData are changed to point the domain to a webpage indicating the suspension. If the URS Complaint is resolved to be unsuccessful, the three previously-mentioned EPP status values / RDAP status values are removed from the domain.

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.

Available: This is the initial state where a domain name has not yet been registered by anyone. Registration (Active): Once a domain name is successfully registered, it enters the "active" period. Domain Transfer: During the active registration period, a domain can be transferred from one registrar to another. This process extends the registration period by one year. Manual vs. Auto-Renewal: Registrants can choose to manually renew their domains to prevent accidental expiration. Expiration: The registration period has ended, and the domain name has not been renewed by the registrant. Grace Period (Auto-Renew Grace Period): This is a short period (45 days) after the expiration date during which the previous registrant can still renew the domain name at the renewal price without any penalties or additional fees. Pending Delete This is a short period, usually around 5 days, during which the domain is scheduled to be deleted from the registry's database. Released/Available for Re-registration: After the pending delete period, the domain name is deleted from the registry and returns to the "available" state.

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

We follow the relevant RFCs with regards to EPP / RDAP status values (5731). A domain is "ok/active" when in good standing, in "add period" during the add-grace-period after domain registration, in "auto renew period" after an auto renew has been processed, in "pendingTransfer/pending transfer" when a domain transfer is pending, in "redemptionPeriod / redemption period" when a delete request has been issued but the domain has not been deleted yet, and in "pendingDelete / pending delete" when a delete request has been processed but the domain is still restorable.

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.

EPP Status: - Every host gets the OK status when it is created. It loses this status when it gains any other status other than LINKED. - A host gains the LINKED status if it is used as a name server by at least one active domain managed by this registry. This status can coexist with OK. - A host gains the PENDING_TRANSFER status if it is a subordinate host in a domain managed by this registry, and that domain is pending transfer. - The client may add CLIENT_UPDATE_PROHIBITED or CLIENT_DELETE_PROHIBITED statuses to a host. They will prevent update or deletion of the host. - The following statuses are not used on hosts: PENDING_CREATE, PENDING_DELETE, and PENDING_UPDATE - The following status are also not used on hosts: SERVER_DELETE_PROHIBITED and SERVER_UPDATE_PROHIBITED EPP to RDAP Status Mapping: - OK -> active - LINKED -> associated - PENDING_TRANSFER -> pending transfer - CLIENT_UPDATE_PROHIBITED -> client update prohibited - CLIENT_DELETE_PROHIBITED -> client delete prohibited

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.

In the next round, we will only be supporting the minimum dataset. As a result, we will not store or provide any data on contacts whatsoever.

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.

For Data Escrow, our registry generates a Full deposit of the TLDs under management every day. We do not generate differential deposits. Each deposit reflects the state of the registry as of 00:00:00 UTC on the day that the deposit is submitted. The generation of a deposit starts a few minutes after 00:00:00 UTC, and the entire sequence of deposit generation and upload to the Escrow agent typically completes before 00:30:00 UTC, well before the deadline set by ICANN. The code that generates the deposit is located at https://cs.opensource.google/nomulus/nomulus/+/master:core/src/main/java/google/registry/rde/RdeStagingAction.java The deposit only contains standard registry objects. Our registry does not use extensions. The set of files (one per tld) in the deposit are individually compressed and encrypted before being uploaded to the Escrow agent. The uploaded deposits conform to the requirements in Part 4 (Processing of Deposit files) and Part 5 (File Naming Convention) of Specification 2, including naming, compression, encryption, and digital signature. Deposits are uploaded using SFTP. Details of this processing can be found in https://cs.opensource.google/nomulus/nomulus/+/master:core/src/main/java/google/registry/rde/RdeUploadAction.java After the deposit for each TLD is uploaded, a notification is sent to ICANN for that TLD, as specified in Part 7 (Notification of Deposits).

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

Across our current portfolio of 46 TLDs, we operate: DNS, all registry backend services are managed on our “Nomulus” software for managing domain name registrations, a registration system enabling registrars to register, renew, check, and transfer domain names, data escrow, registry lock, registry database, and abuse mitigation services. In the past six months, we had the following registry service disruption: The RDAP service (https://pubapi.registry.google/rdap/) response for .chrome was down over both IPv4 and IPv6 for a few seconds on 2025-04-10.