Skip to main content

Security and Stability Advisory Committee (SSAC)

Completed Projects

Fast Flux Hosting and DNS

This Advisory describes the technical aspects of fast flux hosting and fast flux service networks. It explains how the DNS is exploited to abet criminal activities that employ fast flux hosting, identifying the impacts of fast flux hosting, and calling particular attention to the way such attacks extend the malicious or profitable lifetime of the illegal activities conducted using these fast flux techniques. It describes current and possible methods of mitigating fast flux hosting at various points in the Internet. The Advisory discusses the pros and cons of these mitigation methods, identifies those methods that SSAC considers practical and sensible, and recommends that appropriate bodies consider policies that would make the practical mitigation methods universally available to registrants, ISPs, registrars and registries (where applicable for each).

Domain Name Front Running

This Advisory considers the opportunity for a party with some form of insider information to track an Internet user’s preference for registering a domain name and preemptively register that name. SSAC likens this activity to front running in stock and commodities markets and calls this behavior domain name front running. In the domain name industry, insider information would be information gathered from the monitoring of one or more attempts by an Internet user to check the availability of a domain name.

Related Deliverables:

  • Report on Domain Name Front Running [PDF]
    In this report, SSAC presents the findings of our studies of the domain name front running claims received from Internet users. We attempt to classify claims based on information provided by claimants. We review preliminary conclusions made in SAC 022 and either replace or supplement these based on the results of our studies.

Survey of IPv6 Support Among Commercial Firewalls

This report surveys the commercial firewall market for IPv6 security service availability.The report attempts to answer the following questions:

  1. How broadly is IP version 6 (IPv6) transport supported by commercial firewalls?
  2. Is support for IPv6 transport and security services available from commercial firewalls available for all market segments - home and small office (SOHO), small-to-medium business (SMB), large enterprise and service provider networks (LE/SP) or is availability lagging in certain segments?
  3. Among the security services most commonly used at Internet firewalls to enforcean organization's security policy, which are available when IPv6 transport is used?
  4. Can an organization that uses IPv6 transport enforce a security policy at a firewall that is commensurate to a policy supported when IPv4 transport is used?

Is the WHOIS Service a Source for email Addresses for Spammers?

In summer of 2006, SSAC undertook a project to study the correlation of personally identifying information, specifically email addresses, placed in the Whois and the incidence of spam, conducted across major sTLDs and gTLDs. This report provides the results of the study of the correlation of personally identifying information, specifically email addresses, placed in the Whois and the incidence of spam, conducted across major gTLDs.

Impact of Including IPv6 (AAAA) Resource Records in the root hints file and DNS priming exchange

SSAC and RSSAC jointly studied the impact of including IPv6 addresses of root name servers in both the root hints file and response messages returned by root name servers to DNS priming requests. The study will consider how these changes affect static configuration on hosts that operate as name servers and verification methods name servers and name server administrators currently use to verify the root name server addressing information they have is accurate. The study considered how proposed alternatives to include AAAA addresses affect DNS priming response message composition and length. The report concluded with a recommended roadmap the community should follow to minimize the interruption of name service when AAAA records for root name servers are made available in the hints file and returned in DNS priming responses.  

Related Deliverables:

  • Testing Firewalls for IPv6 and EDNS0 Support (5 January 2007) [HTML]
  • Testing Recursive Name Servers for IPv6 and EDNS0 Support (15 March 2007) [HTML]
  • SAC018, Accommodating IP Version 6 Address Resource Records for the Root of the Domain Name System (23 March 2007) [PDF]

On 4 February 2008, IANA introduced AAAA records for six of the root name servers in the root server system, and thereby brought this project to completion.

Information Gathering using Domain Name Registration Records

The GNSO requested public comment on the purpose of WHOIS "data". SSAC obtained a very large sample of domain name registration records and studied two matters of interest: (1) the extent to which registration records are mined to acquire email addresses for the purpose of sending spam, and (2) the extent to which registration records contain contact information that might be classified or considered "personal information". The results of this study were presented at a public ICANN meeting in November 2006.

DNS Denial of Service Attacks

In early February 2006, name servers hosting Top Level Domain zones were the repeated recipients of extraordinary heavy traffic loads. Analysis of traffic by TLD name server operators and security experts at large confirmed that DNS packets comprising the attack traffic exhibited characteristics associated with previously attempted DDoS attacks collectively known as amplification attacks.

