DNS experts have known for a long time that the system is another of those old designed back in an era when we didn't think too hard about security, if we thought about it at all. Like most of those protocols. DNS is too embedded in existing computers and software to displace easily, and proposed fixes are going nowhere.
A recent ICANN blog explains in fairly simple language why the DNS is broken. It's worth reviewing if you're not already familiar with the issues.
An example of the "cache poisoning" attack potential for DNS was revealed this summer in a bug in almost all DNS servers found by researcher Dan Kaminsky of IOActive. Kaminsky and others showed a remarkable discipline and coordination in contacting DNS software authors to arrange for coordinated patch release.
But researchers were quick to realize that the fix wasn't a fix for all cache poisoning attacks. More will follow and there may be one some day that will not be easily patched. What do we do? As a practical matter, the DNS is vital to almost every application on the Internet.
As the ICANN blog says, there isn't really a way to fix the conventional DNS. The answer is to move to DNSSEC, a system which uses public key encryption to provide authentication of DNS records for clients. DNSSEC is not new; the original work on it is about 10 years old. But deployment of it is quite sparse, and limited by the fact that, to be truly effective, the whole of the DNS hierarchy up to the root servers need to be digitally signed. Right now the root is not signed; nor are many significant top-level domains, including .com.
The signing of the root has been held up by the usual lethargy with which significant ICANN actions and changes to Internet infrastructure are done. These things always take many years, preceded by committees to study how the problem should be addressed, committees to decide on who the relevant interest groups are and, finally, committees to discuss the actual problem. The signing issue has been complicated by the fact that it's not really ICANN's decision to make: changes to the root zone must be authorized by the U.S. government, and specifically by the NTIA (National Telecommunications and Information Administration) of the Department of Commerce. Here's their DNSSEC page.
The signing issue has been complicated by some politics in that it involves the last vestiges of authority of the U.S. government over the Internet. 10 years ago ICANN was created to take the government out of more direct authority (which it ran through contracts with universities and companies like Network Solutions; click here for a good story about how that worked out, but it retained control over changes to the root zone, including signing the root. Recently the NTIA solicited input on how signing of the root should proceed; their DNSSEC page includes that solicitation and the reactions of many parties, including ICANN's.
In the past I've been pretty skeptical of the prospects for DNSSEC to achieve success, and my arguments still have some merit. It's not hard to see political infighting delaying the signing, or shaping it into a political compromise which would impede its effectiveness and trust in it. On top of that there are just the technical inertia problems: like any other big change on the Internet, many will ignore DNSSEC as long as they have more pressing problems on their plate competing for budget dollars.
I'm seeing a consensus emerging among DNS experts that, in the wake of the Kaminsky bug, the signing of the root is more clearly an urgent issue and that acceptable ways to do it are also fairly clear. The root zone is now administered by the IANA (Internet Assigned Numbers Authority), a department within ICANN. IANA has some other ominous responsibilities, such as parceling out IP address and AS number blocks. Their work is occasionally controversial, such as in how IP and AS numbers are allocated to different parts of the world; the Wikipedia IANA page states (without any attribution) that the relationships between ICANN, IANA and other bodies in these administration tasks are highly political and controversial. But I think that generally they are viewed as a dispassionate and apolitical engineering organization.
It doesn't bother me if ICANN and the IANA contract out the actual signing of the root to a company like VeriSign, as they currently do with many root zone operations. VeriSign should enjoy no unique access or other advantage from this relationship, but I'm sure that's well understood. VeriSign has significant experience in working with the root zone and it makes sense to take advantage of that.
Much of my skepticism may have confused a vision of an all-DNSSEC Internet with one where users and services can provide DNSSEC properly and interact with others. The former is, as things stand now, pie in the sky, akin to a vision of all Americans tossing their SUVs for hybrids or fuel cell vehicles. You can imagine it as a technical matter, but economics, politics and human behavior say it's just not going to happen.
Be that as it may, there's no good excuse for ignoring a problem we know to be serious and not seeking progress with the only solution at hand. Failing to make the DNSSEC infrastructure complete is telling people that they cannot secure themselves, and represents failure on the part of decision makers.
Lastly, allowing some trusted agency, probably the IANA, to sign the root zone, does not represent a loss of authority for the US government as custodian of the root zone. Rather it strengthens that authority by showing that the government is taking reasonable measures to secure the root zone and the rest of the DNS.
A bug like the Kaminsky bug that did not have a practical solution would be a major disaster for the Internet. As it is, months after patches were made available a high percentage of DNS servers still are vulnerable. If it were impossible to patch, attackers could go after high-profile recursive servers at prominent ISPs and nobody would be able to trust anything on the Internet anymore.
The only responsible way to move is forward, and the only forward path is through DNSSEC. Put it on your radar if you take your users' security seriously.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's blog Cheap Hack.