gTLD	Full Legal Name	E-mail suffix	Detail
.cologne	NetCologne Gesellschaft für Telekommunikation mbH	netcologne.de	View

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.

gTLD	Full Legal Name	E-mail suffix	Detail
.ruhr	regiodot GmbH & Co. KG	dotzon.com	View

As the registry backend provider for .RUHR, Knipp will work in close cooperation with regiodot to establish thorough and effective methods to prevent abuse of .RUHR domain names, .RUHR 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, regiodot and Knipp are committed to deploy extensive organizational and technical measures; these are described in the following.
All policies described within this answer will be implemented upon the launch of the new .RUHR TLD and will also be made available prominently on the regiodot’s website.
As .RUHR domain names will principally be available to the general public, regiodot is well aware of the fact that clear, strict and enforceable policies are needed to prevent and to mitigate abusive registrations as well as abusive usage of .RUHR domain names.
By applying for and registering a .RUHR domain name the registrant will therefore need to agree to the terms and conditions of the .RUHR ACCEPTABLE USE POLICY (AUP).

1. .RUHR ACCEPTABLE USE POLICY (AUP)

The AUP will contain of

• the requirements for registering a .RUHR domain name,
• detailed descriptions of abusive registration⁄usage of .RUHR domain names, and
• the way in which regiodot and⁄or the sponsoring registrar or Registry may enforce the AUP by following the Rapid Takedown Policy.

The AUP will clearly state, that the registrant will accept .RUHR policies by applying for and registering a .RUHR domain name giving the registry the right to reject an application for a .RUHR domain name and⁄or to delete or cancel a .RUHR domain name registration directly.

1.1 Reserved⁄blocked domain names⁄local presence
As a first layer of security regiodot will exclude (blocked from and⁄or reserved for registration and⁄or internal usage by the registry) certain domain names for abuse prevention reasons from registration:

• names which are reserved on behalf of ICANN are not available at the second level and at all other levels within the .RUHR TLD;
• certain pornographic, defamatory or discriminatory words and expressions will be blocked from registration. Even though regiodot respects the fact, that registrants should be free to choose a .RUHR domain name, there a certain inappropriate words and expressions that should not be used;
• the official names of certain cities, authorities, institutions and regions as well as emergency numbers are blocked from general registration and will only be available to the respective entitled parties, which is an additional means of protecting the rights of the respective rights holders;
• certain Premium Names will be blocked from general registration and will be sold and⁄or auctioned off by regiodot;
• finally regiodot has the right to reserve certain .RUHR domain names for personal and ⁄ or internal usage and for the provision of directory services to populate the namespace with valuable information relevant to the region (as described in the answer to question 18).

.RUHR domain names will be available to registrants from all over the world.
In order to lower the risk for the .RUHR TLD from abusive registrations from abroad a local presence in Germany is needed to apply for a .RUHR domain name. Like DENIC, the Registry operating the “.de” ccTLD, regiodot has installed a requirement for registrants to name an Admin-C in Germany to whom correspondence can be served. This allows for an efficient enforcement of applicable laws as well as contractual sanctions, if needed.


1.2 Abusive Registrations⁄Abusive Usage
The most important goal of the AUP is the protection of the common Internet users, who are often not aware of the various threats and dangers.
Furthermore, regiodot and⁄or the sponsoring registrars will be enabled to investigate and to take action in case of malicious use of domain names and to deter registrants from engaging in illegal or fraudulent use of domain names.
The AUP will differentiate between “registration abuse” and “usage abuse” (together “malicious use”).
“Registration abuse” is:

• Use of faulty⁄falsified⁄incomplete⁄stolen person-related or company-related data on registration (danger to Whois accuracy, see below);
• Cybersquatting⁄typosquatting;
• Registration of illegal domain names , which themselves constitute a breach of applicable laws(see question 29);
“Usage abuse” is:
• Violation of applicable laws or regulation; in particular the provisions of the German Criminal Code, the German Youth Protection Act and the German Interstate Treaty on the Protection of Minors in the Media (JMStV);
• Use of a domain to publish content which incites to hatred against parts of the population or against a national, racial, religious or ethnic group, content which glorifies violence, content which violates the human dignity, content which denies or plays down acts committed under the National Socialist regime;
• Distribution of child abusive material;
• Use of a domain name for the dissemination of spam, i.e. unsolicited bulk electronic communication (e-mail, instant messaging, on websites, in forums or mobile messaging) or advertising a domain name by means of spam;
• Use of a domain name for Distributed Denial-of-service attacks (“DDoS attacks”);
• Use of domain names in phishing activities, tricking Internet users into divulging personal data such as names, addresses, usernames, passwords, or financial data;
• Use of domain names in pharming, such as DNS hijacking and DNS cache poisoning;
• Use of domain names for the intentional distribution of malicious code such as spyware, botware, keylogger bots, viruses, worms or trojans;
• Use of domain names to command and control botnets, i.e. a network of compromised computers or “zombies,”
• Use of domain names in activities intended to gain illegal access to other computers or networks (“hacking”), as well as any activity to prepare for such a system penetration; or
• Use of a domain name fast flux hosting, disguising the location of Internet addresses or Internet services.

