A panel discussion at IETF 75 helps shed light on the need for DNS security and the reasons why it has taken so long.
Few technologies are more critical to the operation of the Internet than the Domain Name System (DNS). At the time of its development-and for many years since-the DNS has functioned without many formal security mechanisms, thereby making it vulnerable to DNS spoofing and other malicious attacks. In 2008, Dan Kaminsky released his now famous bug, demonstrating how easily an attacker can trick Internet users by temporarily taking over a domain name and redirecting queries to another server.
The vulnerabilities of the DNS were discovered long before the Kaminsky bug, with discussions taking place as far back as 1990. The watershed moment came in 1995 in the form of a paper published by Steve Bellovin in which he described the system’s key weaknesses. In 1997, a set of open standards that would authenticate DNS data by using public key infrastructure to digitally sign DNS records was developed and published as RFC 2065: Domain Name System Security Extensions (DNSSEC).
In simple terms, DNSSEC is designed to enable authentication of DNS response data. It verifies responses to make sure that what you get from a DNS server is what the zone administrator intended. It does not address all threats (nothing does), but it provides a building block for providing additional data security-and not just within the DNS but also within the applications and services that are built on it.
After nearly 15 years of discussion and development, deployment of the DNSSEC is gaining momentum. In July 2009, the Internet Society organized a panel discussion in Stockholm as part of IETF 75 for the purpose of making the issues associated with the adoption of DNSSEC accessible to a broader audience.See details, including presentation materials and a transcript. Moderated by Leslie Daigle, the Internet Society’s chief Internet technology officer, the panel featured a distinguished group of developers, administrators, and Internet infrastructure operators who talked about their experiences with DNSSEC, the problems they’ve had to overcome, and what they see as next steps toward a more robustly secure Internet.
AcPIR’s Jim Galvin presents at DNSSEC panel at IETF 75.
DNSSEC History
In the scheme of things, 15 years seems like a long time to wait for a DNS security framework to be put in place. Panellist Olaf Kolkman said he believes the delays can be traced to three “key actors”? in the DNS deployment world that created a chicken-and-egg problem. The first is the DNS hierarchy, which includes the root and moving into the enterprises and companies that make the high-level decisions. They are the people who need to sign and deploy DNSSEC so that those in the second group, who maintain ISP infrastructure, can validate the components that are used for validating the name servers. Finally, there are the people who can provide operating system and applications support once everything is in place.
The chicken-and-egg problem comes in when the DNS hierarchy decision makers ask why they should invest in signing when signatures are not being validated; when the ISPs ask why they should invest in validation when there is nothing to validate; and when the operating system and application support folks ask why they should invest in development when there is so little infrastructure.
When RFC 2535 was published, DNSSEC seemed ready for deployment. There was a period of code development and standardization, including regular interaction between the two, from 1995 to 2000, but there was very little deployment, except in a few labs. In 2000, the first real deployment trials began. Sweden’s .se registry was interested in signing but discovered privacy and scalability issues. As Olaf explained, it wasn’t until the registry world was making the jump to early deployment that both the standardization team and the development team noticed that something had been missed. The standardization efforts began anew. By 2008, the privacy and scalability issues had been addressed in the form of a technology known as NSEC3.
Soon afterward, training became available, and software was being developed to facilitate deployment outside the laboratory setting. Top-level domains started signing, and things started bubbling up.
“Right now, I think we are at the sweet spot when it comes to deployment,”? Olaf said. “We are at the sweet spot of making the Internet as a whole a more secure place.”?
A View from the Registry
As the top-level-domain registry for Sweden, .SE takes the issue of DNS security seriously. The company began working with DNSSEC in 1999, but it wasn’t until the Kaminsky bug that the company began to thinking beyond the technology and about things like education on, marketing for, and pricing of DNS security services.
As panellist Patrik Wallström of .SE explained, the company originally charged a fairly high price for DNSSEC, but after the Kaminsky bug, the company dropped the pricing altogether. “We consider this to be an important piece of the Internet infrastructure,”? he said.
With the Kaminsky bug still fresh in everyone’s minds, .SE was noticing that a large number of servers were vulnerable to attack. In the interest of reducing that number, .SE launched a DNS security promotional Web site. The site features a movie that demonstrates an attack on the DNS. It also enables visitors to see whether their computers are vulnerable to the Kaminsky bug; if so, the visitor is given advice about what to do. It can also test a visitor’s domain to see whether it runs DNSSEC.
Now the company is working to help registrars become active in promoting DNSSEC, and it is working with all of the major Swedish resolver operators to make sure they validate domain names as well.
In general, .SE is using education and public relations to make people in Sweden aware of what the Kaminsky bug really means and why they should secure their name servers. As a result, a number of high-profile domains have signed. The value of the company’s educational and promotional efforts became especially evident when the Swedish tax office and the Swedish election tax office domain names signed. “The vote survived the recent election and the recent tax returns, so we have really proved that DNSSEC works by now,”? said Patrik.
Deployment, however, was not without problems. In particular, problems arose with one large domain in Sweden, but, as Patrik explained, that ended up being a bug in the BIND, which two of the major ISPs were using. There was, however, a problem with home routers that did not let large packets through, but that was resolved, as was the problem with name servers, which they solved with better monitoring. The major problem now is with registration transfers in cases when one registrar does DNSSEC and the other does not. Patrik said this would eventually be solved through education. Currently, all Swedish registrars that have registrations for the .se domain have an agreement with .SE that, at the very least, they must be able to remove DNS records from the delegation.
Speaking to the experiences of the .org domain space was Jim Galvin, who pointed out that the Public Interest Registry, which runs .org, was created to serve the public interest. “The .org brand is known for being informative, well-intentioned, trustworthy, and the source of valuable information,”? he said. “DNSSEC was a natural extension of all of those elements, and so it seemed pretty obvious that it was the right thing to do.”? The .org TLD finalized signing the zone with DNSSEC on 2 June 2009.
The threats to the DNS cannot be understated, said Jim. As recently as July 2009, Irish Internet service provider Eircom, within the previous few weeks, reported it had been targeted by a cache poisoning attack that redirected customers to sites they did not intend to visit.1 As scary as those attacks were, securing the DNS, as Jim pointed out, is not about just the DNS. “It is not about the man-in-the-middle attacks and getting false information about the DNS,”? he said. “It is about securing an infrastructure protocol.”? Clearly, that protocol matters more and more as societies become increasingly dependent on the Internet for storing and relaying sensitive data such as online health records and conducting online transactions.
Jim offered specific advice about what TLDs and other community members could do as they make plans to sign their domain. First, he suggests making technology the key driver for whatever is done-as opposed to public relations, marketing, or management issues. “DNSSEC will change your operation and the way you do things,”? he said. “It is important to put the time into making sure that things are going to work right. And you can’t let that be driven by anything other than the technology itself.”?
Second, Jim suggests adopting a strategy of collaboration. “There are plenty of experts and they are all willing to help, and you should let them,”? he said. Finally, he advocates a phased approach, particularly for an undertaking as large as DNS security.
Today, roughly 50 percent of the queries that Afilias gets are asking for DNSSEC information-something Jim says should be kept in mind if you’re a TLD or a larger enterprise. Equally notable is that from 1 June to 3 June, when .org was signed, TCP traffic increased by two orders of magnitude. While it did not have a measurable impact on operations, PIR is still, as Jim pointed out, thinking about what they can do to optimize that and make things better in the future.
Panellist Matt Larson of VeriSign discussed plans to sign the .com and .net TLDs. VeriSign has had a long involvement with DNS security-not just with DNSSEC but also with the NSEC3 extension. The company helped develop the NSEC3 extension and has been involved with the addressing of issues of privacy and scalability. According to Matt, when a zone is signed with DNSSEC, the size of that zone can grow quite large-as large as three or four times its size. At a current rate of 90 million delegations between .com and .net, the effect of DNSSEC could be enormous. However, Matt assured the audience that NSEC3 should allow them to scale “much more gracefully.”?
Given the breadth of change that would result from DNSSEC, VeriSign has conducted a handful of pilot projects. This has allowed the company to gain operational experience. One of the pilot projects dealt with NSEC3, but the most recent pilot involved signing the root zone, in which VeriSign used the production signing infrastructure that it uses for its certificate business to secure and handle the cryptographic signing of a test root zone. The actual signing of the production root zone will use a similar architecture.
“If you have a domain underneath .com or .net and you want to sign it and take full advantage of DNSSEC, it does require that .com and .net also be signed,”? said Matt. “In my opinion, it is one of the largest changes we’ll have done with DNS, so as a result, we are approaching this cautiously.”?
Not surprisingly, VeriSign will be using the NSEC3 protocol, and its registrars will be provisioning DS records. In addition, a set of root zone signing requirements has been developed by the U.S. Department of Commerce and is undergoing technical review. The actual signing is going to be a collaborative effort between VeriSign and the Internet Corporation for Assigned Names and Numbers (ICANN). VeriSign and ICANN are the current contractors to the Department of Commerce and the partners that provide the root zone
today.
The road to signing the root has been a long and difficult one, said panellist Richard Lamb of ICANN. However, it is regarded by ICANN and many in the community as an essential step toward greater DNS security. The benefits of DNSSEC in this regard are varied. First, it removes deployment barriers, and it lends simplicity by having a single key, as opposed to multiple TLDs. Second, it allows for compromise recovery. And finally, DNSSEC makes it possible to unsign, if that becomes necessary.
According to Richard, the issue of cybersecurity has captured the attention of the U.S. White House and is the basis for a report being circulated within the Obama Administration. “We cannot improve cybersecurity without improving authentication,”? said Lamb.
“Today there is a generalized awareness of the need to implement the security extensions already at the root of the Domain Name System,”? Richard said. “With the widespread deployment of DNSSEC, we will be able to create a platform for innovation, new product development, and international cooperation.”
DNSSEC Panelists
Leslie Daigle, The Internet Society (moderator)
Jim Galvin, Public Interest Registry
Olaf Kolkman, NLnet Labs
Richard Lamb, ICANN
Matt Larson, Verisign
Patrick WallstrÃm, .SE