Back

28 Abuse Prevention and Mitigation

gTLDFull Legal NameE-mail suffixDetail
.bzhAssociation www.bzhafnic.frView
Table of Contents

1 - Rapid Takedown Policy for Cases of General Malicious Activity
2 - Rapid Takedown Policy for Cases of Phishing
3 - Abuse Single Point of Contact
4 - Prevention of Domain Name Tasting or Domain Name Front Running
5 - Prevention of Domain Name Sniping (Grabbing)
6 - Prevention of Orphaned Glue Records
7 - Preventing Use of Reserved, Invalid, Illegal or Otherwise Unsuitable .BZH Names
7.1 - Rule Engine
8 - Domain Data Access Control
8.1 - Prevention of Whois Data Mining
8.2 - Prevention of Unauthorized Data Modifications
9 - Whois Accuracy
10 - Resourcing plans


The .BZH Registry will establish thorough and effective methods to prevent abuse of .BZH domain names, .BZH registrant data or the associated infrastructure, as well as to mitigate any impact from such abuse (should it occur despite the preventive measures). In order to achieve this, the .BZH Registry is committed to deploy extensive organizational and technical measures. The most salient examples of these measures are described below.


------------------------
1 - Rapid Takedown Policy for Cases of General Malicious Activity

The .BZH Registry is committed to closely collaborate with law enforcement authorities and security agencies in order to take quick action in case a .BZH name is reported to be involved in malicious activity. For this purpose, a ʺRapid Takedown Policyʺ is established that :

* identifies cases of malicious activity,
* defines ways for the registry to be notified of such activity (e.g. via a dedicated web site, e-mail address or phone hotline),
* defines clear and consistent procedures to quickly stop the malicious activity (after the activity was confirmed and impact of the measures has been assessed),
* defines related service levels (e.g. with respect to the maximum time the registry may take to respond to takedown requests). This time limits will never exceed 14 business days in the case of less urgent cases, and not exceed 24 hours in the most urgent cases such as phishing.
* defines rules regarding the notification of involved parties (registrant, administrative contact, technical contact, registrar, informant),
* defines ways to appeal against any measures taken (through the general Eligibility Restrictions Dispute Resolution Procedure as is the case for all appeals against Registry decisions, but with panelists that are specialized in Security and Malicious Conducts).
* defines how cases covered by the policy need to be documented and reported. In this context, cases of malicious activity may include (but are not limited to) :
* wrong, invalid or harmful DNS setup (e.g. pointers to false IP addresses),
* use of trademarked or otherwise reserved names without proper rights,
* use of the domain in actions that affect the stability and security of the Internet (e.g. in Denial of Service (DoS), Distributed Denial of Service (DDoS) attacks or botnets)
* use of the domain for the distribution of malware (such as computer viruses, worms, Trojan horses, spyware or rootkits)
* use of the domain for phishing or spamming
* use of the domain for spamming (affecting e-mail or other forms of electronic messaging)

Where applicable, the policy includes metrics and thresholds for finding quantitative indications of malicious conduct.

Procedures to stop malicious activity may include (but are not limited to) :

* notifying the domainʹs sponsoring registrar, specifying a deadline until which the activity needs to be ceased,
* notifying the domainʹs registrant, administrative or technical contact directly (again specifying a deadline until which the activity needs to have ceased),
* locking the domain and putting it on hold in order to prevent changes to the domain and to remove it from the .BZH zone (ʺtakedownʺ)
* deleting the domain name and blocking it from further registration if need be. Escalation rules (defining which steps are to be taken in which order and conditions for moving on to the next, more drastic measure) are part of the policy.

Since removing a domain name from the .BZH zone usually has serious consequences (such as rendering web sites and e-mail addresses utilizing the domain name unusable), the .BZH Registry will, in accordance with the policy, exercise extreme caution with regard to any takedown decision.

At the same time, the .BZH Registry is aware that malicious activity potentially affects a large number of Internet users, which sometimes warrants drastic measures. The Rapid Takedown Policy aims at finding appropriate measures, taking the interests of all involved parties into consideration. The Rapid Takedown Policy will be announced to both .BZH registrars and .BZH registrants and be part of the Registry-Registrar Agreement (RRA) and the .BZH registration terms.


------------------------
2 - Rapid Takedown Policy for Cases of Phishing

