| gTLD | Full Legal Name | E-mail suffix | Detail | | .كوم | VeriSign Sarl | verisign.com | View |
1. COMPREHENSIVE ABUSE POLICIES, WHICH INCLUDE CLEAR DEFINITIONS OF WHAT CONSTITUTES
ABUSE IN THE TLD, AND PROCEDURES THAT WILL EFFECTIVELY MINIMIZE POTENTIAL FOR ABUSE IN THE TLD
Verisign has more than 16 years’ experience in protecting our domains and Domain Name
System (DNS) from malicious abuse, and we offer multiple services, products, and policies to
combat abuse of the ARABIC_TRANSLITERATION_OF_.COM gTLD.
Definitions
Malicious abuse of the ARABIC_TRANSLITERATION_OF_.COM gTLD, where software is
disseminated to infiltrate or damage a computer system without the owner’s informed consent,
can include the following types of abuse:
* Trojan ⁄ Malware Executable(s): A malicious executable is hosted on a server.
* Trojan ⁄ Malware Drive-By: A website is crafted such that it attempts to exploit a
vulnerability in a browser or browser plugin (e.g., Flash, PDF, Java) for the purpose of
automatically downloading and installing a malicious executable on a client machine.
* Phishing: A link in an email (often sent as spam) points to fraudulent web pages⁄ website
(primarily Trojan ⁄ Malware Drive-By). These fraudulent web pages are designed to trick
recipients into divulging sensitive data such as user names or passwords.
* Command-and-Control (CnC): A server is used to send and receive commands from
infected machines (bots).
* Mass Registrations: Many different domain names are used as part of a CnC
infrastructure. The domain names are linked to a specific malware family and are registered
in close proximity to each other (time-wise) or by a common entity (malicious actor).
We offer a number of security services to protect registrants and minimize the potential for
abuse. These products include:
* Verisign MalDetector: This new commercial service enables registrars to offer malware
scanning to their customers. MalDetector analyzes a website’s content by scanning the
site’s web pages (text, video, images, ads, web code) for malware and obfuscations (hidden
malware code). If MalDetector detects malware code in the website content, it provides
remediation instructions for removing the malicious code.
* Verisign Domain Name System Security Extensions (DNSSEC) Signing Service: This
services helps registrars build the infrastructure capability to protect users from redirection to
unintended sites while reducing the cost, complexity, and administrative burden associated
with implementing DNSSEC.
* Verisign Registry Lock Service: This service enables registrars to offer server-level
protection for registrants’ ARABIC_TRANSLITERATION_OF_.COM domain name records,
thereby guarding against unintended changes, deletions, or transfers. These modification
may result in malicious use of the domain name.
* Verisign Registry-Registrar Two-Factor Authentication: Helps registrars better manage
and control communications with the Verisign registry by providing a mechanism to validate
that requested changes come from authorized personnel and update authorized contacts as
personnel changes occur.
In the case of other forms of illegal activity, we work with law enforcement personnel, as
needed, to mitigate abuse through the judicial system.
1.1 Abuse Prevention and Mitigation Implementation Plan
The security services described in the preceding section are currently implemented in the other
TLDs that Verisign operates. These services are available immediately to the
ARABIC_TRANSLITERATION_OF_.COM gTLD, without the need for additional implementation.
The ARABIC_TRANSLITERATION_OF_.COM gTLD is added to the root zone, and second-
level domain names are provisioned through Verisign’s Shared Registration System
(SRS). Registrars have the ARABIC_TRANSLITERATION_OF_.COM gTLD and the products
and services described in this application added to their account in the SRS. Registrars are
required to complete a ramp-up period during which they test their Extensible Provisioning
Protocol (EPP) client applications and services through our Operational Test Environment
(OTE). The OTE is a functional equivalent to the production environment that allows registrars
to determine whether their client applications are production ready. Once the registrar has
completed the testing and certification of its client applications and services, it is granted access
to the production environment and may begin processing domain names registrations to be
published in the ARABIC_TRANSLITERATION_OF_.COM gTLD zone.
1.2 Policies for Handling Complaints Regarding Abuse
Verisign handles complaints regarding abuse as detailed in this section.
Abuse complaints are initially addressed to the Registrar of Record (ROR). If registrars or
registrants need to escalate an abuse complaint, our Customer Service Center (CSC) is the
initial point of contact. Our Customer Support includes the 24⁄7 onsite CSC staff and on-call
support from Tier 3 teams (e.g., registry operations staff, engineers, and developers) during
non-business hours. Our primary concern is to resolve issues quickly. As such, we maintain a
formal escalation process to ensure that all issues are addressed promptly by the appropriate
person⁄teams.
Abuse complaints are first directed to the Verisign CSC, which manages the complaint through
the processes outlined in Section 3.2.2. Our CSC provides world-class support to our
customers with key performance metrics that support a timely response to customer issues,
including complaints of abuse. Team leads actively manage all access channels to ensure
appropriate responsiveness via each access channel.
1.3 Proposed Measures for Removal of Orphan Glue Records
Although orphan glue records may support correct and ordinary operation of the Domain Name
System (DNS), registry operators are required to remove orphan glue records (as defined at
http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf) when provided with evidence in written
form that such records are present in connection with malicious conduct. Verisign’s registration
system is specifically designed to not allow orphan glue records. Registrars are required to
delete⁄move all dependent DNS records before deleting the parent domain name.
To prevent orphan glue records, we perform the following checks before removing a domain or
name server:
Checks during domain delete:
* A parent domain name deletion transaction is not allowed if any other domain name in the
zone refers to the child name server.
* If the parent domain name is the only domain name using the child name server, then both
the domain name and the glue record are removed from the zone.
Check during explicit name server delete:
* We confirm that the current name server is not referenced by any in-zone domain name
before deleting the name server.
Zone-file impact:
* If the parent domain name references the child name server AND if other domain names in
the zone also reference it AND if the parent domain name is assigned a serverHold status,
then the parent domain name is removed from the zone file, but the name server glue
record is not.
* If no domain names reference a name server, then the zone file removes the glue record.
1.4 Resourcing Plans
Details related to resourcing plans for the initial implementation and ongoing maintenance of our
abuse plan are provided in Section 2 of this response.
1.5 Measures to Promote Whois Accuracy
Verisign performs periodic Whois reviews to verify accuracy and completeness of data for which
the registry is authoritative. For data maintained in the registry database for which the registry is
not authoritative and is therefore unable to verify registrant contact data, the registry validates
the syntax and completeness of all required contact fields during registration and modification
transactions. In addition, we coordinate with the respective registrars to promote accuracy of
these data, including periodic notifications of ICANN’s Whois Data Reminder Policy.
1.5.1 Authentication of Registrant Information
Authentication of registrant information is performed by the registrant’s registrar, since the
registry has no direct relationship with the registrant. The registration rules for
ARABIC_TRANSLITERATION_OF_.COM require creation of an AuthInfo code for each domain
name. This AuthInfo code is required to initiate a request to transfer the domain name between
registrars. Use of this authorization by the gaining registrar is intended to prevent unauthorized
transfers of domain names.
1.5.2 Regular Monitoring of Registration Data for Accuracy and Completeness
Verisign has established policies and procedures to encourage registrar compliance with
ICANN’s Whois accuracy requirements. We incorporate the following services into our full-
service registry operations.
Registrar Self Certification
Our self-certification program consists, in part, of evaluations applied equally to all operational
ICANN accredited registrars and conducted from time to time throughout the year. Process
steps are as follows:
* Verisign sends an email notification to the ICANN primary registrar contact, requesting that
the contact go to a designated URL, log in with his⁄her Web ID and password, and complete
and submit the online form. The contact must submit the form within 15 business days of
receipt of the notification.
* When the form is submitted, we send the registrar an automated email confirming that the
form was successfully submitted.
* We review the submitted form to ensure the certifications are compliant.
* We send the registrar an email notification if the registrar is found to be compliant in all
areas.
* If a review of the response indicates that the registrar is out of compliance or if we have
follow-up questions, the registrar has 10 days to respond to the inquiry.
* If the registrar does not respond within 15 business days of receiving the original
notification, or if it does not respond to the request for additional information, we send the
registrar a Breach Notice and give the registrar 30 days to cure the breach.
* If the registrar does not cure the breach, we terminate the Registry-Registrar Agreement
(RRA).
Whois Data Reminder Process
Verisign regularly reminds registrars of their obligation to comply with ICANN’s Whois Data Reminder
Policy, which was adopted by ICANN as a consensus policy on 27 March 2003
(http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm). We send a notice to all registrars once a year
reminding them of their obligation to be diligent in validating the Whois information provided
during the registration process, to investigate claims of fraudulent Whois information, and to cancel
domain name registrations for which Whois information is determined to be invalid.
1.6 Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements
for Resolution
Please see Section 1.0 for the definition of potential forms of abuse specific to the
ARABIC_TRANSLITERATION_OF_.COM gTLD. See Section 3.2.2 for a definition of Verisign’s
response procedures.
The initial response from Customer Service is within 20 seconds or less for 90% of phone calls.
Verification of malicious activity and removal of confirmed malicious infections is completed
within 24 hours.
1.7 Controls to Ensure Proper Access to Domain Functions
The following sections describe various controls that Verisign employs to ensure appropriate
access to domain functions.
1.7.1 Multi-Factor Authentication
To ensure proper access to domain functions, we incorporate our Registry-Registrar Two-Factor
Authentication Service into our full-service registry operations. The service is designed to
improve domain name security and assist registrars in protecting the accounts they manage by
providing another level of assurance that only authorized personnel can communicate with the
registry. 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
OTPs 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 OTP 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. As
shown in Figure 28-1 (see Attachment VRSN_.comAra_Q28 Figures for all figures in this
response), the registrars’ authorized contacts use the OTP to enable strong authentication when
they contact the registry. 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.
1.7.2 Requiring Multiple, Unique Points of Contact
Each user of the system is required to have an account established with a responsibility role
assigned to him⁄her. The authoritative contact for the account is the ICANN Primary Contact. In
addition to the Administrative Contact, the following roles are available: Billing, Technical, Legal,
Marketing, Administrative, CEO, and Technical 24⁄7. Only one user is designated as the ICANN
Primary and, as such, is the authoritative contact on the account should any conflict arise.
2. 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.)
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 abuse
prevention and mitigation:
* Application Engineers: 19
* Business Continuity Personnel: 3
* Customer Affairs Organization: 9
* Customer Support Personnel: 36
* Information Security Engineers: 11
* Network Administrators: 11
* Network Architects: 4
* Network Operations Center (NOC) Engineers: 33
* Project Managers: 25
* Quality Assurance Engineers: 11
* Systems Architects: 9
To implement and manage the ARABIC_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. 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.
3. POLICIES AND PROCEDURES IDENTIFY AND ADDRESS THE ABUSIVE USE OF REGISTERED NAMES AT STARTUP
AND ON AN ONGOING BASIS
3.1 Start-Up Anti-Abuse Policies and Procedures
We incorporate the following domain name abuse prevention service into our full-service
registry operations. This service is available at the time of domain name registration.
Registry Lock
The Registry Lock Service allows registrars to offer server-level protection for their registrants’
domain names. A registry lock can be applied during the initial standup of the domain name or
at any time that the registry is operational.
Specific EPP status codes are set on the domain name to prevent malicious or inadvertent
modifications, deletions, and transfers. Typically, these ‘server’ level status codes can only be
updated by the registry. The registrar only has ‘client’ level codes and cannot alter ‘server’ level
status codes. The registrant must provide a pass phrase to the registry before any updates are
made to the domain name. However, with Registry Lock, 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.
The Registry Lock Service is used in conjunction with a registrar’s proprietary security measures
to bring a greater level of security to registrants’ domain names and help mitigate potential for
unintended deletions, transfers, and⁄or updates.
Two components comprise the Registry Lock Service:
* Registrars provide 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 registrars require 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 a registrar-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 registrar-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.
3.2 Ongoing Anti-Abuse Policies and Procedures
3.2.1 Policies and Procedures That Identify Malicious or Abusive Behavior
We incorporate the following service into our full-service registry operations.
Malware Scanning Service
Registrants are often unknowing victims of malware exploits. We have developed proprietary
code to help identify malware in the zones we manage, which in turn helps us to identify
malicious code hidden in ARABIC_TRANSLITERATION_OF_.COM domain names.
MalDetector, our malware scanning service, helps prevent
ARABIC_TRANSLITERATION_OF_.COM websites from infecting other websites by scanning
web pages for embedded malicious content that will infect visitors’ websites. Our malware
scanning technology uses a combination of in-depth malware behavioral analysis, anti-virus
results, detailed malware patterns, and network analysis to discover known exploits for the
particular scanned zone. If malware is detected, the service sends the registrant a report that
contains the number of malicious domain names found and details about malicious content
within its TLD zones. Reports with remediation instructions are provided to help the response
team quickly and effectively remove the malicious code.
3.2.2 Policies and Procedures That Address the Abusive Use of Registered Names
Suspension Processes
In the case of domain name abuse, Verisign verifies the nature of the abuse and remediates the
abuse using the procedures detailed in this section and in Figure 28-2.
Step 1.1: Verisign Notification. External party escalates the abuse notification to Verisign for
processing, documented by:
* Threat domain name
* Registrar of record (ROR)Incident narrative, threat analytics, screen shots to depict abuse,
and⁄or other evidence
* Threat classification
* Recommended timeframe for action
* Technical details (e.g., Whois records, IP addresses, hash values, anti-virus detection
results⁄nomenclature, name servers, domain name statuses that are relevant to the suspension)
* Contact details (e.g. name, phone, email address)
* Escalation history (initial timeframe of report to ROR, response from ROR, and so on)
Step 1.2: Registry Notification Verification. When we receive a request for escalation from an
external party, we perform the following verification procedures:
* Validate that all the required data appears in the notification.
* Validate that the request for escalation is for a registered domain name.
* Return a case number for tracking purposes.
Step 1.3: Escalation Rejection. If required data is missing from the request for escalation, or
the domain name is not registered, the request will be rejected and returned to the external
party with the following information:
* Threat domain name
* Verisign case number
* Error reason
Step 1.4: Registrar Notification. Once we have performed the verification, we notify the
registrar of the issue. Registrar notification includes the following information:
* Threat domain name
* Verisign case number
* Classification of type of domain name abuse
* Evidence of abuse
* Verisign anti-abuse contact name and number
Step 1.5: Registrant Notification. Once the registrar receives the notification from Verisign, it
may, at its discretion, notify the registrant and⁄or take any appropriate action.
Step 1.6: Website⁄Domain Cleanup. We may work with the registrar to complete the following
steps:
* Remediation steps: The registrar performs the remediation, and can elect to have us
deploy MalDetector, our malware scanning service, to determine the remediation needed to
remove the malware.
* Additional action needed: We provide additional comments to the registrar or information
to contact the Internet service provider (ISP) or hosting company for additional action.
Step 1.7: Cleanup Acknowledgement. We notify the external party that the abuse cleanup has
been completed. Acknowledgement of the cleanup includes the following information:
* Threat domain name
* Verisign case number
* Domain name
* Verisign abuse contact name and number
* Cleanup status
4. WHEN EXECUTED IN ACCORDANCE WITH THE REGISTRY AGREEMENT, PLANS WILL RESULT IN COMPLIANCE
WITH CONTRACTUAL REQUIREMENTS
All Verisign abuse mitigation policies are based on the corresponding terms in the Registry
Agreement and the Registry-Registrar Agreement as applicable. Whenever we develop a policy,
we look first at the language of our agreements to determine what we can and cannot do. We
then structure policies that are based on these determinations and appropriate stakeholders,
such as registrars, to develop policies with processes to monitor compliance with the policies.
In addition, ICANN recently asked us to participate (along with some other registries) in its 2011
Pilot Registry Self-Assessment. We are willingly cooperating with this pilot, for which we provide
ICANN with our certification that we comply with specific terms of our Registry Agreements (as
identified by ICANN).
5. TECHNICAL PLAN SCOPE⁄SCALE THAT IS CONSISTENT WITH THE OVERALL BUSINESS APPROACH
AND PLANNED SIZE OF THE REGISTRY
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
ARABIC_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 “Other Operating Cost” (Template 1, Line I.L) within
the Question 46 financial projections response.
| gTLD | Full Legal Name | E-mail suffix | Detail | | .verisign | VeriSign, Inc. | verisign.com | View |
1. COMPREHENSIVE ABUSE POLICIES, WHICH INCLUDE CLEAR DEFINITIONS OF WHAT CONSTITUTES A
BUSE IN THE TLD, AND PROCEDURES THAT WILL EFFECTIVELY MINIMIZE POTENTIAL FOR ABUSE IN THE TLD
Because the .verisign gTLD is used solely by Verisign and not as a gTLD for others to utilize,
the potential for domain name abuse is greatly reduced.
Registrations of domain names for the .verisign gTLD may only be performed by an authorized
registrant acting on behalf of VeriSign, Inc. All domain name registrations in the gTLD are
registered to and maintained by VeriSign, Inc. for our own exclusive use. VeriSign, Inc. does not
sell, distribute, or transfer control or use of any registrations in the gTLD to any third party that is
not an affiliate. We implement registration policies that (i) require Verisign to approve any and all
registrations; (ii) require all registrations to be in the name of Verisign and⁄or our affiliates; and
(iii) require that control of such registrations and their use remain with Verisign and ⁄or our
affiliates and partners.
Potential abuse is largely limited to the following areas:
* Phishing. Verisign defines phishing as the use of fraudulent web pages that are designed to
trick recipients into divulging sensitive data such as user names or passwords. The .verisign
gTLD will increase Internet users’ trust by allowing them to more easily identify the landing
pages of our products and services as authentically Verisign’s and not those of a third party
that may be spoofing the site or operating a phishing scam. The .verisign gTLD provides
credibility that the inventions and data we share through this gTLD come directly from
Verisign.
* Willful Distribution of Malware: Verisign defines the willful distribution of malware as the
dissemination of software designed to infiltrate or damage a computer system without the
ownerʹs informed consent. Examples include, without limitation, computer viruses, worms,
keylogging, and trojan horses. Verisign, as the trusted provider of registry services for the
world’s largest TLDs (e.g., .com and .net), is uniquely positioned to detect malware attacks
on our sites. We have developed proprietary code to help identify malware in the zones we
manage, which in turn enables us to identify malicious code hidden in our own domain
names. Our malware scanning service helps prevent our websites from infecting other
websites by scanning web pages for embedded malicious content that could potentially
infect visitors’ websites. Our malware scanning technology uses a combination of in-depth
malware behavioral analysis, anti-virus results, detailed malware patterns, and network
analysis to discover known exploits for the particular scanned zone.
1.1 Abuse Prevention and Mitigation Implementation Plan
Second-Level Domain Name Registration
We use the .verisign gTLD in the promotion and communication of the new Verisign brand and
in product marketing efforts. We may use second-level domain names to create secure and
personalized access to content, resources, and information for these brand and product
marketing efforts. The .verisign second- level domains are registered exclusively by VeriSign,
Inc. (“Verisign”) and are not available to the general public. Only authorized employees of
Verisign are permitted to register .verisign domain names on behalf of Verisign or an eligible
affiliate. Second-level domains are signed using DNSSEC, secured with Verisign’s Registry
Lock service, scanned for malware using MalDetector, and monitored using our suite of security
tools.
Website Visitors
The .verisign gTLD serves as the destination point for our channel and alliance partners. We
use .verisign second-level domain names as secure, personalized entry points that partners can
access. Each custom entry point provides customized co-marketing assets, information, and
other resources relevant to the partner’s business and ⁄ or its customers’ needs. Verisign
controls all content.
We ask customers for consent to collect personal information for the following purposes:
* Email Request for Information or Registrations for Guides or Seminars. Links
throughout our website enable customers to contact us via email to ask questions, request
information and materials, register for guides or seminars, or provide comments and
suggestions. We also offer customers the opportunity to have one of our representatives
contact them personally to provide additional information about our products or services. To
help us satisfy the customer’s request, we may request additional personal information,
such as the customer’s name and telephone number.
* Enrollment. If a customer enrolls for one of our products or services, we request certain
information. Depending on the type of product or service, we may ask the customer to
provide his⁄her name, address, telephone number, email address, credit card number, bank
account information, IP address, and⁄or Social Security number.
We take reasonable steps to protect this personal data from loss, misuse, unauthorized
disclosure, alteration, or destruction. We do not use or authorize the use of personal data in a
way that is incompatible with the verification and confirmation of the customer authorized use of
the data. In addition, at a minimum, we scan the website daily to ensure customers are not
exposed to malicious code.
1.2 Policies for Handling Complaints Regarding Abuse
Verisign will handle complaints regarding abuse as detailed in this section.
Medium for External Complaints
External users of the system who have an abuse complaint (i.e., a researcher complaining of
botnet activity or a user complaining of malware infection) can call Verisign Customer Service.
Verisign’s Customer Service includes the 24⁄7 onsite Customer Service Center (CSC) staff and
on-call support from Tier 3 teams (e.g., registry operations staff, engineers, and developers)
during non-business hours. Our primary concern is to resolve issues quickly and as such, we
maintain a formal escalation process to ensure that all issues are addressed promptly by the
“right” person⁄teams.
The CSC staff accepts every external complaint of malicious abuse of the .verisign gTLD’s
domain names, websites, or Domain Name System (DNS).
Our key performance metrics support timely response to customers’ complaints of abuse. Our
CSC answers 90 percent of phone calls within 20 seconds. Team leads actively manage all
access channels to ensure appropriate responsiveness via each access channel.
Medium for Internal Complaints
Because the .verisign gTLD is used exclusively by Verisign, it is not available to the general
public. Only Verisign and its affiliates are permitted to be registrants of .verisign domain names.
Any security incidents or breaches noted by the registrant are reported to Verisign’s formal
Incident Response Team.
The Incident Response Team (IRT) is supported by a Corporate Incident Management Team
(CIMT) and business-unit Business Continuity teams. These teams respond to and manage any
incident or disaster that impacts Verisign employees, operations, environments, or facilities. To
provide a secure and sound backup operational environment, our IT disaster recovery site has
implemented the physical security protections and operational controls required by Verisign’s
overall Physical Security Program and Verisign’s overall Information Security Program. In the
event of an incident or disaster that requires temporary or permanent cessation of operations
from Verisignʹs primary facility, the Verisign IRT and CIMT initiate Verisignʹs business continuity
and IT disaster recovery process.
1.3 Proposed Measures for Removal of Orphan Glue Records
Although orphan glue records often support correct and ordinary operation of the DNS, registry
operators are required to remove orphan glue records (as defined at
http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf) when provided with evidence in written
form that such records are present in connection with malicious conduct. Verisign’s registration
system is specifically designed to not allow orphan glue records. Registrars are required to
delete⁄move all dependent DNS records before they are allowed to delete the parent domain.
To prevent orphan glue records, we perform the following checks before removing a domain or
name server:
Checks during domain delete:
* Parent domain delete is not allowed if any other domain in the zone refers to the child name
server.
* If the parent domain is the only domain using the child name server, then both the domain
and the glue record are removed from the zone.
Check during explicit name server delete:
* We confirm that the current name server is not referenced by any domain name (in-zone)
before deleting the name server.
Zone-file impact:
* If the parent domain references the child name server AND if other domains in the zone also
reference it AND if the parent domain name is assigned a serverHold status, then the parent
domain goes out of the zone but the name server glue record does not.
* If no domains reference a name server, then the zone file removes the glue record.
1.4 Resourcing Plans
Details related to resourcing plans for the initial implementation and ongoing maintenance of
Verisign’s abuse plan are provided in Section 2 of this response.
1.5 Measures to Promote Whois Accuracy
Because .verisign is used exclusively by Verisign, it is not available to the general public. Only
authorized employees of Verisign are permitted to register .verisign domain names on behalf of
Verisign or an affiliate, and each registered domain name has Verisign corporate registrant,
administrative, billing, and technical contact information.
1.5.1 Authentication of Registrant Information
Registrations of .verisign domain names require the registrant to enter a valid Verisign
employee ID to begin the registration process. Registrant data is cross referenced against the
Verisign employee directory to validate the accuracy of the contact information. In addition, as
part of the Registry-Registrar Agreement the registrar uses two-factor authentication to validate
that the registrant data is accurate. Section 1.7.2 of this response provides further details about
our two-factor authentication process.
1.5.2 Regular Monitoring of Registration Data for Accuracy and Completeness
Verisign has the capability to regularly validate registration data against our employee records
to confirm that the registration data remains accurate. We investigate and correct any
discrepancies within a reasonable period of time. Further, at least once per year and in
accordance with ICANN’s consensus policy relating to Whois accuracy, we ask each registrant
to review and confirm the validity of the Whois data for domain names for which the contact is
named.
Verisign has established policies and procedures to encourage registrar compliance with
ICANN’s Whois accuracy requirements. We incorporate the following services into our full-
service registry operations.
Registrar self certification
The self-certification program consists, in part, of evaluations applied equally to all operational
ICANN accredited registrars and conducted from time to time throughout the year. Process
steps are as follows:
* Verisign sends an email notification to the ICANN primary registrar contact, requesting that
the contact go to a designated URL, log in with his⁄her Web ID and password, and complete
and submit the online form. The contact must submit the form within 15 business days of
receipt of the notification.
* When the form is submitted, we send the registrar an automated email confirming that the
form was successfully submitted.
* We review the submitted form to ensure the certifications are compliant.
* We send the registrar an email notification if the registrar is found to be compliant in all
areas.
* If a review of the response indicates that the registrar is out of compliance or if we have
follow-up questions, the registrar has 10 days to respond to the inquiry.
* If the registrar does not respond within 15 business days of receiving the original
notification, or if it does not respond to the request for additional information, we send the
registrar a Breach Notice and give the registrar 30 days to cure the breach.
* If the registrar does not cure the breach, we terminate the Registry-Registrar Agreement
(RRA).
Whois Data Reminder Process
Verisign regularly reminds registrars of their obligation to comply with ICANN’s Whois Data
Reminder Policy, which was adopted by ICANN as a consensus policy on 27 March 2003
(http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm). We send a notice to all registrars once a year
reminding them of their obligation to be diligent in validating the Whois information provided
during the registration process, to investigate claims of fraudulent Whois information, and to
cancel domain name registrations for which Whois information is determined to be invalid.
1.6 Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements
for Resolution
Please see Section 1.0 for the definition of potential forms of abuse specific to the .verisign
gTLD. See Section 3.2.2 for a definition of Verisign’s response procedures.
The initial response from Customer Service should be within 20 seconds or less for 90 percent
of the phone calls. Verification of malicious activity and removal of confirmed malicious
infections is completed within 24 hours.
1.7 Controls to Ensure Proper Access to Domain Functions
The following sections describe various controls that Verisign employs to ensure appropriate
access to domain functions.
1.7.1 Registration Eligibility Restrictions
As noted in our response to Question 18, Mission and Purpose, Verisign intends to impose
registration eligibility restrictions to prevent the sale, distribution, or transfer of control or use of
any registration in .verisign to any third party that is not an affiliate of Verisign. These
restrictions, which require Verisign to approve all registrations before they are allowed to go live,
are implemented through provisions in the Registry-Registrar Agreement.
1.7.2 Multi-Factor Authentication
To ensure proper access to domain functions, we incorporate our Registry-Registrar Two-Factor
Authentication Service into our full-service registry operations. The service is designed to
improve domain name security and assist registrars in protecting the accounts they manage by
providing another level of assurance that only authorized personnel can communicate with the
registry. 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. As shown in Figure 28-1 (see Attachment VRSN_.verisign_Q28 Figures for
all figures in this question response), the registrars’ authorized contacts use the OTP to enable
strong authentication when they contact the registry. 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.
1.7.3 Requiring Multiple, Unique Points of Contact
Each user of the system is required to have an account established with a responsibility role
assigned to him⁄her. The authoritative contact for the account is the ICANN Primary Contact. In
addition the following roles are available: Billing, Technical, Legal, Administrative,
Marketing, CEO, and Technical 24⁄7. Only one user is designated as the
ICANN Primary Contact and, as such, is the authoritative contact on the account should any
conflicts arise.
2. 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 abuse
prevention and mitigation:
* Application Engineers: 19
* Business Continuity Personnel: 3
* Customer Affairs Organization: 9
* Customer Support Personnel: 36
* Information Security Engineers: 11
* Network Administrators: 11
* Network Architects: 4
* Network Operations Center (NOC) Engineers: 33
* Project Managers: 25
* Quality Assurance Engineers: 11
* Systems Architects: 9
To implement and manage the .verisign 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.
3. POLICIES AND PROCEDURES IDENTIFY AND ADDRESS THE ABUSIVE USE OF REGISTERED NAMES AT STARTUP
AND ON AN ONGOING BASIS
3.1 Start-Up Anti-Abuse Policies and Procedures
Verisign incorporates the following domain name abuse prevention service into its full-service
registry operations. This service is available at the time of domain name registration.
Registry Lock
The Registry Lock Service offers server-level protection for .verisign domain names. A registry
lock can be applied during the initial standup of the domain name or at any time that the registry
is operational.
Specific Extensible Provisioning Protocol (EPP) status codes are set on the domain name to
prevent malicious or inadvertent modifications, deletions, and transfers. Typically, these ‘server’
level status codes can only be updated by the registry. The registrar only has ‘client’ level codes
and cannot alter ‘server’ level status codes. The registrant must provide a pass phrase to the
registry before any updates are made to the domain name. However, with Registry Lock,
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.
The Registry Lock Service is used in conjunction with a registrar’s proprietary security measures
to bring a greater level of security to registrants’ domain names and help mitigate potential for
unintended deletions, transfers, and⁄or updates.
Two components comprise the Registry Lock Service:
* Registrars provide 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 registrars require 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 a registrar-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 registrar-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.
3.2 Ongoing Anti-Abuse Policies and Procedures
3.2.1 Policies and Procedures That Identify Malicious or Abusive Behavior
Verisign incorporates the following service into its full-service registry operations.
Malware scanning service
Registrants are often unknowing victims of malware exploits. We have developed proprietary
code to help identify malware in the zones we manage, which in turn helps us to identify
malicious code hidden in .verisign domain names.
MalDetector, our malware scanning service, helps prevent .verisign websites from infecting
other websites by scanning web pages for embedded malicious content that will infect visitors’
websites. Our malware scanning technology uses a combination of in-depth malware behavioral
analysis, anti-virus results, detailed malware patterns, and network analysis to discover known
exploits for the particular scanned zone. If malware is detected, the service sends the registrant
a report that contains the number of malicious domains found and details about malicious
content within its TLD zones. Reports with remediation instructions are provided to help the
response team quickly and effectively remove the malicious code.
3.2.2 Policies and Procedures That Address the Abusive Use of Registered Names
In the case of domain name abuse, Verisign verifies the nature of the abuse and remediates the
abuse using the procedures detailed in this section and in Figure 28-2.
Step 1.1: Verisign Notification
External party submits the abuse notification to Verisign for processing, documented by:
* Threat domain name
* Incident narrative, threat analytics, screen shots to depict abuse, and⁄or other evidence
* Threat classification
* Threat urgency description
* Recommended timeframe for action
* Technical details (e.g., Whois records, IP addresses, hash values, anti-virus detection
results⁄nomenclature, name servers, domain name statuses that are relevant to the abuse
notification)
* Contact details
Step 1.2: Registry Notification Verification
When we receive an abuse notification from a registrar⁄external party, we perform the following
verification procedures:
* Validate that all the required data appears in the notification.
* Validate that the abuse notification is for a registered domain name.
* Return a case number for tracking purposes.
Step 1.3: Complaint Rejection
If required data is missing from the abuse notification, or the domain name is not registered, the
request is rejected and returned to the registrar with the following information:
* Threat domain name
* Verisign case number
* Error reason
Step 1.4: Registrar Notification
Once we have performed the abuse mitigation, we may notify the registrar of the action taken.
Registrar notification includes the following information:
* Threat domain name
* Verisign case number
* Classification of type of domain name abuse
* Evidence of abuse
* Verisign anti-abuse contact name and number
* Action taken
* Date⁄time of action taken
Step 1.5: Registrant Notification
Once we have performed the domain name cleanup, we notify the registrant of the action taken.
Registrant notification includes the following information:
* Threat domain name
* Verisign case number
* Classification of type of domain name abuse
* Evidence of abuse
* Verisign anti-abuse contact name and number
* Action taken
Step 1.6: Website⁄Domain Cleanup
Verisign works with the registrar to complete the following steps:
* Remediation steps: Verisign runs MalDetector, our malware scanning service, to determine
the remediation needed to remove the malware.
* Additional action needed: Verisign provides additional comments to the registrar or
information to contact the Internet service provider (ISP) or hosting company for additional
action.
Step 1.7: Cleanup Acknowledgement
We notify the external party that the abuse cleanup has been completed. Acknowledgement of
the cleanup includes the following information:
* Threat domain name
* Verisign case number
* Domain name
* Verisign abuse contact name and number
* Cleanup status
4. WHEN EXECUTED IN ACCORDANCE WITH THE REGISTRY AGREEMENT, PLANS WILL RESULT IN COMPLIANCE
WITH CONTRACTUAL REQUIREMENTS
All Verisign abuse mitigation policies are based on the corresponding terms in the Registry
Agreement and the Registry-Registrar Agreement as applicable. Whenever we develop any
policy, we look first at the language of our agreements to determine what we can and cannot do.
We then structure policies that are based on these determinations, and we develop processes
to monitor compliance with the policies.
In addition, ICANN recently asked us to participate (along with some other registries) in its 2011
Pilot Registry Self-Assessment. We are willingly cooperating with this pilot, for which we provide
ICANN with our certification that we comply with specific terms of our Registry Agreements (as
identified by ICANN).
5. TECHNICAL PLAN SCOPE⁄SCALE THAT IS 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 .verisign 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 “Other Operating Cost”
(Template 1, Line I.L) within the Question 46 financial projections response.