DNSSEC is supposed to put trust into DNS by signing responses indicating that the response is authentic. A few TLD's like Puerto Rico and Sweden are moving forward with DNSSEC while ICANN and IANA figure out when to sign the root zones.
DNSSEC is easily understood using a model similar to SSL (DNSSEC Tools also has a good set of tutorials ). A zone such as example.com has a public/private key pair and the responses are signed using the private key. Public-key cryptography ensures that DNSSEC responses can be verified using the associated public key and there is an extremely ridiculously low chance that the signature could be forged. I won't say impossible because the crypto nerds will beat me up, but for all intents and purposes, the chance of forging a signed response is low enough to be trustworthy.
So that's the answer, right? DNSSEC authoritatively signs records so the DNS forgery problem is no more? Well, no. Let me do some hand waving here and pretend that DNSSEC is starting to roll out on a global scale. The roll out will take time and there is no indication that DNSSEC will reach 100% penetration, though that would be nice. But let's say some sensitive organizations like banks and online stores are starting to support DNSSEC. That's good, but the deployment is uneven, and how is the user to know when a host record should be signed or not?
Another critical component is DNSSEC-aware computers called stub resolvers that can request and process DNSSEC requests. Your workstation should verify DNSSEC responses itself and not rely on the DNS server to do so. DNSSEC-aware stub resolver is reportedly coming to Windows 7 and already is available on platforms like Linux that uses the Bind 9 software.
Of course, applications have to be DNSSEC-aware so they can differentiate between authenticated DNS responses and unauthenticated ones. Some zones will be signed by DNSSEC and some won't. Some hosts will be signed and some won't. In theory, we might want to reject any responses that are not signed, but that assumes that all DNS records will be signed and that would be a bad assumption, today and in the near future. The user will have to make a decision about whether to continue using a site located using an unauthenticated DNS response. We've Been Here Before
I envision DNSSEC deployments very much like SSL deployments. Some Web sites use SSL, some don't. A few sites use EV certificates, most don't. Not every Web site needs to be SSL-enabled. Trying to enforce SSL on all Web sites would be disastrous because virtual hosting would be broken; millions of Web site owners would have to become certificate managers; and the costs in time and money would be exorbitant. Since SSL deployment is uneven, the responsibility of determining what is trusted and what is not falls to the user.
The user is notified of the status of SSL in the Web browser and that interaction is woefully inadequate. When users are met with an SSL problem described in a dialog box, they will invariably click through. But a more subtle attack was demonstrated by Moxie Marlinspike which fools a user into thinking they are at the SSL Web site of their choice when that is not the case.
The attacks work because the way SSL enablement is presented to users is inconsistent. Each browser vendor displays SSL status differently and the display changes with version differences. In addition, Web site owners have opted to make the remaining visual cues confusing. You go to your bank's Web site via unencrypted HTTP, http://www.example.com, and there is a form to log in. That form displays a tiny lock image which is just an image. The authentication request may be sent over SSL, but the user doesn't know that unless they view the page source and look for the form action.
DNS, however, is lower in the stack and hidden from users. I bet most users don't even know how names are resolved to IP addresses nor should they be required to understand how DNS works, much less understand how DNSSEC works. The salient information is in knowing whether the host they are talking to is, in fact, the host they are talking to. DNSSEC can tell us that, but if the presentation is inconsistent and DNSSEC deployment is uneven, too much burden is placed on the user. Just like users can be fooled into trusting fraudulent SSL-enabled Web sites, they could be fooled into trusting fraudulent hosts.
User interaction is just as important as the technical deployment specifications, yet little work is being done on that front. If DNSSEC will actually be useful for users, a few things need to occur:
- Browser vendor should agree on a consistent method to display the status of DNSSEC to the user in an unambiguous and clear manner. Even something as a text representation of "Authenticated Host" or something like that.
- Web sites that are known to contain sensitive information or activity like financial institutions, online retailers, health care providers, and other entities that should have a higher standard of trust, should be required -- through regulation or best practice -- to use DNSSEC. If bank A uses DNSSEC and you get a DNS response that is not signed, the user should know that is a potential problem. But a user shouldn't have to keep track of which banks use DNSSEC and which don't.
- The sites using DNSSEC and any organization demanding the use of DNSSEC should work together to educate users on what to look for in a signed response and clearly indicate the conditions where an unauthenticated response to a name should not be trusted.
Users can make the right decisions if they are given the right information. That is just as difficult as figuring out how to generate the response in the first place.