Back

24 Shared Registration System (SRS) Performance

gTLDFull Legal NameE-mail suffixDetail
.carCharleston Road Registry Inc.google.comView
All Shared Registration System (SRS) services described in Question 23 will run on Google’s robust, high-performance platform. Google’s production platform is an extremely high-capacity, high-availability, scalable platform designed to support some of the most resource-intensive and often-used applications on the Internet, including Google Search, Gmail, and YouTube. Google builds large clusters out of thousands of individual servers. Google uses a common set of tools to allocate resources, provide access to basic services such as storage and locking, and to simplify programmers’ ability to build distributed systems using the cluster’s hardware. Rather than relying on expensive hardware to provide reliability, Google uses a more cost effective approach based on commodity components, and builds fault tolerance into its software. Google simultaneously increases performance, reliability, and scalability of our production systems by splitting work into shards and running multiple replicas of the same process.

The numbered sections below discuss details of our SRS implementation and capacity plans.

24.1. Google SRS (GSRS)

The Google Shared Registration System (GSRS) will provide all standard 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 Support for all domain names
- Domain Name System Security Extensions (DNSSEC) support
- IPv6 Support
- Data Escrow

For descriptions and details of all SRS functions, see Question 23.

24.2. Google SRS Components

GSRS will be a multi-tier application that consists of the following components.

- Google SRS Front End (GSRS-FE): Presentation. A web application which provides an interface between registrars, developers, and other parties that need access to Google Registry information through a web interface. GSRS-FE will also include a web-based WHOIS interface.
- Google SRS Back End (GSRS-BE): Business Logic. A representational state transfer (RESTful) service that exposes and controls all registry data. Most business logic related to registry data storage and persistence will be implemented in GSRS-BE.
- Google EPP (GEPP): API Proxy. A public end-point for EPP (Extensible Provisioning Protocol) for the top-level domain. GEPP will translate all EPP requests and responses to interface with GSRS-BE. For more information on EPP support, see Question 25.
- Google WHOIS (GWHO): A public end-point for WHOIS queries for the top-level domain. GWHO will translate all WHOIS requests and responses to interface with the GSRS-BE. For more information on WHOIS support, see Question 26.

In addition, GSRS will integrate with the following internal systems. These internal systems are designed for extremely high performance and robustness, and use the same technologies used for other high-capacity services currently in production.

- Google Persistence Service (Persistence): A multi-master persistence solution which will run on top of Google’s proprietary database, BigTable. The Google Persistence Service coordinates between masters using an algorithm for fault-tolerant distributed systems, such as Paxos. BigTable is Google’s internal implementation of a distributed hash table used for the majority of our persistence needs.
- Google Accounts (Authentication): An existing platform for creation and authentication of user accounts. Google Accounts provides a standard login page for all Google products, as well as programmatic access for internal applications to retrieve credentials for the logged-in user.
- Google Monetization (Billing, as needed for the TLD): A monetization and billing system. Enables Google products to create accounts, create invoices, and perform financial transactions for Google customers.
- Google Authoritative DNS (Master Zone File): A robust public DNS server. Google Authoritative DNS will receive master zone file information from the GSRS-BE and distribute DNS information to clients.

“Q24_SRS Services Diagram” shows the interactions with these systems as requests come into a Google datacenter and are handled appropriately. Note that, as shown in “Q24_SRS Services Diagram”, all SRS requests are passed to the GSRS-BE, which contains all business logic for Google Registry. Integrated services are then used as needed. Google plans to provision these services to handle significantly greater load than our most aggressive expectations -- see below for details.

24.3. Google SRS Deployment Parameters

Google plans to deploy GSRS in five geographically-distributed datacenters throughout North America. Traffic to these datacenters is dynamically adjusted according to load, and the system will be provisioned to allow two simultaneous datacenter outages without substantial performance impact.