The .BZH Registry will work closely with French-based CERTs to develop an Anti-Phishing-specific simplified procedure. The goals will be to :

* get all 7 French CERTs (at least, but open to other CERTs) accredited as Authorized Intervenors
* develop criteria and checklist for domain names eligible for Rapid Suspension
* develop secured communications method between Authorized Intervenor and Registry, including Affidavit form

Names reported by Authorized Intervenors will be suspended in less than 4 hours. This system should expand to a global Authorized Intervenors list. In this regard, the .BZH Registry will work with the Antiphishing Working Group in order to develop and complete their proposed Accelerated Take Down proposal, which is still in beta stage.


------------------------
3 - Abuse Single Point of Contact

To ensure that the .BZH Registry gets notified of any cases of abuse as quickly and as easily as possible, an area of the public web site operated by the .BZH Registry for the .BZH TLD will be dedicated to the reporting of such cases.

The respective web pages establish a single point of contact where abuse cases can be reported via a simple web form. An e-mail address and a phone number will also be provided as alternative means of communication.

Every case reported will raise a high-priority ticket within the .BZH support staffʹs ticket system, examined immediately and treated in accordance with the Rapid Takedown Policy (and the other Compliance Procedures related to Eligibitly and Use, and IP Claims).


------------------------
4 - Prevention of Domain Name Tasting or Domain Name Front Running

The life cycle of a .BZH domain name includes a 5-day Add Grace Period (AGP) during which a newly created domain name may be deleted with a refund of the domain fee. This is common practice and corresponds to the policies of almost all existing generic top level domains.

However, in the past the Add Grace Period has been abused for practices such as domain name tasting and domain name front running.

Domain name tasting means that domains were created simply for the purpose of testing whether revenue can be generated by e.g. creating a web page with advertisements for the domain; if this was found feasible within the first few days, the domain was retained, otherwise it was deleted within the add grace period for a full refund, i.e. the domain was ʺtastedʺ for potential revenue without any payment to the registry.

Domain name front running refers to the practice of pre-registering domain names somebody has merely expressed interest in (e.g. by searching for them on the Whois web frontend of a registrar) with the purpose of reselling the domain to that person (at an inflated price) afterwards; again, the Add Grace Period has been abused for this purpose since a registrar could do that without any cost (if the unsold domain was deleted before the end of the add grace period).

In 2008, ICANN introduced the so-called ʺAGP Limits Policyʺ (http:⁄⁄ www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm) which addresses these and other issues resulting from the Add Grace Period. The .BZH TLD, will fully implement this policy by restricting Add Grace Period refunds to registrars according to the limits specified by the policy. At the end of every month, the registration systemʹs billing module will determine every registrarʹs net domain adds and check whether the add grace period refunds granted during that month exceed the permissible number according to the policy; if this is the case, additional charges to the registrarʹs account will be initiated to effectively revert the excessive refunds.

Any exemption requests by registrars, whether they were granted (as permitted by the policy) or rejected, are documented, and such documentation will be maintained and made available for review by ICANN on request. The registryʹs monthly report to ICANN will contain per-registrar information on the granted add-deletes, as well as additional columns regarding the exemption requests.

The related report columns are (with column header names in parentheses):

* 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 - Prevention of Domain Name Sniping (Grabbing)

Domain name sniping (also known as ʺgrabbingʺ) is another common abuse pattern; the name refers to the practice of trying to re-register potentially interesting domain names immediately after they are deleted (sometimes by accident, or because a registrant failed to renew the domain with his registrar in time).

Starting in 2002, registries have started to implement an ICANN proposal, the so-called ʺRedemption Grace Periodʺ (RGP, http:⁄⁄www.icann.org⁄en⁄registrars⁄redemption-proposal-14feb02.htm). The proposal recommends to introduce a 30-day period after a nameʹs deletion during which the name is removed from the TLD zone (in order to give the registrant the chance to take notice
of his nameʹs deletion) but is still eligible for being restored by the previous registrar⁄registrant.

Supporting the RGP significantly reduces chances for domain grabbers to obtain inadvertently deleted domains, since a registrant gets 30 days to notice the mistake and restore the domain before it becomes available for re-registration.

The .BZH 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)ʺ).

------------------------
6 - Prevention of Orphaned Glue Records

