Back

26 Whois

gTLDFull Legal NameE-mail suffixDetail
.theatreKey GTLD Holding Incwolfe-sbmc.comView
1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF THIS ASPECT OF REGISTRY TECHNICAL REQUIREMENTS
Verisign, the Applicant’s selected backend registry services provider, has operated the Whois lookup service for the gTLDs and ccTLDs it manages since 1991, and will provide these proven services for the TLD registry. In addition, it continues to work with the Internet community to improve the utility of Whois data, while thwarting its application for abusive uses.
1.1 High-Level Whois System Description
Like all other components of the Applicant’s selected backend registry services provider’s (Verisign’s) registry service, Verisign’s Whois system is designed and built for both reliability and performance in full compliance with applicable RFCs. Verisign’s current Whois implementation has answered more than five billion Whois queries per month for the TLDs it manages, and has experienced more than 250,000 queries per minute in peak conditions. The proposed gTLD uses a Whois system design and approach that is comparable to the current implementation. Independent quality control testing ensures Verisign’s Whois service is RFC-compliant through all phases of its lifecycle.
Verisignʹs redundant Whois databases further contribute to overall system availability and reliability. The hardware and software for its Whois service is architected to scale both horizontally (by adding more servers) and vertically (by adding more CPUs and memory to existing servers) to meet future need.
Verisign can fine-tune access to its Whois database on an individual Internet Protocol (IP) address basis, and it works with registrars to help ensure their services are not limited by any restriction placed on Whois. Verisign provides near real-time updates for Whois services for the TLDs under its management. As information is updated in the registration database, it is propagated to the Whois servers for quick publication. These updates align with the near real-time publication of Domain Name System (DNS) information as it is updated in the registration database. This capability is important for the TLD registry as it is Verisign’s experience that when DNS data is updated in near real time, so should Whois data be updated to reflect the registration specifics of those domain names.
Verisign’s Whois response time has been less than 500 milliseconds for 95 percent of all Whois queries in .com, .net, .tv, and .cc. The response time in these TLDs, combined with Verisign’s capacity, enables the Whois system to respond to up to 30,000 searches (or queries) per second for a total capacity of 2.6 billion queries per day.
The Whois software written by Verisign complies with RFC 3912. Verisign uses an advanced in-memory database technology to provide exceptional overall system performance and security. In accordance with RFC 3912, Verisign provides a website at whois.nic.〈TLD〉 that provides free public query-based access to the registration data.
Verisign currently operates both thin and thick Whois systems.
Verisign commits to implementing a RESTful Whois service upon finalization of agreements with the IETF (Internet Engineering Task Force).
Provided Functionalities for User Interface
To use the Whois service via port 43, the user enters the applicable parameter on the command line as illustrated here:
• For domain name: whois EXAMPLE.TLD
• For registrar: whois ʺregistrar Example Registrar, Inc.ʺ
• For name server: whois ʺNS1.EXAMPLE.TLDʺ or whois ʺname server (IP address)ʺ

To use the Whois service via the web-based directory service search interface:
• Go to http:⁄⁄whois.nic.〈TLD〉
• Click on the appropriate button (Domain, Registrar, or Name Server)
• Enter the applicable parameter:
o Domain name, including the TLD (e.g., EXAMPLE.TLD)
o Full name of the registrar, including punctuation (e.g., Example Registrar, Inc.)
o Full host name or the IP address (e.g., NS1.EXAMPLE.TLD or 198.41.3.39)
• Click on the Submit button.
Provisions to Ensure That Access Is Limited to Legitimate Authorized Users and Is in Compliance with Applicable Privacy Laws or Policies
To further promote reliable and secure Whois operations, Verisign, the Applicant’s selected backend registry services provider, has implemented rate-limiting characteristics within the Whois service software. For example, to prevent data mining or other abusive behavior, the service can throttle a specific requestor if the query rate exceeds a configurable threshold. In addition, QoS technology enables rate limiting of queries before they reach the servers, which helps protect against denial of service (DoS) and distributed denial of service (DDoS) attacks.
Verisign’s software also permits restrictions on search capabilities. For example, wild card searches can be disabled. If needed, it is possible to temporarily restrict and⁄or block requests coming from specific IP addresses for a configurable amount of time. Additional features that are configurable in the Whois software include help files, headers and footers for Whois query responses, statistics, and methods to memory map the database. Furthermore, Verisign is European Union (EU) Safe Harbor certified and has worked with European data protection authorities to address applicable privacy laws by developing a tiered Whois access structure that requires users who require access to more extensive data to (i) identify themselves, (ii) confirm that their use is for a specified purpose and (iii) enter into an agreement governing their use of the more extensive Whois data.
1.2 Relevant Network Diagrams
Figure ‎26 1 provides a summary network diagram of the Whois service provided by Verisign, the Applicant’s selected backend registry services provider. The figure details the configuration with one resolution⁄Whois site. For this TLD Verisign provides Whois service from 6 of its 17 primary sites based on the proposed gTLD’s traffic volume and patterns. A functionally equivalent resolution architecture configuration exists at each Whois site.
1.3 IT and Infrastructure Resources
Figure ‎26 2 summarizes the IT and infrastructure resources that Verisign, the Applicant’s selected backend registry services provider, uses to provision Whois services from Verisign primary resolution sites. As needed, virtual machines are created based on actual and projected demand.

