28 Abuse Prevention and Mitigation

Prototypical answer:

The Registry Operator, Merck KGaA, working with Afilias, will take the requisite operational and technical steps to promote WHOIS data accuracy, limit domain abuse, remove outdated and inaccurate data, and other security measures to ensure the integrity of the “.MERCK” Top-Level Domain (“TLD”). The specific measures include, but are not limited to:

- Posting a TLD Anti-Abuse Policy that clearly defines abuse, and provide point-of-contact information for reporting suspected abuse;
- Committing to rapid identification and resolution of abuse, including suspensions;
- Ensuring completeness of WHOIS information at the time of registration;
- Publishing and maintaining procedures for removing orphan glue records for names removed from the zone; and,
- Establishing measures to deter WHOIS abuse, including rate-limiting, determining data syntax validity, and implementing and enforcing requirements from the Registry-Registrar Agreement


A. Abuse policy

The Anti-Abuse Policy stated below will be enacted under the contractual authority of the registry operator through the Registry-Registrar Agreement, and the obligations will be passed on to and made binding upon registrants. This policy will be posted on the TLD web site along with contact information for registrants or users to report suspected abuse.

The policy is designed to address the malicious use of domain names. The registry operator and its registrars will make reasonable attempts to limit significant harm to Internet users. This policy is not intended to take the place of the Uniform Domain Name Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension System (URS), and it is not to be used as an alternate form of dispute resolution or as a brand protection mechanism. Its intent is not to burden law-abiding or innocent registrants and domain users; rather, the intent is to deter those who use domain names maliciously by engaging in illegal or fraudulent activity.

The below policy is a recent version of the policy that has been used by the “.INFO” registry since 2008, and the “.ORG” registry since 2009. It has proven to be an effective and flexible tool, and Merck KGaA anticipates adopting it in connection with the new “.MERCK” TLD.

A.1 “.MERCK” Anti-Abuse Policy

The following Anti-Abuse Policy is effective upon launch of the TLD. Malicious use of domain names will not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars, and registrants, as well as for users of the Internet in general. The registry operator definition of abusive use of a domain includes, without limitation, the following:

- Illegal or fraudulent actions;
- Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums;
- Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information, usernames, passwords, or financial data;
- Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through, but not limited to, DNS (Domain Name System) hijacking or poisoning;
- Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and Trojan horses;
- Malicious fast-flux hosting: Use of fast-flux techniques with a botnet to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities;
- Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct distributed denial-of-service attacks (DDoS attacks);
- Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). This also includes any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity)

Pursuant to the Registry-Registrar Agreement, the Registry Operator reserves the right at its sole discretion to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of registry operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement and this Anti-Abuse Policy, or (5) to correct mistakes made by registry operator or any registrar in connection with a domain name registration. The Registry Operator also reserves the right to place upon registry lock, hold, or similar status a domain name during resolution of a dispute.

The policy stated above will be accompanied by notes about how to submit a report to the Registry Operator’s abuse point of contact, and how to report an orphan glue record suspected of being used in connection with malicious conduct (see below).


B. Abuse point of contact and procedures for handling abuse complaints

The Registry Operator will establish an abuse point of contact. This contact will be a role-based e-mail address of the form “abuse@registry.merck”. This e-mail address will allow multiple staff members to monitor abuse reports on a 24x7 basis, and then work toward closure of cases as each situation calls for. This role-based approach has been used successfully by ISPs, e-mail service providers, and registrars for many years, and is considered a global best practice.

The Registry Operator’s designated abuse handlers will then evaluate complaints received via the abuse system address. They will decide whether a particular issue is of concern, and decide what action, if any, is appropriate. A tracking ticket will be generated which will be used to track the report internally at the Registry Operator, and will also be provided to the reporter for reference and potential follow-up.

In general, the Registry Operator will find itself receiving abuse reports from a wide variety of parties, including security researchers and Internet security companies, financial institutions such as banks, ordinary Internet users, and law enforcement agencies among others. Some of these parties may provide good forensic data or supporting evidence of the malicious behavior. In other cases, the party reporting an issue may not be familiar with how to provide such data or proof of malicious behavior. It is expected that a percentage of abuse reports to the registry operator will not be actionable, because there will not be enough evidence to support the complaint (even after investigation), and because some reports or reporters will simply not be credible.

Assessing abuse reports requires great care, and the Registry Operator will rely upon professional, trained investigators who are versed in such matters. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants.

Different types of malicious activities require different methods of investigation and documentation. Further, the Registry Operator expects to face unexpected or complex situations that call for professional advice, and will rely upon professional, trained investigators as needed.

In general, there are two types of domain abuse that must be addressed:

- Compromised domains. These domains have been hacked or otherwise compromised by criminals, and the registrant is not responsible for the malicious activity taking place on the domain. For example, the majority of domain names that host phishing sites are compromised. The goal in such cases is to get word to the registrant (usually via the registrar) that there is a problem that needs attention with the expectation that the registrant will address the problem in a timely manner. Ideally such domains do not get suspended, since suspension would disrupt legitimate activity on the domain
- Malicious registrations. These domains are registered by malefactors for the purpose of abuse. Such domains are generally targets for suspension, since they have no legitimate use

