Back

23 Provide name and full description of all the Registry Services to be provided

gTLDFull Legal NameE-mail suffixDetail
.cloudCharleston Road Registry Inc.google.comView
Charleston Road Registry (CRR) will outsource the entirety of its technical operations to Google. In addition to running the technical platform, Google will provide CRR with staffing and support to ensure that all registry services meet both the requirements laid out by ICANN in the new generic top-level domain (gTLD) Applicant Guidebook as well as in the gTLD registry agreement. Additional details of Google’s provision of services to CRR are set forth in Question 31, Section 31.1.

By making use of Google’s Registry platform, CRR will provide the following registry services:

- Receipt of data from registrars concerning registration of domain names and name servers
- Dissemination of top-level domain (TLD) zone files
- Dissemination of contact or other information concerning domain name registrations (WHOIS service)
- Internationalized Domain Names (IDN) Support for all domain names
- Domain Name System Security Extensions (DNSSEC) support
- IPv6 Support
- Data escrow
- Redemption grace period for domain names
- Registrar and developer account creation
- Google DNS hosting and service association

“Q23_Registry Services Diagram” shows major services being exposed by high-level systems. Note that this diagram shows only data flow and does not specify the physical deployment characteristics of these services.

Details on these services are discussed below.

23.1. Receipt of Registration Data

Google will receive registration data from users in a manner consistent with standard registry operations. This will be handled via the extensible provisioning protocol (EPP) interface through ICANN-accredited third-party registrars. Google will operate a robust Shared Registration Service (SRS) that allows registrars to add, modify, and delete domain registrations and provides full support for the domain registration lifecycle.

Google’s shared registration system (SRS) infrastructure consists of three major components: an extensible provisioning protocol (EPP) server that provides an EPP interface to registrars; the Google SRS Frontend, which provides web-based access to the state of the Google Registry, the registrar’s profile and access to registration reports for the registrar; and the Google SRS Backend, which implements most business logic, interacts with the data store, and pushes updates to DNS and WHOIS servers in order to disseminate TLD Zone files as well as registrant contact information.

Details of the SRS are described in Question 24, EPP support in Question 25, and the registration lifecycle in Question 27.

23.2. Dissemination of TLD Zone Files

TLD zone data will be propagated in near real time to Google’s Authoritative DNS infrastructure, which will serve as the primary means of publication of the TLD zone files. This DNS infrastructure is based on Google’s existing Public DNS product, which handles over 70 billion queries per day. This DNS implementation will be fully compliant with RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, 4472, 4972, and 5966 as well as ICANN’s Specification 10. A full description of Google’s Authoritative DNS infrastructure is described in Question 35.

In addition to real-time publication via port 53, the registry will also support publication of the entire zone, as described below:

The master zone file will be internally generated and cached in the Google Shared Registration System (GSRS) as modifications to GSRS’s persistent store are made. The zone data will be signed by the Authoritative DNS infrastructure; a copy of the signed data is also returned to the GSRS. The entire master zone file will then be available to authorized parties at an HTTP URL shared with them over the web.

The master zone file at this location will be guaranteed to be no more than one hour old.

When retrieving the zone file, the client will pass a single HTTP request parameter (“key”), in order to identify individually the qualified client requesting access. This parameter will be the API key given to the registrar during account signup.

The mimetype “text⁄dns” will be set on the HTTP response and the content encoding will be gzip.

The master zone file will follow the format specified by RFC 1035, with the additional restrictions as specified in Specification 4, Section 2.1.4 of the gTLD Applicant Guidebook. DNSSEC resource records will also be present.

In addition, the master zone file will be made available through the Centralized Zone Data Access Provider as specified in Specification 4, Section 2.1.4 of the gTLD Applicant Guidebook.

23.3. Dissemination of Contact Information (WHOIS)

Google will create an implementation of the WHOIS protocol (as defined by RFC 3912) that will listen on port 43 for WHOIS requests. Googleʹs WHOIS service will communicate to the name registry through a private API end-point in order to retrieve the necessary information for WHOIS responses. In addition, Google will operate a public WHOIS, web-based Directory Service at 〈WHOIS.nic.cloud〉 providing free, public query-based access. Both traditional WHOIS and web-based WHOIS will be made available over both IPv4 and IPv6.

As required by Specification 4 in the gTLD Applicant Guidebook, Googleʹs WHOIS service will perform in the following manner:
- Semi-free text format followed by a blank line and disclaimer specifying the rights of the Registry Operator, and user querying the database.
- Each data object shall be represented as a set of key⁄value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
- For fields where more than one value exists, multiple key⁄value pairs with the same key shall be allowed.
- The first key⁄value pair after a new-line starts a new record, and is used to identify the record itself.
- The format of fields governed by EPP RFCs 5730-5734 (domain status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses, date and times) will be formatted as specified by those RFCs.

