Back

28 Abuse Prevention and Mitigation

gTLDFull Legal NameE-mail suffixDetail
.cologneNetCologne Gesellschaft für Telekommunikation mbHnetcologne.deView
As the registry backend provider for .cologne, Knipp Medien und Kommunikation GmbH will work in close cooperation with the NetCologne GmbH to establish thorough and effective methods to prevent abuse of .cologne domain names, .cologne 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 NetCologne GmbH and Knipp Medien und Kommunikation GmbH are committed to deploy extensive organisational and technical measures; these are described in the following.


1. Rapid Takedown Policy for Cases of Malicious Activity

The NetCologne GmbH (and Knipp Medien und Kommunikation GmbH as its technical provider) are committed to closely collaborate with law enforcement authorities and security agencies in order to take quick action in case a .cologne 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),
* defines rules regarding the notification of involved parties (registrant, administrative contact, technical contact, registrar, informant, the public),
* defines ways to appeal against any measures taken,
* 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 scamming,
* use of the domain for spamming (affecting e-mail or other forms of electronic messaging),
* maintaining invalid registrant contact data in the domain.

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 be ceased),
* locking the domain and putting it on hold in order to prevent changes to the domain and to remove it from the .cologne 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 .cologne zone usually has serious consequences (such as rendering web sites and e-mail addresses utilising the domain name unusable), the NetCologne GmbH (and Knipp Medien und Kommunikation GmbH as its technical provider) will, in accordance with the policy, exercise extreme caution with regard to any takedown decision. At the same time, the NetCologne GmbH 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 .cologne registrars and .cologne registrants and be part of the Registry-Registrar Agreement (RRA) and the .cologne registration terms.


1.1 Specifics for .cologne

In addition to the above, the following applies.

According to NetCologne abusive behaviour comprises

* Trademark infringement
* Lack of legitimate interest
* Proof of bad faith

Cases of trademark infringement will in any case be handled in compliance with the resolution processes set out by ICANN and through the respective service providers. Therefore the definition of trademark infringement also rests upon ICANN.

A legitimate interest is considered as given if:

* The registrant has used the name in relation with the offer of goods or services or has verifiably made respective preparations prior to the announcement of the dispute resolution proceeding
* The registrant is a company, organisation or natural person that is generally known under this name, even though no registered right exists
* The registrant uses the name in a legitimate, non-commercial or fair manner without causing user confusion or corrupting the name’s image

Many of these guidelines are also in line with ICANN’s perception.

Lastly, NetCologne will declare a registrant to act in bad faith if:

* It becomes evident that the registrant acquired the domain name mainly with the purpose of selling, renting or in any other form assigning the domain to the proper owner or a public institution
* The domain name was registered in order to prevent the proper owner or a public institution from using this name as a domain name
* The domain name was primarily registered with the goal of disturbing the professional or organisational activity ⁄ activities of a competitor
* The domain name is used in order to attract Internet users to one’s own website with the goal of profit maximisation (more detailed information with regard to phishing and pharming will be provided in the answer to question 29 “Rights Protection Mechanism”)


1.1.1 Policies for handlings complaints regarding abusive behaviour

Requests and complaints submitted via the contact form will be received by NetCologne as well as the technical service provider. Thereby, the technical service provider will immediately become informed as to the problem brought forward. Requests and complaints brought forward by phone will be directed towards our technical service provider, who offers a 24⁄7 hotline. This allows for immediate reporting in urgent cases.

The contact provided can be used by registrants as well as third parties to report abusive registrations. In general NetCologne expects the respective registrars to handle complaints by registrants or third parties. Thus, NetCologne will redirect incoming complaints to the respective registrar who services the allegedly abusive registrant. NetCologne commits to redirect complaints within one working day (Monday through Friday) upon receipt. In return registrars are also obligated to contact the complainant within one working day upon receipt of the complaint from NetCologne.

