The DNS is fragile they say. Not only is it another one of those old Internet protocols that was never designed to handle either the load or the level of attack to which it is subjected today, but the sheer number of DNS servers out there is immense, and many are misconfigured.
Imagine then trying to introduce a new standard that changes all of them, as DNSSEC does. Already the idea seems crazy and doomed to failure. There's far greater consensus that SMTP is broken and an active problem on the Internet and the prospect of upgrading all those SMTP servers is a distant one.
In a column a few months ago I compared some arguments for and against DNSSEC, concluding that they both had merit. But I also argued that DNSSEC is one of those massive changes that is highly unlikely to occur because it relies on herding cats: You can't just order every DNS admin around the world to upgrade their server and to implement secure key management. And then there's all the old DNS clients, but we won't go into that.
Of course, nothing's perfect, and engineering is all about trade-offs and surely it's better to have DNSSEC partially implemented than not implemented at all. I might have bought that argument. But it turns out that a partial implementation is a waste of time.
As Geoff Huston argued recently in CircleID (please follow the link, Circle ID is a great site and Geoff's writing is always a learning experience), silly political arguments are preventing the signing of the DNS root zone for DNSSEC.
If you think like an engineer, you'd assume that since the IANA administers the root zone, of course the IANA should maintain the private key used to sign it. But various authorities have gotten paranoid about this development, thinking perhaps that George Bush will use the root zone private key to control which Facebook pages we can view. The problems are serious enough to make me think that the root zone will never be signed.
Putting aside the merits of the arguments about U.S. government "control" of the Internet, Huston shows that without the root zone being signed, DNSSEC simply doesn't do what it claims to do. It's designed to require that the entire hierarchy be signed.
But even if it were signed, Huston shows that there are plenty of infrastructure problems in DNSSEC for which there are no obvious solutions. The controversy over signing the root is saving us from addressing these issues, but they're still there.
Another brick wall in the way of DNSSEC is DNS providers in the real world. OpenDNS is one of the largest DNS resolvers in the world, and CEO David Ulevitch says they will never support DNSSEC (not that this will be a problem for him, as he says they get absolutely no customer interest in it).
Ulevitch says no major ISP would ever support DNSSEC because they don't want to put lots of money into an infrastructure item that brings no customer benefit or cost savings. Quite the contrary, DNSSEC would add a major source of computational burden and complexity to the network. "If DNSSEC were a stock symbol, I'd be shorting it," he says. Ulevitch thinks the OpenDNS approach of looking at the actual content of the DNS traffic does a lot more for security than DNSSEC has ever done.
The arguments I covered in my previous DNSSEC column had to do with whether DNSSEC really solves the problem it claims to solve, but it turns out that's not the point. Assume that it really does authenticate everything it claims to authenticate and that there aren't easy ways to hack around those protections, and DNSSEC is still dead. There's no reasonable way to foresee it being adopted widely.
You need to pick your battles, and fighting for DNSSEC is a battle that cannot be won. I've never expended much energy on it myself, but this is the end of the line for me. Dead issue.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.com's Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's blog Cheap Hack
More from Larry Seltzer