Each datacenter will include several replicas to handle specific machine failures for any GSRS service. Google’s production servers include the ability to expand to add new servers dynamically according to need. If SRS performance suddenly requires additional throughput capacity -- for instance, during a Distributed Denial of Service (DDoS) attack -- Google will be able to enable up to 100 additional replica servers in any datacenter dynamically. The limit of 100 additional replica machines is a self-imposed limit and may be revised upward based on ongoing operational considerations.

Each machine will be able to support a minimum of 250 queries per second (read or write), where one query contains one record. For architectural simplicity, our initial implementation will read data without any additional SRS-level caches.

24.4. GSRS Performance Scaling

Google plans to deploy sufficient capacity to handle SRS request load on the same scale as the largest top-level domains on the Internet. These computations are detailed in “Q24_GSRS Performance and Scaling”.

The key factor for scaling GSRS performance capacity will be the GSRS-BE component. Other components for GSRS (both GSRS-FE and GEPP) will receive user requests and then transform them into Remote Procedure Call (RPC) calls to GSRS-BE. GSRS-FE and GEPP will not perform any CPU-, disk-, or memory-intensive computations themselves. The performance capacity estimations below will therefore discuss only GSRS-BE capacity.

Based on existing domains and calculations for inbound traffic, Google estimates that there will be about 2300 queries per second for EPP operations, consisting mostly of checks for existing domains, and 3600 queries per second for WHOIS operations. In total, Google estimates that GEPP-BE must handle roughly 5900 queries per second for a scale of 100 million domains. Other operations, such as zone file operations and developer API calls, will create a relatively negligible level of load.

Google will meet the SRS throughput requirement, with a 50% utilization rate, with 48 machines allocated across the five datacenters. At this level of utilization, our active capacity will be double the expected throughput requirement. If a datacenter is lost through a production outage or change request, then additional machines will be enabled immediately to take upon the additional load with no manual intervention required. Google production systems have the standard capability to enable new machines to handle increased capacity needs immediately.

These estimations do not include any smart caching anywhere in the architecture. If the Google Registry reaches a very large number of domains and additional capacity measures are required, Google will consider a design for an appropriate WHOIS and EPP check result caching plan to relieve load and to improve latency characteristics.

These estimates use a very aggressive set of assumptions for scaling, which should be sufficient for a large open domain.

24.5. GSRS Network Scaling

Google expects that our SRS network bandwidth requirements will be greatly below Google’s existing per-datacenter network capacity, even for its lowest-capacity datacenters in production. Details of its computations are included below.

Google assumes that 99% of RPC calls across both EPP and WHOIS will be less than 5 kB. EPP and WHOIS queries return more of a fixed number of records, and most queries will return only one record. 5 kB is derived as an estimate from taking the sample WHOIS output in the applicant guidebook, and multiplying it by three to account for XML inflation as if the same information passed through an EPP interface. Considering that most EPP commands are expected to be 〈check〉 commands, this is a very conservative estimate.

Google then uses 5 kB as the assumed size to calculate the estimates for bandwidth per machine and per datacenter at maximum load.

Network Bandwidth Requirements per Machine = Queries per Second * Size of RPC Calls

With 250 qps and 5 kB per query, Google expect a maximum of about 12.5 MB⁄s of bandwidth requirement. This is about one-eighth of our current absolute minimum commodity standard of 1 Gb Ethernet. Our backbone routers connect many metro networks around the globe at 10Gb or greater.

Network Bandwidth Requirement per datacenter = Requirements per Machine * Number of Machines

With 12.5 MB⁄s of bandwidth per machine, and 100 machines maximum per datacenter, Google expects a maximum of about 1.25 GB⁄s data requirements during a major event that requires increased load demand. All Google datacenters’ connections to its production network have a multiple 10 GB⁄s links, and many exceed this by far.

Based on these computations, Google believes that the network bandwidth required by the SRS system for as many as 100 million second-level domains will never exceed the capacity that even our smallest datacenter can provide.

24.6. Multi-Master Design