Updates to WHOIS data will be made in near real-time, with the registry’s service level agreement (SLA) committing to 95% of the updates reaching the serving infrastructure within 15 minutes. Details of WHOIS support are included in Question 26.

23.4. Internationalized Domain Names

IDNs allow registrars to register domain names with unicode code points representing non-ASCII-based character sets. IDNs constrained by the IDN Tables for this TLD will be supported by the Google Registry. Google’s IDN implementation will make use of the IDNA standard and be fully compliant with both RFCs 5890-5893 and ICANN’s IDN implementation guidelines. For more information on the IDN implementation for the TLD, see Question 44.

23.5. DNS Security Extensions

The Google Registry will support DNSSEC. In particular, registrants will be able to specify a DS record as part of normal domain name registration with their registrars, which will be transmitted to the Google Registry via its EPP interface. The Google Registry will then sign the DS record, along with all other DNS resource records in the TLD Zone, forming a chain of trust between the Google Registry and second-level domain name. The Google Registry itself will publish its own DS record with the root. Google’s DNSSEC implementation will be fully compliant with RFCs 4033, 4034, 4035, 5910, 4509, 4641, and 5155. More information on this topic, including the DNSSEC Policy statement for the TLD is contained in Question 43.

23.6. IPv6 Support

The Google Registry operates on Google’s production network, which supports IPv6. Specifically, the Google Registry will specifically support IPv6 access to all registry service endpoints (WHOIS, EPP, DNS, etc.). All services are provided through dual-stack, which is considered the industry-standard best practice for supporting IPv6. In addition, domain name registrants will be able to create IPv6 AAAA glue records for nameservers in the TLD zone. Further detail about Google’s IPv6 implementation is available in Question 36.

23.7. Data Escrow

Google will escrow relevant registration data, as required by ICANN’s registry agreement. Google will ensure that its data escrow will be fully ICANN compliant and performed in accordance to industry best practices. In addition to Google’s practice of hosting critical data on redundant and geographically disparate datacenters, data escrow will provide further assurance against data loss and ensure that all Google Registry data can be retrieved in a timely manner. For more information on Data Escrow, see Question 38.

23.8. Redemption Grace Period for Domain Names

After a domain name has been deleted by a registrar, the domain name shall move into a Redemption Grace Period. The status of the domain will be listed as PENDING DELETE RESTORABLE. When a domain is in this state, it is deleted from the zone for the TLD. This is a strong indicator to the registrant that it must act take action in order to restore the domain to its previous state. For details, see Question 27.

23.9. Creation of Registrar and Developer Accounts

Google’s registry will use Google Accounts to manage registrars.

To create a Google Account, all parties will be directed to the following URL:

http:⁄⁄www.google.com⁄accounts

Once a prospective registrar or developer has created an account in Google, the registrar or developer can upgrade from a standard Google account to a registrar and⁄or developer, if certain requirements are met.

To obtain a set of credentials used to interact with the Google Registry, a registrar will proceed through the following workflow:
A. The Google registrar logs in with Google account credentials.
B. The Google registrar submits an application identifying that it is an accredited ICANN registrar, and that it wishes to interact with the Google Registry.
C. The Google registrar requests and resets initial EPP credentials, which are separate from a Google account.

Once a Registrar has been certified and authorized for billing, they will be ready to interact with Google through Google EPP. At this point, the registrar can also view reports on domains registered, EPP transactions, remaining account balance, and other TLD registry statistics.

“Q23_Registrar Registration Process Diagram” shows the registration process for registrars.

In addition to registrars, Google will also provide accounts to developers and other authorized users, who will obtain credentials through the following workflow:
A. The developer logs in the previously created Google account.
B. The developer requests an API key to be used for all public API calls.
C. The developer reviews access restrictions, quota, and service-level agreements and agrees to appropriate terms.
D. Google Registry grants access to zone data exported by the domain.

“Q23_Developer Registration Process Diagram” shows the registration process for developers.

23.10 Google DNS Hosting and Service Association

This Google Registry service causes the domain name to be associated with the Google cloud offering service, so that DNS for second-level domains (SLD) within the TLD will automatically resolve to the relevant Google service.

When a domain is initially registered, the DNS hosting service automatically becomes active, which will cause the nameservers associated with the Google Registry to be automatically changed to a specific set of nameservers operated by Google (e.g., ns1.google.com and ns2.google.com). These nameservers will operate on the same Google infrastructure used to host the Google Registry’s own zone data, and will therefore offer equivalent levels of reliability, security, and performance. Client-initiated updates to the name servers for the domain name will not be accepted and the server will respond with an error type 2304 - “Object status prohibits operation”.

Google will maintain a database with an association between individual SLDs and one or more specific Google services. In the case of the .cloud TLD, all SLDs will be automatically associated with the Google’s cloud offerings. Depending on the specific services associated with a domain name, zone data will be generated within the SLD zone with the appropriate resource records required in order to properly operate the service. For association with the Google cloud offering service, this may include creating MX, A and AAAA records at the apex of the zone as well as A records for the www label. These resource records would be dynamically (but infrequently) updated to seek to ensure that the end user would always be directed to the appropriate Google servers to handle requests for the relevant service.

The SLD will be associated with a particular user’s Google cloud offering account by means of the Account Ownership EPP Extension, as described in Question 25. This association will be required during the registration process, and will allow Google to serve the appropriate content for the TLD.

Sample zone data demonstrating the general model of DNS provisioning for these TLDs is included below:

*** Example .cloud TLD zone file: ***
$ORIGIN cloud.
$TTL 172800
@ IN SOA ns1.google.com. wkumari.google.com. (
2012033000 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 min)
1209600 ; expire (2 weeks)
300 ; negative (5 min)
)

NS ns1.google.com.
NS ns2.google.com.

example 86400 IN NS ns1.google.com.
86400 IN NS ns2.google.com.
86400 IN NS ns3.google.com.
86400 IN NS ns4.google.com.

*** Example example.cloud zone file: ***
$ORIGIN example.cloud.
$TTL 172800
@ IN SOA ns1.google.com. skirkham.google.com. (
2012033000 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 min)
1209600 ; expire (2 weeks)
300 ; negative (5 min)
)

NS ns1.google.com.
NS ns2.google.com.
NS ns3.google.com.
NS ns4.google.com.

MX 5 smtp-in.l.google.com.
MX 10 alt1.smtp-in.l.google.com.
MX 20 alt2.smtp-in.l.google.com.

@ 600 IN A 192.0.2.1
600 IN AAAA 2001:0DB8::1

www 600 IN A 192.0.2.1
600 IN AAAA 2001:0DB8::1
gTLDFull Legal NameE-mail suffixDetail
.siteCharleston Road Registry Inc.google.comView
Charleston Road Registry (CRR) will outsource the entirety of its technical operations to Google. In addition to running the technical platform, Google will provide CRR with staffing and support to ensure that all registry services meet both the requirements laid out by ICANN in the new generic top-level domain (gTLD) Applicant Guidebook as well as in the gTLD registry agreement. Additional details of Google’s provision of services to CRR are set forth in Question 31, Section 31.1.

By making use of Google’s Registry platform, CRR will provide the following registry services:

- Receipt of data from registrars concerning registration of domain names and name servers
- Dissemination of top-level domain (TLD) zone files
- Dissemination of contact or other information concerning domain name registrations (WHOIS service)
- Internationalized Domain Names (IDN) Support for all domain names
- Domain Name System Security Extensions (DNSSEC) support
- IPv6 Support
- Data escrow
- Redemption grace period for domain names
- Registrar and developer account creation
- Google DNS hosting and service association

“Q23_Registry Services Diagram” shows major services being exposed by high-level systems. Note that this diagram shows only data flow and does not specify the physical deployment characteristics of these services.

Details on these services are discussed below.

23.1. Receipt of Registration Data

Google will receive registration data from users in a manner consistent with standard registry operations. This will be handled via the extensible provisioning protocol (EPP) interface through ICANN-accredited third-party registrars. Google will operate a robust Shared Registration Service (SRS) that allows registrars to add, modify, and delete domain registrations and provides full support for the domain registration lifecycle.

Google’s shared registration system (SRS) infrastructure consists of three major components: an extensible provisioning protocol (EPP) server that provides an EPP interface to registrars; the Google SRS Frontend, which provides web-based access to the state of the Google Registry, the registrar’s profile and access to registration reports for the registrar; and the Google SRS Backend, which implements most business logic, interacts with the data store, and pushes updates to DNS and WHOIS servers in order to disseminate TLD Zone files as well as registrant contact information.

Details of the SRS are described in Question 24, EPP support in Question 25, and the registration lifecycle in Question 27.

23.2. Dissemination of TLD Zone Files

TLD zone data will be propagated in near real time to Google’s Authoritative DNS infrastructure, which will serve as the primary means of publication of the TLD zone files. This DNS infrastructure is based on Google’s existing Public DNS product, which handles over 70 billion queries per day. This DNS implementation will be fully compliant with RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, 4472, 4972, and 5966 as well as ICANN’s Specification 10. A full description of Google’s Authoritative DNS infrastructure is described in Question 35.

In addition to real-time publication via port 53, the Google Registry will also support publication of the entire zone, as described below:

The master zone file will be internally generated and cached in the Google Shared Registration System (GSRS) as modifications to GSRS’s persistent store are made. The zone data will be signed by the Authoritative DNS infrastructure; a copy of the signed data is also returned to the GSRS. The entire master zone file will then be available to authorized parties at an HTTP URL shared with them over the web.

The master zone file at this location will be guaranteed to be no more than one hour old.

When retrieving the zone file, the client will pass a single HTTP request parameter (“key”), in order to identify individually the qualified client requesting access. This parameter will be the API key given to the registrar during account signup.

The mimetype “text⁄dns” will be set on the HTTP response and the content encoding will be gzip.

The master zone file will follow the format specified by RFC 1035, with the additional restrictions as specified in Specification 4, Section 2.1.4 of the gTLD Applicant Guidebook. DNSSEC resource records will also be present.

In addition, the master zone file will be made available through the Centralized Zone Data Access Provider as specified in Specification 4, Section 2.1.4 of the gTLD Applicant Guidebook.

23.3. Dissemination of Contact Information (WHOIS)

Google will create an implementation of the WHOIS protocol (as defined by RFC 3912) that will listen on port 43 for WHOIS requests. Googleʹs WHOIS service will communicate to the name registry through a private API end-point in order to retrieve the necessary information for WHOIS responses. In addition, Google will operate a public WHOIS, web-based Directory Service at 〈WHOIS.nic.site〉 providing free, public query-based access. Both traditional WHOIS and web-based WHOIS will be made available over both IPv4 and IPv6.

As required by Specification 4 in the gTLD Applicant Guidebook, Googleʹs WHOIS service will perform in the following manner:
- Semi-free text format followed by a blank line and disclaimer specifying the rights of the Registry Operator, and user querying the database.
- Each data object shall be represented as a set of key⁄value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
- For fields where more than one value exists, multiple key⁄value pairs with the same key shall be allowed.
- The first key⁄value pair after a new-line starts a new record, and is used to identify the record itself.
- The format of fields governed by EPP RFCs 5730-5734 (domain status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses, date and times) will be formatted as specified by those RFCs.

Updates to WHOIS data will be made in near real-time, with the registry’s service level agreement (SLA) committing to 95% of the updates reaching the serving infrastructure within 15 minutes. Details of WHOIS support are included in Question 26.

23.4. Internationalized Domain Names

IDNs allow registrars to register domain names with unicode code points representing non-ASCII-based character sets. IDNs constrained by the IDN Tables for this TLD will be supported by the Google Registry. Google’s IDN implementation will make use of the IDNA standard and be fully compliant with both RFCs 5890-5893 and ICANN’s IDN implementation guidelines. For more information on the IDN implementation for the TLD, see Question 44.

23.5. DNS Security Extensions

The Google Registry will support DNSSEC. In particular, registrants will be able to specify a DS record as part of normal domain name registration with their registrars, which will be transmitted to the Google Registry via its EPP interface. The Google Registry will then sign the DS record, along with all other DNS resource records in the TLD Zone, forming a chain of trust between the Google Registry and second-level domain name. The Google Registry itself will publish its own DS record with the root. Google’s DNSSEC implementation will be fully compliant with RFCs 4033, 4034, 4035, 5910, 4509, 4641, and 5155. More information on this topic, including the DNSSEC Policy statement for the TLD is contained in Question 43.

23.6. IPv6 Support

The Google Registry operates on Google’s production network, which supports IPv6. Specifically, the Google Registry will specifically support IPv6 access to all registry service endpoints (WHOIS, EPP, DNS, etc.). All services are provided through dual-stack, which is considered the industry-standard best practice for supporting IPv6. In addition, domain name registrants will be able to create IPv6 AAAA glue records for nameservers in the TLD zone. Further detail about Google’s IPv6 implementation is available in Question 36.

23.7. Data Escrow

Google will escrow relevant registration data, as required by ICANN’s registry agreement. Google will ensure that its data escrow will be fully ICANN compliant and performed in accordance to industry best practices. In addition to Google’s practice of hosting critical data on redundant and geographically disparate datacenters, data escrow will provide further assurance against data loss and ensure that all Google Registry data can be retrieved in a timely manner. For more information on Data Escrow, see Question 38.

