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

Prototypical answer:

1 CUSTOMARY REGISTRY SERVICES

Verisign provides a comprehensive system and physical security solution that is designed to
ensure a TLD is protected from unauthorized disclosure, alteration, insertion, or destruction of
registry data. Our system addresses all areas of security including information and policies,
security procedures, the systems development lifecycle, physical security, system hacks, break-
ins, data tampering, and other disruptions to operations. Our operational environments not only
meet the security criteria specified in our customer contractual agreements, thereby preventing
unauthorized access to or disclosure of information or resources on the Internet by systems
operating in accordance with applicable standards, but also are subject to multiple independent
assessments as detailed in the response to Question 30, Security Policy. Our physical and
system security methodology follows a mature, ongoing lifecycle that was developed and
implemented many years before the development of the industry standards with which we
currently comply. Please see the response to Question 30, Security Policy, for details of the
security features of our registry services.

Our registry services fully comply with relevant standards and best current practice RFCs
published by the Internet Engineering Task Force (IETF), including all successor standards,
modifications, or additions relating to the DNS and name server operations including without
limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472.
Moreover, our Shared Registration System (SRS) supports the following IETF Extensible
Provisioning Protocol (EPP) specifications, where the Extensible Markup Language (XML)
templates and XML schemas are defined in RFC 3915, 5730, 5731, 5732, 5733, and 5734. By
strictly adhering to these RFCs, we help ensure our registry services do not create a condition
that adversely affects the throughput, response time, consistency, or coherence of responses to
Internet servers or end systems. Besides our leadership in authoring RFCs for EPP, Domain
Name System Security Extensions (DNSSEC), and other DNS services, we have created and
contributed to several now well-established IETF standards and are a regular and long-standing
participant in key Internet standards forums.

Figure 23-1 (see Attachment VRSN_.verisign_Q23_Figures for all figures in this question
response) summarizes the technical and business components of those registry services,
customarily offered by a registry operator (i.e., Verisign), that support this application. These
services are currently operational and support both large and small Verisign-managed
registries. Customary registry services are provided in the same manner as we provide these
services for our existing gTLDs.

Through these established registry services, we have proven our ability to operate a reliable and
low-risk registry that supports millions of transactions per day. We are unaware of any potential
security or stability concern related to any of these services.
Registry services defined by this application are not intended to be offered in a manner unique
to the new generic top-level domain (gTLD) nor are any proposed services unique to this
application’s registry.

As further evidence of our compliance with ICANN mandated security and stability
requirements, Verisign allocates the applicable RFCs to each of the five customary registry
services (items A – E above). For each registry service, we also provide evidence in Figure 23-2
of our RFC compliance and include relevant ICANN prior-service approval actions.

1.1 Critical Operations of the Registry

i. Receipt of Data from Registrars Concerning Registration of Domain Names and
Name Servers

See Item A in Figure 23-1 and Figure 23-2.

ii. Provision to Registrars Status Information Relating to the Zone Servers

Verisign registry services provisions to registrars status information relating to zone servers for
the TLD. The services also allow a domain name to be updated with clientHold, serverHold
status, which removes the domain name server details from zone files. This ensures that DNS
queries of the domain name are not resolved temporarily. When these hold statuses are
removed, the name server details are written back to zone files and DNS queries are again
resolved. Figure 23-3 describes the domain name status information and zone insertion
indicator provided to registrars. The zone insertion indicator determines whether the name
server details of the domain name exist in the zone file for a given domain name status. We also
have the capability to withdraw domain names from the zone file in near-real time by changing
the domain name statuses as needed or by request from courts or legal authorities.

iii. Dissemination of TLD Zone Files

See Item B in Figure 23-1 and Figure 23-2.

iv. Operation of the Registry Zone Servers

As a company, Verisign operates zone servers and serves DNS resolution from 76
geographically distributed resolution sites located in North America, South America, Africa,
Europe, Asia, and Australia. Currently, 17 DNS locations are designated primary sites, offering
greater capacity than smaller sites comprising the remainder of our constellation. We also use
Anycast techniques and regional Internet resolution sites to expand coverage, accommodate
emergency or surge capacity, and support system availability during maintenance procedures.
We operate the .verisign gTLD from a minimum of eight of our primary sites (two on the East
Coast of the United States, two on the West Coast of the United States, two in Europe, and two
in Asia) and expand resolution sites based on traffic volume and patterns. Further details of the
geographic diversity of our zone servers are provided in the response to Question 34,
Geographic Diversity. Moreover, additional details of our zone servers are provided in the
response to Question 32, Architecture and the response to Question 35, DNS Service.