According to the definition found in the ʺSSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebookʺ (http:⁄⁄www.icann.org⁄en⁄ committees⁄security⁄sac048.pdf), a glue record becomes an ʺorphanʺ when the delegation point NS record (the ʺparent NS recordʺ) that references it 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 .BZH TLD avoids this situation entirely by disallowing orphan glue records altogether. This corresponds to policy #3 mentioned in section 4.3 (page 6) of the SSAC document mentioned above. The technical implementation within the Registry and its associated zone generation process ensures this by the following measures:

* A host object within the .BZH TLD (like e.g. ʺns.example.BZHʺ) cannot exist without its parent domain (ʺexample.BZHʺ). Any attempt to create the host ʺns.example.BZHʺ will be rejected by the SRS if the domain ʺexample.BZHʺ doesnʹt already exist or isnʹt sponsored by the registrar creating the host. Likewise, the domain ʺexample.BZHʺ cannot be deleted by the registrar if subordinate hosts like ʺns.example.BZHʺ still exist. These subordinate hosts have to be deleted before the domain may be deleted; if such hosts are used in delegations for other .BZH names, these delegations in turn have to be removed before the host may be deleted.
* If a domain name is put on hold (e.g. as a consequence of the Rapid Takedown Policy described above), this not only means that the delegation for the name itself is removed from the zone; it also means that any occurrences of NS records referencing a name server that is subordinate to the domain are also removed from other .BZH domains, along with any accompanying glue records. The same of course holds true should the domain name have to be deleted entirely by the registry.

Consequently, no glue records can exist for a certain domain in the .BZH zone after that domain is put on hold or deleted as part of abuse prevention or mitigation procedures.

It should be noted that this policy may lead to other domains (not directly involved in the abuse case) being affected by the takedown if they were delegated to a name server subordinate to the offending domain. Depending on their overall DNS architecture, such domains may become unreachable or less reachable after the delegation point is removed. While this could in theory be avoided by a less rigid orphan glue record policy, the overall benefit of adopting the strict policy described above is deemed higher than the potential damage to domains using an DNS infrastructure depending on an offending domain name.


------------------------
7 - Preventing Use of Reserved, Invalid, Illegal or Otherwise Unsuitable .BZH Names

As laid out in the answer to Question 29 (Rights Protection Mechanisms), the .BZH Registry takes extensive measures to protect the legal rights of others (such as trademark holders) with regard to .BZH domain names.

In addition, the .BZH Registration System provides general means to make sure that no .BZH names are registered which are for other reasons deemed invalid, reserved, illegal, offensive or unsuitable.


------------------------
7.1 - Rule Engine

For the most part, this is achieved by the deployment of a complex rule engine that checks each registered name at the time of registration for compliance with a configurable set of rules. Among other things, these rules will include :

= 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

For the tests checking for reserved names, custom lists of labels can be conveniently maintained by the registry to define the disallowed names for each category.


------------------------
8 - Domain Data Access Control

One important point of attack that may lead to abuse of .BZH domains and their associated data is the unauthorized or excessive access to data stored within the .BZH repository. This applies to both read access (e.g. via public interfaces such as the port 43⁄port 80 Whois) and write access (such as registrar interfaces like EPP or the web-based Control Panel). The measures taken in the .BZH TLD to properly restrict access are laid out in the following sub-sections.

------------------------
8.1 - Prevention of Whois Data Mining

The port 43⁄port 80 Whois interfaces grant public access to domain, host and contact data. As such they are a potential target for data mining, i.e. the retrieval of large amounts of postal or e-mail addresses for e.g. the purpose of advertising.

As explained in detail in the answer to question 26 (Whois), the Whois implementation provided by the .BZH Registration System prevents such data mining attempts, most importantly by :

* rate-limiting access to all Whois interfaces (for machines not whitelisted for unlimited access),
* requiring web interface users to pass a CAPTCHA before access is granted and
* providing full support for contact disclosure flags as specified in RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, giving registrants control over the contact fields they want to disclose in the Whois. In this respect, the system is configurable and allows restricting the use of EPP contact disclosure settings via rules defined by specific registry policies or legal requirements.

------------------------
8.2 - Prevention of Unauthorized Data Modifications

