SEPTEMBER/OCTOBER 2009 ■ 1540-7993/09/$26.00 © 2009 IEEE ■ COPUBLISHED BY THE IEEE COMPUTER AND RELIABILITY SOCIETIES 11

Guest Editors’ Introduction

Securing the Domain Name System

Daniel Massey

Colorado State University

Dorothy e. Denning

The Naval Postgraduate School

The Domain Name System (DNS) is a critical part of the

Internet infrastructure. Virtually every Internet appli-

cation depends on some form of DNS data, yet access to

and the reliability of that data aren’t assured. DNS attacks

and abuses, meanwhile, are increasingly common and

sophisticated. Part of the problem is that security wasn’t a major goal of the original DNS design. The DNS community has been aware of security issues for decades, but only now are solutions ready for wide-scale deployment. Motivated by both its importance and recent enhancements to strengthen its se-curity, this issue of IEEE Security & Privacy looks at the challenges in securing the DNS.

Security Aspects of Today’s DNSThe DNS maps host names such as www.computer.org to IP addresses and provides a wide range of other mapping services, from email to geographic location. In its most basic form, a DNS attack can pre-vent an application from receiving critical DNS data or redirect the application to a bogus server by providing false data. For example, a Web browser will be unable to load the www.computer.org Web site if DNS fails to respond to a request for the site’s IP address. If DNS responds but with the wrong IP address, the browser will con-tact the wrong server and load phony Web pages. Even if the user

recognizes that the loaded pages are fake, he or she generally can’t reach the valid site unless DNS provides a legitimate IP address. In this sense, the DNS is truly criti-cal Internet infrastructure, and we must understand its security vul-nerabilities and potential solutions.

The article “Protecting the DNS from Routing Attacks: Two Alternative Anycast Implementa-tions,” by Ioannis Avramopoulos and Martin Suchara, addresses the challenge of reaching legitimate DNS servers in the first place. To obtain the IP address of www.computer.org, the application must communicate with serv-ers, but by disrupting the routes to them, a DNS attack can deny service or redirect queries to false servers that provide forged DNS data. This article shows how to ap-ply different anycast routing tech-niques to ensure that critical DNS servers remain available.

Legitimate network adminis-trators work to ensure that DNS data is available for their sites, but spam and phishing campaign orga-nizers also want to guarantee that their sites remain available. The ar-ticle “Phishing Infrastructure Flux-

es All the Way,” by D. Kevin M c G r a t h , Andrew Kala-fut, and Minaxi Gupta, exam-ines how attack-ers are abusing the DNS to en-sure the availability of fake sites and make it more difficult to shut them down. Using a technique called “fast flux,” a DNS name resolves to a large number of IP addresses, which typically have short validi-ties and change frequently, mak-ing it difficult to track them down and end the phishing campaign. The article describes the fast-flux behavior in more detail along with variations such as DNS flux and double flux. The authors consider techniques for detecting vari-ous flux events and provide both an understanding of the fast-flux problem and a potentially powerful tool for detecting it.

The DNS Security ExtensionsProtecting routes to servers im-proves the DNS’s availability, whereas addressing problems such

Guest Editors’ Introduction

12 IEEE SECURITY & PRIVACY

as fast flux limits its misuse. These security enhance-ments are clearly important, but fundamental prob-lems remain. An attacker with sufficient capabilities can provide false DNS data that denies legitimate ser-vice or redirects traffic to false sites. This basic vul-nerability has been well known since the early ’90s, when Steve Bellovin circulated a paper—“Using the Domain Name System for System Break-Ins”—and several years later presented it at the Fifth Usenix Security Symposium.1 Concerns over the ability to spoof DNS responses and poison DNS caches remain today. A little more than a year ago, Dan Kaminsky identified an exploit that lets attackers effectively poi-son DNS caches with false results and demonstrated this attack’s devastating impact at Black Hat 2008. Patches were released for most DNS software to help mitigate the vulnerability, but the race between at-tack strategies and defenses continues.

To address the vulnerabilities Bellovin and oth-ers have discovered, the DNS community developed DNS Security Extensions (DNSSEC), which adds data origin authentication and data integrity to the DNS. Roughly speaking, DNSSEC uses digital sig-natures to provide cryptographic assurance that IP ad-dresses reported for a name such as www.computer.org were entered by the owner of the computer.org zone. With DNSSEC deployed, attackers can’t pro-vide DNS data for the site unless they’ve gained access to a private key belonging to the zone or its ances-tors in the DNS hierarchy. After many years of devel-opment, DNSSEC was published in March 2005 as RFCs 4033, 4034, and 4035.2–4 The focus has since shifted from DNSSEC design to deployment.