v. Dissemination of Contact and Other Information Concerning Domain Name
Server Registrations

See Item C in Figure 23-1 and Figure 23-2.

2 OTHER PRODUCTS OR SERVICES THE REGISTRY OPERATOR IS REQUIRED TO PROVIDE BECAUSE OF THE ESTABLISHMENT OF A
CONSENSUS POLICY

Verisign is a proven supporter of ICANN’s consensus-driven, bottom-up policy development
process whereby community members identify a problem, initiate policy discussions, and
generate a solution that produces effective and sustained results. We currently provide all of the
products or services (collectively referred to as services) that the registry operator is required to
provide because of the establishment of a Consensus Policy. For the .verisign gTLD, we
implement these services using the same proven processes and procedures currently in-place
for all registries under our management. Furthermore, we execute these services on computing
platforms comparable to those of other registries under our management. Our extensive
experience with consensus policy required services and our proven processes to implement
these services greatly minimize any potential risk to Internet security or stability. Details of these
services are provided in the following subsections. It shall be noted that consensus policy
services required of registrars (e.g., Whois Reminder, Expired Domain) are not included in this
response. This exclusion is in accordance with the direction provided in the question’s Notes
column to address registry operator services.

2.1 Inter-Registrar Transfer Policy (IRTP)

Technical Component: In compliance with the IRTP consensus policy, we have designed our
registration systems to systematically restrict the transfer of domain names within 60 days of the
initial create date. In addition, we have implemented EPP and “AuthInfo” code functionality,
which is used to further authenticate transfer requests. The registration system has been
designed to enable compliance with the five-day Transfer grace period and includes the
following functionality:

* Allows the losing registrar to proactively ‘ACK’ or acknowledge a transfer prior to the
expiration of the five-day Transfer grace period
* Allows the losing registrar to proactively ‘NACK’ or not acknowledge a transfer prior to the
expiration of the five-day Transfer grace period
* Allows the system to automatically ACK the transfer request once the five-day Transfer
grace period has passed if the losing registrar has not proactively ACK’d or NACK’d the
transfer request.

Business Component: All requests to transfer a domain name to a new registrar are handled
according to the procedures detailed in the IRTP. Dispute proceedings arising from a registrarʹs
alleged failure to abide by this policy may be initiated by any ICANN-accredited registrar under
the Transfer Dispute Resolution Policy (TDRP). Verisign’s compliance office serves as the first-
level dispute resolution provider pursuant to the associated TDRP.

Verisign has developed and implemented an automated system known as the Transfer Dispute
Resolution System (TDRS) by which to track and process Requests for Enforcement that
registrars may file under the TDRP. Registrars access the TDRS by using unique login
credentials assigned to their designated transfer point of contact. Using the TDRS, registrars
may submit a Request for Enforcement case, check on the status of a case to which they are a
party, withdraw a case, respond to a case filed against them, and waive their right to appeal
once a decision has been rendered. The TDRS is designed to comply with the timelines
specified in the TDRP and allows Verisign’s compliance office to track and process cases in
accordance with the policy.

The TDRS is also integrated with other Verisign systems to facilitate the transfer dispute case
activity reporting that ICANN mandates for Verisign’s Monthly Registry Operator Reports.

Security and Stability Concerns: We are unaware of any impact, caused by the service, on
throughput, response time, consistency, or coherence of the responses to Internet servers or
end-user systems. By implementing the IRTP in accordance with ICANN policy, security is
enhanced as all transfer commands are authenticated using the AuthInfo code prior to
processing.

ICANN Prior Approval: We have been in compliance with the IRTP since November 2004.

Unique to the TLD: This service is not provided in a manner unique to the .verisign TLD.

2.2 Add Grace Period (AGP) Limits Policy

Technical Component: Our registry system monitors registrars’ Add grace period deletion
activity and provides reporting that permits us to assess registration fees upon registrars that
have exceeded the AGP thresholds stipulated in the AGP Limits Policy. Further, we accept and
evaluate all exemption requests received from registrars and determine whether the exemption
request meets the exemption criteria. We maintain all AGP Limits Policy exemption request
activity so that this material may be included within our Monthly Registry Operator Report to
ICANN.

Registrars that exceed the limits established by the policy may submit exemption requests to
Verisign for consideration. Our compliance office reviews these exemption requests in
accordance with the AGP Limits Policy and renders a decision. Upon request, we submit
supplemental detailed reporting on exemption request activity to support the high-level
exemption request activity reporting that ICANN mandates for Verisign’s Monthly Registry
Operator Reports.

Business Component: The Add grace period (AGP) is restricted for any gTLD operator that
has implemented an AGP.