1.4 Description of Interconnectivity with Other Registry Systems
Figure ‎26 3 provides a technical overview of the registry system provided by Verisign, the Applicant’s selected backend registry services provider, and shows how the Whois service component fits into this larger system and interconnects with other system components.
1.5 Frequency of Synchronization Between Servers
Synchronization between the SRS and the geographically distributed Whois resolution sites occurs approximately every three minutes. Verisign, the Applicant’s selected backend registry services provider, uses a two-part Whois update process to ensure Whois data is accurate and available. Every 12 hours an initial file is distributed to each resolution site. This file is a complete copy of all Whois data fields associated with each domain name under management. As interactions with the SRS cause the Whois data to be changed, these incremental changes are distributed to the resolution sites as an incremental file update. This incremental update occurs approximately every three minutes. When the new 12-hour full update is distributed, this file includes all past incremental updates. Verisign’s approach to frequency of synchronization between servers meets the Performance Specifications defined in Specification 10 of the Registry Agreement for new gTLDs.
2 TECHNICAL PLAN SCOPE⁄SCALE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY
Verisign, the Applicant’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.
Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the TLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to the Applicant fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
3 TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION
Verisign, the Applicant’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to the Applicant fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support Whois services:
• Application Engineers: 19
• Database Engineers: 3
• Quality Assurance Engineers: 11

To implement and manage the TLD as described in this application, Verisign, the Applicant’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.
4 COMPLIANCE WITH RELEVANT RFC
The Applicant’s selected backend registry services provider’s (Verisign’s) Whois service complies with the data formats defined in Specification 4 of the Registry Agreement. Verisign will provision Whois services for registered domain names and associated data in the top-level domain (TLD). Verisign’s Whois services are accessible over Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), via both Transmission Control Protocol (TCP) port 43 and a web-based directory service at whois.nic.〈TLD〉, which in accordance with RFC 3912, provides free public query-based access to domain name, registrar, and name server lookups. Verisign’s proposed Whois system meets all requirements as defined by ICANN for each registry under Verisign management. Evidence of this successful implementation, and thus compliance with the applicable RFCs, can be verified by a review of the .com and .net Registry Operator’s Monthly Reports that Verisign files with ICANN. These reports provide evidence of Verisign’s ability to meet registry operation service level agreements (SLAs) comparable to those detailed in Specification 10. The reports are accessible at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.
5 COMPLIANCE WITH SPECIFICATIONS 4 AND 10 OF REGISTRY AGREEMENT
In accordance with Specification 4, Verisign, the Applicant’s selected backend registry services provider, provides a Whois service that is available via both port 43 in accordance with RFC 3912, and a web-based directory service at whois.nic.〈TLD〉 also in accordance with RFC 3912, thereby providing free public query-based access. Verisign acknowledges that ICANN reserves the right to specify alternative formats and protocols, and upon such specification, Verisign will implement such alternative specification as soon as reasonably practicable.
The format of the following data fields conforms to the mappings specified in Extensible Provisioning Protocol (EPP) RFCs 5730 – 5734 so the display of this information (or values returned in Whois responses) can be uniformly processed and understood: domain name status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses, date, and times.
Specifications for data objects, bulk access, and lookups comply with Specification 4 and are detailed in the following subsections, provided in both bulk access and lookup modes.
Bulk Access Mode. This data is provided on a daily schedule to a party designated from time to time in writing by ICANN. The specification of the content and format of this data, and the procedures for providing access, shall be as stated below, until revised in the ICANN Registry Agreement.
The data is provided in three files:
• Domain Name File: For each domain name, the file provides the domain name, server name for each name server, registrar ID, and updated date.
• Name Server File: For each registered name server, the file provides the server name, each IP address, registrar ID, and updated date.
• Registrar File: For each registrar, the following data elements are provided: registrar ID, registrar address, registrar telephone number, registrar email address, Whois server, referral URL, updated date, and the name, telephone number, and email address of all the registrarʹs administrative, billing, and technical contacts.

Lookup Mode. Figures ‎26 4 through Figure ‎26 6 provide the query and response format for domain name, registrar, and name server data objects.
5.1 Specification 10, RDDS Registry Performance Specifications
The Whois service meets all registration data directory services (RDDS) registry performance specifications detailed in Specification 10, Section 2. Evidence of this performance can be verified by a review of the .com and .net Registry Operator’s Monthly Reports that Verisign files monthly with ICANN. These reports are accessible from the ICANN website at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

In accordance with RDDS registry performance specifications detailed in Specification 10, Verisignʹs Whois service meets the following proven performance attributes:
• RDDS availability: 864 min of downtime (98%)
• RDDS query RTT: 2000 ms, for at least 95% of the queries
• RDDS update time: 60 min, for at least 95% of the probes
6 SEARCHABLE WHOIS
Verisign, the Applicant’s selected backend registry services provider, provides a searchable Whois service for the TLD. Verisign has experience in providing tiered access to Whois for the .name registry, and uses these methods and control structures to help reduce potential malicious use of the function. The searchable Whois system currently uses Apache’s Lucene full text search engine to index relevant Whois content with near-real time incremental updates from the provisioning system.
Features of the Verisign searchable Whois function include:

• Provision of a web-based searchable directory service
• Ability to perform partial match, at least, for the following data fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state, or province)
• Ability to perform exact match, at least, on the following fields: registrar ID, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records)
• Ability to perform Boolean search supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT
• Search results that include domain names that match the selected search criteria

Verisign’s implementation of searchable Whois is EU Safe Harbor certified and includes appropriate access control measures that help ensure that only legitimate authorized users can use the service. Furthermore, Verisign’s compliance office monitors current ICANN policy and applicable privacy laws or policies to help ensure the solution is maintained within compliance of applicable regulations. Features of these access control measures include:

• All unauthenticated searches are returned as thin results.
• Registry system authentication is used to grant access to appropriate users for thick Whois data search results.
• Account access is granted by the Applicant’s defined TLD admin user.

Potential Forms of Abuse and Related Risk Mitigation. Leveraging its experience providing tiered access to Whois for the .name registry and interacting with ICANN, data protection authorities, and applicable industry groups, Verisign, the Applicant’s selected backend registry services provider, is knowledgeable of the likely data mining forms of abuse associated with a searchable Whois service. Figure ‎26 7 summarizes these potential forms of abuse and Verisign’s approach to mitigate the identified risk.
gTLDFull Legal NameE-mail suffixDetail
.コムVeriSign Sarlverisign.comView
1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF THIS ASPECT OF REGISTRY TECHNICAL REQUIREMENTS

Verisign has operated the Whois lookup service for the gTLDs and ccTLDs we manage since
1991, and will provide these proven services for the JAPANESE_TRANSLITERATION_OF_.COM gTLD registry. In
addition, we continue to work with the Internet community to improve the utility of Whois data,
while thwarting its application for abusive uses.


1.1 High-Level Whois System Description

Like all other components of our registry service, our Whois system is designed and built for
both reliability and performance in full compliance with applicable RFCs. Our current Whois
implementation has answered more than five billion Whois queries per month for the TLDs we
manage, and has experienced more than 250,000 queries per minute in peak conditions. The
proposed gTLD uses a Whois system design and approach that is comparable to the current
implementation. Independent quality control testing ensures our Whois service is RFC-
compliant through all phases of its lifecycle.

Our redundant Whois databases further contribute to overall system availability and reliability.
The hardware and software for our Whois service is architected to scale both horizontally (by
adding more servers) and vertically (by adding more CPUs and memory to existing servers) to
meet future need.

We can fine-tune access to our Whois database on an individual Internet Protocol (IP) address
basis, and we work with registrars to help ensure their services are not limited by any restriction
placed on Whois. We provide near real-time updates for Whois services for the TLDs under our
management. As information is updated in the registration database, it is propagated to the
Whois servers for quick publication. These updates align with the near real-time publication of
Domain Name System (DNS) information as it is updated in the registration database. This
capability is important for the JAPANESE_TRANSLITERATION_OF_.COM gTLD registry as it is Verisign’s experience
that when DNS data is updated in near real time, so should Whois data be updated to reflect the
registration specifics of those domain names.

