DNSSEC – The root is signed with DNSSEC. So what does this mean? Can we all relax? Is the Internet secure now?
In July, ICANN, VeriSign and the NTIA generated and published the cryptographic keys used to sign the domain name system’s root zone. This so-called “trust anchor” will eventually be relied upon by the entire DNS and used to protect billions of Internet users against several types of online attack, bringing a new foundation of security to the Internet’s fundamental infrastructure.
The signing of the root zone came as part of a global, cross-industry effort to make DNS Security Extensions, DNSSEC, a reality. The IETF-approved standard was 18 years in development, and represents the best method we know to transparently and securely authenticate DNS queries. DNSSEC can be used to prove that DNS data has not been modified in transit, so users can be assured the website or e-mail they attempted to access, are actually where they go. Once it is widely adopted, DNSSEC will be able to help prevent problems such as cache poisoning and could have implications for user-facing applications that wish to improve authentication security in their underlying DNS.
So, what does this mean? Can we all relax? Is the Internet secure now?
Unfortunately, the answer is no. DNSSEC offers threat protection from only certain subsets of attacks, and it is only truly effective when it is broadly implemented. While the signing of the root zone represents the end of one long process it also represents the beginning of another, more challenging era. The publication of the trust anchor was in that sense merely a first step. The age of development has ended; the age of adoption has begun.
The keys in the root are known as the trust “anchor” because they sit at one end of a chain of trust that reaches all the way back to the end user. For DNSSEC to be fully useful, a number of key industry players, as well as end users themselves, need to do their part to deploy the technology. Because DNSSEC extends regular DNS, almost every place that uses DNS also needs to take account of DNSSEC. This is a chain, and every link must be secured for it to be fully effective.
The operators of top-level domains sit logically directly underneath the root servers in the DNS hierarchy, and this is the place where DNSSEC is currently seeing the greatest level of real-world support. The .org zone is already signed, as are the zones for country-code domains including those belonging to Brazil, Sweden, the UK and Puerto Rico. Other domains, such as .info, .asia and .me will sign their zones this year , and VeriSign plans to introduce DNSSEC in .com and .net by the first quarter of 2011.
By next year, the vast majority of domain name owners will have the ability to enable DNSSEC for their names. Of course, DNSSEC does not implement itself. Domain name owners have to take the initiative to add the extra security to their domains, and most of those will choose to do so using tools made available by their domain name registrars. This is where most of the work through 2011 will be spent, as registries educate and assist registrars with rolling out DNSSEC services within the domain name registration process. It will be extremely important that new best-practices in domain name and DNS service transfers be thoroughly tested. Ensuring that websites and e-mail resolve during these transfer processes is an important complexity that needs practice and uniform processes.
Signing zones and publishing DNSSEC keys is of course only half of the problem. For the technology to be fully useful, the capability to validate those keys needs to be implemented as close to the end user as possible. Imagine a situation where millions of websites are technically able use SSL certificates, but ISPs do not support HTTPS traffic and there is no method for browsers to decrypt it. DNSSEC is in a similar situation today.
This is where ISPs and application developers come in. The vast majority of Web surfers do not and never will know what DNSSEC is, but most know that the Internet can be a dangerous place. It is incumbent on ISPs and application developers to turn DNSSEC into a technology that improves DNS authentication and reduces risks to users who are attempting to access legitimate websites.
To date, there has been less traction on this side of the DNSSEC deployment equation. Few ISPs have publicly stated their support for the technology. In the US, Comcast is a thought-leader, and has been running a live DNSSEC test for several months. Today, any Comcast customer can manually configure their client or home hub to use Comcast’s DNSSEC compatible name servers. If they choose to do so, they know that their ISP will transparently authenticate any zone that publishes DNSSEC data. Other ISPs should show the same level of initiative.
In terms of applications, the two most obvious and exciting places where DNSSEC support would be widely useful are the browser and the e-mail client. A browser that supported SSL and DNSSEC validation would be able to tell a Web surfer with high confidence not only that the data had not been tampered with but also that the source address had been authenticated using a chain of trust stretching all the way up to the DNS root itself. Similarly, an e-mail client that supported DNSSEC might be able to warn users when an email pretending to be from their bank or an e-commerce site doesn’t check out to the authentic site.
So far, the browser and e-mail vendors have yet to publicly confirm their support, although a validation plug-in is available for Firefox from a third-party developer. But recently, at the Black Hat conference in Las Vegas, DNS security expert Dan Kaminsky demonstrated tools he had developed not only to easily sign zones but also to use DNSSEC to authenticate websites and e-mails. Among the software demonstrated was a custom-built Chrome browser and plug-in code for Outlook. The major takeaway is that DNSSEC can be easily implemented on the desktop, if tools are available.
It’s an exciting time for application developers, who are now able to start to leverage the new security protocols inherent in the Internet’s infrastructure to improve their customers’ user experience. When adoption among ISPs and developers reaches the same level as it is approaching in the registry/registrar community, the Internet community will have taken the steps necessary to improve user confidence in the Internet as a means to do business with confidence.