28 Abuse Prevention and Mitigation

Prototypical answer:

Question 28: Concerns on Abuse Prevention and Mitigation

As detailed in the answer to question 18(A) the mission of the proposed .gmbh gTLD is to

• establish a trusted namespace for GmbHs with validated registrants;
• provide unique content and ⁄ or added value information about GmbHs or relevant to GmbHs with via domain names operated by validated registrants (e.g. register.gmbh or search.gmbh);
• help to forge trust in e-commerce; and
• provide for a safer and more secure surfing experience and reduce the risk of users being deceived by illegitimate offers and therefore mitigate the risk of users becoming victims of abusive behavior and malicious conduct.


The Applicant is well aware of the fact that abusive registrations are able to cause harm to the aforementioned proposed mission as well as to the reputation of the new name space, before it can even be established. Therefore the proposed use for the .gmbh gTLD will include robust protection mechanisms designed to preclude any abusive registrations within the space.


In particular the Applicant will implement the following policies upon the launch of the new .gmbh gTLD, which will also be made available prominently on the Applicant’s website:

“.GMBH Eligibility Policy”
“.GMBH ACCEPTABLE USE POLICY” (AUP)



All policies will be made binding for all registrants by contractually obligating sponsoring registrars through the Registry-Registrar Agreement (RRA) to pass on the above mentioned policies as part of their registration agreements.

These abuse protection mechanisms will described in the following.

The Applicant will additionally:


• Restrict and⁄or block certain domain names from registration.
• Develop a trusted method of communication for all correspondence between the Applicant and the TLDʹs registrars, to ensure that all registrant contact information, including WHOIS records, is complete and remains current, and that all requests for registration within the space may be easily verified for authenticity.
Implement effective mechanisms for identifying and addressing abusive practices.
• Establish a point of contact for third-party reporting of abusive practices.
• Determine and implement a streamlined practice for addressing and removing orphan glue records.


All policies described within this answer will be implemented upon the launch of the new .gmbh gTLD and will also be made available prominently on the Applicant’s website.


A. Blocked ⁄ Reserved names

As a first layer of security the Applicant will exclude (blocked from and⁄or reserved for registration and⁄or internal usage by the Applicant) 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 .gmbh gTLD;
• certain pornographic, defamatory or discriminatory words and expressions will be blocked from registration;
• the official names of cities, authorities, institutions and regions are blocked from general registration and will only be available to the respective entitled parties subject to the eligibility criteria;
• country codes and national emergency numbers are blocked form reservation;
• finally the Applicant has the right to reserve certain .gmbh domain names for personal and ⁄ or internal usage.


B. Eligibility Policy


The .gmbh gTLD will only be available to specific registrants. This enables the Applicant to control the registration process and the WHOIS accuracy in a way most registries are not able to, thus providing a extra layer of security to prevent registration abuse.

The “.GMBH Eligibility Policy” will detail that only GmbHs and gGmbHs (the latter being GmbHs serving the public good) whose existence can be validated with the respective public registers in Germany, Austria, Switzerland, Liechtenstein and Luxembourg are eligible registrants. The Applicant will validate each registrant by checking the respective public registers. Should a registrant cease to be a member of eglible registrants the Applicant has the right to cancel the registration.

It will further specify how the names entered into registers will be „translated“ into domain names. This is particularly important because for example many companies are known in the trade by a catchword or acronym and users would be confused if they were „confronted“ with the full company name.

Subject to further specification, as a general rule the following will apply:

• the domain name applied for must be identical to the text string used within the respective public registers; or
• the domain name must be the characterizing text string in company names that consist of multiple parts; or
• the domain name must be an acronym of the company name the use of which the registrant can evidence;
• if a qualifying name contains spaces, the Applicant is entitled to remove these entirely and⁄or replace them by hyphens;
• if a qualifying name contains special characters, e.g. -, @, !, §, %, ^, © or &, the Applicant is entitled to remove these special characters entirely, transcribe them or replace them by hyphens;
• if a qualifying name contains letters with additional elements not contained in the Standard Latin Script (e.g. ä, é, ñ), the Applicant is entitled:

- to replace these characters with conventional letters (e.g. a, e, n) or
- to substitute conventional spellings, e.g. replace ä with ae, or
- to represent the spelling in a “U-label”, as provided in the IDN standard.

Finally, the Applicant is entitled to delete the conventional designations of a legal entity, e.g. “GmbH” or “Gesellschaft”, as those will be part of the new .gmbh gTLD.


B.”.GMBH ACCEPTABLE USE POLICY” (AUP)”

AUP will contain provisions reserving the Applicant the right to deny, cancel or transfer any registration, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, at its discretion (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests by law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of the applicant, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) in accordance with the terms of the registration agreement or (5) to correct mistakes made by the applicant or any sponsoring registrar in connection with a domain name registration.

The AUP will clearly state, that the registrant will enter into a direct agreement with the Applicant by applying for and registering a .gmbh domain name giving the Applicant the right to reject an application for a .gmbh domain name and⁄or to delete or cancel a .gmbh domain name registration directly.


Furthermore, the Applicant 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 (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, adresses, 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.


As detailed in the answer to Question 29 (Rights Protection Mechanisms), the Applicant will implement various protection mechanisms to protect third party rights with regard to .gmbh domain names. This includes
• conducting a Sunrise phase to allow trademark holders to secure names related to their trademarks prior to general availability,
• implementing so-called grandfathering provisions for holders of certain, identical domain names;
• 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), the Uniform Domain Name Dispute Resolution Policy (URDP), and the Registration Restriction Dispute Resolution Policy (RRDRP).

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


C. Point of Contact for Abuse Complaints


The Applicant will provide Internet users with a prominent online point of contact to report “Registration Abuse” or “Usage Abuse” as defined above by using a standardized web form enabling every user to report abuse.

The key points of the online point of contact are:

- The complaints procedure is open to any user;
- Users must give at least one email address where they can be notified of the status of the complaint procedure;
- Depending on which abuse variant they select, users are obliged to supply certain additional information; there is also the option to upload e.g. screenshots or other files for the purposes of evidence;
- If the predefined abuse forms do not fit, users can enter their own information which must meet certain minimum standards for length (to prevent abuse of the form);
- Users must state in every case for which .gmbh domain names a complaint is being submitted;
- Users must finally declare in every case that all the information submitted is true; the form is secured by a CAPTCHA query.


The abuse email inbox will be routinely and continuously monitored several times per day. Complainants will be provided with a responsive communication containing an auditable tracking or case number.

The abuse point of contact will be responsive and effective, tasked with answering email quickly, empowered to take effective action, and guided by well-defined written criteria. This role-based function will be performed by the legal team at Schollmeyer & Rickert Rechtsanwaltsgesellschaft mbH (www.anwaelte.de), a law firm which 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 management 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.
The law firm has seven attorneys so that an efficient abuse management can be granted even if the volume of complaints should be high at times.

With regard to the estimated number of registrations and the Registration Restrictions, these allocated resources will be sufficient to handle the expected initial volume of abuse complaints. Abuse complaint metrics will be tracked and reviewed carefully each year, and adequate resources will be expended to ensure appropriate trending of those metrics, thus providing the abuse point of contact with sufficient resources.

Given the Applicant’s belief that infrastructure protection, rights protection, and user security are of paramount importance for a TLD owner, the Applicant expects to ensure sufficient resources for this critical role, and to do whatever is reasonably necessary to ensure a secure and trusted zone.


D. Handling of Abuse Reports

All abuse reports received by the abuse point of contact will be tracked internally in a ticketing system to ensure accountability and ease of reference, and a tracking number will be provided to the reporter. Each report will be carefully reviewed and evaluated regarding its credibility, to determine whether the reported issue is an abuse concern and to assess the required action(s), if any. The Applicant will work in tandem with the sponsoring registrar as well as the Registry Service Provider to rapidly address potential threats or abuse complaints, investigate all reasonable complaints, and take any appropriate action(s) thereto.