Verisign’s Whois response time has been less than 500 milliseconds for 95 percent of all Whois
queries in .com, .net, .tv, and .cc. The response time in these TLDs, combined with our
capacity, enables the Whois system to respond to up to 30,000 searches (or queries) per
second for a total capacity of 2.6 billion queries per day.

The Whois software written by Verisign complies with RFC 3912. We use an advanced in-
memory database technology to provide exceptional overall system performance and security.
In accordance with RFC 3912, we provide a website at whois.nic.〈TLD〉 that provides free
public query-based access to the registration data.

We currently operate both thin and thick Whois systems.

Verisign commits to implementing a RESTful Whois service upon finalization of the relevant
standards and protocols by the IETF (Internet Engineering Task Force).


Provided Functionalities for User Interface

To use the Whois service via port 43, the user enters the applicable parameter on the command
line as illustrated here:

* For domain name: whois EXAMPLE.TLD

* For registrar: whois ʺregistrar Example Registrar, Inc.ʺ

* For name server: whois ʺNS1.EXAMPLE.TLDʺ or whois ʺname server (IP address)ʺ


To use the Whois service via the web-based directory service search interface:

* Go to http:⁄⁄whois.nic.〈TLD〉

* Click on the appropriate button (Domain, Registrar, or Name Server)

* Enter the applicable parameter:
a. Domain name, including the TLD (e.g., EXAMPLE.TLD)
b. Full name of the registrar, including punctuation (e.g., Example Registrar, Inc.)
c. Full host name or the IP address (e.g., NS1.EXAMPLE.TLD or 198.41.3.39)

* Click on the Submit button.


Provisions to Ensure That Access Is Limited to Legitimate Authorized Users and Is in Compliance
with Applicable Privacy Laws or Policies

To further promote reliable and secure Whois operations, Verisign has implemented rate-limiting
characteristics within the Whois service software. For example, to prevent data mining or other
abusive behavior, the service can throttle a specific requestor if the query rate exceeds a
configurable threshold. In addition, QoS technology enables rate limiting of queries before they
reach the servers, which helps protect against denial of service (DoS) and distributed denial of
service (DDoS) attacks.

Our software also permits restrictions on search capabilities. For example, wild card searches
can be disabled. If needed, it is possible to temporarily restrict and⁄or block requests coming
from specific IP addresses for a configurable amount of time. Additional features that are
configurable in the Whois software include help files, headers and footers for Whois query
responses, statistics, and methods to memory map the database. Furthermore, we are
European Union (EU) Safe Harbor certified and have worked with European data protection
authorities to address applicable privacy laws by developing a tiered Whois access structure
that requires users who require access to more extensive data to (i) identify themselves, (ii)
confirm that their use is for a specified purpose and (iii) enter into an agreement governing their
use of the more extensive Whois data.


1.2 Relevant Network Diagrams

Figure 26-1 (see Attachment VRSN_.comJapan_Q26 Figures for all figures in this
response) provides a summary network diagram of the Whois service provided by Verisign. The
figure details the configuration with one resolution⁄Whois site. For the JAPANESE_TRANSLITERATION_OF_.COM
gTLD, we provide Whois service from six of our 17 primary sites based on the proposed gTLD’s
traffic volume and patterns. A functionally equivalent resolution architecture configuration exists
at each Whois site.


1.3 IT and Infrastructure Resources

Figure 26-2 summarizes the IT and infrastructure resources that Verisign uses to provision
Whois services from Verisign primary resolution sites. As needed, virtual machines are created
based on actual and projected demand.


1.4 Description of Interconnectivity with Other Registry Systems

Figure 26-3 provides a technical overview of Verisign’s registry system, and shows how the
Whois service component fits into this larger system and interconnects with other system
components.


1.5 Frequency of Synchronization Between Servers

Synchronization between the SRS and the geographically distributed Whois resolution sites
occurs approximately every three minutes. We use a two-part Whois update process to ensure
Whois data is accurate and available. Every 12 hours an initial file is distributed to each
resolution site. This file is a complete copy of all Whois data fields associated with each domain
name under management. As interactions with the SRS cause the Whois data to be changed,
these incremental changes are distributed to the resolution sites as an incremental file update.
This incremental update occurs approximately every three minutes. When the new 12-hour full
update is distributed, this file includes all past incremental updates. Our approach to frequency
of synchronization between servers meets the Performance Specifications defined in
Specification 10 of the Registry Agreement for new gTLDs.



