Opinion: With the recent onset of the ZLOB virus, sufficient fuel has been provided to get people talking about DNS's inherent lack of security again. There's nothing new to see here, but we'll once again explain some of the evil things that a compromised DNS server can allow, and how the proposed solutions simply will not work.
The ZLOB virus writes to a Windows computer's registry and changes DNS server settings. If for example, you type "usbank.com" in your browser, and your system is configured to use a malicious DNS server, there is no telling where you will actually end up. Countless people may be easily fooled by a well-designed malicious site, so taking over someone's DNS is probably the most effective phishing mechanism available.
All the security features in the world, including browser-based detection, are circumvented if DNS is controlled by the phishers. "But what about the wonderful security of SSL?" you ask. If I were a phisher, controlling DNS, I would likely have the bank Web page send an HTTP redirect to a similar-sounding name. The SSL certificate could be 100% valid in this case. Less sophisticated users may even notice this, so perhaps we could even just make our own SSL certificate and assume that users will 'accept' the bogus cert. Chances are, they will. Finally, it is probably enough to simply forgo the SSL masquerade altogether. Most users will still login, assuming the front page looks familiar enough. It suffices to say "control DNS, and you control the Internet (for those who use your DNS server)."
Three years ago, we received some interesting feedback when we claimed that DNSSEC simply wouldn't scale Internet-wide, but it still hasn't been deployed.
DNSSEC is an asymmetric key system. This means that the owner of a DNS zone has a private key and a public key. Using the private key to digitally sign a zone will allow anyone with the zone's public key to verify that the data is authentic. It sounds wonderful in theory, but it does require someone to take responsibility and sign a top-level key.
The age-old problem with any type of cryptography is: whom do you trust? In the end, there always has to be some trusted source.
The proposed solution to the basic key management problem is to have Network Solutions sign everyone's public key. For example; myname.com will create a key, sign it, and then send it to Network Solutions for signing. DNS servers around the world who have Network Solutions' key are now able to reject DNS records about myname.com that aren't accompanied by the appropriate signatures.
This is the proposed method for global DNSSEC. It hasn't happened. There is no Network Solutions key that everyone knows, and Network Solutions has no mechanism to gather *.com keys. The highest level domain, '.' (dot), also needs to be under some administrative control. IANA or ICANN can hold this key, and sign all TLD's (.com, .org, etc), but the political mess this would create puts the implementation a long ways off. Whether the U.S. holds the key to the entire Internet or not, someone must before DNSSEC can work globally. Until this is in place, DNSSEC cannot protect anything outside your administrative control or access; meaning you have to manually distribute keys.
DNSSEC also increases the size of zone files by 10-fold, but that concern is not even relevant, given that we're trying to implement it in such an inherently decentralized system, where it cannot possibly work.
ISC's acknowledgement that DNSSEC cannot scale comes in the form of DLV. Domain Lookaside Validation attempts to provide a temporary or transitionary DNSSEC, for "islands of trust." Essentially, it's a nicer way to implement cross-site trust, which you can do currently with DNSSEC if you manually talk to the remote site you want a secure DNS relationship with, and if you're all under the same DNS sub-domain. With DLV however, you can delegate the responsibilities to a specified third party, and even talk DNS securely with unknown parties. It's nice, and may even be used between some highly security-sensitive sites, but it clearly has the same scaling issues as DNSSEC.
DLV is essentially SSL for DNSSEC, in that you can have multiple trusted parties. As long as two sites agree that they both trust Verisign, for example, the trust relationship is established. The only way DNSSEC will ever take off is if enough people start using the DLV model. Not holding my breath, but it could actually work.
TSIG, Transaction Signatures, are meant to improve the security of DNS zone transfers, and allow trusted clients to update dynamic DNS records. It isn't relevant to DNSSEC, but people often confuse it as an alternative. In fact, TSIG is even worse: it uses symmetric keys (shared secrets) that must be distributed manually.
What Can We Do?
Everybody, by now, certainly believes that DNS is critical. The solution unfortunately has not been found. In this basic endeavor to expand trust relationships throughout the whole Internet, we all understand that ultimately a single source needs to be the authority. With SSL there's multiple sources, but their CA keys get manually distributed by Web browser makers.
Site administrators wishing to dabble in DNSSEC can certainly implement it for their own personal zones. The benefit is pretty minimal, but you can be certain that the integrity of your internal DNS is safe and sound. The other major problem with DNSSEC is that implementing part of it, for most people, just isn't useful. It's an all-or-nothing proposition, and without signed parent zones, the only option is nothing.
The question is, assuming we want to proceed with DNSSEC: Who will hold the key to the Internet?
See the problem?