This advisory describes representative incidents, identifies the impacts, and recommends countermeasures that TLD name server operators can employ for immediate and long-term relief from the harmful effects of these attacks. Certain countermeasures may adversely affect legitimately operated domain name resolvers whose configurations contribute to the success of DDoS attacks; specifically, by operating in the manner they do, some resolvers facilitate DNS amplification attacks. Countermeasure that name server operator might implement to assist in their timely restoration of normal service could also adversely affect name server operators who rely on the service they provide. TLD operators may need to take specific measures to assure they do not worsen the effects of the attacks.

Alternative TLD Name Systems and Root Name Services

In this report, SSAC considers conditions and factors that could accelerate fragmentation, destabilize root name service and alter the existing name system management framework to a much greater degree than pure for-profit initiatives. We present a rudimentary classification of alternative root name server systems and alternative TLD name system administrators. For each class, we attempt to identify the stated or implied incentives for operating an alternative root name service and managing alternative TLDs. We describe the operational models and the technical mechanisms each class of operators employs to provide name resolution and registration services. We then consider the impact on Internet users and service providers (ISPs), domain name registrants, and registries that operate under agreements with ICANN.

This report intentionally examines alternative root server systems and alternative TLD name system administrators generically, i.e., according to the characteristics SSAC associates with a class of operator rather than by the characteristics of individual operators. By elevating our examination to this level, we can focus on the common characteristics of each class of operator, and perhaps more accurately assess whether TLD name system administration and root name service operation of a given class create security and stability issues.

Domain Name Hijacking Report

The Domain Name Hijacking Report was commissioned in response to both highly publicized hijacking events and a number of lesser publicized events. The SSAC found that domain name hijacking incidents are commonly the result of flaws in registration and related processes, failure to comply with the transfer policy and poor administration of domain names. The report recommends ten key actions including implementation of improved auditing and compliance measures, and additional measures to protect registration information from misuse by would-be hijackers, as well as implementation of emergency procedures to assist in the urgent restoration of a domain name.

SSAC Wildcard Report - A Report from the ICANN Security and Stability Advisory Committee (SSAC): Redirection in the COM and NET Domains

On September 15, 2003, VeriSign changed the way the COM and NET registries responded when presented with uninstantiated names. Instead of returning the standard error code, it responded with the address of one of its servers. This change has raised concerns about the stability of the domain name system. On October 4, 2003, VeriSign temporarily sus ended this change, but the matter remains unresolved.

The Security and Stability Advisory Committee is gathering facts. On September 22, SSAC  issued a preliminary advisory as a first step in its examination of this situation. The Committee then called for inputs and held an open meeting on Tuesday, October 7, 2003 in Washington, D.C. The Committee scheduled a second meeting on Wednesday, October 15, 2003 in Washington, D.C. Click here to see announcements and details of that meeting. Shortly after the meeting, the Committee will report to ICANN, the technical community and the general Internet community. While this committee examined the security and stability aspects of the wild card deployment, ICANN also examined a broader range of issues. See ICANN's wild card web page for more information.

DNS Infrastructure Recommendation

A key element of the DNS infrastructure is the delegation of zones. Beginning with the root of the DNS ("."), each zone administrator has the authority to delegate sub-zones to other responsible parties. Each sub-zone becomes another delegation point in the DNS infrastructure tree. The correct operation of the delegation hierarchy is essential to the stability of the DNS. There are two fundamental requirements for the correct operation of the delegation. First, the parent of a sub-zone must point to the sub-zone server(s). Second, the sub-zone server(s) have to be in operation and be reliable.

In this document SSAC we recommend that each zone operate at least two independent servers to provide a high degree of reliability and availability. This recommendation applies most strongly to the root and top-level domains, but we also recommend that zones with a high volume of DNS queries and/or zones that aspire to be highly available also operate two or more independent servers.

Securing the Edge

At every edge of the global Internet are the hosts who generate and consume the packet flows which, together, form the overall Internet traffic load. By number, most of these hosts are not secure, leading to dangerous, untraceable traffic flows which can be used to attack other hosts. This memo describes some of the security problems "at the edge" and makes some recommendations for improvement.

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