23.8. Redemption Grace Period for Domain Names

After a domain name has been deleted by a registrar, the domain name shall move into a Redemption Grace Period. The status of the domain will be listed as PENDING DELETE RESTORABLE. When a domain is in this state, it is deleted from the zone for the TLD. This is a strong indicator to the registrant that it must act take action in order to restore the domain to its previous state. For details, see Question 27.

23.9. Creation of Registrar and Developer Accounts

Google’s Registry will use Google Accounts to manage registrars.

To create a Google Account, all parties will be directed to the following URL:

http:⁄⁄www.google.com⁄accounts

Once a prospective registrar or developer has created an account in Google, the registrar or developer can upgrade from a standard Google account to a registrar and⁄or developer, if certain requirements are met.

To obtain a set of credentials used to interact with the Google Registry, a registrar will proceed through the following workflow:
A. The Google registrar logs in with Google account credentials.
B. The Google registrar submits an application identifying that it is an accredited ICANN registrar, and that it wishes to interact with the Google Registry.
C. The Google registrar requests and resets initial EPP credentials, which are separate from a Google account.

Once a Registrar has been certified and authorized for billing, they will be ready to interact with Google through Google EPP. At this point, the registrar can also view reports on domains registered, EPP transactions, remaining account balance, and other TLD registry statistics.

“Q23_Registrar Registration Process Diagram” shows the registration process for registrars.

In addition to registrars, Google will also provide accounts to developers and other authorized users, who will obtain credentials through the following workflow:
A. The developer logs in the previously created Google account.
B. The developer requests an API key to be used for all public API calls.
C. The developer reviews access restrictions, quota, and service-level agreements and agrees to appropriate terms.
D. Google Registry grants access to zone data exported by the domain.

“Q23_Developer Registration Process Diagram” shows the registration process for developers.

23.10 Google DNS Hosting and Service Association

This Google Registry service causes the domain name to be associated with the Google Sites service, so that DNS for second-level domains (SLD) within the TLD will automatically resolve to the relevant Google service.

When a domain is initially registered, the DNS hosting service automatically becomes active, which will cause the nameservers associated with the Google Registry to be automatically changed to a specific set of nameservers operated by Google (e.g., ns1.google.com and ns2.google.com). These nameservers will operate on the same Google infrastructure used to host the Google Registry’s own zone data, and will therefore offer equivalent levels of reliability, security, and performance. Client-initiated updates to the name servers for the domain name will not be accepted and the server will respond with an error type 2304 - “Object status prohibits operation”.

Google will maintain a database with an association between individual SLDs and one or more specific Google services. In the case of the .site TLD, all SLDs will be automatically associated with the Google Sites service. Depending on the specific services associated with a domain name, zone data will be generated within the SLD zone with the appropriate resource records required in order to properly operate the service. For association with the Google Sites service, this may include creating MX, A, and AAAA records at the apex of the zone as well as A records for the www label. These resource records would be dynamically (but infrequently) updated to seek to ensure that the end user would always be directed to the appropriate Google servers to handle requests for the relevant service.

The SLD will be associated with a particular user’s Google Site account by means of the Account Ownership EPP Extension, as described in Question 25. This association will be required during the registration process, and will allow Google to serve the appropriate content for the TLD.

Sample zone data demonstrating the general model of DNS provisioning for these TLDs is included below:

*** Example .site TLD zone file: ***
$ORIGIN site.
$TTL 172800
@ IN SOA ns1.google.com. jordyn.google.com. (
2012033000 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 min)
1209600 ; expire (2 weeks)
300 ; negative (5 min)
)

NS ns1.google.com.
NS ns2.google.com.

example 86400 IN NS ns1.google.com.
86400 IN NS ns2.google.com.
86400 IN NS ns3.google.com.
86400 IN NS ns4.google.com.

*** Example example.site zone file: ***
$ORIGIN example.site.
$TTL 172800
@ IN SOA ns1.google.com. tprodromou.google.com. (
2012033000 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 min)
1209600 ; expire (2 weeks)
300 ; negative (5 min)
)

NS ns1.google.com.
NS ns2.google.com.
NS ns3.google.com.
NS ns4.google.com.

MX 5 sites-smtp-in.l.google.com.
MX 10 alt1.sites-smtp-in.l.google.com.
MX 20 alt2.sites-smtp-in.l.google.com.

@ 600 IN A 192.0.2.1
600 IN AAAA 2001:0DB8::1

www 600 IN A 192.0.2.1
600 IN AAAA 2001:0DB8::1