* At the end of each month, Verisign assesses overage charges to any registrar account for
domain names deleted during the AGP that exceed (i) 10% of that registrarʹs net new
registrations (calculated as the total number of net adds of one-year through ten-year
registrations as defined in the monthly reporting requirement of Operator Agreements) in
that month, or (ii) fifty (50) domain names, whichever is greater. If a registrar applies for an
exemption (as described in the next paragraph) and Verisign grants an exemption, the
registrar’s account will be credited for the amount of the exemption that has been granted.

* Upon the documented demonstration of extraordinary circumstances, a registrar may seek
an exemption from such restrictions in a specific month. The registrar must confirm in writing
how, at the time the names were deleted, these extraordinary circumstances were not
known, reasonably could not have been known, and were outside the registrarʹs control.
Acceptance of any exemption will be at our sole and reasonable discretion; however
ʺextraordinary circumstancesʺ that reoccur regularly for the same registrar will not be
deemed extraordinary.

In addition to all other reporting requirements to ICANN, we identify each registrar that has
sought an exemption, along with a brief description of the type of extraordinary circumstance
and the action, approval, or denial that we took. Further, Verisign makes registrar-specific
reports available to each registrar that provide the registrar with its specific Add grace period
deletion activity as it relates to the AGP Limits Policy. These reports help registrars identify and
address excessive deletion activity before they exceed policy thresholds.

Security and Stability Concerns: We are unaware of any impact, caused by the policy, on
throughput, response time, consistency, or coherence of the responses to Internet servers or
end-user systems.

ICANN Prior Approval: We have had experience with this policy since its implementation in
April 2009.

Unique to the TLD: This service is not provided in a manner unique to the .verisign TLD.

2.3 Registry Services Evaluation Policy (RSEP)

Technical Component: Verisign adheres to all RSEP submission requirements. We have
followed the process many times and are fully aware of the submission procedures, the type of
documentation required, and the evaluation process that ICANN employs.

Business Component: In accordance with ICANN procedures detailed on the ICANN RSEP
website (http:⁄⁄www.icann.org⁄en⁄registries⁄rsep⁄), we follow this policy when submitting a
request for new registry services.

Security and Stability Concerns: As part of the RSEP submission process, we identify any
potential security and stability concerns in accordance with RSEP stability and security
requirements. We never launch services without satisfactory completion of the RSEP process
and resulting approval.

ICANN Prior Approval: Not applicable.

Unique to the TLD: gTLD RSEP procedures are not implemented in a manner unique to the
.verisign TLD.

3 PRODUCTS OR SERVICES ONLY A REGISTRY OPERATOR IS CAPABLE OF PROVIDING BY REASON OF ITS DESIGNATION AS THE REGISTRY
OPERATOR

Verisign has developed a number of services that complement traditional registration and
resolution registry services. For each proposed .verisign service, in accordance with direction
provided in Question 23, we detail the technical and business components of the service and
identify any potential threat to registry security or stability. Each service is currently operational,
supporting multiple registries under ICANN’s purview. Details of previous interactions with
ICANN to approve the operational use of the service are also provided.

We are unaware of any competition issue that may require the registry services listed in this
response to be referred to the appropriate governmental competition authority or authorities with
applicable jurisdiction. ICANN previously approved each service, at which time it was
determined that either the service raised no competitive concerns or any applicable concerns
related to competition were satisfactorily addressed.

3.1 WhoWas Service

Technical Component: From time to time Verisign may receive requests for historical domain
name registration data, including information on domain names that have been deleted. These
requests may be made for a variety of reasons, such as a request from a registrar who may
need a more complete registration history of a particular domain name, a request related to an
investigation, legal action related to trademark infringement claims, or other investigations of
potential nefarious uses.

Once a domain name deletion request has been completed, we ensure the domain name is
removed from the registry Whois service and the Whois data associated with the domain name
is no longer publicly available. This occurs at the time the deletion transaction is processed for a
domain name within the Add grace period, or for domain names that are deleted outside of the
Add grace period following the Pending Delete period.

The WhoWas service provides an automated capability for a customer (i.e., registrar or non-
registrar) to obtain the registration history for the entire life of a domain name. This history
includes the domain name, registration dates, and registrar of record for each period (i.e., until
the domain name expired, was transferred to another registrar, or was deleted). The WhoWas
service does not modify the existing Whois service nor disclose the full registration transaction
history (e.g., modifications, renewals, status changes), which could be made available through
special request to Verisign. The response data includes only the registry data listed above and
does not include registrant or other contact data.

Business Component: We offer the Domain Name WhoWas Service through a secure web-
based interface. In the future, an application programming interface (API) may be available to
support automated activity.

The .verisign gTLD offers the Domain Name WhoWas Service under a subscription-based
model to both registrars and non-registrars. To subscribe to the service, customers must
execute a service agreement that contains, among other things, a license grant and appropriate
restrictions on use of the data.

Qualified customers may subscribe to the service for a 90-day term with an auto-renewal
clause. There is a nominal fee to offset the implementation, maintenance, and operational costs
of the service.

Security and Stability Concerns: We are unaware of any impact, caused by the service, on
throughput, response time, consistency, or coherence of the responses to Internet servers or
end-user systems.

ICANN Prior Approval: ICANN approved the same WhoWas service for Verisign’s use for
.com and .net on 16 July 2009 (Reference: Registry Services Evaluation Process (RSEP)
Proposal 2009007).

Unique to the TLD: This service is not provided in a manner unique to the .verisign TLD.

3.2 Registry Lock Service

Technical Component: Verisign may wish to protect certain domains against accidental or
inadvertent modifications or deletions that would affect high profile or valuable domain names.
The Extensible Provisioning Protocol (EPP) specifies both client (registrar) and server (registry)
status codes that prevent registry changes (i.e., a delete, transfer, or update) that are not
intended by the registrant. Registrars can use client status codes, but with Verisign’s Registry
Lock Service, registrars can also take advantage of server status codes.

The following EPP server status codes are applicable for domain names: (i)
serverUpdateProhibited, (ii) serverDeleteProhibited, and (iii) serverTransferProhibited. These
statuses may be applied individually or in combination.

The EPP also enables setting host (i.e., name server) status codes to prevent deleting or
renaming a host or modifying its IP addresses. Setting host status codes at the registry reduces
the risk of inadvertent disruption of DNS resolution for domain names.

Business Component: The Registry Lock Service is used in conjunction with a registrar’s
proprietary security measures to bring a greater level of security to domain names and help
mitigate potential for unintended deletions, transfers, and⁄or updates.

Two components comprise the Registry Lock Service:
* Verisign and⁄or its registrars provides Verisign with a list of the domain names to be placed
on the server status codes. During the term of the service agreement, the registrar can add
domain names to be placed on the server status codes and⁄or remove domain names
currently placed on the server status codes. We then manually authenticate that the
registrar submitting the list of domain names is the registrar-of-record for such domain
names.

* If a registrar requires changes (including updates, deletes, and transfers) to a domain name
placed on a server status code, we follow a secure, authenticated process to perform the
change. This process includes a request from an authorized representative for Verisign to
remove the specific registry status code, validation of the authorized individual by Verisign,
removal of the specified server status code, registrar completion of the desired change, and
a request from the authorized individual to reinstate the server status code on the domain
name. This process is designed to complement automated transaction processing through
the Shared Registration System (SRS) by using independent authentication by trusted
registry experts.

There will be no additional fees charged for this service.

Security and Stability Concerns: We are unaware of any impact, caused by the service, on
throughput, response time, consistency, or coherence of the responses to Internet servers or
end-user systems.

ICANN Prior Approval: ICANN approved the same Registry Lock Service for Verisign’s use on
.com and .net on 10 July 2009 (RSEP Proposal 2009005) and for .name on 16 February 2011
(RSEP Proposal 2011002).

Unique to the TLD: This service is not provided in a manner unique to the .verisign TLD.

3.3 Bulk Transfer after Partial Portfolio Acquisition (BTAPPA) Service

Technical Component: BTAPPA applies to situations where one ICANN-accredited registrar
(i.e., a gaining registrar) acquires by means of a stock or asset purchase, merger, or similar
transaction a portion, but not all, of another ICANN-accredited registrarʹs (i.e., losing registrar)
domain name portfolio in the gTLD or a gaining registrar receives a request from a registrant to
transfer a significant number of its domain names from the losing registrar to the gaining
registrar.

Unless an entire portfolio of domain names is being transferred, gaining registrars must request
that each domain name be transferred individually.

Gaining and⁄or losing registrars must meet the following requirements:

* Gaining registrar must be ICANN-accredited for the gTLD.

* Gaining registrar must be in good standing and be under a Registry-Registrar Agreement
with Verisign.

* Gaining registrar must provide us with evidence (i.e., affidavit, sale documents) that sets
forth the transfer date or, if an acquisition, the target closing date.

* If domain names are to be transferred from multiple losing registrars, then they must be
registrar affiliates. A registrar affiliate is a registrar entity that controls, is controlled by, or is
under common control with, another entity.

