Introductory Text
By the Staff of ICANN
This document was produced by the Staff of ICANN for information of At-Large Summit participants to provide basic information on some of the main subjects being considered during the Summit meetiings.
[End of Introduction]
At-Large Summit Briefing Note
DNSSec and Fast Flux Hosting Attacks – a Primer
What is the ICANN Commitment to Internet Stability and Security?
ICANN exists to ensure the stable, secure operation of the Internet’s system of unique identifiers. According to its bylaws, the organization must preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet.
Recently, many members of the ICANN community have begun to ask how the organization can work within its remit to thwart “bad actors” who use the DNS in criminal or fraudulent ways. This is a challenge because many such activities may either exceed the boundaries of the DNS and the autonomous number system, or may take place in areas where law enforcement agencies assert exclusive jurisdiction over such unlawful activities.
Two issues that fall into this challenging gray area are community concerns about fast flux hosting techniques and a growing interest in the implementation of DNSSEC (a technical change to certain DNS operations designed to make the DNS more secure).
What is Fast Flux Hosting?
The term “fast flux” refers to a series of techniques that cause rapid and repeated changes to Internet Host and/or name server resource records in a DNS zone. These changes have the effect of rapidly changing the location (IP address) to which the domain name of an Internet host (A) or name server (NS) resolves. Variations of this technique include rapid updates to A records in the zone file of a subdomain, causing IP addresses to change; rapid updates to NS records causing IP addresses to change; and the combination of these techniques to cause location changes to both hosts and name servers.
Fast flux techniques need not be deployed in every case for malicious or destructive purposes, but they are often used in that context. Behavior and intent of the technology user must be considered separately from the capability of the technology in question. Constructive purposes for fast fluxing include content distribution, improved network availability and increased network resilience.
A key characteristic of a fast flux attack network includes the distribution and use of software on hosts without system owner or operator knowledge or consent. A fast flux attack network is not a cyber attack in and of itself, but rather a series of techniques that enable cybercriminals to avoid detection. When used by cybercriminals, the main purpose of fast flux hosting is to prolong the period of time in which an attack continues to be successful and thereby extend the useful lifetime of compromised hosts used in illegal activities.
Where Does ICANN Stand on Fast Flux Hosting Today?
In January 2008, ICANN”s Security and Stability Advisory Committee (SSAC) published an Advisory paper on Fast Flux Hosting and the DNS. The GNSO Council instructed ICANN staff in March 2008 to prepare an issues report to consider the SSAC advisory and outline potential policy development steps seeking to mitigate the harmful impacts of fast flux hosting on the DNS. In May 2008, the GNSO Council established a formal policy development process on fast flux hosting and charged a working group to examine a series of questions about the issue. The working group presented its initial report in January 2009 which proposed several ideas for follow-up work for the GNSO. A final report will follow after a period of public comment.
What is DNSSEC?
DNSSEC is a series of security extensions designed to protect the DNS and the Internet community from attacks by cybercriminals and other bad actors who use various means to intercept lookup requests, transmit false information and otherwise misdirect Internet users. This behavior can be used as part of a fraud to harvest credit card numbers, passwords or personally identifiable information. DNSSEC uses public-private key encryption to digitally “sign” DNS messages, thereby providing a means to assure that DNS data has not been altered during its transmission over the Internet. By building backwardly compatible key pairs into the DNS hierarchy, DNSSEC is able to build a scalable network of trusted servers, a network which could ultimately originate at the root zone.
DNSSEC is not a complete security solution to every form of cyber attack, nor is it free of certain drawbacks. The scope of DNSSEC protections is limited to specific types of exploits. Moreover, some critics maintain that even these protections can be otherwise achieved using modern DNS software, adopting best practices and educating users to insist on the Secure Sockets Layer for transmitting sensitive data. Widespread adoption of DNSSEC could, they argue, introduce complex key management requirements, lengthen data responses and create a single point of failure.
Where Does the DNSSEC Protocol Stand Today?
Support for DNSSEC root signing is growing. DNSSEC is now deployed by four TLD operators, and others are preparing to do so. In June 2007, the RIPE community asked ICANN to get the root zone signed as soon as possible. Stakeholders in Sweden and the United Kingdom quickly followed suit with a similar request. In September 2008, ICANN submitted a proposal to the U.S. Department of Commerce to sign the root zone using DNSSEC technology.
Want to Learn More?
The SSAC Advisory on Fast Flux Hosting and DNS provides an overview of that issue area (see http://www.icann.org/en/committees/security/sac025.pdf). The GNSO Fast Flux Working Group Initial Report provides initial answers to a set of charter questions, offers interim conclusions and has provides a number of ideas for next steps for discussion and feedback. http://gnso.icann.org/issues/fast-flux-hosting/fast-flux-initial-report-26jan09.pdf.
A summary of ICANN actions to prepare for DNSSEC signing activities is available at http://www.icann.org/en/announcements/dnssec-paper-15jul08-en.pdf. The ICANN proposal to the U.S. Department of Comment on signing the root can be found here: