Completed Projects
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).
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:
- How broadly is IP version 6 (IPv6) transport supported by commercial firewalls?
- 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?
- Among the security services most commonly used at Internet firewalls to enforcean organization's security policy, which are available when IPv6 transport is used?
- 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.
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.
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.
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.
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.
