28 Abuse Prevention and Mitigation

Prototypical answer:

gTLDFull Legal NameE-mail suffixDetail
.ovhOVH SAScorp.ovh.comView

1. Overview
2. Definition of what constitutes abuse in the .OVH TLD
3. Whois Abuse Prevention Policies
3.1 Whois Accuracy
3.1.1 Syntactic and semantic registration constraints
3.1.2 Verification tools
3.1.3 Whois Data Reminder Policy (WDRP)
3.2 Protection against potential abusive use of Whois service
3.2.1 Protection against Data Mining Captcha Rate-limiting
3.2.2 Prevention of Unauthorized data modification
4. Prevention from other abusive conducts
4.1 DNSSEC (cache poisoning)
4.2 Domain name Sniping (grabbing)
4.3 Domain name tasting
5. Disposal of Orphan Glue Records
6. Single Abuse Point of Contact
7. Policies for handling complaints regarding abuse
7.1 Abuse case response
7.2 Rapid Takedown Policy for Cases of General Fraudulent and Malicious Activity
7.3 Trademark abuse
8. Resourcing Plans

1 - Overview

Our objective in answering question 28 is to provide a thorough explanation of our policies and procedures to minimize abuse registration and other activities that have a negative impact on internet users.
Protection of the internet users is a core value of the project and is key to insure the user experience as described in question 18 (b) iii. By implementing anti-abuse policy the registry will also contribute and protect the integrity, security and stability of the DNS.

In its online presentation of Registration Abuse Policy (RAP - available at http:⁄⁄www.icann.org⁄en⁄resources⁄policy⁄background⁄rap), ICANN offers the following definition:

ʺIn general, the term covers a broad variety of illegal or illegitimate behaviors considered contrary to the intent and design of normal domain registration processes. Registration abuse often involves malicious actors trying to register in ways that avoid lawful authorities or conceal a registrantʹs identity. Registration abuse can also enable other kinds of abuses, such as phishing and spam.ʺ

The .OVH registry is committed to create and implement policies and procedure that prevent abusive registrations and other activities that have a negative impact on internet users. According to the industry best practises presented in the Registration Abuse Policies Issues Report (ICANN 2008), the .OVH registry will offer a wide range of effective safeguards to prevent abusive uses of domain names such as phishing, spamming, and also unlawful or fraudulent actions. The registry operator will regularly update these policies and procedures in order to maximize its readiness to deal with new threats at all levels and new forms of abuse.

For that purpose, the .OVH registry will implement prevention and mitigations policies.

Prevention starts at the time of registration, Whois accuracy (3) is therefore the first and main focus of the .OVH prevention policies. The following answer describes in details the mechanisms in place to maximize Whois accuracy. Others mechanisms (4) will be implemented and described here, including management of orphan glue records (5).

In addition to strong preventive measure against various forms of abuse, .OVH will implement mitigation policies to address actual case of abuse that may eventually occur. This answer will describe these mitigation measures in detail: single abuse point of contact (6), complaint handling policy and takedown procedures (7).

Resources allocated to handle prevention and mitigation (8) will be described at the end of this answer.

2 - Definitions of what constitutes abuse in the .OVH TLD
(based on the ʺDomain Name Anti-Abuse Policyʺ of PIR - http:⁄⁄www.pir.org⁄why⁄anti_abuse_policy)

= Spam =

The use of electronic messaging systems to send unsolicited bulk messages. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums. An example, for purposes of illustration, would be the use of email in denial-of-service attacks;

= Phishing =

The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;

= Pharming =

The redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning;

= Willful distribution of malware =

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, keyloggers, and trojan horses.

= Fast flux hosting =

Use of fast-flux techniques to disguise the location of Web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast-flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves. Fast flux hosting may be used only with prior permission of PIR;

Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (DDoS attacks);

= Distribution of child pornography =

Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).

Unlawful content or any content that contravene public order according to French law and in particular to Law on the Freedom of the Press of 29 July 1881 (crimes against humanity apology⁄promotion or contestation, incitement to discrimination, hatred or violence).

3. - Whois Abuse Prevention Policies

3.1 - Whois Accuracy

RFC3912 specifies the Whois protocol and explain it as follows:

Whois is a TCP-based transaction-oriented query⁄response protocol that is widely used to provide information services to Internet users. While originally used to provide ʺwhite pagesʺ services and information about registered domain names, current deployments cover a much broader range of information services. The protocol delivers its content in a human-readable format.