In handling complaints, NetCologne will obligate registrars to adhere to the relevant resolution procedures set out by ICANN, i.e. the Uniform Domain Name Dispute Resolution Policy (UDRP) and the Uniform Rapid Suspension (URS). This means that in cases of trademark infringement the registrar shall inform the claimant that he⁄she can file a claim with the respective service providers and provide the relevant contact information. NetCologne will then implement all decisions made throughout the resolution process (cf. question 29 “Rights Protection Mechanism”).

Depending on the type of complaint, a proper court proceeding or an extrajudicial conciliation between the two parties will be enforced. This however will only take place as long as there is no special resolution process set out by ICANN. The decision whether a court proceeding or an extrajudicial conciliation will take place will depend on the registrar’s as well as the contending party’s wish.

NetCologne will include all mentioned obligations for the registrars in the Registry Registrar Agreement.


1.1.2 Resolutions for abusive behaviour

NetCologne will lock domains within 24 hours in two cases:

1. A proper court or an arbitration committee has declared that the respective domain name is defamatory or racist or is in breach of public law. As soon as NetCologne receives the verdict, the domain name will be locked within 24 hours and will remain suspended from further registration.

2. NetCologne receives a “Notice of Complaint” from a URS Provider. This process is further elaborated upon in the answer to question 29 “Rights Protection Mechanism”. Besides locking domains in certain cases, NetCologne will withdraw any domain if instructed to do so by relevant service providers (e.g. URS Provider), a proper court or an arbitration committee. The final decision will in any case be with the mentioned decision-making bodies.


2. Abuse Point of Contact

To ensure that the NetCologne GmbH gets notified of any cases of abuse as quickly and easily as possible, an area of the public web site operated by the NetCologne GmbH for the .cologne 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 .cologne support staffʹs ticket system, examined immediately and treated in accordance with the Rapid Takedown Policy.


3. Prevention of Domain Name Tasting and Domain Name Front Running

The life cycle of a .cologne 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. As the registry operator for the .cologne TLD, Knipp Medien und Kommunikation GmbH 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ʺ)


4. 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).

Since .cologne domains are (per registry policy) automatically renewed when they reach their expiration date, no explicit renewals by registrars are required to prevent a domain name from being deleted when they expire. Registrars need to explicitly delete domains in order to release them for re-registration. This substantially reduces opportunities for domain name sniping.

However, registrars may still send unintended domain deletions, i.e. due to clerical errors or miscommunication with the registrants. Even for these cases, measures against domain sniping are in place. Starting in 2002, registries have begun 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 to restore the domain before it becomes available for re-registration.

The TANGO Registration System used by Knipp Medien und Kommunikation GmbH to operate the .cologne TLD 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)ʺ).


5. 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 .cologne 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 TANGO Registration System and its associated zone generation process ensures this by the following measures:

* As a general principle, glue records are only created if they are really necessary, i.e. only in the case where a name server (e.g. ʺns.example.cologneʺ) is used for the delegation of a superdomain of its own name, e.g. ʺexample.cologneʺ in this example. If the same name server is used for e.g. ʺexample2.cologneʺ, no glue record is created.
* A host object within the .cologne TLD (like ʺns.example.cologneʺ) cannot exist without its parent domain (ʺexample.cologneʺ). Any attempt to create the host ʺns.example.cologneʺ will be rejected by the SRS if the domain ʺexample.cologneʺ doesnʹt already exist or is not sponsored by the registrar creating the host. Likewise, the domain ʺexample.cologneʺ cannot be deleted by the registrar if subordinate hosts like ʺns.example.cologneʺ still exist. These subordinate hosts have to be deleted before the domain itself may be deleted; if such hosts are used in delegations for other .cologne 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 .cologne 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 .cologne 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 a DNS infrastructure depending on an offending domain name.


6. Preventing Use of Trademarked, Reserved, Invalid, Illegal or Otherwise Unsuitable .cologne Names

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