GSRS will use a multi-master architecture. This architecture is detailed further in Question 32. Machines across multiple datacenters will serve active traffic, with no machines on cold or hot standby. All instances of the data store update in real-time, and updates to registry data are committed across a quorum of replicas before the write is confirmed. When GSRS or a dependent service goes down or is drained by an outage, Google’s network architecture will redirect all affected traffic to another datacenter. Google will design most services as stateless, so service instances will not require any coordination mechanisms.

24.7 Google SRS Adherence to Specification 6

The Google Registry, and in particular the SRS will be compliant with all RFCs outlined in Specification 6. Any RFCs mentioned below and their successors will be complied with.

24.7.1 - Standards Compliance

24.7.1.1 DNS

Google’s domain name system (DNS) implementation will comply with RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966. See Question 35 for more details on DNS RFC implementation compliance.

24.7.1.2 EPP

Google’s EPP implementation will comply with RFCs 5910, 5730, 5731, 5732, 5733, 5734, 3915, and 3735 for any extensions developed. Please see Question 25 for more details on EPP RFC implementation compliance.

24.7.1.3 DNSSEC

Google’s DNSSEC implementation will comply with RFCs 4033, 4034, 4035, 4509, 5155, and the best practices indicated in RFC 4641. A DPS statement will be published for each TLD supported by the Google Registry. Please see Question 43 for more details on DNSSEC implementation compliance.

24.7.1.4 IDN

Google’s implementation of internationalized domain names (IDN) will comply with RFCs 5890, 5891, 5892, 5893 and ICANN’s published IDN Guidelines. Please see Question 44 for more details on IDN RFC implementation compliance.

24.7.1.5 IPv6

Google’s implementation of IPv6 will follow BCP 91 and RFCs 4472. All Registry services will be offered over IPv6. Please see Question 36 for more details on Google’s IPv6 implementation.

24.7.2 Registry Services and Wildcard Prohibition

Google understands the definition of “registry services” as defined in section 2.1 of Specification 6. Google will not support wildcard matching or resolution in the TLD zone as required by Section 2.2 of Specification 6.

24.7.3 Registry Continuity

Google will ensure registry continuity as specified in Section 3 of Specification 6. High availability, extraordinary event handling, and business continuity will be provided with respect to the TLD. See Question 39 for more details on Google’s Registry continuity plan.

24.7.4 Abuse Mitigation

Google will implement the abuse mitigation requirements as specified in Section 4 of Specification 6. An abuse contact will be made available. See Question 28 for more details on Google’s abuse handling. Google will also take action to remove malicious use of orphan glue records when provided evidence in written form that such records are present in connection with malicious content.

24.7.5 Supported Initial and Renewal Registration Periods

Google will implement the supported initial and renewal registration periods as specified in Section 5 of Specification 6. The Google Registry will support domain name registration with validity periods of between one to 10 years in increments of one year. Renewal registration may extend registration to a maximum of 10 years from renewal date in increments of one year.

24.8. Google SRS SLA and Adherence to Specification 10

The Google SRS will significantly exceed the requirements of the Service Level Requirement Matrix defined in Specification 10 in the gTLD Applicant Guidebook. All EPP and WHOIS⁄RDDS calls supported by the Google SRS system will have a 99.9% monthly uptime.

For the purpose of measuring this commitment, Google uses the following definitions:
RPC: A series of TCP⁄IP packets forming a distinct request, and the corresponding TCP⁄IP packets forming the response.
Error RPC: An RPC which does not return with 3x 95th percentile latency, or which fails because of internal transient errors.
Error Minute: Any minute during which 10% of RPC requests are error RPCs.
Monthly Uptime: The total number of minutes in a month minus the number of error minutes divided over the total number of minutes in the month, rounded to the nearest .01%.

When calculating monthly uptime percentage, Google does not distinguish between scheduled and unscheduled downtime.

Google will meet or exceed all service level agreements (SLA) described in the ICANN Applicant Guidebook. Specifically, Google will meet the commitments as specified in attachment “Q24_SLAs”. Note that the values represent a commitment to exceed SLA Requirements in Specification 10.

DNS
- DNS Availability: 0 minutes of downtime.
- DNS Name Server Availability: Less than 31 minutes of downtime per month (At least 99.93% availability)
- TCP DNS resolution RTT: 300ms for at least 95% of the queries
- UDP DNS resolution RTT: 300ms for at least 95% of the queries
- DNS update time: 15 min, for at least 95% of the probes

RDDS (WHOIS)
- RDDS Availability: Less than 43 minutes of downtime per month. (At least 99.9% availability)
- RDDS Query RTT: Less than 400 ms.
- RDDS Update Time: Less than 15 minutes for 95% of probes.

EPP
- EPP Service Availability: Less than 43 minutes of downtime per month. (At least 99.9% availability)
- EPP Session-Command RTT: Less than 1000 ms for at least 95% of commands.
- EPP Query-Command RTT: Less than 400 ms for at least 95% of commands.
- EPP Transform-Command RTT: Less than 800 ms for at least 95% of commands.

Downtime values are on a monthly basis.

Google has the track record to deliver SRS to 99.9% availability. Google is confident in its ability to meet these SLAs for SRS because of its experience with engineering highly-available platforms. As discussed by Urs Hoelzle, Senior Vice President of Technical Architecture, Google has designed its major services to obtain 99.99% reliability [1].

24.9. SRS Technical Support

Charleston Road Registry will provide registrars with access to telephone, email, and web chat support, and will escalate issues to the Google technical team as technical faults are identified. For a further elaboration of the escalation process, see Question 42.

Google will notify ICANN and registrars, at least 24 hours beforehand, of maintenance for all planned outages and maintenance which will directly, significantly, and visibly affect users of the SRS.

24.10. Resourcing Plans

Google will implement these technical requirements using the teams and resources discussed below.

The cost of these services will generally be set at reasonable market rates per agreement between Charleston Road Registry and Google. The expected costs are discussed in Questions 46 and 47.

All services that GSRS will depend on are already well-provisioned and ready to assume the additional load of the Google SRS, including up to 100 million second-level domains, which is well in excess of expected need. The load that GSRS will generate for existing systems will be significantly less than the capacity already designated as part of normal growth for Google and the company’s need for high-performance hardware and support personnel resources.

24.10.1. Registry Team

The Google Registry Team will be responsible for designing and implementing our SRS, EPP, and WHOIS systems, including IDNs. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least four to seven software engineers responsible for implementing the project. Additionally, Google plans to staff one software engineer who is responsible for engineering testing and monitoring for the Google Registry, and one software engineer who is responsible for backup, restoration and escrow. In total, Google plans to implement the Google Registry with a team of six to nine software engineers.

After the Google Registry is complete, Google expects to staff a team to support the ongoing operation of the registry. This team will consist of at least four engineers who will participate in on-call rotation, respond to alerts, provide support to ICANN and registrars for emergency escalations, and maintain responsibility for bug fixes and improvements. This team will continue maintenance throughout the life of the registry.

This team’s responsibilities will generally be limited to registry-specific components. The Google Registry Team will work closely with other relevant teams, including the Authoritative DNS support team, Storage Site Reliability Engineering team, network engineering and operations, and customer support teams. These other teams are described in more detail in Question 31 (Section 31.16) as well as the relevant sections throughout this application.

24.11. Summary and Key Insights

Google has an existing production infrastructure that can exceed the performance requirements of the SRS platform:
- Google has a global network of datacenters to provide the scalability to meet the performance requirements of SRS.
- Google has a multi-master high availability strategy to meet the reliability requirements of SRS.
- Google has the proven operational processes and personnel to support the requirements going forward.
- The use of Google’s platform allows Charleston Road Registry to commit to service levels that substantially exceed the ICANN requirements in Specification 10.

24.12. Footnotes