The standard procedure is that the Registry Operator will forward a credible alleged case of malicious domain name use to the domain’s sponsoring registrar with a request that the registrar investigate the case and act appropriately. The registrar will be provided evidence collected as a result of the investigation conducted by the trained abuse handlers. The registrar is the party with a direct relationship with—and a direct contract with—the registrant. The registrar will also have vital information that the Registry Operator will not, such as:

- Details about the domain purchase, such as the payment method used (credit card, PayPal, etc.);
- The identity of a proxy-protected registrant;
- The purchaser’s IP address;
- Whether there is a reseller involved; and,
- The registrant’s past sales history and purchases in other TLDs (insofar as the registrar can determine this)

Registrars do not share the above information with Registry Operators due to privacy and liability concerns, among others. Because they have more information with which to continue the investigation, and because they have a direct relationship with the registrant, the registrar is in the best position to evaluate alleged abuse. The registrar can determine if the use violates the registrar’s legal terms of service or the registry Anti-Abuse Policy, and can decide whether or not to take any action. While the language and terms vary, registrars will be expected to include language in their registrar-registrant contracts that indemnifies the registrar if it takes action, and allows the registrar to suspend or cancel a domain name; this will be in addition to the registry Anti-Abuse Policy. Generally, registrars can act if the registrant violates the registrar’s terms of service, or violates ICANN policy, or if illegal activity is involved, or if the use violates the registry’s Anti-Abuse Policy.

If a registrar does not take action within a time period indicated by the Registry Operator (usually 24 hours), the Registry Operator might then decide to take action itself. At all times, the Registry Operator reserves the right to act directly and immediately if the potential harm to Internet users seems significant or imminent, with or without notice to the sponsoring registrar.

When valid court orders or seizure warrants are received from courts or law enforcement agencies of relevant jurisdiction, the registry operator will order execution in an expedited fashion. Compliance with these will be a top priority and will be completed as soon as possible.

The Registry Operator may also engage in proactive screening of its zone for malicious use of the domains in the TLD, and report problems to the sponsoring registrars. The Registry Operator could take advantage of a combination of the following resources, among others:

- Blocklists of domain names and nameservers published by organizations such as SURBL and Spamhaus
- Anti-phishing feeds, which will provide URLs of compromised and maliciously registered domains being used for phishing
- Analysis of registration or DNS query data [DNS query data received by the TLD nameservers]

The Registry Operator will keep records and track metrics regarding abuse and abuse reports. These will include:

- Number of abuse reports received by the registry’s abuse point of contact described above;
- Number of cases and domains referred to registrars for resolution;
- Number of cases and domains where the registry took direct action;
- Resolution times;
- Number of domains in the TLD that have been blacklisted by major anti-spam blocklist providers; and,
- Phishing site uptimes in the TLD

Law enforcement is only expected to be involved in a miniscule percentage of e-crime cases, due to the large number of such incidents worldwide, the limited resources available to the authorities, and the difficulties of investigating and prosecuting across jurisdictions. The Registry Operator will be prepared to call upon relevant law enforcement bodies as needed.


C. Removal of orphan glue records

By definition, orphan glue records used to be glue records. Glue records are related to delegations and are necessary to guide iterative resolvers to delegated nameservers. A glue record becomes an orphan when its parent nameserver record is removed without also removing the corresponding glue record. (Please reference the ICANN SSAC paper SAC048 at: http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf.) Orphan glue records may be created when a domain (example.tld) is placed on EPP ServerHold or ClientHold status. When placed on Hold, the domain is removed from the zone and will stop resolving. However, any child nameservers (now orphan glue) of that domain (e.g., ns1.example.tld) are left in the zone. It is important to keep these orphan glue records in the zone so that any innocent sites using that nameserver will continue to resolve. This use of Hold status is an essential tool for suspending malicious domains.

Afilias observes the following procedures, which are being followed by other registries and are generally accepted as DNS best practices. Afilias believes these procedures are also in keeping with ICANN SSAC recommendations.

When a request to delete a domain is received from a registrar, the registry first checks for the existence of glue records. If glue records exist, the registry will check to see if other domains in the registry are using the glue records. If other domains in the registry are using the glue records then the request to delete the domain will fail until no other domains are using the glue records. If no other domains in the registry are using the glue records then the glue records will be removed before the request to delete the domain is satisfied. If no glue records exist then the request to delete the domain will be satisfied.

If a registrar cannot delete a domain because of the existence of glue records that are being used by other domains, then the registrar may refer to the zone file or the “weekly domain hosted by nameserver report” to find out which domains are using the nameserver in question and attempt to contact the corresponding registrar to request that they stop using the nameserver in the glue record. The registry operator does not plan on performing mass updates of the associated DNS records.

The registry operator will accept, evaluate, and respond appropriately to complaints that orphan glue is being used maliciously. Such reports should be made in writing to the registry operator, and may be submitted to the registry’s abuse point-of-contact. If it is confirmed that an orphan glue record is being used in connection with malicious conduct, the registry operator will have the orphan glue record removed from the zone file. Afilias has the technical ability to execute such requests as needed.


D. Methods to promote WHOIS accuracy

The creation and maintenance of accurate WHOIS records is an important part of registry management. As described in the response to Question #26, WHOIS, the Registry Operator will manage a secure, robust and searchable WHOIS service for this TLD.