As of today, DNSSEC deployment is still in its infancy, with only a tiny fraction of zones having deployed it, but it has reached important milestones. Several DNS server and resolver implementations support DNSSEC, and there are both open source tools for administering it in most any size zone and commercial appliances that automate its deployment. Several country code top-level domains, including se (Sweden) and bg (Bulgaria), have deployed DNSSEC for a few years now. The US government has man-dated deployment in the gov domain—the gov zone itself is already signed, and a growing set of *.gov zones are deploying DNSSEC. The generic top-lev-el domain org has deployed DNSSEC, and the de-ployment list is growing. You can find operational guidelines, best practices, and updated information on current deployment at sites such as the DNSSEC Deployment Initiative (www.dnssec-deployment.org), the DNSSEC Industry Coalition (http://dns seccoalition.org/website/), the SecSpider DNSSEC Monitoring Site (http://secspider.cs.ucla.edu), and the NLnet Labs DNSSEC page (www.nlnetlabs.nl/projects/dnssec/).

PURPOSE: The IEEE Computer Society is the world’s largest association of computing professionals and is the leading provider of technical information in the field.MEMBERSHIP: Members receive the monthly magazine Computer, discounts, and opportunities to serve (all activities are led by volunteer members). Membership is open to all IEEE members, affiliate society members, and others interested in the computer field.COMPUTER SOCIETY WEB SITE: www.computer.orgOMBUDSMAN: Email help@computer.org.

Next Board Meeting: 17 Nov. 2009, New Brunswick, NJ, USA

EXECUTIVE COMMITTEEPresident: Susan K. (Kathy) Land, CSDP*President-Elect: James D. Isaak;* Past President: Rangachar Kasturi;* Secretary: David A. Grier;* VP, Chapters Activities: Sattupathu V. Sankaran;† VP, Educational Activities: Alan Clements (2nd VP);* VP, Professional Activities: James W. Moore;† VP, Publications: Sorel Reisman;† VP, Standards Activities: John Harauz;† VP, Technical & Conference Activities: John W. Walz (1st VP);* Treasurer: Donald F. Shafer;* 2008–2009 IEEE Division V Director: Deborah M. Cooper;† 2009–2010 IEEE Division VIII Director: Stephen L. Diamond;† 2009 IEEE Division V Director-Elect: Michael R. Williams;† Computer Editor in Chief: Carl K. Chang†

*voting member of the Board of Governors †nonvoting member of the Board of Governors

BOARD OF GOVERNORSTerm Expiring 2009: Van L. Eden; Robert Dupuis; Frank E. Ferrante; Roger U. Fujii; Ann Q. Gates, CSDP; Juan E. Gilbert; Don F. Shafer

Term Expiring 2010: André Ivanov; Phillip A. Laplante; Itaru Mimura; Jon G. Rokne; Christina M. Schober; Ann E.K. Sobel; Jeffrey M. Voas

Term Expiring 2011: Elisa Bertino, George V. Cybenko, Ann DeMarle, David S. Ebert, David A. Grier, Hironori Kasahara, Steven L. Tanimoto

EXECUTIVE STAFFExecutive Director: Angela R. Burgess; Director, Business & Product Development: Ann Vu; Director, Finance & Accounting: John Miller; Director, Governance, & Associate Executive Director: Anne Marie Kelly; Director, Information Technology & Services: Carl Scott; Director, Membership Development: Violet S. Doan; Director, Products & Services: Evan Butterfield; Director, Sales & Marketing: Dick Price

COMPUTER SOCIETY OFFICESWashington, D.C.: 2001 L St., Ste. 700, Washington, D.C. 20036Phone: +1 202 371 0101; Fax: +1 202 728 9614; Email: hq.ofc@computer.org

Los Alamitos: 10662 Los Vaqueros Circle, Los Alamitos, CA 90720-1314

Phone: +1 714 821 8380; Email: help@computer.orgMembership & Publication Orders: Phone: +1 800 272 6657; Fax: +1 714 821 4641; Email: help@computer.org

Asia/Pacific: Watanabe Building, 1-4-2 Minami-Aoyama, Minato-ku, Tokyo 107-0062, Japan

Phone: +81 3 3408 3118 • Fax: +81 3 3408 3553Email: tokyo.ofc@computer.org

IEEE OFFICERSPresident: John R. Vig; President-Elect: Pedro A. Ray; Past President: Lewis M. Terman; Secretary: Barry L. Shoop; Treasurer: Peter W. Staecker; VP, Educational Activities: Teofilo Ramos; VP, Publication Services & Products: Jon G. Rokne; VP, Membership & Geographic Activities: Joseph V. Lillie; President, Standards Association Board of Governors: W. Charlton Adams; VP, Technical Activities: Harold L. Flescher; IEEE Division V Director: Deborah M. Cooper; IEEE Division VIII Director: Stephen L. Diamond; President, IEEE-USA: Gordon W. Day

revised 1 May 2009

Guest Editors’ Introduction

www.computer.org/security 13

This issue provides three articles that cover dif-ferent aspects of DNSSEC. The combined result discusses how zone administrators can deploy it at au-thoritative servers, how DNS resolvers can use DNS-SEC signatures to authenticate data, and open issues on managing public keys.

“Open Issues in Secure DNS Deployment,” by Ramaswamy Chandramouli and Scott Rose, con-siders DNSSEC from a zone administrator’s stand-point. The authors provide a solid overview of both the basic DNSSEC design and DNSSEC deployment issues. With DNSSEC, a zone operator will gener-ate a public-private key pair and use the private key to sign zone data. This article discusses deployment challenges ranging from the selection of appropri-ate key sizes and rolling over keys to managing au-thentication chains that let resolvers learn the public keys. It’s essential reading for anyone who wants to understand how zone operators should deploy and manage DNSSEC.

Wouter C.A. Wijngaards and Benno J. Overeinder also consider DNSSEC in their article, “Securing DNS: Extending DNS Servers with a DNSSEC Vali-dator,” but from the perspective of a DNS resolver trying to validate the DNSSEC signatures zone op-erators provide. The authors have carefully considered the trade-offs in building a resolver that offers both security and performance and present a publicly avail-able resolver that meets their design objectives. They further analyze their resolver’s performance, provid-ing insights on both the advantages and costs in de-ploying a DNS validator.

Having discussed how authoritative servers sign DNS data and how resolvers validate it, we finally turn to a challenging problem that faces any system that relies on public-key cryptography: How do we learn and manage public keys? A zone owner can cre-ate public keys, and resolvers that have learned them can validate data from the zones, but it would be impractical to distribute public keys from all secure zones to all validating resolvers. In an ideal world, DNSSEC would be fully deployed, we could config-ure resolvers with a single public key of the root zone, and each zone would coordinate with its secure par-ent so resolvers could follow an authentication chain from the root public key to the desired DNS record. For example, a resolver could use the root public key to authenticate the org public key, which could au-thenticate the computer.org public key, which in turn could authenticate the IP address (or, more precisely, the DNS type A record set) for www.computer.org. In reality, security extensions are incrementally de-ployed, and full deployment at every DNS zone might never occur. The article “Interadministrative Chal-lenges in Managing DNSKEYs,” by Eric Osterweil and Lixia Zhang, considers the problem of managing

these public keys both when an authentication chain can be formed with a secure parent and when no secure parent exists.

W e believe this special issue provides an interest-ing and important look at the DNS, a system

that almost everyone relies on but is often overlooked when assessing overall security. The article on pro-tecting routes to the DNS servers illustrates some of the complexities and interactions between Internet in-frastructure components, whereas the one on fast flux and phishing demonstrates how attackers can misuse the seemingly simple DNS system in complex ways. Enhancing security in these areas is complementary to the DNSSEC objective of adding origin authentica-tion and data integrity, which the remaining articles examine. We hope this issue helps readers understand the security challenges facing the DNS and the efforts under way to enhance DNS security.

AcknowledgmentsWe thank all those who submitted articles for this special is-sue. We also thank the external reviewers who helped select the articles from a very impressive set of submissions and provided valuable feedback to the authors. Finally, we also thank the IEEE Security & Privacy staff and volunteer editors for all their work in producing this issue.

References1. S.M. Bellovin, “Using the Domain Name System for

System Break-Ins,” Proc. 5th Usenix UNIX Security Symp., Usenix Assoc., June 1995.

2. R. Arends et al., DNS Security Introduction and Require-ments, IETF RFC 4033, Mar. 2005; www.ietf.org/rfc/rfc4033.txt.

3. R. Arends et al., Records for the DNS Security Exten-sions, IETF RFC 4034, Mar. 2005; www.ietf.org/rfc/rfc4034.txt.

4. R. Arends et al., Protocol Modifications for the DNS Secu-rity Extensions, IETF RFC 4035, Mar. 2005; www.ietf.org/rfc/rfc4035.txt.

Daniel Massey is an associate professor at Colorado State

University. His research interests include security for large-

scale critical infrastructure such as the DNS and Internet

routing. Massey has a PhD in computer science from the Uni-

versity of California, Los Angeles. He is a coeditor of the DNS

Security Extensions. Contact him at massey@cs.colostate.edu.

Dorothy E. Denning is distinguished professor in the Depart-

ment of Defense Analysis at the Naval Postgraduate School.

Her research interests include cybersecurity and cyberconflict.

Denning has a PhD in computer science from Purdue Univer-

sity. She’s the author of Information Warfare and Security

(Addison-Wesley, 1999). Contact her at dedennin@nps.edu.