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


    Donna Austin  11:58 UTC on 15 November 2018

    Due to the character limit on the comment box, this comment from the Registries Stakeholder Group will be posted in two parts. Part I The RySG acknowledges the forthcoming audit focusing on DNS infrastructure abuse, and believes it is important for ICANN Compliance to ensure contracted parties are upholding their contractual obligations with respect to DNS infrastructure abuse and security threats. To that end, our members will be responsive to the audit request for information (RFI) questions that are tailored to assess compliance with a specific requirement in the Registry Agreement. The RySG recognizes, understands, and takes seriously the concerns expressed by members of the ICANN community regarding DNS infrastructure abuse. We are willing to engage and work constructively with the community and ICANN org to address and respond to those concerns. As registry operators, we have a vested interest in ensuring that we offer a reputable product consumers can trust. Registries also value prompt action to mitigate DNS abuse and often go above and beyond the requirements of the Registry Agreement. We invest a good deal of time, funds, and other resources combating DNS abuse for the benefit of all, and would be more than happy to detail processes and procedures for ICANN and the community through the appropriate channels.

    Donna Austin  12:03 UTC on 15 November 2018

    Part II--However, the RySG is concerned that several questions contained in the RFI are outside the scope of the current Registry Agreement and therefore beyond the existing mission of ICANN Compliance which is “… to ensure that ICANN's contracted parties fulfill the requirements set forth in their agreements with ICANN.” We agree that it is appropriate to use the audit process to address concerns of non-compliance; however, it is our view that this “broadened” RFI goes beyond that. An audit - which is narrow and specifically defined in our respective Registry Agreements - is not a means for ICANN org to address concerns outside of the remit of contractual requirements, such as the recommendations contained in the yet to be adopted Competition, Consumer Choice and Consumer Trust Review Final Report and GAC advice. Use of the audit as an attempt to impose obligations codifying community concerns, or to evaluate general industry practices outside of our contracts, does not reflect the proper objective of assessing contractual compliance. The RySG is willing to share with ICANN org and the community relevant information regarding our ongoing efforts to combat DNS abuse apart from the requirements set forth in our contracts. However, members of the RySG are reluctant to do so as part of an ICANN Compliance effort that goes beyond what is allowed under the Registry Agreement. Donna Austin, Chair, Registries Stakeholder Group

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