Back

26 Whois

gTLDFull Legal NameE-mail suffixDetail
.gooCharleston Road Registry Inc.google.comView
Google will implement and maintain a “thick” data model WHOIS service, in which the registry will store and serve contact information related to each domain name -- as opposed to a “thin” model, which provides a query referral to a registrar.

Google will operate a public WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service at 〈WHOIS.nic.goo〉 providing free, public query-based access. Both of these services will be made available over both IPv4 and IPv6.

Google’s WHOIS service on port 43 will comply with the WHOIS protocol as described in RFC 3912 by accepting an ASCII request (terminated with a 〈CR〉〈LF〉) and replying with an ASCII response, terminating the TCP connection once the output is finished. RFC 3912 does not contain further detail on the format of the response payload itself; the format will be as described in “SPECIFICATION 4: SPECIFICATION FOR REGISTRATION DATA PUBLICATION SERVICES”, Section 1, and relevant Best Practices.

If ICANN specifies alternative formats and protocols, Google will implement these as soon as reasonably practical and will implement IDN related WHOIS requirements as they evolve. As a matter of policy, Google WHOIS will not return IDN variants for WHOIS queries. Queries for specific domains must be made.

26.1 High-level overview of the WHOIS service.

The attachment “Q26_WHOIS Services Diagram” shows an overview diagram of WHOIS services, and other relevant aspects of Google’s network.

Step 1: Request.
When a request is received (via the web or “traditional” interface), the appropriate service will extract the query from the request and perform checks to combat abusive behavior (such as Denial of Service and “WHOIS scraping”). Google has extensive infrastructure that profiles requests and applies heuristics to determine if requests are legitimate or “scraping”, and we plan to use this infrastructure to limit abuse of the WHOIS service. This functionality is described in Question 30, Section 30.b.3.2.

The request will also increment a counter to allow for reporting of statistics.

Step 2: Lookup.

The service will then query the registry database service, using the GSRS backend API. As the WHOIS service will query the database for the response, Google will provide fresh answers, instead of extracting all of the data from the database and synchronizing the data between servers. In order to provide fast, accurate responses, and to act as the first line of defense against DoS attacks, the WHOIS service may cache the result and reply from cache on subsequent queries for a maximum of 15 minutes.

Step 3: Reply
Once a result, or an indication that the requested information does not exist, is received from the database it will be converted into the appropriate response format: HTML for web-based requests, or RFC 3912 style responses for port 43 requests.

Step 4: Response.
The result of the lookup will then be returned to the requester.

26.2. WHOIS Infrastructure

Google operates a fast, reliable, and redundant network, and has developed frameworks for encoding and making remote procedure calls (RPCs). This infrastructure can be leveraged to provide communication and connectivity with other registry systems.

Google has significant experience developing secure, stable, resilient, and high-performance applications that perform lookups against a datastore, and has built substantial infrastructure for running such applications and scaling them to meet demand.

As described in detail in the responses to Questions 31 and 32, the WHOIS service will be designed as a simple, stateless server that accepts user queries and transforms them into RPCs that will be serviced by the SRS backend server. This model allows additional capacity to be scaled in accordance with need simply by adding additional replicas of the WHOIS server, and means that the resource requirements to operate this layer of the service should be minimal. Google continuously monitors the load on production servers and systems and proactively upgrades and supplements systems before there is any degradation in service. The registry will be initially provisioned to support at least 100 million domain names, which substantially exceeds the expected load, but Google’s overall scale would allow the scope of the service to be increased substantially if required.

We estimate that each second-level domain will generate slightly more than 3 WHOIS queries per day. Based on our projections, this will result in an expected load of 3600 qps (queries per second) from WHOIS requests. Since each machine can handle 250 qps, and we plan for a 50% utilization rate, we expect to provision about 30 machines. For more details of our expected WHOIS load and performance capacity, see Question 24.

This infrastructure will also help Google meet and exceed the specified Service Level Agreements, including those in Section 10 of the Registry Agreement, as discussed in the response to Question 24. We plan to serve WHOIS queries with at least 99.9% availability, with less than 500 ms latency, and an update time of less than 15 minutes for 95% of updates.

26.3 WHOIS Synchronization

As mentioned in previous sections, all incoming RPCs to equivalent calls to the Google SRS Backend. This means that there is no synchronization between Google WHOIS and the SRS since Google WHOIS maintains no persistent state. However, as also previously mentioned, Google may deploy a cache in the WHOIS service to reduce load on the GSRS BE and database while reducing latency, creating a freshness delay of up to 15 minutes.

26.4. WHOIS Data and Request⁄Response Example

Google WHOIS will follow data formats specified in Specification 4 in the application guidebook. Here is an example WHOIS domain query and response.

Query::
EXAMPLE.goo

Response:
Domain Name: EXAMPLE.goo
Domain ID: D424242-goo
WHOIS Server: WHOIS.nic.goo
Updated Date: 2012-08-13T20:13:00Z
Creation Date: 2012-02-14T00:45:00Z
Registry Expiry Date: 2014-10-08T00:44:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR LLC
Sponsoring Registrar IANA ID: 314159265
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State⁄Province: AP
Registrant Postal Code: A1A1A1
Registrant Country: EX
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.goo
Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State⁄Province: AP
Admin Postal Code: A1A1A1
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.goo
Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State⁄Province: AP
Tech Postal Code: A1A1A1
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.goo
Name Server: NS01.EXAMPLEREGISTRAR.goo
Name Server: NS02.EXAMPLEREGISTRAR.goo
DNSSEC: signedDelegation
DNSSEC: unsigned
〉〉〉 Last update of WHOIS database: 2012-08-13T20:15:00Z 〈〈〈

26.5 Bulk Registration Data Access to ICANN

The Google Registry will comply with Section 3 of Specification 4 in the application guidebook to provide ICANN bulk registration data access.

Data will be provided on a weekly basis. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.

The Google Registry will provide at a minimum all content requested in the specification: domain name, domain name repository, object id, registrar id, statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars, the registry will provide: registrar name, registrar repository object id, hostname of registrar Whois server, and URL of registrar.

The format of the data will be provided as specified in Specification 2 for Data Escrow.

The Google Registry will have the file ready for download as of 00:00:00 UTC on the day designated for retrieval by ICANN. The file will be made available for download by SFTP with a hostname, username, and password provided to ICANN.

26.6. Resourcing

Google Inc. 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.

26.6.1. Registry Team

Our 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 4-7 software engineers responsible for implementing the project. Additionally, we plan to staff one software engineer who is responsible for engineering testing and monitoring for the registry, and one software engineer who is responsible for backup, restoration and escrow. In total, we plan to implement the registry with a team of 6-9 software engineers.

After the registry is complete, we expect 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 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.

26.7. Summary and Key Insights

- Google will operate a thick WHOIS service with an interface on port 43 complying with RFC 3912 as well as a web-based query interface. These services will display data in accordance with Specification 4 of the registry agreement.
- Google’s WHOIS service offers a simple, stateless, scalable front end to the registry’s SRS-BE servers. The capacity of the service can be expanded simply by adding additional replica WHOIS servers. Google will initially scale the service to support a registry with 100 million domain names.
gTLDFull Legal NameE-mail suffixDetail
.pageCharleston Road Registry Inc.google.comView
Google will implement and maintain a “thick” data model WHOIS service, in which the registry will store and serve contact information related to each domain name -- as opposed to a “thin” model, which provides a query referral to a registrar.

Google will operate a public WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service at 〈WHOIS.nic.page〉 providing free, public query-based access. Both of these services will be made available over both IPv4 and IPv6.

Google’s WHOIS service on port 43 will comply with the WHOIS protocol as described in RFC 3912 by accepting an ASCII request (terminated with a 〈CR〉〈LF〉) and replying with an ASCII response, terminating the TCP connection once the output is finished. RFC 3912 does not contain further detail on the format of the response payload itself; the format will be as described in “SPECIFICATION 4: SPECIFICATION FOR REGISTRATION DATA PUBLICATION SERVICES”, Section 1, and relevant Best Practices.

If ICANN specifies alternative formats and protocols, Google will implement these as soon as reasonably practical and will implement IDN related WHOIS requirements as they evolve. As a matter of policy, Google WHOIS will not return IDN variants for WHOIS queries. Queries for specific domains must be made.

26.1 High-level overview of the WHOIS service.

The attachment “Q26_WHOIS Services Diagram” shows an overview diagram of WHOIS services, and other relevant aspects of Google’s network.

Step 1: Request.
When a request is received (via the web or “traditional” interface), the appropriate service will extract the query from the request and perform checks to combat abusive behavior (such as Denial of Service and “WHOIS scraping”). Google has extensive infrastructure that profiles requests and applies heuristics to determine if requests are legitimate or “scraping”, and we plan to use this infrastructure to limit abuse of the WHOIS service. This functionality is described in Question 30, Section 30.b.3.2.

The request will also increment a counter to allow for reporting of statistics.

Step 2: Lookup.

The service will then query the registry database service, using the GSRS backend API. As the WHOIS service will query the database for the response, Google will provide fresh answers, instead of extracting all of the data from the database and synchronizing the data between servers. In order to provide fast, accurate responses, and to act as the first line of defense against DoS attacks, the WHOIS service may cache the result and reply from cache on subsequent queries for a maximum of 15 minutes.

Step 3: Reply
Once a result, or an indication that the requested information does not exist, is received from the database it will be converted into the appropriate response format: HTML for web-based requests, or RFC 3912 style responses for port 43 requests.