2 TECHNICAL PLAN SCOPE⁄SCALE CONSISTENT WITH THE OVERALL BUSINESS APPROACH
AND PLANNED SIZE OF THE REGISTRY

As an experienced backend registry provider, we have developed and use proprietary system
scaling models to guide the growth of our TLD supporting infrastructure. These models direct
our infrastructure scaling to include, but not be limited to, server capacity, data storage volume,
and network throughput that are aligned to projected demand and usage patterns. We
periodically update these models to account for the adoption of more capable and cost-effective
technologies.

Our scaling models are proven predictors of needed capacity and related cost. As such, they
provide the means to link the projected infrastructure needs of the JAPANESE_TRANSLITERATION_OF_.COM gTLD
with necessary implementation and sustainment cost. Using the projected usage volume for the
most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as
an input to our scaling models, we derived the necessary infrastructure required to implement
and sustain this gTLD. Cost related to this infrastructure is provided as “Total Critical Registry
Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections
response.



3 TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED
IN THE FINANCIAL SECTION

As an experienced backend registry provider, we have developed a set of proprietary resourcing
models to project the number and type of personnel resources necessary to operate a TLD. We
routinely adjust these staffing models to account for new tools and process innovations. These
models enable us to continually right-size our staff to accommodate projected demand and
meet service level agreements as well as Internet security and stability requirements. Using the
projected usage volume for the most likely scenario (defined in Question 46, Template 1 –
Financial Projections: Most Likely) as an input to our staffing models, we derived the necessary
personnel levels required for this gTLD’s initial implementation and ongoing maintenance.
Cost related to this infrastructure is provided as “Total Critical Registry Function Cash Outflows”
(Template 1, Line IIb.G) within the Question 46 financial projections response.

We employ more than 1,040 individuals of which more than 775 comprise our technical work
force. (Current statistics are publicly available in our quarterly filings.) Drawing from this pool of
on-hand and fully committed technical resources, we have maintained DNS operational
accuracy and stability 100 percent of the time for more than 13 years for .com, proving our
ability to align personnel resource growth to the scale increases of our TLD service offerings.

We project we will use the following personnel roles, which are described in Section 5 of the
response to Question 31, Technical Overview of Proposed Registry, to support Whois services:

* Application Engineers: 19
* Database Engineers: 3
* Quality Assurance Engineers: 11


To implement and manage the JAPANESE_TRANSLITERATION_OF_.COM gTLD as described in this application, we
scale, as needed, the size of each technical area now supporting our portfolio of TLDs.
Consistent with our resource modeling, we periodically review the level of work to be performed
and adjust staff levels for each technical area.

When usage projections indicate a need for additional staff, our internal staffing group uses an
in-place staffing process to identify qualified candidates. These candidates are then interviewed
by the lead of the relevant technical area. By scaling one common team across all our TLDs
instead of creating a new entity to manage only this proposed gTLD, we realize significant
economies of scale and ensure our TLD best practices are followed consistently. This
consistent application of best practices helps ensure the security and stability of both the
Internet and this proposed gTLD, as we hold all contributing staff members accountable to the
same procedures that guide our execution of the Internet’s largest TLDs (i.e., .com and .net).
Moreover, by augmenting existing teams, we afford new employees the opportunity to be
mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps
ensure that new staff members properly execute their duties.



4 COMPLIANCE WITH RELEVANT RFC

Verisign’s Whois service complies with the data formats defined in Specification 4 of the
Registry Agreement. We will provision Whois services for registered domain names and
associated data in the top-level domain (TLD). Our Whois services are accessible over Internet
Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), via both Transmission Control
Protocol (TCP) port 43 and a web-based directory service at whois.nic.〈TLD〉, which in
accordance with RFC 3912, provides free public query-based access to domain name, registrar,
and name server lookups. Our proposed Whois system meets all requirements as defined by
ICANN for each registry under our management. Evidence of this successful implementation,
and thus compliance with the applicable RFCs, can be verified by a review of the .com and .net
Registry Operator’s Monthly Reports that we file with ICANN. These reports provide evidence of
our ability to meet registry operation service level agreements (SLAs) comparable to those
detailed in Specification 10. The reports are accessible at the following URL:
http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.