* Transfers of domain names to multiple gaining registrars are permitted, regardless of
familiar relationship.

* Losing registrar must certify that the existing Registrar-Registrant Agreement with customers
permits the transfer of domain names in the event of acquisition by another party. A losing
registrar must ensure that no obstacles are placed in the way of the gaining registrar.

* Both gaining and losing registrar must approve the list of domain names subject to the
BTAPPA prior to the change in sponsorship by the .verisign gTLD.

* Domain names with the following registry statuses (see response to Question 27,
Registration Lifecycle for details of registry statuses) at the time of the transfer are not
subject to the BTAPPA: Pending Transfer, Redemption Grace Period (RGP), or Pending
Delete.

* Domain names within the 45-day auto-renew grace period are subject to BTAPPA, but we
may deny credit for domain names that the registrant(s) chooses to delete after the partial
BTAPPA, but prior to the expiration of the 45-day auto-renew grace window.

* In an acquisition, the losing registrar must agree to provide at least 15-day prior written
notice of the partial bulk transfer to all registrants associated with domain names involved in
the transfer. Notice must include:

a. Statement that all transfer rules and policies set by ICANN and the .verisign
gTLD shall remain in effect.

b. Instructions on how a registrant can opt-out of bulk transfer in the event that the
losing registrar has indicated that it is willing to continue to serve as the registrar
for the domain name.

* Gaining registrar must make request for BTAPPA to Verisign within one calendar year of the
closing date of the acquisition.

* Request for BTAPPA service from the .verisign gTLD is limited to one request per registrar
affiliate per six-month period unless otherwise agreed to by us.

* We have the discretion to reject requests for BTAPPA if there is reasonable evidence that
BTAPPA is being requested to avoid fees otherwise due to Verisign or ICANN.

* BTAPPA may not be requested if the gaining registrarʹs request would otherwise qualify for
bulk transfer under Part B of ICANN’s Policy on Transfer of Registrations between
Registrars.

* Once a BTAPPA has been completed, there is no grace period to reverse the transfer.
Business Component: BTAPPA is offered to all ICANN-accredited registrars for the .verisign
gTLD. In order to access the service, gaining registrars must submit a formal request to us. We
validate the registrar’s identity, verify the contents of the submission, and schedule the date for
BTAPPA.

We may request additional documentation or take additional steps we deem appropriate to
ensure that all requirements are met with respect to registrar affiliate relationships.
Once we complete all necessary verifications, we perform the BTAPPA per gaining registrar
request and notify both the losing and gaining registrar of the transfer of the domain names. We
also provide the reason for non-transfer of any domain names that were not transferred.
We charge a fee to the gaining registrar based on the total value of the domain names being
transferred.

Security and Stability Concerns: We are unaware of any impact, caused by the service, on
throughput, response time, consistency, or coherence of the responses to Internet servers or
end-user systems.

ICANN Prior Approval: ICANN approved the same BTAPPA service for Verisign’s use for .com
and .net on 9 December 2009 (RSEP Proposal 2009008).

Unique to the TLD: This service is not provided in a manner unique to the .verisign TLD.

3.4 Two-Factor Authentication Service

Technical Component: The Registry-Registrar Two-Factor Authentication Service is designed
to improve domain name security and assist registrars in protecting the accounts they manage.
As part of the service, dynamic one-time passwords (OTPs) augment the user names and passwords
currently used to process update, transfer, and⁄or deletion requests. These one-time passwords
enable transaction processing to be based on requests that are validated both by “what users
know” (i.e., their user name and password) and “what users have” (i.e., a two-factor
authentication credential with a one-time password).

Registrars can use the one-time password when communicating directly with our Customer
Service department as well as when using the registrar portal to make manual updates,
transfers, and⁄or deletion transactions. The Two-Factor Authentication Service is an optional
service offered to registrars that execute the Registry-Registrar Two-Factor Authentication
Service Agreement.

Business Component: There is no charge for the Registry-Registrar Two-Factor
Authentication Service. It is enabled only for registrars that wish to take advantage of the added
security provided by the service.

Security and Stability Concerns: We are unaware of any impact, caused by the service, on
throughput, response time, consistency, or coherence of the responses to Internet servers or
end-user systems. The service is intended to enhance domain name security, resulting in
increased confidence and trust by registrants.

ICANN Prior Approval: ICANN approved the same Two-Factor Authentication Service for
Verisign’s use on .com and .net on 10 July 2009 (RSEP Proposal 2009004) and for .name on
16 February 2011 (RSEP Proposal 2011001).

Unique to the TLD: This service is not provided in a manner unique to the .verisign TLD.

Similar gTLD applications: (0)