Step 4: Response.
The result of the lookup will then be returned to the requester.

26.2. WHOIS Infrastructure

Google operates a fast, reliable, and redundant network, and has developed frameworks for encoding and making remote procedure calls (RPCs). This infrastructure can be leveraged to provide communication and connectivity with other registry systems.

Google has significant experience developing secure, stable, resilient, and high-performance applications that perform lookups against a datastore, and has built substantial infrastructure for running such applications and scaling them to meet demand.

As described in detail in the responses to Questions 31 and 32, the WHOIS service will be designed as a simple, stateless server that accepts user queries and transforms them into RPCs that will be serviced by the SRS backend server. This model allows additional capacity to be scaled in accordance with need simply by adding additional replicas of the WHOIS server, and means that the resource requirements to operate this layer of the service should be minimal. Google continuously monitors the load on production servers and systems and proactively upgrades and supplements systems before there is any degradation in service. The registry will be initially provisioned to support at least 100 million domain names, which substantially exceeds the expected load, but Google’s overall scale would allow the scope of the service to be increased substantially if required.

We estimate that each second-level domain will generate slightly more than 3 WHOIS queries per day. Based on our projections, this will result in an expected load of 3600 qps (queries per second) from WHOIS requests. Since each machine can handle 250 qps, and we plan for a 50% utilization rate, we expect to provision about 30 machines. For more details of our expected WHOIS load and performance capacity, see Question 24.

This infrastructure will also help Google meet and exceed the specified Service Level Agreements, including those in Section 10 of the Registry Agreement, as discussed in the response to Question 24. We plan to serve WHOIS queries with at least 99.9% availability, with less than 500 ms latency, and an update time of less than 15 minutes for 95% of updates.

26.3 WHOIS Synchronization

As mentioned in previous sections, all incoming RPCs to equivalent calls to the Google SRS Backend. This means that there is no synchronization between Google WHOIS and the SRS since Google WHOIS maintains no persistent state. However, as also previously mentioned, Google may deploy a cache in the WHOIS service to reduce load on the GSRS BE and database while reducing latency, creating a freshness delay of up to 15 minutes.

26.4. WHOIS Data and Request⁄Response Example

Google WHOIS will follow data formats specified in Specification 4 in the application guidebook. Here is an example WHOIS domain query and response.

Query::
EXAMPLE.page

Response:
Domain Name: EXAMPLE.page
Domain ID: D424242-page
WHOIS Server: WHOIS.nic.page
Updated Date: 2012-08-13T20:13:00Z
Creation Date: 2012-02-14T00:45:00Z
Registry Expiry Date: 2014-10-08T00:44:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR LLC
Sponsoring Registrar IANA ID: 314159265
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State⁄Province: AP
Registrant Postal Code: A1A1A1
Registrant Country: EX
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.page
Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State⁄Province: AP
Admin Postal Code: A1A1A1
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.page
Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State⁄Province: AP
Tech Postal Code: A1A1A1
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.page
Name Server: NS01.EXAMPLEREGISTRAR.page
Name Server: NS02.EXAMPLEREGISTRAR.page
DNSSEC: signedDelegation
DNSSEC: unsigned
〉〉〉 Last update of WHOIS database: 2012-08-13T20:15:00Z 〈〈〈

26.5 Bulk Registration Data Access to ICANN

The Google Registry will comply with Section 3 of Specification 4 in the application guidebook to provide ICANN bulk registration data access.

Data will be provided on a weekly basis. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.

The Google Registry will provide at a minimum all content requested in the specification: domain name, domain name repository, object id, registrar id, statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars, the registry will provide: registrar name, registrar repository object id, hostname of registrar Whois server, and URL of registrar.

The format of the data will be provided as specified in Specification 2 for Data Escrow.

The Google Registry will have the file ready for download as of 00:00:00 UTC on the day designated for retrieval by ICANN. The file will be made available for download by SFTP with a hostname, username, and password provided to ICANN.

26.6. Resourcing

Google Inc. 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.

26.6.1. Registry Team

Our 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 4-7 software engineers responsible for implementing the project. Additionally, we plan to staff one software engineer who is responsible for engineering testing and monitoring for the registry, and one software engineer who is responsible for backup, restoration and escrow. In total, we plan to implement the registry with a team of 6-9 software engineers.

After the registry is complete, we expect 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 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.

26.7. Summary and Key Insights

- Google will operate a thick WHOIS service with an interface on port 43 complying with RFC 3912 as well as a web-based query interface. These services will display data in accordance with Specification 4 of the registry agreement.
- Google’s WHOIS service offers a simple, stateless, scalable front end to the registry’s SRS-BE servers. The capacity of the service can be expanded simply by adding additional replica WHOIS servers. Google will initially scale the service to support a registry with 100 million domain names.