D.1 WHOIS data accuracy

The Registry Operator will offer a “thick” registry system. In this model, all key contact details for each domain name will be stored in a central location by the registry. This allows better access to domain data, and provides uniformity in storing the information. The Registry Operator will ensure that the required fields for WHOIS data (as per the defined policies for the TLD) are enforced at the registry level. This ensures that the registrars are providing required domain registration data. Fields defined by the registry policy to be mandatory, are documented as such and must be submitted by registrars. The Afilias registry system verifies formats for relevant individual data fields (e.g. e-mail, and phone⁄fax numbers). Only valid country codes are allowed as defined by the ISO 3166 code list.


D.2 Role of registrars

As part of the RRA (Registry Registrar Agreement), the registry operator will require the registrar to be responsible for ensuring the input of accurate WHOIS data by their registrants. The Registrar⁄Registered Name Holder Agreement will include a specific clause to ensure accuracy of WHOIS data, and to give the registrar rights to cancel or suspend registrations if the Registered Name Holder fails to respond to the registrar’s query regarding accuracy of data. ICANN’s WHOIS Data Problem Reporting System (WDPRS) will be available to those who wish to file WHOIS inaccuracy reports, as per ICANN policy (http:⁄⁄wdprs.internic.net⁄

D.3 Privacy services

In order to promote transparency and accuracy within the WhoIs records for the space, privacy registration services shall not be permitted within the “.MERCK” TLD.


E. Controls to ensure proper access to domain functions

Several measures are in place in the Afilias registry system to ensure proper access to domain functions, including authentication provisions in the RRA relative to notification and contact updates via use of AUTH-INFO codes.

IP address access control lists, TLS⁄SSL certificates and proper authentication are used to control access to the registry system. Registrars are only given access to perform operations on the objects they sponsor.

Every domain will have a unique AUTH-INFO code. The AUTH-INFO code is a 6- to 16-character code assigned by the registrar at the time the name is created. Its purpose is to aid identification of the domain owner so proper authority can be established. It is the ʺpasswordʺ to the domain name. Registrars must use the domain’s password in order to initiate a registrar-to-registrar transfer. It is used to ensure that domain updates (update contact information, transfer, or deletion) are undertaken by the proper registrant, and that this registrant is adequately notified of domain update activity. Only the sponsoring registrar of a domain has access to the domain’s AUTH-INFO code stored in the registry, and this is accessible only via encrypted, password-protected channels.

Information about other registry security measures such as encryption and security of registrar channels are confidential to ensure the security of the registry system. The details can be found in the response to Question #30b.

As “.MERCK” will constitute a community-based TLD, it is of paramount importance that the Registry Operator’s eligibility and registration restrictions are enforced by registrars. Accordingly, compliance with the Registration Restrictions and Use Policy for the “.MERCK” space, outlined above in the answer to Question 20(e) and provided in full below, will be required of all registrars offering “.MERCK” domain names via the Registry-Registrar Agreement.


F. Registration Approval System

The Registry Operator, Merck KGaA, will maintain the “.MERCK” space on behalf of the Merck Community, and the companies in the Merck Community will be the sole registrants of domain names within the TLD. Prior to registration of any domain name in “.MERCK,” the Corporate Trademark Department of Merck KGaA will review and approve each applied-for second-level domain name string, to ensure that it will further the goals of the Merck Community.

Registration of a “.MERCK” domain name will involve three steps: Approval of the Registrant, Approval of the Domain Name, and Registration. After Registration, the holder of a “.MERCK” domain name must comply with the Acceptable Use Guidelines located in Section P of the “.MERCK” Registration Restrictions and Use Policy. The “.MERCK” Registration Restrictions and Use Policy will be incorporated contractually, through registrar compliance with the Registry-Registrar Agreement, into every Registration Agreement for domain names in the TLD.

F.1 Step 1 – Approval of the Community Member

Each Registrant must be recognized as member of the Merck Community as defined above under Question 18(a). Upon receiving a request from a potential registrant, the Corporate Trademark Department at Merck KGaA will perform an eligibility assessment, to determine whether the applicant qualifies as a member of the Merck Community. This process will include an application form that the prospective member must fill out, and verification of the applicant’s identity by Merck KGaA. If successful, such assessment will be concluded by assigning a ʺMerck Community Membership IDʺ to the new member. Once a member has obtained a Merck Community Membership ID, the member is entitled to register domain names within the “.MERCK” TLD that have been approved by the Corporate Trademark Department of Merck KGaA.

The member approval step needs to be performed only once for each member⁄registrant. The member’s Merck Community Membership ID is a permanent assignment, and will remain the same for all of that member’s domain name registrations.

F.2 Step 2 - Approval of the Second-Level-Domain by the Corporate Trademark Department of Merck KGaA

Before registering a domain name, each member must ask the Corporate Trademark Department of Merck KGaA for approval of the second-level string text. A domain name within the “.MERCK” TLD must:

- further the mission and purpose of the Merck Community;
- not violate or contribute to the violation of the intellectual property rights or other rights of any other party; and
- comply with any applicable laws, government rules or requirements

If the Corporate Trademark Department of Merck KGaA determines that the requested second-level domain name meets the above requirements, it will consent to such registration by the Community Member. The applicant will receive written notification from the Corporate Trademark Department, either consenting to or rejecting the domain request. Such notification will either take the form of an Approval Statement or a Rejection Statement, depending on Merck KGaA’s assessment.

F.3 Step 3 - Registration

When a second-level string request has been approved by the Corporate Trademark Department of Merck KGaA, a prospective registrant may contact an ICANN-accredited registrar to register the approved second-level string and pay the registration fee. The Merck Community Membership ID can be reused for multiple registrations by the same Registrant, and must be provided in the domain Create attempt submitted into the registry by the registrar. Create attempts that are not accompanied by a valid Community Membership I.D. will be automatically rejected by the registry system.

Once the domain Create request has been received at the registry, the domain record will be placed on a “Pending Create” status. This status includes an EPP ServerHold status, placed on the domain record so that the domain cannot resolve. The Registry Operator will then have the opportunity to view the pending domain name, and will be able to either approve the “Pending Create” (thus releasing the Hold status and enabling the Registrant to use the requested domain, or to reject the Create (which will delete the Registrant’s application for the domain name). The Merck KGaA legal team that reviews membership applications and approves domain strings will review all of the Pending Creates, and will compare those pending Creates will the membership and approved string data in its files.

This procedure will ensure that only qualified members of the Community can register domain names in the TLD, and that only approved domains can be used.

Merck KGaA, as the Registry Operator for “.MERCK,” and Afilias Limited have developed the necessary mechanism by which the Merck Community Membership ID and domain name registration authorization systems will function, in order to ensure that the process will operate smoothly and easily for all concerned actors, including for the domain name registrars.

F.4 Additional Notes Regarding Compliance

Registrants of “.MERCK” domain names will agree to the applicable gTLD Registration Agreement provided by the concerned registrar, in addition to the specific terms and conditions set out for the “.MERCK” space. Such additional terms and conditions shall, inter alia, incorporate the Registration Restrictions and Use Policy applicable to “.MERCK,” as well as the applicable dispute resolution mechanisms. Further information concerning the Acceptable Use provisions is outlined below.

The registrations and use of all registered “.MERCK” domain names will be monitored by Merck KGaA on an ongoing basis, and compliance with the contractual restrictions and guidelines will be enforced. Violations of any restrictions, guidelines or other contractual conditions may result in termination of the relevant domain name registration or, in appropriate circumstances, the revocation of the Merck Community Membership ID. As the Registry Operator, authorized Merck KGaA personnel will have access to registry system that will allow them to suspend domain names and revoke membership credentials as needed.

In order to reduce redundancy within the Application, for additional information please refer to the relevant text of the “.MERCK” Registration Restrictions and Use Policy below, and as discussed above in the answer to Question 20(e).

The identities of Registrants will be public, available via the WHOIS.


G. Validation and abuse mitigation mechanisms

Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the Registry Operator based on their policy and business needs.

Afilias has the ability to analyze the registration data for known patterns at the time of registration. A database of these known patterns is developed from domains and other associated objects (e.g., contact information) which have been previously detected and suspended after being flagged as abusive. Any domains matching the defined criteria can be flagged for investigation by the domain anti-abuse team members. Once analyzed and confirmed, these domains may be suspended. This provides proactive detection of abusive domains.

Provisions are available to enable the registry operator to only allow registrations by pre-authorized contacts. These verified contacts are given a unique code (the Merck Community Membership ID) which can be used for registration of new domains. As indicated above, each individual registration request for a second-level “.MERCK” domain name will be subject to approval by the Registry Operator, as Merck KGaA will have the opportunity to review (and either accept or reject) each “Pending Create” application for a domain within the TLD space.


H. Registrant pre-verification and authentication

One of the systems that could be used for validity and identity authentication is VAULT (Validation and Authentication Universal Lookup). It utilizes information obtained from a series of trusted data sources with access to billions of records containing data about individuals for the purpose of providing independent age and id verification as well as the ability to incorporate additional public or private data sources as required. At present it has the following: US Residential Coverage - 90% of Adult Population and also International Coverage - Varies from Country to Country with a minimum of 80% coverage (24 countries, mostly European).

Various verification elements can be used. Examples might include applicant data such as name, address, phone, etc. Multiple methods could be used for verification include integrated solutions utilizing API (XML Application Programming Interface) or sending batches of requests.

- Verification and Authentication requirements would be based on TLD operator requirements or specific criteria
- Based on required WHOIS Data; registrant contact details (name, address, phone)
- If address⁄ZIP can be validated by VAULT, the validation process can continue (N. America +25 International countries)
- If in-line processing and registration and EPP⁄API call would go to the verification clearinghouse and return up to 4 challenge questions
- If two-step registration is required, then registrants would get a link to complete the verification at a separate time. The link could be specific to a domain registration and pre-populated with data about the registrant
- If Whois data is validated a token would be generated and could be given back to the registrar which registered the domain
- Whois data would reflect the Validated Data or some subset, i.e., fields displayed could be first initial and last name, country of registrant and date validated. Other fields could be generic validation fields much like a “privacy service”
- A “Validation Icon” customized script would be sent to the registrants email address. This could be displayed on the website and would be dynamically generated to avoid unauthorized use of the Icon. When clicked on the Icon would should limited WHOIS details i.e. Registrant: jdoe, Country: USA, Date Validated: March 29, 2011, as well as legal disclaimers
- Validation would be annually renewed, and validation date displayed in the WHOIS


I. Abuse prevention resourcing plans

The Registry Operator, Merck KGaA, will maintain resources to:

- Evaluate incoming reports to the abuse point of contact, and either act upon them or refer them to registrars as per the above-described procedures
- Evaluate incoming reports from other sources and either act upon them or refer them to registrars as per the above-described procedures
- Analyze the registry and TLD DNS zone activity for malicious and suspicious activity and either act upon them or refer them to registrars as per the above-described procedures

These resources may be a combination of internal staff and outside specialty contractors, who can provide the registry operator with extra expertise when needed. In any case, these responders will be specially trained in the investigation of abuse complaints, and will have the latitude to act expeditiously to suspend domain names (or apply other remedies) when called for.

Abuse prevention and detection is a function that is staffed across the various groups inside Afilias, and requires a team effort when abuse is either well hidden or widespread, or both. All of Afilias’ 200+ employees are charged with responsibility to report any detected abuse. The engineering and analysis teams, numbering over 30, provide specific support based on the type of abuse and volume and frequency of analysis required. The Afilias security and support teams have the authority to initiate mitigation.

I.1 Community-Specific enforcement

Pursuant to the terms of the Registration Restrictions and Use Policy for “.MERCK,” which will be incorporated in the Registration Agreement for each domain name in the space, the Registry Operator expressly reserves the authority to cancel, transfer or otherwise modify any domain name registration within the TLD, if it determines that such domain name has not been registered or used within the requirements of the Policy. As the “.MERCK” space will be managed by Merck KGaA on behalf of, and for the collective good of, the Merck Community, registrants shall accept and agree (through this Policy) that Merck KGaA will have such authority necessary to maintain the TLD for the benefit of the Community at large.


J. Full-Text Version of the “.MERCK” Registration Restrictions and Use Policy

The registration eligibility criteria and acceptable use guidelines for the “.MERCK” TLD are detailed in the “.MERCK” Domain Name Registration Restrictions and Use Policy, provided here for reference.


K. DRAFT “.MERCK” Domain Name Registration Restrictions and Use Policy

K.1 General principles

K.1.1 Merck Community and Role of Merck KGaA

The “.MERCK” domain is a community based Top Level Domain (ʺTLDʺ) established by and for the use Merck KGaA and the the companies of the Merck Group (the “Merck Community”). Merck KGaA, the Registry Operator of the “.MERCK” TLD, is the parent company of the Merck Group. As such, Merck KGaA is responsible for managing the “.MERCK” domain in the interests of the Merck Community. Merck KGaA will, with the advice and assistance of the Registry Service Provider Afilias Ltd., members of the Merck Community, and relevant governmental bodies, develop, maintain and enforce this “.MERCK” Domain Name Registration and Use Policy (the “Policy”).

This Policy is intended to be updated and revised regularly to reflect the needs of the Merck Community. The current version of this Policy will be made publicly available at: [insert website when determined ].

The registration of domain names within the “.MERCK” TLD is restricted to the companies of the “Merck Community”, which are defined as follows:

- the company is Merck KGaA or a company which is a fully owned subsidiary of Merck KGaA,
- the company uses “Merck” as the sole element or as a component of its company name, and
- the company uses as its umbrella brand the German figurative trademark No. 30130670, “MERCK”


Merck KGaA keeps an up-to-date, comprehensive list of the members of the Merck Community at all times.

K.1.2 Policy structure

The “.MERCK” domain is designed to allocate domain name registrations to members of the Merck Community. Only members of the Merck Community, as defined in Section K.1.1 above, may register domain names within the “.MERCK” TLD.

This policy defines the rules of eligibility and process for “.MERCK” domain name allocation, as well as the Acceptable Use guidelines which registrants in the “.MERCK” space agree to abide by. It also sets out the dispute resolution procedures applicable to the “.MERCK” TLD.

K.1.3 Registration process

Registration of a “.MERCK” domain name is done in 3 steps: Identification of the Registrant, Approval of the Domain Name, and Registration. After Registration, the holder of a “.MERCK” domain name must comply with the Acceptable Use Guidelines (see below).

K.1.3.1 Step 1 – Approval of the Community member

Each Registrant must be recognized as member of the Merck Community. This eligibility check shall be performed by the Corporate Trademark Department at Merck KGaA (as described in Section K.2 of this document, ʺEligibility Requirementsʺ) and is concluded by the assignment of a ʺMerck Community Membership IDʺ. Once a Registrant has obtained a Merck Community Membership ID, the Member is entitled to register domain names within the “.MERCK” TLD which have been approved by the Corporate Trademark Department of Merck KGaA.

The Identification step needs to be performed only once by each Registrant. The Registrant’s Merck Community Membership ID is a permanent assignment, and will remain the same for all of that Registrant’s domain name registrations. Should the Registrant desire to register a second-level domain name, or domain names, within the “.MERCK” space, the Registrant must contact the Corporate Trademark Department of Merck KGaA to receive an Approval Statement, authorizing to Registrant to apply for its desired second-level domain name string(s).

K.1.3.2 Step 2 - Approval of the Second-Level-Domain by the Corporate Trademark Department of Merck KGaA

Before registering a domain name each Registrant must ask the Corporate Trademark Department for approval of the second-level string text, on the basis that the registration of such domain name within the “.MERCK” TLD:

- furthers the mission and purpose of the Merck Community;
- does not violate or contribute to the violation of the intellectual property rights or other rights of any other party; and
- complies with any applicable laws, government rules or requirements

If the Corporate Trademark Department of Merck KGaA determines that the requested second-level domain name registration meets the above requirements, it will consent to such registration by the Registrant Community Member. The Registrant will receive a Decision from the Corporate Trademark Department of Merck KGaA, stating either its consent to the registration of the requested domain name, or rejection of the Registrant’s request for approval. Such notification will either take the form of an Approval Statement or a Rejection Statement, depending on Merck KGaA’s assessment.

K.1.3.3 Step 3 - Registration

Where a second-level string request has been approved by the Corporate Trademark Department of Merck KGaA, the Member may contact an ICANN-accredited registrar to apply for the registration of the specified second-level string and pay the registration fee. The Merck Community Membership ID can be reused for multiple registrations by the same Member, and must be provided in the application materials submitted to the concerned registrar.

Successful domain requests will be placed into a “Pending Create” status. A “Server Hold” will be placed on the new domain name to ensure that it does not resolve. The Registry Operator will then have the opportunity to view the applied-for, pending domain name, verify the string applied for, and will be able to either approve the “Pending Create” (thus releasing the Hold status and enabling the Registrant to use the requested domain), or to reject the domain.

K.2 Eligibility Requirements

To be recognized as a member of the Merck Community, a Registrant must meet the Eligibility Requirements, which are as follows:

- the Registrant is Merck KGaA or a company which is a fully owned subsidiary of Merck KGaA,
- the Registrant uses “Merck” as the sole element or as a component of its company name, and
- the Registrant uses as its umbrella brand the German figurative trademark No. 30130670, “MERCK”

Once its eligibility is established, the Registrant will receive a Merck Community Membership ID (via mail, email or fax) that it will use to identify itself when registering a “.MERCK” domain name. Merck KGaA and the Registry Service Provider will design and implement the necessary mechanisms for this identification and eligibility assessment process. A Registrant may apply directly to the Corporate Trademark Department of Merck KGaA to receive a Merck Community Membership ID.

After a prospective Registrant has applied for a Merck Community Membership ID, the Corporate Trademark Department of Merck KGaA shall review the request and determine whether or not the Registrant meets the eligibility standards for inclusion in the Merck Community. If Merck KGaA determines that the prospective Registrant is, in fact, a member of the Merck Community, the Corporate Trademark Department of Merck KGaA will issue a Merck Community Membership ID. If Merck KGaA determines that the prospective registrant is not a member of the Merck Community, and declines to issue a Merck Community Membership ID, the prospective applicant may pursue a review of this decision through the “.MERCK” Eligibility and Functionality Reconsideration Policy, discussed further below under the section entitled “Dispute Resolution”.

Once its eligibility is established, the Registrant will receive a Merck Community Membership ID (via mail, email or fax) that it will use to identify itself when registering any “.MERCK” domain name.

Following the assignment of a Merck Community Membership ID, the Registrant can view and update information associated with its Merck Community Membership ID online at [website to be determined].

K.2.1 Application for a Merck Community Membership ID

Any prospective Registrant must request a Merck Community Membership ID from Merck KGaA prior to submitting a domain registration request. Such request for a Merck Community Membership ID must:

- provide information regarding the Registrantʹs identity;
- provide relevant evidence demonstrating the Registrant’s qualification as a member of the Merck Community

By submitting the request for a Merck Community Membership ID, the Registrant:

- Warrants that it is a member of the Merck Community and meets the eligibility requirements set out in this Policy;
- Agrees to the terms set out in this Policy;
- Declares that the information provided in the application is complete and correct;
- Acknowledges that the issue of the Merck Community Membership ID is subject to verification and audit by Merck KGaA and agrees that when required by Merck KGaA, it will supply supporting documents to allow Merck KGaA to verify the credentials and other information in the application, including in connection with ongoing monitoring activities

Merck KGaA may request any necessary additional information from the Registrant in order to evaluate the Registrant’s request for a Merck Community Membership ID.

K.3 Domain Allocation Rules

K.3.1 String Requirements and Reserved Names

Second-Level Domain names within the TLD must only include hyphens in the third and fourth position if they represent valid internationalized domain names in their ASCII encoding (for example ʺxn--ndk061nʺ), and must otherwise comply with any other applicable ICANN requirements.


L. Reserved Names

- The label “EXAMPLE” shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations
- Two-character labels. All two-character labels shall be initially reserved. The reservation of a two-character label string may be released to the extent that Registry Operator reaches agreement with the government and country-code manager. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes
- Second-Level Reservations for Registry Operations. The following names are reserved for use in connection with the operation of the registry for the TLD: NIC, WWW, IRIS and WHOIS
- The List of Reserved Names shall be compiled by Merck KGaA and will be publicly posted online at [website to be determined]. Merck KGaA reserves the right to include new names in the list of reserved names, and to later add names to such list as it deems reasonably necessary for the benefit of the Merck Community


M. Country and Territory Names

The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations:

- the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union ;
- the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
- the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names; provided, that the reservation of specific country and territory names may be released to the extent that Registry Operator reaches agreement with the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN


N. Regulated second-level names within the “.MERCK” TLD

N.1. Format “ANYNAME.MERCK”

N.2. Eligibility

The Registrant is allowed to register any second-level name in the above format, which follows the string requirements and common rules described above and for which the Registrant has been granted an Approval Statement from the Corporate Trademark Department at Merck KGaA, as outlined above in Section K.1.3.2, under Step 2 of the Registration Process.

N.3.Allocation

Domain names will be generally allocated on a ʺfirst come, first servedʺ basis, subject to Merck KGaA’s Corporate Trademark Department’s prior approval that the domain name:

- furthers the mission and purpose of the Merck Community;
- does not infringe any other third parties rights; and
- complies with any applicable laws, government rules or requirements

Merck KGaA does not anticipate there to be multiple applications for a particular domain name. If, however, two registration requests for the same second-level string were to be received by Merck KGaA simultaneously, Merck KGaA would evaluate both requests on the basis of the specified criteria and determine which registrant, if either, should be granted the registration.

Merck KGaA has the authority to make changes to any domain name registration in the “.MERCK” space for the benefit of the Merck Community at large under Section P below.


O. Registration Rules

O.1 Registration period and renewals

A “.MERCK” domain name may be registered, and renewed at the end of each registration period, subject to the current terms and conditions offered by the concerned Registrar.

O.2 Continuing eligibility

If the Registrant ceases to be a member of the Merck Community, then the Registrant’s registered “.MERCK” domain names may be immediately revoked and⁄or transferred at the discretion of Merck KGaA. Additionally, Merck KGaA will undertake ongoing monitoring activities to ensure that all registrants of “.MERCK” domain names remain bona fide members of the Merck Community. Additionally, if a registrant fails to comply with the terms and conditions set out in the “.MERCK” Registration Restrictions and Use Policy, Merck KGaA may in its sole discretion elect to transfer, cancel or revoke any relevant domain name registration(s) held by said registrant.

O.3 Transfer of domain name registrations

A “.MERCK” domain name registration may only be transferred in the following circumstances:

- the company to whom the “.MERCK” domain name is to be transferred to meets the criteria set out in this “.MERCK” Registration Restrictions and Use Policy:

- the prescribed fee is paid; and

- Merck KGaA has previously approved the transfer of the domain name registration from the Transferor to the Transferee

Transfers of a “.MERCK” domain name shall be carried out by the Registrar of the relevant “.MERCK” domain name.

O.4 Revoking a domain name registration

The Registrant agrees with Merck KGaA (the Registry Operator of the “.MERCK” TLD) that Merck KGaA may revoke a Merck Community Membership ID and⁄or the registration of a “.MERCK” domain name for the reasons outlined below:

Change in status
If the Registrant ceases to be a member of the Merck Community.

Fee not paid
If the prescribed fee is not paid within the required time.

Breach of warranty
If a warranty supplied by the Registrant or their agent is breached, including failure to comply with the Acceptable Usage Guidelines contained in this Policy.

Incorrect information
If misleading, incomplete or incorrect information is supplied in the application for either a domain name registration or a Merck Community Membership ID.

Failure to comply with this Policy
If the Registrant fails to comply with this Policy.

Court or arbitration decision
If a court or arbitration panel of competent authority determines that a “.MERCK” domain name should not be registered by the Registrant, it shall be removed from the registry or be registered to another entity.

ADR Decision
If an Alternative Dispute Resolution Panel of competent authority determines that a “.MERCK” domain name should not be registered by the Registrant, it shall be removed from the registry or be registered to another entity.

Improper use
If the Registrant has used its “.MERCK” domain name in violation of the Acceptable Use guidelines provided in Section P below.

Instruction
If instructed by the Registrant.

Error
If a “.MERCK” domain name which could not otherwise be registered under this Policy is registered through mistake.


P. Acceptable Usage Guidelines for “.MERCK” Domain Names

P.1 Acceptable Use

All Registrants agree to abide by the Acceptable Usage Guidelines established herein for the operation and use of their “.MERCK” domain names. Registrants agree that their “.MERCK” domain names shall be used:

- to further the mission and purpose of the Merck Community;
- to display only content related to the Merck Community’s activities; and
- to display only content reasonably related to the textual string of the specific domain name, to enable intuitive navigation by visitors to the “.MERCK” space

Registrants further agree that they shall not use any “.MERCK” domain name in a way that:

- infringes any other third parties rights
- is in breach with any applicable laws, government rules or requirements

or for the purposes of:

- undertaking any illegal or fraudulent actions, including spam or phishing activities,
- defaming Merck KGaA or the Merck Community, its businesses, employees, etc.;
- “parking” the website at a landing page;
- displaying pay-per-click links; or
- “warehousing” or otherwise failing to use the domain name to link to active content


All Registrants agree that the “.MERCK” domain space shall be used for the benefit of the Merck Community at large, and shall cooperate to achieve this common goal. Registrants agree that Merck KGaA, as the Registry Operator of the TLD and parent company of the Merck Group, has the right to revoke any domain name registration or re-allocate any domain name registration to a different Community member should Merck KGaA deem such action appropriate for the benefit of the Community.


Q. Dispute Resolution Policies

Q.1 MERCK Eligibility and Functionality Reconsideration Policy (“MEFRP”)

All Registrants agree to be bound by the “.MERCK” Eligibility and Functionality Reconsideration Policy (“MEFRP”). This Policy serves as a mechanism for reconsideration and shall apply to any challenge by a Registrant to a decision by Merck KGaA (the Registry Operator):

- that the Registrant does not or does no longer meet the “.MERCK” eligibility requirements as described in this Policy, and so is not entitled to a Merck Community Membership ID; or
- that the Registrant’s requested second-level domain name string would not be in the best interests of the Merck Community at large, resulting in the issuance of a Rejection Statement or a rejection of the Registrant’s application for a domain name registration.
- if the Registrant is a holder of a “.MERCK” domain name, to revoke the domain name registration

Full text of the MEFRP is located here: [insert link once available].

Q.2 Charter Eligibility Dispute Resolution Policy (ʺCEDRPʺ)

All Registrants agree to be bound by the Charter Eligibility Dispute Resolution Policy (ʺCEDRPʺ), which applies to challenges on the grounds that a particular Registrant does not meet the eligibility requirements to register its domain name within the “.MERCK” space. The full text of the CEDRP is located here: [http:⁄⁄www.icann.org⁄en⁄help⁄dndr⁄cedrp].

Q.3. Uniform Domain Name Dispute Resolution Policy (ʺUDRPʺ)

All Registrants agree to be bound by the Uniform Domain Name Dispute Resolution Policy (ʺUDRP”), which applies to challenges to registered domain names on the grounds that: 1) such domain names are identical or confusingly similar to a trademark in which the complainant has rights, 2) the registrant lacks rights or legitimate interests in the domain name, and 3) the domain name has been registered and used in bad faith. The full text of the UDRP is located at the following address: http:⁄⁄www.icann.org⁄dndr⁄udrp⁄policy.htm.