Domain data within the .BZH Registry is exclusively provisioned by registrars, i.e. registrants have no direct write access to their data within the repository; all their modifications have to be done via the registrar sponsoring the respective domain. In this constellation, registrants needs to trust their registrar and will expect that the management of domain is conducted in a diligent and correct manner. This means that the registryʹs interfaces used by registrars need to be secured in order to only allow the sponsoring registrar of a domain (and nobody else) to modify domain data.

The EPP interface provided by the .BZH Registration System does this by :
* requiring SSL⁄TLS on the transport layer,
* requiring a strong EPP password (minimum length, mandatory digits and non-alphanumerical characters),
* requiring changing the EPP password on a regular basis,
* requiring registrars to supply lists of IP addresses or subnets from which exclusive access will be granted,
* requiring registrars to use SSL client certificates known to and trusted by the registry, thus providing an additional means of authentication beyond the EPP password.

Likewise, the web-based Control Panel :

* requires SSL⁄TLS on the transport layer,
* requires registrars to log in with a user name and password (for which the same rules regarding minimum length, mandatory digits and non- alphanumerical characters apply),
* requires changing the password on a regular basis,
* requires registrars to supply lists of IP addresses or subnets from which exclusive access will be granted,
* requires registrars to install SSL client certificates known to and trusted by the registry in their web browsers, thus providing an additional means of authentication beyond the web password.

------------------------
9 - Whois Accuracy

Since .BZH is operated as a so-called ʺthick registryʺ, the .BZH Whois displays information about the registrant, as well as the administrative, technical and billing contacts of every .BZH domain. In cases of malicious or abusive activity involving a .BZH domain, this Whois contact information usually is the first and most important source of information, e.g. for law enforcement authorities, to determine the people or organizations responsible for the domain in a timely manner. Consequently, it is deemed very important to maximize the accuracy of contact information stored in the registry repository.


The .BZH Registry is therefore committed to take diligent measures to promote Whois accuracy, including (but not limited to) the following:

* Contact data completeness policy: While RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, merely requires contact data to contain a name, a city, a country code and an e-mail address for a syntactically complete EPP request, the .BZH TLD policy for contact data mandates the specification of at least one address line (street), a voice phone number and a postal code in addition. This means that, in addition to the XML schema validation conducted by the .BZH SRS for every EPP request received from the registrar (which ensures the presence of all RFC-mandated contact data), the SRS also requires these essential fields to be present and will reject requests lacking them with a ʺparameter value policy errorʺ message. The validation done by the SRS also goes beyond validating against the EPP XSDs with respect to field content. For instance, contact e-mail addresses are required to contain an ʹ@ʹ character and a valid domain name; this is not mandated by the XSDs specified in RFC 5733.

* WDRP auditing: In 2003, ICANN adopted the so-called ʺ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 .BZH Registry does not intend to replicate this reminder procedure on the registry level, it will establish an auditing process that monitors the WDRP activities of .BZH registrars to make sure that WDRP responsibilities are honoured.


------------------------
10 - Resourcing plans


The .BZH back-end registry services provider (AFNIC), provides the following resources:

= Initial Implementation =

Thanks to the experience and prior investment by its Registry Back-end Service Provider (AFNIC), the .BZH Registry already supports the above mentioned technical abuse prevention and mitigation measures. No additional engineering is required for these, nor are additional development resources needed.

= Ongoing maintenance =

In support of the Registry Operator’s staff allocated to this function, AFNIC will have specially trained support staff available to assist in the implementation of potential verifications and takedown procedure for the prevention and resolution of potential abuse. Given the scale of the .BZH, we estimate that this would require no more than 10 man days per year of AFNIC anti-abuse support staff.
gTLDFull Legal NameE-mail suffixDetail
.PARISCity of Parisafnic.frView
Table of Contents


1 - Rapid Takedown Policy for Cases of General Malicious Activity
2 - Rapid Takedown Policy for Cases of Phishing
3 - Abuse Single Point of Contact
4 - Prevention of Domain Name Tasting or Domain Name Front Running
5 - Prevention of Domain Name Sniping (Grabbing)
6 - Prevention of Orphaned Glue Records
7 - Preventing Use of Reserved, Invalid, Illegal or Otherwise Unsuitable .PARIS Names
7.1 - Rule Engine
7.2 - Pattern matching and fuzzy string comparison
8 - Domain Data Access Control
8.1 - Prevention of Whois Data Mining
8.2 - Prevention of Unauthorized Data Modifications
9 - Whois Accuracy
10 - Resources
10.1 - Initial Implementation
10.2 - Ongoing maintenance



