Skip to main content

Contractual Compliance: Addressing Domain Name System (DNS) Infrastructure Abuse

Domain abuse 1563x886 08nov18 en

A previous blog, Six weeks in Contractual Compliance and Consumer Safeguards, briefed the ICANN community on three Contractual Compliance department initiatives. Today’s blog is an update on two of those initiatives: increasing transparency around compliance activities and Domain Name System (DNS) infrastructure abuse.

Many of you may have seen some of the recent improvements in transparency. The Contractual Compliance Monthly Dashboard now includes more information regarding registrar-related DNS abuse report handling complaints, including reports regarding spam, pharming, phishing, malware, and botnets. It also includes information on counterfeiting, online pharmaceutical concerns, fraudulent and deceptive practices, trademark or copyright infringement, and complaints regarding registrar abuse contacts.

The second initiative, addressing DNS infrastructure abuse, takes place at a time when large sections of the community have raised concerns about the prevalence of this abuse, and questioned the willingness and ability of the ICANN organization and contracted parties to address it. For example, the Competition, Consumer Choice and Consumer Trust Review Team’s final report includes a lengthy chapter on DNS infrastructure abuse and includes several related recommendations. The Governmental Advisory Committee (GAC) has also raised concerns about DNS infrastructure abuse in the Copenhagen Communiqué, and elsewhere.

In Contractual Compliance, we are conducting audits that are specifically focused on the topic of DNS infrastructure abuse. We have broadened the scope of questions and testing in our registrar and registry audits, focusing on process, procedures, and handling of DNS infrastructure abuse. The revised audit testing focuses on reviewing security threat reports for completeness and comparing them against publicly available reports.

ICANN previously included the expanded audit questions in the March 2018 Registry Audit conducted on 20 generic top-level domains (gTLDs). Through this audit, we identified actions that registries and registrars are taking to address DNS infrastructure abuse. They include conducting security threat analyses frequently and retaining reports for future reference. These reports identified abusive domains that were also identified in publicly available abuse reports (e.g., MalwarePatrol, PhishTank, Spamhaus and SURBL), and included evidence of actions taken against abusive domains. The audit also showed that there were incomplete analyses and security reports for 13 top-level domains (TLDs), as well as a lack of standardized or documented abuse handling procedures and no action being taken on identified threats. These 13 new gTLDs will be retested in the next round.

This week, ICANN launched an audit focused on DNS infrastructure abuse for nearly 1200 gTLDs, and held two audit webinars with the registries to address questions and concerns. Some of these concerns were also raised in a recent email from the Registries Stakeholder Group (RySG) and addressed by Contractual Compliance. For the first time, and to help prepare for the upcoming audit, we sent the auditees the complete list of gTLDs that are included in the audit, and a pro-forma list of questions and data requests that will be included in the November 2018 Registry Audit round. In another first, ICANN is making this information publicly available on in an effort to increase transparency.

ICANN’s mission is to maintain the security and stability of the DNS. Consistent with our mission, ICANN Contractual Compliance is now addressing DNS infrastructure abuse by conducting registry and registrar audits. The purpose of these audits is to ensure that the contracted parties uphold their contractual obligations with respect to DNS infrastructure abuse and security threats. Upon completion of the audits, ICANN Contractual Compliance will publish our findings and observations, including examples of strategies and processes to mitigate DNS infrastructure abuse.

If you have any audit-related questions, please contact ICANN Contractual Compliance at


    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."