1.3 Preventing Use of Trademarked, Reserved, Invalid, Illegal or Otherwise unsuitable .RUHR Names
As laid out in the answer to Question 29 (Rights Protection Mechanisms), regiodot takes extensive measures to protect the legal rights of others (such as trademark holders) with regard to .RUHR 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 TANGO Registration System provides the following general means to make sure that no .RUHR names are registered which are for other reasons deemed invalid, reserved, illegal, offensive or unsuitable.

a. 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 (Internationalized Domain Names) for more information on the rules governing valid IDNs in the .RUHR TLD.
For the tests checking for reserved names, custom lists of labels can be conveniently maintained by regiodot to define the disallowed names for each category. Additional categories can also be added as required for enforcing specific policies of the .RUHR TLD.
The rules are stored in database tables (rather than static configuration files), which means rules can be added, deleted or altered by authorized registry personnel without requiring a shutdown or restart of the .RUHR SRS.

b. Compliance with Specification 5 of the Registry Agreement
The rule engine is the central system component ensuring that regiodot will operate the .RUHR TLD in full compliance with Specification 5 (ʺSCHEDULE OF RESERVED NAMES AT THE SECOND LEVEL IN GTLD REGISTRIESʺ) of the Registry Agreement. Unless regiodot is otherwise authorized by ICANN and the Government Advisory Committee (GAC) in writing, the rule engine for .RUHR will be set up to prohibit the registration of the labels and label types listed in Specification 5 by registrars.
c. 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 normalizations in order to maximize 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 .RUHR 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).

d. Handling of IDNs
In the context of abuse prevention, the proper handling of Internationalized 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.RUHRʺ, a homograph of the Latin-only name ʺpaypal.RUHRʺ 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. Regiodot prevents such abuse by implementing an IDN policy that disallows the mixing of scripts; within each label of a registered .RUHR, only characters from a single script may be used.
Likewise, the Cyrillic-only second level domain ʺрор.RUHRʺ looks identical to its Latin-only counterpart ʺpop.RUHRʺ. 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 regiodot 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.
Regiodot 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.RUHRʺ and a very similar one with diacritics (like ʺpáypàl.RUHRʺ) 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, regiodot does not perform this kind of blocking, but allows the names to coexist in such cases. Should regiodot receive reports about names utilizing diacritics for abusive behavior, other countermeasures described in this chapter will be applied to stop the abuse.

1.4 Abusive usage of the registration process ⁄ Registry Interface Abuse
Finally, it might be possible to abuse the registration processes itself and ⁄ or the Registry Interface. Regiodot will implement contractual safeguards to prevent the following abuse schemes:

a. Prevention of Domain Name Tasting and Domain Name Front Running
The life cycle of a .RUHR 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 .RUHR TLD, Knipp 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ʺ)

b. 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 .RUHR 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 to operate the .RUHR 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)ʺ).

c. Domain Data Access Control
One important point of attack that may lead to abuse of .RUHR domains and their associated data is the unauthorized or excessive access to data stored within the .RUHR 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 .RUHR TLD to properly restrict access are laid out in the following.
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.

d. Prevention of Unauthorised Data Modifications
Domain data within the .RUHR 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.