The .PARIS Registry will establish thorough and effective methods to prevent abuse of .PARIS domain names, .PARIS registrant data or the associated infrastructure, as well as to mitigate any impact from such abuse (should it occur despite the preventive measures). In order to achieve this, the .PARIS Registry is committed to deploy extensive organizational and technical measures. The most salient examples of these measures are described below.


------------------------
1 - Rapid Takedown Policy for Cases of General Malicious Activity


The .PARIS Registry is committed to closely collaborate with law enforcement authorities and security agencies in order to take quick action in case a .PARIS name is reported to be involved in malicious activity. For this purpose, a ʺRapid Takedown Policyʺ is established that :


* identifies cases of malicious activity,
* defines ways for the registry to be notified of such activity (e.g. via a dedicated web site, e-mail address or phone hotline),
* defines clear and consistent procedures to quickly stop the malicious activity (after the activity was confirmed and impact of the measures has been assessed),
* defines related service levels (e.g. with respect to the maximum time the registry may take to respond to takedown requests). This time limits will never exceed 14 business days in the case of less urgent cases, and not exceed 24 hours in the most urgent cases such as phishing.
* defines rules regarding the notification of involved parties (registrant, administrative contact, technical contact, registrar, informant),
* defines ways to appeal against any measures taken (through the general Eligibility Restrictions Dispute Resolution Procedure as is the case for all appeals against Registry decisions, but with panelists that are specialized in Security and Malicious Conducts).
* defines how cases covered by the policy need to be documented and reported. In this context, cases of malicious activity may include (but are not limited to) :
* wrong, invalid or harmful DNS setup (e.g. pointers to false IP addresses),
* use of trademarked or otherwise reserved names without proper rights,
* use of the domain in actions that affect the stability and security of the Internet (e.g. in Denial of Service (DoS), Distributed Denial of Service (DDoS) attacks or botnets)
* use of the domain for the distribution of malware (such as computer viruses, worms, Trojan horses, spyware or rootkits)
* use of the domain for phishing or spamming
* use of the domain for spamming (affecting e-mail or other forms of electronic messaging)

Where applicable, the policy includes metrics and thresholds for finding quantitative indications of malicious conduct.

Procedures to stop malicious activity may include (but are not limited to) :
* notifying the domainʹs sponsoring registrar, specifying a deadline until which the activity needs to be ceased,
* notifying the domainʹs registrant, administrative or technical contact directly (again specifying a deadline until which the activity needs to have ceased),
* locking the domain and putting it on hold in order to prevent changes to the domain and to remove it from the .PARIS zone (ʺtakedownʺ)
* deleting the domain name and blocking it from further registration if need be. Escalation rules (defining which steps are to be taken in which order and conditions for moving on to the next, more drastic measure) are part of the policy.

Since removing a domain name from the .PARIS zone usually has serious consequences (such as rendering web sites and e-mail addresses utilizing the domain name unusable), the .PARIS Registry will, in accordance with the policy, exercise extreme caution with regard to any takedown decision.

At the same time, the .PARIS Registry is aware that malicious activity potentially affects a large number of Internet users, which sometimes warrants drastic measures. The Rapid Takedown Policy aims at finding appropriate measures, taking the interests of all involved parties into consideration. The Rapid Takedown Policy will be announced to both .PARIS registrars and .PARIS registrants and be part of the Registry-Registrar Agreement (RRA) and the .PARIS registration terms.


------------------------
2 - Rapid Takedown Policy for Cases of Phishing


The .PARIS Registry will work closely with French-based CERTs to develop an Anti-Phishing-specific simplified procedure. The goals will be to :
* get all 7 French CERTs (at least, but open to other CERTs) accredited as Authorized Intervenors
* develop criteria and checklist for domain names eligible for Rapid Suspension
* develop secured communications method between Authorized Intervenor and Registry, including Affidavit form


Names reported by Authorized Intervenors will be suspended in less than 4 hours. This system should expand to a global Authorized Intervenors list. In this regard, the .PARIS Registry will work with the Antiphishing Working Group in order to develop and complete their proposed Accelerated Take Down proposal, which is still in beta stage.