[1] New York Times, “99.999% Reliable? Don’t Hold Your Breath”. http:⁄⁄www.nytimes.com⁄2011⁄01⁄09⁄business⁄09digi.html
gTLDFull Legal NameE-mail suffixDetail
.androidCharleston Road Registry Inc.google.comView
All Shared Registration System (SRS) services described in Question 23 will run on Google’s robust, high-performance platform. Google’s production platform is an extremely high-capacity, high-availability, scalable platform designed to support some of the most resource-intensive and often-used applications on the Internet, including Google Search, Gmail, and YouTube. Google builds large clusters out of thousands of individual servers. Google uses a common set of tools to allocate resources, provide access to basic services such as storage and locking, and to simplify programmers’ ability to build distributed systems using the cluster’s hardware. Rather than relying on expensive hardware to provide reliability, Google uses a more cost effective approach based on commodity components, and builds fault tolerance into its software. Google simultaneously increases performance, reliability, and scalability of our production systems by splitting work into shards and running multiple replicas of the same process.

The numbered sections below discuss details of our SRS implementation and capacity plans.

24.1. Google SRS (GSRS)

The Google Shared Registration System (GSRS) will provide all standard 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 Support for all domain names
- Domain Name System Security Extensions (DNSSEC) support
- IPv6 Support
- Data Escrow

For descriptions and details of all SRS functions, see Question 23.

24.2. Google SRS Components

GSRS will be a multi-tier application that consists of the following components.

- Google SRS Front End (GSRS-FE): Presentation. A web application which provides an interface between registrars, developers, and other parties that need access to Google Registry information through a web interface. GSRS-FE will also include a web-based WHOIS interface.
- Google SRS Back End (GSRS-BE): Business Logic. A representational state transfer (RESTful) service that exposes and controls all registry data. Most business logic related to registry data storage and persistence will be implemented in GSRS-BE.
- Google EPP (GEPP): API Proxy. A public end-point for EPP (Extensible Provisioning Protocol) for the top-level domain. GEPP will translate all EPP requests and responses to interface with GSRS-BE. For more information on EPP support, see Question 25.
- Google WHOIS (GWHO): A public end-point for WHOIS queries for the top-level domain. GWHO will translate all WHOIS requests and responses to interface with the GSRS-BE. For more information on WHOIS support, see Question 26.

In addition, GSRS will integrate with the following internal systems. These internal systems are designed for extremely high performance and robustness, and use the same technologies used for other high-capacity services currently in production.

- Google Persistence Service (Persistence): A multi-master persistence solution which will run on top of Google’s proprietary database, BigTable. The Google Persistence Service coordinates between masters using an algorithm for fault-tolerant distributed systems, such as Paxos. BigTable is Google’s internal implementation of a distributed hash table used for the majority of our persistence needs.
- Google Accounts (Authentication): An existing platform for creation and authentication of user accounts. Google Accounts provides a standard login page for all Google products, as well as programmatic access for internal applications to retrieve credentials for the logged-in user.
- Google Monetization (Billing, as needed for the TLD): A monetization and billing system. Enables Google products to create accounts, create invoices, and perform financial transactions for Google customers.
- Google Authoritative DNS (Master Zone File): A robust public DNS server. Google Authoritative DNS will receive master zone file information from the GSRS-BE and distribute DNS information to clients.

“Q24_SRS Services Diagram” shows the interactions with these systems as requests come into a Google datacenter and are handled appropriately. Note that, as shown in “Q24_SRS Services Diagram”, all SRS requests are passed to the GSRS-BE, which contains all business logic for Google Registry. Integrated services are then used as needed. Google plans to provision these services to handle significantly greater load than our most aggressive expectations -- see below for details.

24.3. Google SRS Deployment Parameters

Google plans to deploy GSRS in five geographically-distributed datacenters throughout North America. Traffic to these datacenters is dynamically adjusted according to load, and the system will be provisioned to allow two simultaneous datacenter outages without substantial performance impact.

