Skip to main content

An Update on ICANN Security Efforts

As the community prepares to head into the 39th international ICANN public meeting in Cartagena de Indias, Colombia, ICANN’s Security team provides this update on current activities. A little over a year ago, ICANN signed the Affirmation of Commitments to ensure the global technical coordination of the Internet’s system of unique identifiers. Preserving the security, stability and resiliency of the domain name system (DNS) is central to these commitments.

Threats to the DNS have been around for many years, and ICANN has served as a forum for bringing the Internet community together. An entire international public meeting was dedicated to “Security and Stability of the Internet Naming and Address Allocation Systems” in November 2001. The Security and Stability Advisory Committee was formed in 2002. Each ICANN public meeting since 2006 has included a tech day for the ccTLD community, and recent meetings have included dedicated sessions on DNSSEC and abuse of the DNS. We’ve supported annual contingency exercises since 2008, and we are planning a DNS Operations and L-root exercise for early 2011.

The Security team recently completed a 53-day comment period on the FY 11 Update to the SSR Plan (including several outreach and briefing sessions). The At Large, global business, TLD operations and academic research communities all contributed. A summary and analysis of comments is available at, and we will soon post a version of the Plan showing how comments were incorporated, along with an updated clean version.

As part of our effort to strengthen and improve the security, stability and continuity of ICANN internal operations, consistent with the 2010-13 Strategic Plan, the Security and Information Technology teams formalized internal incident response practices in September 2010. The ICANN Computer Incident Response Team is intended to be the primary responder in handling internal ICANN organizational information security incidents, and detail on this team is posted on our website at

In establishing an internal CIRT, ICANN is following best practices set by other operators of Internet infrastructure. Many entities have them in place, including the US National Institute for Standards and Technology (NIST), Microsoft, Neustar, VeriSign, Symantec, Juniper, Packet Clearing House, Skype, Yahoo, Google, Apple Computer, AT&T, the National Institutes of Health, universities and others.

The FY 11 Operating Plan noted that we would put an emphasis on hardening ICANN’s infrastructure and internal security efforts. This included:

  • Ensuring annual updating of ICANN security plans and monitoring effective implementation of security controls and procedures;
  • Ensuring ICANN security staff has strong skills and appropriate tools and is current with security threats and best practices.

Our FY 11 SSR Plan stated: “Specific initiatives underway in 2010 to improve ICANN’s security posture include improvements to logical and physical access controls, change management, logging/auditing and data backup procedures, security awareness training for staff, building incident response capabilities and improvements to mobile device security.” The formation of an internal incident response team demonstrates these plans are being put into action.

We understand there has been some confusion about whether the internal CIRT is related to the DNS-CERT initiative. The CIRT is not the foundation for a DNS-CERT. ICANN stated very clearly in Brussels, and in the summary and analysis of comments on the Security Strategic Initiatives and DNS-CERT Business Case in May 2010, that ICANN was not taking steps to operate a DNS-CERT.

ICANN supports the Joint DNS Security and Stability Analysis (DSSA) Working Group and other community efforts to develop a proposal on where a DNS-CERT, or collaborative response capability, might be housed and financially supported. The first proposal for an entity to support DNS related operations when DNS incidents occur was by DNS-OARC in 2002 (see Unfortunately, the needs identified at that time and recognized again in the DNS-CERT Business Case have not yet been addressed. ICANN staff very much hope to receive support and guidance from the community on this matter.

ICANN wants to collaborate with the community to identify threats and risks to the DNS, and to facilitate efforts to bring the Security community, the DNS operations community and users of the DNS together to improve overall DNS security, stability and resiliency. The DSSA Working Group is finalizing a charter, led by representatives from the At Large Advisory Committee, Country Code Names Supporting Organization, Generic Names Supporting Organization and Number Resource Organization. Independent experts from the security and infrastructure operations community are likely to be included in this effort.

ICANN continues to regularize root key signing operations for DNSSEC in partnership with VeriSign and with the support of the Internet community. ICANN conducted the third DNSSEC Key Signing Ceremony on 1 November 2010 in Culpeper, Virginia. A growing number of registry operators are implementing DNSSEC in TLD zones, including recent adoption in Finland, India, and in the Caribbean ccTLDs for Antigua and Barbuda, Belize, Honduras, St. Lucia, and St. Vincent and the Grenadines. VeriSign has announced its progress on implementing DNSSEC in .NET and .COM, and ICANN anticipates this will accelerate the adoption of this security enhancement by other registries and registrars, for the benefit of Internet users. Large ISPs such as Comcast are announcing DNSSEC implementation initiatives, and this is a very positive step.

Under the Affirmation of Commitments, we are supporting the efforts of the Security, Stability and Resiliency Review Team (, which will conduct its first face-to-face meeting in Cartagena. This is a strong group of volunteers from across the global Internet community and we stand ready to facilitate their work.

We’re continuing to support DNS capacity building initiatives in partnership with the Network Startup Resource Center and the Internet Society. Successful training sessions have been conducted since the Brussels meeting in Mali for AfTLD and Guatamala for LACTLD. A training session was held on 2-6 November 2010 in Amman, Jordan, for APTLD.

This is a just sampling of our current activities. Security team staff will be in Cartagena and available to discuss the initiatives underway for FY 11. We welcome your suggestions and input. For more information, see

Patrick Jones
Senior Manager of Continuity & Risk Management


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