------------------------
3 - Abuse Single Point of Contact

To ensure that the .PARIS Registry gets notified of any cases of abuse as quickly and as easily as possible, an area of the public web site operated by the .PARIS Registry for the .PARIS TLD will be dedicated to the reporting of such cases.

The respective web pages establish a single point of contact where abuse cases can be reported via a simple web form. An e-mail address and a phone number will also be provided as alternative means of communication.

Every case reported will raise a high-priority ticket within the .PARIS support staffʹs ticket system, examined immediately and treated in accordance with the Rapid Takedown Policy (and the other Compliance Procedures related to Eligibility and Use, and IP Claims).


------------------------
4 - Prevention of Domain Name Tasting or Domain Name Front Running

The life cycle of a .PARIS domain name includes a 5-day Add Grace Period (AGP) during which a newly created domain name may be deleted with a refund of the domain fee. This is common practice and corresponds to the policies of almost all existing generic top level domains.

However, in the past the Add Grace Period has been abused for practices such as domain name tasting and domain name front running.
Domain name tasting means that domains were created simply for the purpose of testing whether revenue can be generated by e.g. creating a web page with advertisements for the domain; if this was found feasible within the first few days, the domain was retained, otherwise it was deleted within the add grace period for a full refund, i.e. the domain was ʺtastedʺ for potential revenue without any payment to the registry.
Domain name front running refers to the practice of pre-registering domain names somebody has merely expressed interest in (e.g. by searching for them on the Whois web frontend of a registrar) with the purpose of reselling the domain to that person (at an inflated price) afterwards; again, the Add Grace Period has been abused for this purpose since a registrar could do that without any cost (if the unsold domain was deleted before the end of the add grace period).

In 2008, ICANN introduced the so-called ʺAGP Limits Policyʺ (http:⁄⁄ www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm) which addresses these and other issues resulting from the Add Grace Period. The .PARIS TLD, will fully implement this policy by restricting Add Grace Period refunds to registrars according to the limits specified by the policy. At the end of every month, the registration systemʹs billing module will determine every registrarʹs net domain adds and check whether the add grace period refunds granted during that month exceed the permissible number according to the policy; if this is the case, additional charges to the registrarʹs account will be initiated to effectively revert the excessive refunds.

Any exemption requests by registrars, whether they were granted (as permitted by the policy) or rejected, are documented, and such documentation will be maintained and made available for review by ICANN on request. The registryʹs monthly report to ICANN will contain per-registrar information on the granted add-deletes, as well as additional columns regarding the exemption requests.

The related report columns are (with column header names in parentheses):
* 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 - Prevention of Domain Name Sniping (Grabbing)

Domain name sniping (also known as ʺgrabbingʺ) is another common abuse pattern; the name refers to the practice of trying to re-register potentially interesting domain names immediately after they are deleted (sometimes by accident, or because a registrant failed to renew the domain with his registrar in time).

Starting in 2002, registries have started to implement an ICANN proposal, the so-called ʺRedemption Grace Periodʺ (RGP, http:⁄⁄www.icann.org⁄en⁄registrars⁄redemption-proposal-14feb02.htm). The proposal recommends to introduce a 30-day period after a nameʹs deletion during which the name is removed from the TLD zone (in order to give the registrant the chance to take notice
of his nameʹs deletion) but is still eligible for being restored by the previous registrar⁄registrant.

Supporting the RGP significantly reduces chances for domain grabbers to obtain inadvertently deleted domains, since a registrant gets 30 days to notice the mistake and restore the domain before it becomes available for re-registration.

The .PARIS 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)ʺ).


------------------------
6 - Prevention of Orphaned Glue Records

According to the definition found in the ʺSSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebookʺ (http:⁄⁄www.icann.org⁄en⁄ committees⁄security⁄sac048.pdf), a glue record becomes an ʺorphanʺ when the delegation point NS record (the ʺparent NS recordʺ) that references it 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 .PARIS TLD avoids this situation entirely by disallowing orphan glue records altogether. This corresponds to policy #3 mentioned in section 4.3 (page 6) of the SSAC document mentioned above. The technical implementation within the Registry and its associated zone generation process ensures this by the following measures:

* A host object within the .PARIS TLD (like e.g. ʺns.example.parisʺ) cannot exist without its parent domain (ʺexample.parisʺ). Any attempt to create the host ʺns.example.parisʺ will be rejected by the SRS if the domain ʺexample.parisʺ doesnʹt already exist or isnʹt sponsored by the registrar creating the host. Likewise, the domain ʺexample.parisʺ cannot be deleted by the registrar if subordinate hosts like ʺns.example.parisʺ still exist. These subordinate hosts have to be deleted before the domain may be deleted; if such hosts are used in delegations for other .PARIS names, these delegations in turn have to be removed before the host may be deleted.
* If a domain name is put on hold (e.g. as a consequence of the Rapid Takedown Policy described above), this not only means that the delegation for the name itself is removed from the zone; it also means that any occurrences of NS records referencing a name server that is subordinate to the domain are also removed from other .PARIS domains, along with any accompanying glue records. The same of course holds true should the domain name have to be deleted entirely by the registry.

Consequently, no glue records can exist for a certain domain in the .PARIS zone after that domain is put on hold or deleted as part of abuse prevention or mitigation procedures.

It should be noted that this policy may lead to other domains (not directly involved in the abuse case) being affected by the takedown if they were delegated to a name server subordinate to the offending domain. Depending on their overall DNS architecture, such domains may become unreachable or less reachable after the delegation point is removed. While this could in theory be avoided by a less rigid orphan glue record policy, the overall benefit of adopting the strict policy described above is deemed higher than the potential damage to domains using an DNS infrastructure depending on an offending domain name.


------------------------
7 - Preventing Use of Reserved, Invalid, Illegal or Otherwise Unsuitable .PARIS Names

As laid out in the answer to Question 29 (Rights Protection Mechanisms), the .PARIS Registry takes extensive measures to protect the legal rights of others (such as trademark holders) with regard to .PARIS domain names.

In addition, the .PARIS Shared Registration System (SRS) provides general means to make sure that no .PARIS names are registered which are for other reasons deemed invalid, reserved, illegal, offensive or unsuitable.

------------------------
7.1 - Rule Engine

For the most part, this is achieved by the deployment of a complex rule engine that checks each registered name at the time of registration for compliance with a configurable set of rules. Among other things, these rules will include :
* 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 disallow reserved geopolitical names
* a test to disallow registry reserved names
* a test to disallow ICANN reserved names
* a test to disallow otherwise reserved or unsuitable names

For the tests checking for reserved names, custom lists of labels can be conveniently maintained by the registry to define the disallowed names for each category.

------------------------
7.2 - Pattern matching and fuzzy string comparison

In addition to the pre-registration checks described above, the rule engine also supports testing registered domain names against a set of configurable string patterns, as well as for their similarity to a set of disallowed strings.

------------------------
8 - Domain Data Access Control

One important point of attack that may lead to abuse of .PARIS domains and their associated data is the unauthorized or excessive access to data stored within the .PARIS repository. This applies to both read access (e.g. via public interfaces such as the port 43⁄port 80 Whois) and write access (such as registrar interfaces like EPP or the web-based Control Panel or Extranet). The measures taken in the .PARIS TLD to properly restrict access are laid out in the following sub-sections.

------------------------
8.1 - Prevention of Whois Data Mining

The port 43⁄port 80 Whois interfaces grant public access to domain, host and contact data. As such they are a potential target for data mining, i.e. the retrieval of large amounts of postal or e-mail addresses for e.g. the purpose of advertising.

As explained in detail in the answer to question 26 (Whois), the Whois implementation provided by the .PARIS Registration System prevents such data mining attempts, most importantly by :
* rate-limiting access to all Whois interfaces (for machines not whitelisted for unlimited access),
* requiring web interface users to pass a CAPTCHA before access is granted and
* providing full support for global contact disclosure flags as specified in RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, giving registrants control over the contact fields they want to disclose in the Whois. In this respect, the system is configurable and allows restricting the use of EPP contact disclosure settings via rules defined by specific registry policies or legal requirements.

------------------------
8.2 - Prevention of Unauthorized Data Modifications

Domain data within the .PARIS Registry is exclusively provisioned by registrars, i.e. registrants have no direct write access to their data within the repository; all their modifications have to be done via the registrar sponsoring the respective domain. In this constellation, registrants needs to trust their registrar and will expect that the management of domain is conducted in a diligent and correct manner. This means that the registryʹs interfaces used by registrars need to be secured in order to only allow the sponsoring registrar of a domain (and nobody else) to modify domain data.