2. Abuse Point of Contact
Abusive usage cannot and will not be tolerated. To ensure that the regiodot GmbH & Co. KG gets notified of any cases of abuse as quickly and easily as possible, an area of the public web site operated by the regiodot GmbH & Co. KG for the .RUHR 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. In addition this website will contain all applicable policies.
Every case reported will raise a high-priority ticket within the .RUHR support staffʹs ticket system, examined immediately and treated in accordance with the Rapid Takedown Policy. Regiodot (and Knipp 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 .RUHR name is reported to be involved in malicious activity. The ʺRapid Takedown Policyʺ contains guidelines and regulations on how to:

• identifiy cases of malicious activity,
• ways for the registry to be notified of such activity (e.g. via a dedicated web site, e-mail address or phone hotline),
• to quickly stop the malicious activity (after the activity was confirmed and impact of the measures has been assessed),
• the applicable service levels (e.g. with respect to the maximum time the registry may take to respond to takedown requests),
• notify the parties (registrant, administrative contact, technical contact, registrar, informant, the public),
• appeal against any measures taken,
• document and archive cases covered by the policy.

Reports and requests from competent authorities, law enforcement and⁄or courts receive top priority. These parties will receive priority contact options to ensure quick and proper reactions. Such requests will be handled and without delay, the latest within 24 hrs.
The abuse management is outsourced to the legal team at Schollmeyer & Rickert Rechtsanwaltsgesellschaft mbH (www.anwaelte.de), a law firm which will will ensure that the abuse point-of-contact has broad familiarity with current industry knowledge and a high-level awareness of evolving online security risks. The responsible partner is Attorney at law Thomas Rickert, who has considerable expertise in this area. Thomas Rickert has been the manager of a hotline taking complaints about illegal content and conduct on the Internet operated by eco Verband der deutschen Internetwirtschaft e.V. (www.eco.de) for several years. In addition to that he has been in the project managment of a tip line operated by eco and Freiwillige Selbstkontrolle Mutimediadienste e.V. (see www.internet-beschwerdestelle.de). Further, he was President of the Inhope Association (www.inhope.org), an international network of such hotlines, who co-operate with Law Enforcement, Internet Service Providers, Governments and NGOs to provide for efficient counter measures against the downside issues on the Internet, in particular child abusive material.
Thomas Rickert has also been advising registrars and working on domain disputes for 14 years and is a well-known expert in this area. Thomas Rickert has also been in the project management of the Spotspam project, a pilot project financially supported by the European Commission aiming at the facilitation of international co-operation in the fight against unsolicited electronic communication. He was also project manager of the ICRAdeutschland industry consortium which aimed at promoting user autonomous filtering systems to protect minors from being exposed to harmful content online.
After receiving the report, the law firm will determine the appropriate actions and notify the respective sponsoring registrar with a recommendation on what action should be taken. The recommendation also states the type of infringement and the legal basis of the sanction, such as the applicable terms of use, ICANN policies, applicable laws or the AUP.
The standard procedure – subject to the specifications of the Rapid Takedown Policy as described above - will be:

• the registrant will receive the complaint by email and is obliged to process and reply to all correspondence forwarded by .RUHR support staffʹ without delay, and at least within 48 hours, unless a third party has set a shorter period or there is other specific need for speed;
• with the response, the registrant must state whether he wishes cure the alleged breach or to defend against the third party allegation;
• a matter is settled when the registrant evidences to have cured the breach within the deadline given;
• should a registrant fail to respond to the request of RUHR support staffʹ in time, the following procedures (but are not limited to) to stop malicious shall apply:
o locking the domain and putting it on hold in order to prevent changes to the domain and to remove it from the .RUHR zone (ʺtakedownʺ),
o deleting the domain name and blocking it from further registration to prevent future abuse.

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. Where feasible depending on the urgency of the report and the violation, the communication with the registrant shall not be directly, but through the respective registrar.
Since removing a domain name from the .RUHR zone usually has serious consequences (such as rendering web sites and e-mail addresses utilizing the domain name unusable), regiodot (and Knipp as its technical provider) will, in accordance with the policy, exercise extreme caution with regard to any takedown decision. At the same time, regiodot 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 .RUHR registrars and .RUHR registrants and be part of the Registry-Registrar Agreement (RRA) and the .RUHR registration terms.

3. 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 .RUHR 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.RUHRʺ) is used for the delegation of a superdomain of its own name, e.g. ʺexample.RUHRʺ in this example. If the same name server is used for e.g. ʺexample2.RUHRʺ, no glue record is created.
• A host object within the .RUHR TLD (like ʺns.example.RUHRʺ) cannot exist without its parent domain (ʺexample.RUHRʺ). Any attempt to create the host ʺns.example.RUHRʺ will be rejected by the SRS if the domain ʺexample.RUHRʺ doesnʹt already exist or is not sponsored by the registrar creating the host. Likewise, the domain ʺexample.RUHRʺ cannot be deleted by the registrar if subordinate hosts like ʺns.example.RUHRʺ 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 .RUHR 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 .RUHR 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 .RUHR 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.

4. Whois Accuracy
Since .RUHR is operated as a so-called ʺthick registryʺ, the .RUHR Whois displays information about the registrant, as well as the administrative, technical and billing contacts of every .RUHR domain. In cases of malicious or abusive activity involving a .RUHR 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.
Regiodot (and Knipp 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 .RUHR mandates the association of each .RUHR 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 .RUHR 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 .RUHR 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 .RUHR 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 unauthorized or unintended changes to domain and contact data to be detected immediately. This functionality will however need to be deployed after consultation with .RUHR 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 regiodot does not intend to replicate this reminder procedure on the registry level, it will establish an auditing process that monitors the WDRP activities of .RUHR registrars to make sure that WDRP responsibilities are honored.

5. 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.
For the initial setup, the following resources are allotted:

• Registry Policy Officer: finalizing 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 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.
Schollmeyer & Rickert Rechtsanwaltsgesellschaft mbH has seven attorneys plus additional support staff so that an efficient abuse management can be granted even if the volume of complaints should be high at times. The abuse management will be rendered on the basis of a fix fee as already included in the financial projections. There will be no additional costs for regiodot.