Each datacenter will include several replicas to handle specific machine failures for any GSRS service. Google’s production servers include the ability to expand to add new servers dynamically according to need. If SRS performance suddenly requires additional throughput capacity -- for instance, during a Distributed Denial of Service (DDoS) attack -- Google will be able to enable up to 100 additional replica servers in any datacenter dynamically. The limit of 100 additional replica machines is a self-imposed limit and may be revised upward based on ongoing operational considerations.

Each machine will be able to support a minimum of 250 queries per second (read or write), where one query contains one record. For architectural simplicity, our initial implementation will read data without any additional SRS-level caches.

24.4. GSRS Performance Scaling

Google plans to deploy sufficient capacity to handle SRS request load on the same scale as the largest top-level domains on the Internet. These computations are detailed in “Q24_GSRS Performance and Scaling”.

The key factor for scaling GSRS performance capacity will be the GSRS-BE component. Other components for GSRS (both GSRS-FE and GEPP) will receive user requests and then transform them into Remote Procedure Call (RPC) calls to GSRS-BE. GSRS-FE and GEPP will not perform any CPU-, disk-, or memory-intensive computations themselves. The performance capacity estimations below will therefore discuss only GSRS-BE capacity.

Based on existing domains and calculations for inbound traffic, Google estimates that there will be about 2300 queries per second for EPP operations, consisting mostly of checks for existing domains, and 3600 queries per second for WHOIS operations. In total, Google estimates that GEPP-BE must handle roughly 5900 queries per second for a scale of 100 million domains. Other operations, such as zone file operations and developer API calls, will create a relatively negligible level of load.

Google will meet the SRS throughput requirement, with a 50% utilization rate, with 48 machines allocated across the five datacenters. At this level of utilization, our active capacity will be double the expected throughput requirement. If a datacenter is lost through a production outage or change request, then additional machines will be enabled immediately to take upon the additional load with no manual intervention required. Google production systems have the standard capability to enable new machines to handle increased capacity needs immediately.

These estimations do not include any smart caching anywhere in the architecture. If the Google Registry reaches a very large number of domains and additional capacity measures are required, Google will consider a design for an appropriate WHOIS and EPP check result caching plan to relieve load and to improve latency characteristics.

These estimates use a very aggressive set of assumptions for scaling, which should be sufficient for a large open domain.

24.5. GSRS Network Scaling

Google expects that our SRS network bandwidth requirements will be greatly below Google’s existing per-datacenter network capacity, even for its lowest-capacity datacenters in production. Details of its computations are included below.

Google assumes that 99% of RPC calls across both EPP and WHOIS will be less than 5 kB. EPP and WHOIS queries return more of a fixed number of records, and most queries will return only one record. 5 kB is derived as an estimate from taking the sample WHOIS output in the applicant guidebook, and multiplying it by three to account for XML inflation as if the same information passed through an EPP interface. Considering that most EPP commands are expected to be 〈check〉 commands, this is a very conservative estimate.

Google then uses 5 kB as the assumed size to calculate the estimates for bandwidth per machine and per datacenter at maximum load.

Network Bandwidth Requirements per Machine = Queries per Second * Size of RPC Calls

With 250 qps and 5 kB per query, Google expect a maximum of about 12.5 MB⁄s of bandwidth requirement. This is about one-eighth of our current absolute minimum commodity standard of 1 Gb Ethernet. Our backbone routers connect many metro networks around the globe at 10Gb or greater.

Network Bandwidth Requirement per datacenter = Requirements per Machine * Number of Machines

With 12.5 MB⁄s of bandwidth per machine, and 100 machines maximum per datacenter, Google expects a maximum of about 1.25 GB⁄s data requirements during a major event that requires increased load demand. All Google datacenters’ connections to its production network have a multiple 10 GB⁄s links, and many exceed this by far.

Based on these computations, Google believes that the network bandwidth required by the SRS system for as many as 100 million second-level domains will never exceed the capacity that even our smallest datacenter can provide.

24.6. Multi-Master Design

