Skip to main content

Advisory, New gTLD Registry Agreement Specification 11 (3)(b)

Please note that the English language version of all translated content and documents are the official versions and that translations in other languages are for informational purposes only.

Publication date: 8 June 2017


ICANN is publishing this Advisory in response to questions from some registry operators concerning what practices they can implement to establish compliance with Section 3(b) of Specification 11 of the New gTLD Registry Agreement ("Spec 11 (3)(b)"), which states:

Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.

This Advisory offers one voluntary approach registry operators may adopt to perform such technical analyses to assess security threats and produce statistical reports as required by Spec 11 (3)(b). It should be noted registry operators who use the practices as set forth in this Advisory are not automatically deemed to be compliant. In all cases, registry operators remain subject to the same level of case-by-case, fact-based inquiry processes and audit to evidence compliance. Registry operators may remain fully compliant with Spec 11 (3)(b) by implementing their own procedures to satisfy the obligations.

Security Threat Definition

For the purposes of this Advisory, the security threats ("Security Threats") as referenced in Spec 11 (3)(b) include, among others:

  • pharming1,
  • phishing,
  • malware,
  • botnets, and
  • other types of security threats.

What constitutes a 'technical analysis' to be compliant with this advisory:

A 'technical analysis' may constitute steps taken to identify Security Threats in a TLD(s) by:

  • reviewing data feeds; and/or
  • conducting automated analyses that provide data at least equivalent to that provided by Domain Reputation Service Providers.

Technical Analysis Performance

A Registry Operator conducts the technical analysis itself or it can elect to outsource one or more of the steps described above to a Domain Reputation Service Provider(s).

For the purpose of this Advisory, Domain Reputation Service Providers are entities that own or manage databases that include information about domain names and their associations with Security Threats and provide services known as "reputation services."

  • Use of Reputation Services.

    Reputation services rely upon data analytics to correlate domain name registration information with other data known to be associated with domain name abuse. These services typically compile continuously updated blocklists, malware signatures, and reported abuse data from vetted sources to ensure accuracy and efficacy. In most cases, the aggregated data is analyzed, labeled by threat category, and assigned a weighted reputational score, factoring in the temporal nature of domain names to prevent faulty reliance on obsolete information. These services can enable Registry Operators to query data to determine the likelihood of association of domain name registrations with domain names known to be used to perpetrate Security Threats.

Upon discovering a domain name associated with Security Threats, Registry Operators might choose to take actions described in the Framework for Registry Operator to Respond to Security Threats, which is currently undergoing community review. The Advisory will be updated with a link to the finalized Security Framework when available. [20 October 2017 UPDATE: Please find the finalized Framework for Registry Operator to Security Threats here:]

  • Selection of Reputation Services

    When Registry Operators are selecting Domain Reputation Service Providers (or performing the services themselves), they should consider the following criteria:

    • Does the reputation service cover the specific Security Threats for which the Registry Operator is seeking reputation data?
    • Does the reputation service send notification to the Registry Operator upon entry of a domain name into the Domain Reputation Service Provider's database(s)?
    • Is there a mechanism for automating queries, such as an API?
    • Is there a publicly available description of methodology and criteria used by the Domain Reputation Service Provider in preparing the domain reputation data, including: how names are added to their database(s), how long those names may remain in the database(s), and how the names are removed from the database(s).

    Given the focus of this advisory on industry self-regulation, ICANN will not recommend specific Domain Reputation Service Providers.

Frequency of the Technical Analysis and Statistical Reporting on Identified Security Threats

Performance of technical analyses pursuant to Spec 11 (3)(b) gives the Registry Operator the ability to determine which domain names in their TLD(s) are associated with Security Threats. Once identified, this information can be used to prepare the statistical reports described herein.

In order to demonstrate they are adhering to the guidelines in this advisory, Registry Operators should be able to conduct their analyses as frequently as needed, but no less frequently than on a monthly basis. A daily frequency of analysis is recommended to allow prompt detection of the newly created domain names that are used to perpetrate Security Threats.

Statistical Reports on Identified Security Threats and Actions Taken

Statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks will be maintained for the term of the Agreement unless a shorter period is required by law or approved by ICANN.

Statistical reports most commonly include the following:

  • Number of domain names reviewed during analysis;
  • List of domain names with potential threats;
  • Type of threat identified, such as malware and botnets;
  • Type of actions taken in response to threats, such as suspension;
  • Status (open/pending/closed) of threat and statistics on actions taken;
  • Additional details on threats such as IP address, geographic location, and registrant information; and
  • Trends and alerts.

1 As pharming is a threat that affects domain name resolution services, not registration services, it may not be subject to Domain Reputation Service Provider services and the guidance provided in this Advisory.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."