The EPP interface provided by the .PARIS SRS does this by :
* requiring SSL⁄TLS on the transport layer,
* requiring a strong EPP password (minimum length, mandatory digits and non-alphanumerical characters),
* requiring changing the EPP password on a regular basis,
* requiring registrars to supply lists of IP addresses or subnets from which exclusive access will be granted,
* requiring registrars to use SSL client certificates known to and trusted by the registry, thus providing an additional means of authentication beyond the EPP password.


Likewise, the web-based Control Panel (Extranet) :
* requires SSL⁄TLS on the transport layer,
* requires registrars to log in with a user name and password (for which the same rules regarding minimum length, mandatory digits and non- alphanumerical characters apply),
* requires changing the password on a regular basis,
* requires registrars to supply lists of IP addresses or subnets from which exclusive access will be granted,
* requires registrars to install SSL client certificates known to and trusted by the registry in their web browsers, thus providing an additional means of authentication beyond the web password.


------------------------
9 - Whois Accuracy

Since .PARIS is operated as a so-called ʺthick registryʺ, the .PARIS Whois displays information about the registrant, as well as the administrative, technical and billing contacts of every .PARIS domain. In cases of malicious or abusive activity involving a .PARIS domain, this Whois contact information usually is the first and most important source of information, e.g. for law enforcement authorities, to determine the people or organizations responsible for the domain in a timely manner. Consequently, it is deemed very important to maximize the accuracy of contact information stored in the registry repository.


The .PARIS Registry is therefore committed to take diligent measures to promote Whois accuracy, including (but not limited to) the following:

* Contact data completeness policy: While RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, merely requires contact data to contain a name, a city, a country code and an e-mail address for a syntactically complete EPP request, the .PARIS TLD policy for contact data mandates the specification of at least one address line (street), a voice phone number and a postal code in addition. This means that, in addition to the XML schema validation conducted by the .PARIS SRS for every EPP request received from the registrar (which ensures the presence of all RFC-mandated contact data), the SRS also requires these essential fields to be present and will reject requests lacking them with a ʺparameter value policy errorʺ message. The validation done by the SRS also goes beyond validating against the EPP XSDs with respect to field content. For instance, contact e-mail addresses are required to contain an ʹ@ʹ character and a valid domain name; this is not mandated by the XSDs specified in RFC 5733.

* Domain data change notifications: The .PARIS Registration System can be configured (on a per-registrar basis) to automatically notify certain contacts of a domain (e.g. both the registrant and the administrative contact in order to reach multiple people concerned with the domain) after every change made to the domain (i.e. alterations of associated contacts or name servers). When enabled, this feature allows unauthorized or unintended changes to domain and contact data to be detected immediately. This functionality will however need to be deployed after consultation with .PARIS registrars, since many registrars do not endorse direct communication between the registry and registrants, i.e. their customers.

* Contact data monitoring: On a regular basis, the registry will run automated plausibility audits on the contact data submitted by registrars. Using publicly available databases, contact address lines will e.g. be mapped to cities and zip codes, which are then compared to the ones provided by the registrant.

* WDRP auditing: In 2003, ICANN adopted the so-called ʺ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 .PARIS Registry does not intend to replicate this reminder procedure on the registry level, it will establish an auditing process that monitors the WDRP activities of .PARIS registrars to make sure that WDRP responsibilities are honoured.


------------------------
10 - Resources

------------------------
10.1 - Initial Implementation

Thanks to the experience and prior investment by its Registry Service Providers (AFNIC and CORE), the .PARIS Registry already supports the above mentioned technical abuse prevention and mitigation measures. No additional engineering is required for these, which means that no special development resources are needed.

------------------------
10.2 - Ongoing maintenance

As for ongoing operations when the TLD is launched, regular audits and permanent monitoring actions, as well as timely reactions to reports of malicious activity will be provided by specially trained support staff from The Registry Operator.

It is estimated that the ongoing maintenance of this function will require on average about 30 man. hours per month, or a total of 43 man.day per year. These resources will be committed in part by the Registry Operator - The City of Paris - in line with its Staffing projection as detailed in Question 47 (Costs), and by the Registry Service Providers - AFNIC and CORE.