Skip to main content

DSSA Working Group Phase 1 Report

Comment/Reply Periods (*) Important Information Links
Comment Open: 14 August 2012
Comment Close: 13 September 2012
Close Time (UTC): 23:59 UTC Public Comment Announcement
Reply Open: 14 September 2012 To Submit Your Comments (Forum Closed)
Reply Close: 21 October 2012 View Comments Submitted
Close Time (UTC): 23:59 UTC Report of Public Comments
Brief Overview
Originating Organization: DNS Security & Stability Analysis Working Group
  • DNS
  • Security/Stability
Purpose (Brief): The DNS Security & Stability Analysis (DSSA) Working Group is seeking community comment on its Phase 1 Report. The Report was originally published on 15 June 2012 prior to the ICANN meeting in Prague, Czech Republic. The goal of the report is to bring forward for the community the work that the DSSA has completed to date and describe the work that remains.
Current Status: Open for public comment
Next Steps: The DSSA Working Group intends to perform a proof of concept to refine and streamline the methodology on one broad risk-scenario topic with the goal of reducing cycle time and making it more accessible to the broader community. Public comment on the Phase 1 Report will be used to focus attention of the DSSA Working Group on specific work areas and refinement of the methodology.
Staff Contact: Patrick Jones Email:
Detailed Information
Section I: Description, Explanation, and Purpose

This is the first of two reports from the DNS Security & Stability Analysis Working Group. The goal of this document is to bring forward the substantial work that has been completed to date and describe the work that remains. This has been in many respects a “pioneering” cross-constituency security-assessment effort that has developed knowledge and processes that others will hopefully find helpful and can be reused in the future.

The DSSA has:

  • Established a cross-constituency working group and put the organizational framework to manage that group in place
  • Clarified the system, organizational and functional scope of the effort
  • Developed an approach to handling confidential information, should such information be required for certain assessments
  • Selected and tailored a risk-assessment methodology to structure the work
  • Developed and tested mechanisms to rapidly collect and consolidate risk-assessment scenarios across and broad and diverse group of interested participants
  • Used an “alpha-test” of those systems to develop the high-level risk-scenarios in this report. Those scenarios will serve as the starting point for the remainder of the effort.

Work that remains:

  • Perform a proof of concept to refine and streamline the methodology on one broad risk-scenario topic with the goal of reducing cycle time and making it more accessible to a broader community
  • Roll the methodology out to progressively broader groups of participants to introduce the methodology to the community and further improve the process and tools on the way to completing the assessment.

Public comment is sought on the Phase 1 Report.

Section II: Background

The objective of the DSSA Working Group is to draw upon the collective expertise of the participating SOs and ACs, solicit expert input and advice and report to the respective participating SOs and ACs on: The actual level, frequency and severity of threats to the DNS.

The DSSA Working Group was originally published on 15 June 2012 prior to the ICANN Prague meeting. The report was discussed at the DSSA Working Group open session in Prague, and details on that meeting can be found at

Section III: Document and Resource Links
DSSA Working Group Phase 1 Report [PDF, 4.57 MB]
Section IV: Additional Information

(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

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