GSRS will use a multi-master architecture. This architecture is detailed further in Question 32. Machines across multiple datacenters will serve active traffic, with no machines on cold or hot standby. All instances of the data store update in real-time, and updates to registry data are committed across a quorum of replicas before the write is confirmed. When GSRS or a dependent service goes down or is drained by an outage, Google’s network architecture will redirect all affected traffic to another datacenter. Google will design most services as stateless, so service instances will not require any coordination mechanisms.

24.7 Google SRS Adherence to Specification 6

The Google Registry, and in particular the SRS will be compliant with all RFCs outlined in Specification 6. Any RFCs mentioned below and their successors will be complied with.

24.7.1 - Standards Compliance

24.7.1.1 DNS

Google’s domain name system (DNS) implementation will comply with RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966. See Question 35 for more details on DNS RFC implementation compliance.

24.7.1.2 EPP

Google’s EPP implementation will comply with RFCs 5910, 5730, 5731, 5732, 5733, 5734, 3915, and 3735 for any extensions developed. Please see Question 25 for more details on EPP RFC implementation compliance.

24.7.1.3 DNSSEC

Google’s DNSSEC implementation will comply with RFCs 4033, 4034, 4035, 4509, 5155, and the best practices indicated in RFC 4641. A DPS statement will be published for each TLD supported by the Google Registry. Please see Question 43 for more details on DNSSEC implementation compliance.

24.7.1.4 IDN

Google’s implementation of internationalized domain names (IDN) will comply with RFCs 5890, 5891, 5892, 5893 and ICANN’s published IDN Guidelines. Please see Question 44 for more details on IDN RFC implementation compliance.

24.7.1.5 IPv6

Google’s implementation of IPv6 will follow BCP 91 and RFCs 4472. All Registry services will be offered over IPv6. Please see Question 36 for more details on Google’s IPv6 implementation.

24.7.2 Registry Services and Wildcard Prohibition

Google understands the definition of “registry services” as defined in section 2.1 of Specification 6. Google will not support wildcard matching or resolution in the TLD zone as required by Section 2.2 of Specification 6.

24.7.3 Registry Continuity

Google will ensure registry continuity as specified in Section 3 of Specification 6. High availability, extraordinary event handling, and business continuity will be provided with respect to the TLD. See Question 39 for more details on Google’s Registry continuity plan.

24.7.4 Abuse Mitigation

Google will implement the abuse mitigation requirements as specified in Section 4 of Specification 6. An abuse contact will be made available. See Question 28 for more details on Google’s abuse handling. Google will also take action to remove malicious use of orphan glue records when provided evidence in written form that such records are present in connection with malicious content.

24.7.5 Supported Initial and Renewal Registration Periods

Google will implement the supported initial and renewal registration periods as specified in Section 5 of Specification 6. The Google Registry will support domain name registration with validity periods of between one to 10 years in increments of one year. Renewal registration may extend registration to a maximum of 10 years from renewal date in increments of one year.

24.8. Google SRS SLA and Adherence to Specification 10

The Google SRS will significantly exceed the requirements of the Service Level Requirement Matrix defined in Specification 10 in the gTLD Applicant Guidebook. All EPP and WHOIS⁄RDDS calls supported by the Google SRS system will have a 99.9% monthly uptime.

For the purpose of measuring this commitment, Google uses the following definitions:
RPC: A series of TCP⁄IP packets forming a distinct request, and the corresponding TCP⁄IP packets forming the response.
Error RPC: An RPC which does not return with 3x 95th percentile latency, or which fails because of internal transient errors.
Error Minute: Any minute during which 10% of RPC requests are error RPCs.
Monthly Uptime: The total number of minutes in a month minus the number of error minutes divided over the total number of minutes in the month, rounded to the nearest .01%.

When calculating monthly uptime percentage, Google does not distinguish between scheduled and unscheduled downtime.

Google will meet or exceed all service level agreements (SLA) described in the ICANN Applicant Guidebook. Specifically, Google will meet the commitments as specified in attachment “Q24_SLAs”. Note that the values represent a commitment to exceed SLA Requirements in Specification 10.