As standard practice, the Applicant’s abuse team will forward all credible and actionable reports including the accompanying evidence with a recommendation what action should be taken to the sponsoring registrar, with a request to investigate the issue further and to take appropriate action. The sponsoring registrar has a direct relationship with the registrant and therefore possesses further information not available to the Applicant, such as payment details, sales history, and IP addresses of the customer, reseller data (if applicable) and other specific data unique to the customer. 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 will be:

• The Abuse Team will notify the respective sponsoring registrar detailing the reported abuse and recommend the appropriate action(s) which should be taken;
• The registrant will receive the complaint by email and is obliged to process and reply to all correspondence forwarded by its sponsoring registrar 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 Applicant’s abuse team in time, Applicant ⁄ the sponsoring registrar is entitled to delete or suspend the respective domain name or make certain content or services offered there under unavailable, e.g. put the domain name on HOLD.

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 resolved by Applicant’s abuse team without delay, the latest within 24 hrs. The Applicant will implement valid court orders or seizure warrants from courts, arbitration tribunals, or law enforcement agencies of applicable jurisdiction as a top priority. The Applicant will further work closely with law enforcement agencies if necessary.

In all cases the Applicant reserves the right to act directly and immediately in cases of obvious and significant malicious conduct.

Based upon the applicable registration policies and restrictions, the Applicant does not expect further measures to be required to effectively prevent or stop malicious use. In case of an unexpected volume of credible abuse complaints, the Applicant will take advantage of additional resources such as spam databases and blocklists, anti-phishing feeds, analysis of registration data, and DNS queries.


E. Orphan Glue Records

According to the ICANN SSAC paper SAC048 at: http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf orphan glue records are defined as follows:

“By definition, orphan records used to be glue records. A glue record becomes an ‘orphan’ when the delegation point NS record referencing it is removed without also removing the corresponding glue record. The delegation point NS record is sometimes referred to as the parent NS record.”

An orphan glue record can occur whenever a domain is placed in ServerHold or ClientHold status. In these cases, the domain is removed from the zone file but existing name servers of this domain will be kept in the zone file so that other sites which are still using these name servers are still kept functional.

Example:
“example.string” is deleted from the zone file by setting to ServerHold status, but “ns1.example.string” will be kept in the zone file.

D.1 Prevention of Orphan Glue Records During Domain Deletion

Deleting a domain name is only possible if there are no glue records used by other domains associated with the domain being deleted.

If there are glue records available but not used by other domains in the registry, the glue records will be deleted prior to the domain deletion. Whenever there are glue records available which are still in use, this has to be resolved first. If there are no glue records at all the domain can be deleted instantly.

Solving the problem of glue records for domains which are supposed to be deleted can be done by checking the zone file. The zone file reveals the domains which are using the name servers. Once the required information is available, the named registrars must be contacted and new name servers should be set for the remaining domains in order to release the glue records.

In cases where glue records are being used in a malicious way, the abuse point of contact has to be contacted. The abuse point of contact will check this issue and take any appropriate actions, which may result in removing relevant records from the zone file in case the abuse complaint is valid.


F. Preventive Countermeasures

Pharming is an abusive practice used to gain illegal access to personal and confidential internet user information by diverting internet traffic through the manipulation of the information between the recursive resolver name server and the client software (e.g. web browser) (DNS-cache poisoning). Since pharming is commonly accomplished by redirecting traffic at the recursive DNS level, mitigation is most effective at the ISP level.

However, as an added countermeasure, the Registry Service Provider registry.net will sign the domain zone using DNSSEC, as detailed in the answer to question 35, allowing the relying party to establish a chain of trust from the DNS root down to the domain name, thus validating DNS queries in the zone.

Registrars will be encouraged to use a DNSSEC enabled DNS hoster and to provision the related delegation signers (originating from the DNS hoster) to registry.net’s SRS via EPP. This way it will be possible for the relying party to validate DNS queries and to protect from DNS tampering to a certain degree.