* conducting a Sunrise phase to allow trademark holders to secure names related to their trademarks prior to GA,
* accessing a Trademark Clearinghouse to validate trademarks presented by registrants,
* offering a Trademark Claims Service, at least during the first 60 days of general availability,
* taking precautions against phishing and pharming and
* committing to full compliance with established Dispute Resolution and Suspension Procedures, including the Uniform Rapid Suspension (URS), the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP), and the Uniform Domain Name Dispute Resolution Policy (URDP).

Please refer to the answer to Question 29 for more detailed information on these measures.

In order to prevent from domain name registrations which are defamatory, racist or in breach of public law, NetCologne in collaboration with the city council has compiled a list of 322 names and terms which will be blocked (cf. question 22 “Protection of Geographic Names”). These names and terms will not be available for registration over the entire registry lifespan, i.e. at least for ten years. If however, a domain name happens to be registered which is defamatory, racist or in breach of public law the above mentioned process will set in and the respective name will be added to the existing list of blocked names.

In addition to these specific rights protection measures, the TANGO Registration System provides the following general means to make sure that no .cologne names are registered which are for other reasons deemed invalid, reserved, illegal, offensive or unsuitable.


6.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 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 supported IDN 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.

Please refer to the answer to Question 44 (Internationalised Domain Names) for more information on the rules governing valid IDNs in the .cologne TLD.

For the tests checking for reserved names, custom lists of labels can be conveniently maintained by the NetCologne GmbH to define the disallowed names for each category. Additional categories can also be added as required for enforcing specific policies of the .cologne TLD.

The rules are stored in database tables (rather than static configuration files), which means rules can be added, deleted or altered by authorised registry personnel without requiring a shutdown or restart of the .cologne SRS.


6.2 Compliance with Specification 5 of the Registry Agreement

The rule engine is the central system component ensuring that the NetCologne GmbH will operate the .cologne TLD in full compliance with Specification 5 (ʺSCHEDULE OF RESERVED NAMES AT THE SECOND LEVEL IN GTLD REGISTRIESʺ) of the Registry Agreement. Unless the NetCologne GmbH is otherwise authorised by ICANN and the Government Advisory Committee (GAC) in writing, the rule engine for .cologne will be set up to prohibit the registration of the labels and label types listed in Specification 5 by registrars.


6.3 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. The former is implemented by matching names against regular expressions, the latter by calculating the so-called ʺLevenshtein distanceʺ between the registered name and a given disallowed string (which is a measure for their similarity). Prior to performing any of these checks, the registered name is subjected to a number of normalisations in order to maximise its comparability; this includes the mapping of IDN characters with accents to their ASCII counterparts where feasible, the removal of hyphens and the removal of digits.

If a name matches a regular expression, or if the calculated Levenshtein distance falls below a certain threshold, the name is still normally registered, however it is also internally flagged for review. Due to the fuzzy nature of the pattern and Levenshtein matching, a name flagged via these checks may not necessarily be invalid or illegal; this is why the flagged names need to be reviewed manually by the .cologne support staff. Flagged names automatically create tickets within the support teamʹs issue system, which starts a workflow that ultimately decides whether the name is permissible (in which case the flag is removed) or invalid⁄illegal (in which case the name is deleted and the registrar gets notified).


6.4 Handling of IDNs

In the context of abuse prevention, the proper handling of Internationalised Domain Names (IDNs) becomes an important aspect.

If different IDN scripts were allowed to be mixed within one domain name, so-called homographs could be used to make users believe they are looking at a certain web site while it is actually a different one which name just has an identical or very similar visual representation. For example, since the Cyrillic letter ʺErʺ (ʺрʺ in Cyrillic script) in lower case has the same visual appearance as the Latin lower case letter ʺpʺ, mixing Latin and Cyrillic scripts would allow the creation of a domain name like ʺрayрal.cologneʺ, a homograph of the Latin-only name ʺpaypal.cologneʺ which, despite being a different word, looks exactly the same. Such a domain name could thus e.g. be used for spoofing or phishing attacks. The NetCologne GmbH prevents such abuse by implementing an IDN policy that disallows the mixing of scripts; within each label of a registered .cologne, only characters from a single script may be used.