DNS
- DNS Availability: 0 minutes of downtime.
- DNS Name Server Availability: Less than 31 minutes of downtime per month (At least 99.93% availability)
- TCP DNS resolution RTT: 300ms for at least 95% of the queries
- UDP DNS resolution RTT: 300ms for at least 95% of the queries
- DNS update time: 15 min, for at least 95% of the probes

RDDS (WHOIS)
- RDDS Availability: Less than 43 minutes of downtime per month. (At least 99.9% availability)
- RDDS Query RTT: Less than 400 ms.
- RDDS Update Time: Less than 15 minutes for 95% of probes.

EPP
- EPP Service Availability: Less than 43 minutes of downtime per month. (At least 99.9% availability)
- EPP Session-Command RTT: Less than 1000 ms for at least 95% of commands.
- EPP Query-Command RTT: Less than 400 ms for at least 95% of commands.
- EPP Transform-Command RTT: Less than 800 ms for at least 95% of commands.

Downtime values are on a monthly basis.

Google has the track record to deliver SRS to 99.9% availability. Google is confident in its ability to meet these SLAs for SRS because of its experience with engineering highly-available platforms. As discussed by Urs Hoelzle, Senior Vice President of Technical Architecture, Google has designed its major services to obtain 99.99% reliability [1].

24.9. SRS Technical Support

Charleston Road Registry will provide registrars with access to telephone, email, and web chat support, and will escalate issues to the Google technical team as technical faults are identified. For a further elaboration of the escalation process, see Question 42.

Google will notify ICANN and registrars, at least 24 hours beforehand, of maintenance for all planned outages and maintenance which will directly, significantly, and visibly affect users of the SRS.

24.10. Resourcing Plans

Google will implement these technical requirements using the teams and resources discussed below.

The cost of these services will generally be set at reasonable market rates per agreement between Charleston Road Registry and Google. The expected costs are discussed in Questions 46 and 47.

All services that GSRS will depend on are already well-provisioned and ready to assume the additional load of the Google SRS, including up to 100 million second-level domains, which is well in excess of expected need. The load that GSRS will generate for existing systems will be significantly less than the capacity already designated as part of normal growth for Google and the company’s need for high-performance hardware and support personnel resources.

24.10.1. Registry Team

The Google Registry Team will be responsible for designing and implementing our SRS, EPP, and WHOIS systems, including IDNs. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least four to seven software engineers responsible for implementing the project. Additionally, Google plans to staff one software engineer who is responsible for engineering testing and monitoring for the Google Registry, and one software engineer who is responsible for backup, restoration and escrow. In total, Google plans to implement the Google Registry with a team of six to nine software engineers.

After the Google Registry is complete, Google expects to staff a team to support the ongoing operation of the registry. This team will consist of at least four engineers who will participate in on-call rotation, respond to alerts, provide support to ICANN and registrars for emergency escalations, and maintain responsibility for bug fixes and improvements. This team will continue maintenance throughout the life of the registry.

This team’s responsibilities will generally be limited to registry-specific components. The Google Registry Team will work closely with other relevant teams, including the Authoritative DNS support team, Storage Site Reliability Engineering team, network engineering and operations, and customer support teams. These other teams are described in more detail in Question 31 (Section 31.16) as well as the relevant sections throughout this application.

24.11. Summary and Key Insights

Google has an existing production infrastructure that can exceed the performance requirements of the SRS platform:
- Google has a global network of datacenters to provide the scalability to meet the performance requirements of SRS.
- Google has a multi-master high availability strategy to meet the reliability requirements of SRS.
- Google has the proven operational processes and personnel to support the requirements going forward.
- The use of Google’s platform allows Charleston Road Registry to commit to service levels that substantially exceed the ICANN requirements in Specification 10.

24.12. Footnotes

[1] New York Times, “99.999% Reliable? Don’t Hold Your Breath”. http:⁄⁄www.nytimes.com⁄2011⁄01⁄09⁄business⁄09digi.html