5 COMPLIANCE WITH SPECIFICATIONS 4 AND 10 OF REGISTRY AGREEMENT

In accordance with Specification 4, Verisign provides a Whois service that is available via both
port 43 in accordance with RFC 3912, and a web-based directory service at whois.nic.〈TLD〉
also in accordance with RFC 3912, thereby providing free public query-based access. We
acknowledge that ICANN reserves the right to specify alternative formats and protocols, and
upon such specification, we will implement such alternative specification as soon as reasonably
practicable.

The format of the following data fields conforms to the mappings specified in Extensible
Provisioning Protocol (EPP) RFCs 5730 – 5734 so the display of this information (or values
returned in Whois responses) can be uniformly processed and understood: domain name
status, individual and organizational names, address, street, city, state⁄province, postal code,
country, telephone and fax numbers, email addresses, date, and times.

Specifications for data objects, bulk access, and lookups comply with Specification 4 and are
detailed in the following subsections, provided in both bulk access and lookup modes.


Bulk Access Mode

This data is provided on a daily schedule to a party designated from time to time in writing by
ICANN. The specification of the content and format of this data, and the procedures for
providing access, shall be as stated below, until revised in the ICANN Registry Agreement.

The data is provided in three files:

* Domain Name File: For each domain name, the file provides the domain name, server
name for each name server, registrar ID, and updated date.

* Name Server File: For each registered name server, the file provides the server name,
each IP address, registrar ID, and updated date.

* Registrar File: For each registrar, the following data elements are provided: registrar ID,
registrar address, registrar telephone number, registrar email address, Whois server,
referral URL, updated date, and the name, telephone number, and email address of all
the registrarʹs administrative, billing, and technical contacts.


Lookup Mode

Figures 26-4 through Figure 26-6 provide the query and response format for domain name,
registrar, and name server data objects


5.1 Specification 10, RDDS Registry Performance Specifications

Verisign’s Whois service meets all registration data directory services (RDDS) registry
performance specifications detailed in Specification 10, Section 2. Evidence of this performance
can be verified by a review of the .com and .net Registry Operator’s Monthly Reports that we file
monthly with ICANN. These reports are accessible from the ICANN website at the following
URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

In accordance with RDDS registry performance specifications detailed in Specification 10, our
Whois service meets the following proven performance attributes:

* RDDS availability: Fewer than or equal to 864 min of downtime (approximately 98%)

* RDDS query RTT: Fewer than or equal to 2000 ms, for at least 95% of the queries

* RDDS update time: Fewer than or equal to 60 min, for at least 95% of the probes



6 SEARCHABLE WHOIS

Verisign provides a searchable Whois service for the JAPANESE_TRANSLITERATION_OF_.COM gTLD. We have
experience in providing tiered access to Whois for the .name registry, and we use these
methods and control structures to help reduce potential malicious use of the function. The
searchable Whois system currently uses Apache’s Lucene full text search engine to index
relevant Whois content with near-real time incremental updates from the provisioning system.

Features of our searchable Whois function include:

* Provision of a web-based searchable directory service

* Ability to perform partial match, at least, for the following data fields: domain name,
contacts and registrant’s name, and contact and registrant’s postal address, including all
the sub-fields described in EPP (e.g., street, city, state, or province)

* Ability to perform exact match, at least, on the following fields: registrar ID, name server
name, and name server’s IP address (only applies to IP addresses stored by the
registry, i.e., glue records)

* Ability to perform Boolean search supporting, at least, the following logical operators to
join a set of search criteria: AND, OR, NOT

* Search results that include domain names that match the selected search criteria


Our implementation of searchable Whois is EU Safe Harbor certified and includes appropriate
access control measures that help ensure that only legitimate authorized users can use the
service. Furthermore, our compliance office monitors current ICANN policy and applicable
privacy laws or policies to help ensure the solution is maintained within compliance of applicable
regulations. Features of these access control measures include:

* All unauthenticated searches are returned as thin results.

* Registry system authentication is used to grant access to appropriate users for thick
Whois data search results.

* Account access is granted by our defined JAPANESE_TRANSLITERATION_OF_.COM gTLD admin user.


Potential Forms of Abuse and Related Risk Mitigation

Leveraging our experience providing tiered access to Whois for the .name registry and interacting
with ICANN, data protection authorities, and applicable industry groups, we are knowledgeable of the
likely data mining forms of abuse associated with a searchable Whois service. Figure 26-7 summarizes these
potential forms of abuse and our approach to mitigate the identified risk.