28 Abuse Prevention and Mitigation
|gTLD||Full Legal Name||E-mail suffix||Detail|
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.
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
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
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.
* 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
* 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
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
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
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.
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
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
* 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.
Similar gTLD applications: (13)
|gTLD||Full Legal Name||E-mail suffix||z||Detail|