DNSSEC is a set of records and protocol modifications that provide authentication of the signer of the DNS data, verification of integrity of the DNS data against modification, non-repudiation of DNS data that have been signed, and authenticated denial of existence of DNS records. DNS data secured with DNSSEC are cryptographically signed and incorporate asymmetric cryptography in the DNS hierarchy, whereby trust follows the same chain as the DNS tree, meaning that trust originates from the root and is delegated in the same way as the control of a domain. When a domain name in the TLD is requested by a browser, the signature is validated with the public key stored in the parent zone.


G. Promoting Accurate WHOIS Data

The Applicant is committed to maintaining the zone as a safe, secure online environment. A key component of such a plan is the creation and upkeep of accurate WHOIS records for the registry. All registrants will be validated against public registers.

As indicated in detail in the above answer to Question 26, the Applicant will develop strong safeguards to verify the accuracy and privacy of the data stored in the WHOIS database, and will ensure that such records will be publicly-available to the extent required by ICANN regulations. The WHOIS records for this TLD will constitute a “thick” WHOIS, combining all applicable data and information for domain name registrants in a central location.

The Applicant shall expressly reserve the right to cancel or suspend any domain name registrations within the space should a registrant fail to provide accurate or complete whois information. Details will be executed in the Registration Guidelines.

In order to ensure Whois Accuracy, registrars will be obligated by the Registry-Registrar Agreement to commit registrants to provide only current, accurate and complete whois data according to the Registration Guidelines.

The Registry Service Provider will ensure that registrars comply with the contractual agreements to provide accurate data, including the use of field-valid telephone and fax numbers and the use of country names as defined under ISO 3166.

Complaints about Inaccurate Whois Information can be filed by everyone via InterNICs website (http:⁄⁄www.internic.org). The well developed process for the Whois Data Problem Reports (WDPR) will assure a prompt investigation by the responsible registrar and - in case - correction of whois data.

Registrars will be obligated by the RRA to fulfill ICANNs Whois Data Reminder Policy (WDRP). This means, a registrar must present to the registrant the current Whois information, and remind the registrant that provision of false Whois information can be grounds for cancellation of their domain name registration. Registrants must review their Whois data, and make any corrections.

The Applicant will take adequate measures to ensure whois accuracy by random examinations of whois data against public registers like telephone directories or other suitable measures.

H. Ensuring Proper Access to Domain Functions

The Registry will be operated using a comprehensive and detailed authentication system designed to implement a wide range of registry functions for both internal operations and as external registrar access. Registrar access will be limited by IP address control lists and TLS⁄SSL certificates, as well as verification processes for proper authentication and appropriate limitations to restrict access to the sponsored objects.

Each domain name will be assigned a unique AUTH-INFO code. The AUTH-INFO code is a 6- to 16-character code assigned by the registrar at the time a domain is created and which can be modified by the registrar at any time. Its purpose is to aid in the identification of the domain owner so that proper authority can be established. For example, a registrar-to-registrar transfer can be initiated only by using the correct AUTH-INFO code, to ensure that domain updates (update contact information, transfer, or deletion) are undertaken by the authorized registrant. Access to the domain’s AUTH-INFO code, stored in the registry, is limited to the sponsoring registrar and is accessible only via encrypted, password-protected channels.

Registrars will be obligated by the RRA to provide best practice processes like Form-Of-Authorization (FOA) emails to confirm a domain name transfer and will be encouraged to take advantage of the domain status clientTransferProhibited to mitigate abuse.

Further security measures are anticipated and will be implemented in the new space, but are currently treated as confidential for security reasons. Accordingly, a full explanation of these mechanisms may be found in the response to Question 30(b).

I. Resourcing Plan

Staff will deal with these tasks, where needed, since the abuse management is entirely outsourced.
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 the Applicant.

J. References and Attachments

http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf

Similar gTLD applications: (0)