Skip to main content

ICANN Coordinated Disclosure Guidelines

The Security Team has prepared a set of guidelines to explain ICANN's Coordinated Vulnerability Disclosure Reporting. The guidelines serve two purposes. They define the role ICANN will perform in circumstances where vulnerabilities are reported and ICANN determines that the security, stability or resiliency of the DNS is exploited or threatened. The guidelines also explain how a party, described as a reporter, should disclose information on a vulnerability discovered in a system or network operated by ICANN.

Together, these guidelines affirm ICANN's commitment to facilitating the security, stability and resiliency of the Internet's unique identifiers through coordination and collaboration, and to operating and maintaining ICANN systems and networks responsibly.

Coordinated Vulnerability Disclosure Reporting

As explained in the Guidelines [PDF, 470 KB], Coordinated Vulnerability Disclosure refers to "a reporting methodology where a party ('reporter') privately discloses information relating to a discovered vulnerability to a product vendor or service provider ('affected party') and allows the affected party time to investigate the claim, and identify and test a remedy or recourse before coordinating the release of a public disclosure of the vulnerability with the reporter."

The Security Team chose a coordinated disclosure reporting policy after consulting disclosure policies of computer emergency response teams (CERTs), Fortune 100 corporations, cloud service providers and network operators. This decision was strongly influenced by the scale and complexity that is often associated with mitigating threats to or involving the DNS. ICANN is committed to limiting risk and preventing harm to third parties. The guidelines are consistent with actions ICANN and other involved parties took to contain the Conficker botnet [PDF, 386 KB] in 2009-2010.

ICANN's Coordinator Role

As illustrated in the diagram, any party that has discovered a vulnerability that threatens the security, stability, or resiliency of the DNS is encouraged to give notice to ICANN, who will coordinate or facilitate reporting the threat directly and exclusively to the product vendors or services providers who the party or ICANN determines are affected by the threat.

The Guidelines describe how to notify and submit reports, how confirmation and progress will be reported once a vulnerability is submitted, and how notice will be released when a resolution is identified and can be made available.

ICANN will apply the coordinated vulnerability disclosure reporting when notifying product vendors or service operators of vulnerabilities (in such cases, ICANN serves as a "reporter"), and we encourage parties that discover vulnerabilities in systems or networks ICANN operates to report to us in this manner as well.

ICANN Security Team Points of Contact Information

Contact the ICANN Security Team to report events and incidents where the DNS or registration services are exploited and/or misdirected on a large scale, attacks where the name service or domain registration services are used to facilitate those attacks, or where the DNS infrastructure or registrations services are the targets of malicious activity.

Report discoveries of vulnerabilities or threats of a global scale to the DNS or domain registration services to (Note: please first consider reporting threats to individual registry operators, registrars, or other operators of elements of the DNS in circumstances where you are able to determine that the vulnerability directly affects one of these parties.)

Report discoveries of vulnerabilities to ICANN systems or networks to the ICANN Computer Incident Response Team (ICANN CIRT) at Additional contact information can be found at

Reports sent to will be forwarded to the ICANN Security Team. Additional contact information can be found 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."