Information about registered domain names is very sensitive. A Registry Operator shall insure the accuracy of the registrant contact information, including administrative, technical and billing contact details. In case of malicious or abusive activity, the Whois contact is usually the first and most important source of information. Whois accuracy is therefore a major step to counter malicious conducts. These information may be required by law-enforcement authorities to identify individuals and organizations responsible for domain names.

The .OVH registry will make a firm commitment to obtaining true and accurate registration details from each registrant. It should be noted that OVH is currently an ICANN accredited registrar. Hence, OVH will act as the sole registrar for the .OVH registry. The vertical integration of these functions, as permitted by ICANN (ICANN Board decision, 5 November 2010) will reinforce OVH ability as well as its responsibility to maintain a consistent Whois accuracy throughout the registry.

3.1.1 - Syntactic and semantic registration constraints:

The .OVH registry is firmly committed to run a ʺthick-registryʺ with high quality of data. The first step to accuracy is achieved through syntactic and semantic checks which are being carried out at the time of registration of the domain name.

= Standard EPP checks =
a first set of tests is implemented in compliance with standards:

* RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, requires contact data to contain a name, a city, a country code and an e-mail address in order to allow or perform a syntactically complete EPP request

* RFC 5731, the Extensible Provisioning Protocol (EPP) requires domain object to have at least one associated status value, Date and time attribute values to be represented in Universal Coordinated Time (UTC) using the Gregorian calendar and Validity periods to be measured in years or months with the appropriates units specified using the ʺunitʺ attribute.

* RFC 5732, the Extensible Provisioning Protocol (EPP) requires host object to have at least one associated status value

= Additional checks =
the following syntactic checks are implemented:

* a test to ensure that the domain name has the proper number of labels (which is two for a traditional registry that allows only second level domains to be registered),
* a test to ensure that no hyphens occur in position 3 and 4 of any of the domainʹs U-labels (to protect ʺxn--ʺ and future ACE prefixes),
* a test to disallow hyphens at the beginning or end of the name,
* a test to find ASCII characters which are neither a letter, nor a digit or a hyphen,
* a test to find invalid IDN characters, i.e. characters not contained in any of the support IDN character tables
* a test to validate IP address format using the following scheme :
〈ipv4-addr〉 [1-255](\.[0-255]){3,3}
〈ipv6-addr〉 [a-fA-F0-9:]+(:〈ipv4-addr〉)?
* a test to validate telephone and mail format using the following scheme (with specific tests for fr numbers):
〈num tel〉 \+[1-9][0-9]{0,3}〈sp〉[1-9]([〈sp〉\.-]?[0-9])+
〈num tel fr〉 \+33〈sp〉[1-9]([〈sp〉\.-]?[0-9]){8}
〈e-mail〉 (([^\s\(\)\[\]\.\\〉〈,;:ʺ@]+(\.[^\s\(\)\[\]\.\\〉〈,;:ʺ@]+)*)|(ʺ[^ʺ@\\\r\n]+ʺ))@〈label〉(\.〈label〉)*

= Additional checks =
the following semantic checks are implemented :

* a test to disallow reserved names if authorisation code is not present
* a test to disallow registry reserved names if authorisation code is not present
* a test to disallow ICANN reserved names
* a test to disallow otherwise reserved or unsuitable names
* a test to ensure that at least one address element is given

3.1.2 - Verification tools

This verification procedure is designed to guarantee the reliability and the accuracy of the Whois database.
The .OVH registry will conduct Whois accuracy verification for compliance with criteria concerning the reliability of registrantʹs identification: the registry will verify whether the information provided by the registrant when registering the domain name contains inaccurate or false information about the registrantʹs identity.

Those verifications will be carried out on a random basis or following a third-party request.

In this purpose, the .OVH registry will set up a surveillance robot and a staff dedicated to these issues.

The .OVH registry already has the resources ready to be used and staff totally able to handle the workload.

Given the vertical integration of its registry⁄registrar functions, OVH may be led to directly ask registrants for additional information or documents, including the production of documentary evidence of compliance with the reliability of the data provided by the registrant if OVH is in possession of documentary evidence to the contrary (mail returned marked ʺNot Known at This Addressʺ, bailiffʹs report, unidentifiable address, etc.).

A domain name may be blocked under the following circumstances: when a check of the identification data provided by the registrant shows that it is inaccurate or that the registrant is not eligible.

A domain name may also be deleted further to such procedure. The deletion of a domain name can only occur after the registrant has been formally asked to rectify the situation and to modify its registration data to comply with eligibility criteria.

During the redemption period, the domain name can be reactivated with the same configuration. Once deleted, the domain name will become available again, unless permanently blocked by the Registry Operator.

3.1.3 - Whois Data Reminder Policy (WDRP)

In 2003, ICANN adopted the ʺWhois Data Reminder Policyʺ (WDRP, http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm) which obliges ICANN-accredited registrars to send yearly Whois data reminder notices to registrants. These notices contain the Whois data currently on file for the respective domain, as well as instructions for the registrant about ways to correct the data if required. While the .OVH Registry does not intend to replicate this reminder procedure on the registry level, however OVH will comply with WDRP as expected from an accredited ICANN registrar.

3.2 - Protection against unfair use of Whois service

As stated above, Whois Service gives access to sensitive data, including contact details of registrants. The .OVH registry is committed to insure the protection of these data against abusive behaviours. Firstly, the .OVH registry will implement technical measures to prevent data mining on the Whois, such as automated collection of registrantsʹ email addresses, which may on their turn be used by third parties for the purposes of spamming. Secondly, the .OVH registry and its registry backend service provider, AFNIC, will deploy all necessary means to secure access to its database, specifically by implementing procedures in order to prevent Unauthorized Data Modifications. These procedures will reinforce the security of both EPP and Web-based access to Whois data.

3.2.1 - Protection against Data Mining

The .OVH registry database user commits to using the published data according to the laws and regulations in effect. Besides, the user shall respect the provisions of the French Data Protection Act. Violation of this act carries criminal penalties.

As the user is accessing personal data, he must refrain from any collection, mesuse or any act that could lead to invasion of privacy or damaging the reputation of individuals.
The Registry can at any time filter the access to its services in case of malevolent use suspicions.

------------------------ - Captcha

Users shall pass a Captcha before access is granted to the web based RDDS.

------------------------ - Rate-limiting

The registry has chosen limitation measures for the number of requests in order to prevent abuse in the use of personal data and to guarantee the quality of the service.
By a transparent parameter adjustment policy, the registry guarantees quality of service to the punctual users and professionals. The rates and thresholds of this system are described in the registry use case of question Q26.

------------------------ - White list

The white list mechanism offers specific access for registrars to the port 43 whois considering that the incoming traffic must come from two pre-defined IP address. This white list access offers higher thresholds of rate limiting for the users.

3.2.2 - Prevention of Unauthorized data modification

Data modification is managed through strict authentication and access policies.
* SSL⁄TLS protocol is used on all interfaces with clients (both EPP and web based SRS).
* a password policy is applied both on the password itself (minimum length, mandatory digits and non-alphanumerical characters), and on the live length of the password
* use of an SSL client certificate pre-installed by the registry for EPP access.
* IP authentication limited to two addresses.

The .OVH registry backend service provider, AFNIC, will share its experience in the .fr with a view to ensuring effective, timely and sufficient Domain Data Access Control.

4 - Prevention from other abusive conducts

4.1 - DNSSEC (cache poisoning)

One of the main authentication issue encountered on the DNS is the cache poisoning issue. This directly affects DNS service integrity without the attacker having to corrupt or modify data in the registry database. The answer to this issue is implementation and deployment of DNSSEC. The registry operator already successfully manages DNSSEC-enabled zones: on September, 29th 2010, the .OVH registry back-end service provider, AFNIC, finished adding its 6 ccTLDs key materials (DS records) into the IANA root zone, ending with .FR after extensive tests with its other TLDs. Since then, related DNSSEC operations and monitoring are spread inside the organization, alongside all other standard day to day operations, so that DNSSEC is a core service enabled by default.

4.2 - Domain name Sniping (grabbing)

Domain name sniping refers to the practice of trying to re-register potentially interesting domain names immediately after they are deleted.
The .OVH Registry supports the Redemption Grace Period as proposed by ICANN and implements it in full compliance with RFC 3915 (ʺDomain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)ʺ). This greatly reduces the possibility of a domain name being ʺforgottenʺ by its registrant.

4.3 - Domain name tasting

Domain name testing is a practice using the 5-days Add Grace Period (AGP) during which a newly created domain name may be deleted with a refund of the domain fee to check if the domain name is of interest or not. AGP is implemented and therefore domain name testing has to be dealt with.

This is common practice and corresponds to the policies of almost all existing generic top level domains.

In 2008, ICANN introduced the ʺAGP Limits Policyʺ (http:⁄⁄ www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm) which addresses these issues resulting from the Add Grace Period. The [-TLD-] TLD, will fully implement this policy by restricting Add Grace Period refunds to registrars according to the limits specified by the policy.

The number of operations concerned are included in ICANN reports and related report columns are :
* number of AGP deletes (ʺdomains-deleted-graceʺ)
* number of exemption requests (ʺagp-exemption-requestsʺ)
* number of exemptions granted (ʺagp-exemptions-grantedʺ)
* number of names affected by granted exemption request (ʺagp- exempted-domainsʺ)

5 - Disposal of Orphan Glue Records

According to the definition found in the ʺSSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebook, a glue record becomes an ʺorphanʺ when the delegation point NS record (the ʺparent NS recordʺ) that references is removed while retaining the glue record itself in the zone. Consequently, the glue record becomes ʺorphanedʺ since it no longer has a parent NS record. In such a situation, registrars and registrants usually lose administrative control over the record, and the recordʹs attribution to a certain registrar may become unclear, which makes it a potential vector for abuse.

The glue record policy in effect for the .OVH avoids this situation entirely by disallowing orphan glue records altogether. OVH being the sole registrar of .OVH, management of orphan glue records will not depend on cooperation with other sponsored registrars. Nonetheless, .OVH wishes to underline its understanding of this issue and acknowledge policy #3 mentioned in section 4.3 (page 6) of the SSAC document mentioned above.

6 - Single Abuse Point of Contact

To avoid abusive registration practices, the .OVH registry will provide Internet users access to a Single Point of Contact on its website, where all kinds of abuse of the TLD or domain names registered therein can be reported.

This point of contact will include a contact web interface offering the possibility to internet users to report any abuse concerning a name registered in the .OVH registry.

Such contact web interface will be displayed on the registryʹs website (phishing, spamming etc.).

This single point of contact will enable a quicker and better management of complaints and resolution of any issues arising. Complaints will be addressed by filling out form through online services on .OVH registry web site.

A dedicated team will be in charge of handling these various complaints in a due time. All requests should be acknowledged and processed within 24 hours. According to the nature of the reported abuse (phishing, spamming etc), an appropriate response will be taken by the .OVH registry.

Moreover, Internet users will be given access to all necessary information regarding remedies to abusive online conducts on the registry Single Point of Contact webpage. The single abuse point of contact webpage will also contain links to all the relevant organizations addressing these issues.

As required by the French legislation, OVH already has a single Abuse Point of contact to allow internet users to report any illicit contents that may be hosted on it network.

7 - Policies for handling complaints regarding abuse

7.1 - Abuse case response

The registry will process each complaint within 24 hours and will take all the necessary steps to offer a satisfying answer to the complainants:

Should immediate action be taken by competent authorities, the .OVH registry is committed to alert such authorities without delay. As the French leading registrar, OVH has already a proven record of handling such cases and will continue to work closely with these authorities. This may concerns the following cases (but limited to):

* Court orders
* Inquiries from law enforcement bodies (e.g, OCLCTIC - The Office central de lutte contre la criminalité liée aux technologies de lʹinformation et de la communication is the French Police unit specialized in cybercrime)
* Anti-phishing groups (e.g, CERTs)

7.2 - Rapid Takedown Policy for Cases of General Fraudulent and Malicious Activity

All reports will be treated by the registry as following:
* Acknowledgment of the complaint,
* Immediate report sent to the registrant and demanding an prompt reply
* Further checking proceeded by OVH staff,
* Within 48 hours and without correction by the customer of the fraudulent or malicious activity, the registry locks the domain name reported,
* Within 48 hours and without correction by the customer of the fraudulent or malicious activity, the registry suspends the domain name reported.

7.3 - Trademark abuse

Detailed and complete Information to right owners on effective safeguards protecting their rights will be provided on the registry website and are detailed in Question 29.

8 - Resourcing Plans

The .OVH registry already has the resources ready to be used to handle the Abuse Prevention and Mitigation workload.

The .OVH registry will ensure that suitable resources and staffing are available and committed to deal with these issues.

More specifically, OVH has a dedicated legal⁄compliance department responsible for monitoring and addressing issues described above.

Similar gTLD applications: (0)

gTLDFull Legal NameE-mail suffixzDetail