Likewise, the Cyrillic-only second level domain ʺрор.cologneʺ looks identical to its Latin-only counterpart ʺpop.cologneʺ. If only the rule described above (no mixing of scripts) would apply, these two names could coexist for different registrants, and could thus be abused to confuse users. However, the special way the NetCologne GmbH handles such IDN variants while considering respective IDN tables and canonical forms of domain names, as described in detail in the answer to Question 44 (Support for Registering IDN Domains), prevents this situation; only one of these two domains may exist at the same time.

The NetCologne GmbH is aware that even within the same script (e.g., Latin), the use of diacritics may potentially cause similar confusion among users, e.g. if the ASCII-only name ʺpaypal.cologneʺ and a very similar one with diacritics (like ʺpáypàl.cologneʺ) are coexisting as completely separate registrations. However, after thorough consideration, it has been decided that the benefit of allowing situations like this is higher than the potential damage; in many languages, words with completely different meanings are created just via the use of diacritics, so quite useful domains would become blocked if diacritics would be considered for calculating a nameʹs equivalent variants. Consequently, the NetCologne GmbH does not perform this kind of blocking, but allows the names to coexist in such cases. Should the NetCologne GmbH receive reports about names utilising diacritics for abusive behaviour, other countermeasures described in this chapter will be applied to stop the abuse.


7. Domain Data Access Control

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


7.1 Prevention of Whois Data Mining

The port 43⁄web 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 TANGO Registration System prevents such data mining attempts, most importantly by the following measures:

* Access to all Whois interfaces is rate-limited (when accessed from IP addresses not whitelisted for unlimited access).
* Web interface users are required to pass a CAPTCHA before access is granted.
* Web interface users seeking access to extended Whois search capabilities are required to authenticate by entering login credentials (which are only issued to eligible parties).
* For improved spam protection, E-mail addresses may be displayed as images only in the web-based Whois.
* Contact disclosure flags as specified in RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, are fully supported. This gives registrants enhanced 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.


7.2 Prevention of Unauthorised Data Modifications

Domain data within the .cologne 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 their 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 TANGO 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.


8. Whois Accuracy

Since .cologne is operated as a so-called ʺthick registryʺ, the .cologne Whois displays information about the registrant, as well as the administrative, technical and billing contacts of every .cologne domain. In cases of malicious or abusive activity involving a .cologne 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 organisations responsible for the domain in a timely manner. Consequently, it is deemed very important to maximise the accuracy of contact information stored in the registry repository.

The NetCologne GmbH (and Knipp Medien und Kommunikation GmbH as its technical provider) are therefore committed to take diligent measures to promote Whois accuracy, including (but not limited to) the following:

* Contact data completeness policy: The thick registry model used for .cologne mandates the association of each .cologne domain with exactly one registrant, one administrative contact, one technical contact and one billing contact. The data of all used contacts is stored in the registry repository. 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 .cologne 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 .cologne 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 XML Schema Definitions (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.
* 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. Likewise, phone and fax numbers will be checked for plausibility.
* Domain data change notifications: The TANGO Registration System used to operate the .cologne TLD 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 unauthorised or unintended changes to domain and contact data to be detected immediately. This functionality will however need to be deployed after consultation with .cologne registrars, since many registrars do not endorse direct communication between the registry and registrants, i.e. their customers.
* 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 NetCologne GmbH does not intend to replicate this reminder procedure on the registry level, it will establish an auditing process that monitors the WDRP activities of .cologne registrars to make sure that WDRP responsibilities are honoured.


9. Resourcing Plans

The TANGO Registration System already supports the technical abuse prevention and mitigation measures above at the time of writing. No additional coding is required for this, which means that no special developing resources will be needed. Continuous audits and monitoring, as well as timely reactions to reports of malicious activity will be provided by the staff on duty at Knipp Medien und Kommunikation GmbH.

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 7 man days
* System Administrator: monitoring setup: 3 man days
* First Level Support: training: 1 man day per person
* Second Level Support: training: 1 man day per person

For the ongoing maintenance, the following resources are allotted:

* First Level Support: 10 man hours per month
* Second Level Support: 20 man hours per month
* System Administrator: 3 man hours per month

Employees already working for Knipp Medien und Kommunikation GmbH will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by Knipp in the past over the course of 12 months.
gTLDFull Legal NameE-mail suffixDetail
.eurovisionEuropean Broadcasting Union (EBU)ebu.chView

Q28 - Abuse Prevention and Mitigation

As the registry backend provider for .eurovision, CORE Internet Council of Registrars will work in close cooperation with the .eurovision Registry to establish thorough and effective methods to prevent abuse of .eurovision domain names, .eurovision 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 .eurovision Registry and CORE Internet Council of Registrars are committed to deploy extensive organisational and technical measures; these are described in the following.


1. Rapid Takedown Policy for Cases of Malicious Activity

The .eurovision Registry (and CORE Internet Council of Registrars as its technical provider) are committed to closely collaborate with law enforcement authorities and security agencies in order to take quick action in case a .eurovision 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),
* defines rules regarding the notification of involved parties (registrant, administrative contact, technical contact, registrar, informant, the public),
* defines ways to appeal against any measures taken,
* 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 scamming,
* use of the domain for spamming (affecting e-mail or other forms of electronic messaging),
* maintaining invalid registrant contact data in the domain.

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 be ceased),
* locking the domain and putting it on hold in order to prevent changes to the domain and to remove it from the .eurovision 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 .eurovision zone usually has serious consequences (such as rendering web sites and e-mail addresses utilising the domain name unusable), the .eurovision Registry (and CORE Internet Council of Registrars as its technical provider) will, in accordance with the policy, exercise extreme caution with regard to any takedown decision. At the same time, the .eurovision 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 .eurovision registrars and .eurovision registrants and be part of the Registry-Registrar Agreement (RRA) and the .eurovision registration terms.


2. Abuse Point of Contact

To ensure that the .eurovision Registry gets notified of any cases of abuse as quickly and easily as possible, an area of the public web site operated by the .eurovision Registry for the .eurovision 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 .eurovision support staffʹs ticket system, examined immediately and treated in accordance with the Rapid Takedown Policy.


3. Prevention of Domain Name Tasting and Domain Name Front Running

The life cycle of a .eurovision 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. As the registry operator for the .eurovision TLD, CORE Internet Council of Registrars 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ʺ)


4. 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).

Since .eurovision domains are (per registry policy) automatically renewed when they reach their expiration date, no explicit renewals by registrars are required to prevent a domain name from being deleted when they expire. Registrars need to explicitly delete domains in order to release them for re-registration. This substantially reduces opportunities for domain name sniping.

However, registrars may still send unintended domain deletions, i.e. due to clerical errors or miscommunication with the registrants. Even for these cases, measures against domain sniping are in place. Starting in 2002, registries have begun 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 to restore the domain before it becomes available for re-registration.

The CORE Registration System used by CORE Internet Council of Registrars to operate the .eurovision TLD 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)ʺ).


5. 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 .eurovision 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 CORE Registration System and its associated zone generation process ensures this by the following measures:

* As a general principle, glue records are only created if they are really necessary, i.e. only in the case where a name server (e.g. ʺns.example.eurovisionʺ) is used for the delegation of a superdomain of its own name, e.g. ʺexample.eurovisionʺ in this example. If the same name server is used for e.g. ʺexample2.eurovisionʺ, no glue record is created.
* A host object within the .eurovision TLD (like ʺns.example.eurovisionʺ) cannot exist without its parent domain (ʺexample.eurovisionʺ). Any attempt to create the host ʺns.example.eurovisionʺ will be rejected by the SRS if the domain ʺexample.eurovisionʺ doesnʹt already exist or is not sponsored by the registrar creating the host. Likewise, the domain ʺexample.eurovisionʺ cannot be deleted by the registrar if subordinate hosts like ʺns.example.eurovisionʺ still exist. These subordinate hosts have to be deleted before the domain itself may be deleted; if such hosts are used in delegations for other .eurovision 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 .eurovision 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 .eurovision 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 a DNS infrastructure depending on an offending domain name.


6. Preventing Use of Trademarked, Reserved, Invalid, Illegal or Otherwise Unsuitable .eurovision Names

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

* conducting a Sunrise phase to allow trademark holders to secure names related to their trademarks prior to GA,
* accessing a Trademark Clearinghouse to validate trademarks presented by registrants,
* offering a Trademark Claims Service, at least during the first 60 days of general availability,
* taking precautions against phishing and pharming and
* committing to full compliance with established Dispute Resolution and Suspension Procedures, including the Uniform Rapid Suspension (URS), the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP), and the Uniform Domain Name Dispute Resolution Policy (URDP).

Please refer to the answer to Question 29 for more detailed information on these measures.

In addition to these specific rights protection measures, the CORE Registration System provides the following general means to make sure that no .eurovision names are registered which are for other reasons deemed invalid, reserved, illegal, offensive or unsuitable.


6.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 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 supported IDN 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.

Please refer to the answer to Question 44 (Internationalised Domain Names) for more information on the rules governing valid IDNs in the .eurovision TLD.

For the tests checking for reserved names, custom lists of labels can be conveniently maintained by the .eurovision Registry to define the disallowed names for each category. Additional categories can also be added as required for enforcing specific policies of the .eurovision TLD.

The rules are stored in database tables (rather than static configuration files), which means rules can be added, deleted or altered by authorised registry personnel without requiring a shutdown or restart of the .eurovision SRS.


6.2 Compliance with Specification 5 of the Registry Agreement

The rule engine is the central system component ensuring that the .eurovision Registry will operate the .eurovision TLD in full compliance with Specification 5 (ʺSCHEDULE OF RESERVED NAMES AT THE SECOND LEVEL IN GTLD REGISTRIESʺ) of the Registry Agreement. Unless the .eurovision Registry is otherwise authorised by ICANN and the Government Advisory Committee (GAC) in writing, the rule engine for .eurovision will be set up to prohibit the registration of the labels and label types listed in Specification 5 by registrars.


6.3 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. The former is implemented by matching names against regular expressions, the latter by calculating the so-called ʺLevenshtein distanceʺ between the registered name and a given disallowed string (which is a measure for their similarity). Prior to performing any of these checks, the registered name is subjected to a number of normalisations in order to maximise its comparability; this includes the mapping of IDN characters with accents to their ASCII counterparts where feasible, the removal of hyphens and the removal of digits.

If a name matches a regular expression, or if the calculated Levenshtein distance falls below a certain threshold, the name is still normally registered, however it is also internally flagged for review. Due to the fuzzy nature of the pattern and Levenshtein matching, a name flagged via these checks may not necessarily be invalid or illegal; this is why the flagged names need to be reviewed manually by the .eurovision support staff. Flagged names automatically create tickets within the support teamʹs issue system, which starts a workflow that ultimately decides whether the name is permissible (in which case the flag is removed) or invalid⁄illegal (in which case the name is deleted and the registrar gets notified).


6.4 Handling of IDNs

In the context of abuse prevention, the proper handling of Internationalised Domain Names (IDNs) becomes an important aspect.