Q.4 Uniform Rapid Suspension System (“URS”)

All Registrants agree to be bound by the Uniform Rapid Suspension System (“URS”), which applies to challenges to registered domain names on the grounds that: 1) such domain names are identical or confusingly similar to a trademark in which the complainant has rights, 2) the registrant lacks rights or legitimate interests in the domain name, and 3) the domain name has been registered and used in bad faith. The full text of the URS is located at the following address: [insert website when available].

Q.5 Registry Restrictions Dispute Resolution Procedure (“RRDRP”)

The Registry Operator for “.MERCK” shall agree to be bound by the Registry Restrictions Dispute Resolution Procedure (“RRDRP”). The RRDRP applies to challenges by Merck Community members claiming to be “a harmed established institution” as a result of the community-based gTLD registry operator not complying with the registration restrictions set out in the Registry Agreement. Full text of the RRDRP is located at the following address: insert website when available].

Q.6 Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP)

The Registry Operator for “.MERCK” shall agree to be bound by the Trademark Post-Delegation Dispute Resolution Procedure (“Trademark PDDRP”). The Trademark PDDRP applies to challenges by trademark holders claiming that one or more of its marks have been infringed, and thereby the trademark holder has been harmed, by the registry operator’s manner of operation or use of the gTLD. Full text of the Trademark PDDRP is located at the following address: [insert website when available].


R. Verification of eligibility and domain name registrations

R.1 Verification Process

Merck KGaA shall operate a verification system to prevent the misuse of Merck Community Membership IDs and to ensure that this Policy, including the Acceptable Usage Guidelines of Section P, is complied with. The verification may be conducted by Merck KGaA directly or by a third party appointed by Merck KGaA for this purpose.

If a Registrant is selected for verification, then it may be asked to provide supporting information demonstrating that it meets the eligibility requirements defined in this Policy, that its “.MERCK” domain name registration complies with this Policy, or that the content displayed on the website at its “.MERCK” domain name complies with the Acceptable Usage Guidelines contained in this Policy.

If the Registrant fails to cooperate with a request or fails to cooperate within a reasonable time period, then Merck KGaA may cancel the Merck Community Membership ID and⁄or revoke the registration agreement for the “.MERCK” domain names registered by that Registrant.


S. Warranties

The administration of the “.MERCK” domain relies upon the information and warranties supplied by the Registrant. Accordingly, by applying for a “.MERCK” domain name, the Registrant:

- warrants that the Registrant meets the eligibility requirements set out in this Policy;
- warrants that the Corporate Trademark Department of Merck KGaA has approved the registration of the applied-for domain name;
- warrants that the domain name complies with this Policy;
- warrants that the information provided by the Registrant is complete, true and accurate;
- warrants that the registration and use of the “.MERCK” domain name does not breach any third partyʹs rights (such as those of a registered trademark holder);
- warrants that the operation and use of the “.MERCK” domain name will be undertaken in line with the Acceptable Usage Guidelines contained in this Policy;
- warrants that they have read and understood this Policy, and that they understand that this Policy is legally binding; and
- indemnifies Merck KGaA to the full extent legally permitted against all claims and demands from third parties regarding the registration and use of the “.MERCK” domain name

Similar gTLD applications: (0)