If different IDN scripts were allowed to be mixed within one domain name, so-called homographs could be used to make users believe they are looking at a certain web site while it is actually a different one which name just has an identical or very similar visual representation. For example, since the Cyrillic letter ʺErʺ (ʺрʺ in Cyrillic script) in lower case has the same visual appearance as the Latin lower case letter ʺpʺ, mixing Latin and Cyrillic scripts would allow the creation of a domain name like ʺрayрal.eurovisionʺ, a homograph of the Latin-only name ʺpaypal.eurovisionʺ which, despite being a different word, looks exactly the same. Such a domain name could thus e.g. be used for spoofing or phishing attacks. The .eurovision Registry prevents such abuse by implementing an IDN policy that disallows the mixing of scripts; within each label of a registered .eurovision, only characters from a single script may be used.

Likewise, the Cyrillic-only second level domain ʺрор.eurovisionʺ looks identical to its Latin-only counterpart ʺpop.eurovisionʺ. If only the rule described above (no mixing of scripts) would apply, these two names could coexist for different registrants, and could thus be abused to confuse users. However, the special way the .eurovision Registry handles such IDN variants while considering respective IDN tables and canonical forms of domain names, as described in detail in the answer to Question 44 (Support for Registering IDN Domains), prevents this situation; only one of these two domains may exist at the same time.


7. Domain Data Access Control

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


7.1 Prevention of Whois Data Mining

The port 43⁄web 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 CORE Registration System prevents such data mining attempts, most importantly by the following measures:

* Access to all Whois interfaces is rate-limited (when accessed from IP addresses not whitelisted for unlimited access).
* Web interface users are required to pass a CAPTCHA before access is granted.
* Web interface users seeking access to extended Whois search capabilities are required to authenticate by entering login credentials (which are only issued to eligible parties).
* For improved spam protection, E-mail addresses may be displayed as images only in the web-based Whois.
* Contact disclosure flags as specified in RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, are fully supported. This gives registrants enhanced 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.


7.2 Prevention of Unauthorised Data Modifications

Domain data within the .eurovision 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 their 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 CORE 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.


8. Whois Accuracy

Since .eurovision is operated as a so-called ʺthick registryʺ, the .eurovision Whois displays information about the registrant, as well as the administrative, technical and billing contacts of every .eurovision domain. In cases of malicious or abusive activity involving a .eurovision 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 organisations responsible for the domain in a timely manner. Consequently, it is deemed very important to maximise the accuracy of contact information stored in the registry repository.

The .eurovision Registry (and CORE Internet Council of Registrars as its technical provider) are therefore committed to take diligent measures to promote Whois accuracy, including (but not limited to) the following:

* Contact data completeness policy: The thick registry model used for .eurovision mandates the association of each .eurovision domain with exactly one registrant, one administrative contact, one technical contact and one billing contact. The data of all used contacts is stored in the registry repository. 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 .eurovision 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 .eurovision 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 XML Schema Definitions (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.
* 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. Likewise, phone and fax numbers will be checked for plausibility.
* Domain data change notifications: The CORE Registration System used to operate the .eurovision TLD 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 unauthorised or unintended changes to domain and contact data to be detected immediately. This functionality will however need to be deployed after consultation with .eurovision registrars, since many registrars do not endorse direct communication between the registry and registrants, i.e. their customers.
* 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 .eurovision 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 .eurovision registrars to make sure that WDRP responsibilities are honoured.


9. Resourcing Plans

The CORE Registration System already supports the technical abuse prevention and mitigation measures above at the time of writing. No additional coding is required for this, which means that no special developing resources will be needed. Continuous audits and monitoring, as well as timely reactions to reports of malicious activity will be provided by the staff on duty at CORE Internet Council of Registrars.

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 7 man days
* System Administrator: monitoring setup: 3 man days
* First Level Support: training: 1 man day per person
* Second Level Support: training: 1 man day per person

For the ongoing maintenance, the following resources are allotted:

* First Level Support: 10 man hours per month
* Second Level Support: 20 man hours per month
* System Administrator: 3 man hours per month

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.