At the time of this writing DNSSEC mostly does not work. This is not a bad thing—in fact it’s expected. New technologies go through a necessary “early adoption” phase where you can for example buy a hydrogen powered car but you can’t get hydrogen near your house. There is a significant last-mover advantage DNSSEC deployment (or IPv6 deployment) and that can’t be helped. It’s all in a good cause though—everybody knows we need this stuff and some farsighted contributors put a lot of money and other resources into DNSSEC years or decades ago to ensure that when the time comes the world will have a migration path. Sadly, this leaves current investors and application designers and developers wondering whether there’s a market yet. I could sit back and quote Field of Dreams and say “if you build it they will come” but everybody always says that even about technologies which turn out to have been really useless in retrospect. Let me instead take a look at the case for DNSSEC as seen through the eyes of an application designer.

The two things that keep DNSSEC from mostly working are that (1) other people aren’t using it yet to either sign their zones or validate the signatures they receive when they look things up, and (2) many other people have made assumptions about what a DNS transaction will look like and they either drop anything strange-looking (like a DNSSEC transaction) or they mindlessly modify your DNS transactions (which damages DNSSEC). DNS has been around since the Internet’s earliest non-commercial days and a whole lot of firewall and intrusion detection and ad-insertion and network address translation machinery has been built and deployed successfully which is now very much in the way of expanding the DNS protocol to include things like DNSSEC. I know some of the designers of these “mindless middleboxes” and from what they tell me, schedule and revenue pressures led them to look at what DNS looked like on the wire in the lab on a particular day and build their products accordingly. The details of what the protocol meant or what other packets they did not see that day might also be valid did not enter into it.

The DNSSEC industry can probably solve problem (1) above—the lack of signed zones and the lack of validation by DNS requestors—by just rolling out solid products and services which make these activities cheap and easy and maybe even turning them on by default at some point. But there is no deliberate way to solve problem (2) above—because there’s no way to incent the millions of middlebox owners to stop interfering with our DNSSEC transactions. This creates a big risk to any DNSSEC application designer (and their investors) who have to worry that problem (2) will keep DNSSEC from succeeding—ever—and that any effort they expend could be wasted. To me the interesting question therefore becomes: how can the designer of a DNSSEC application protect their design investment and mitigate risks in the network? My proposed answer is the approach that’s protected Skype all these years: Defense in Depth. This is more or less what I meant in my previous article on COICA and Secure DNS when I said:

... if someone upstream of you can interfere with your traffic then you’ll have to use anti-censorship tools rather than Secure DNS to frustrate that interference.

Defense in depth just means having Plan B ready (and perhaps Plan C and Play D) if your Plan A doesn’t work out. A DNSSEC application who will offer advanced functionality when it receives and validates DNSSEC signed data has to be optimistic about the existence of such signatures. Just because you don’t see them doesn’t mean they aren’t there—you could be behind a home gateway or firewall or deep packet inspection device that strips out DNSSEC responses. Since the application presumably has enhanced functionality it can only offer if it can see the real DNSSEC data, then to defend the investment in this enhanced functionality it will be necessary to try more than one approach to getting that data. You might for example try multiple name servers rather than believing the first one who answers you. You could try far-away name servers such as the one at your house or your employer if the name server in your hotel or coffee shop or ISP does not offer you a DNSSEC secured response. You could try a proxy or a VPN if you think you’re being prohibited from reaching far-away name servers. The one thing you will not do is just give up without first trying every trick you can think of to get a complete DNSSEC validated response to your DNS questions.

This is an obstacle to the development and deployment of DNSSEC applications and therefore to DNSSEC itself, but it’s how the game is played. Skype has made voice-over-IP practical globally because their application doesn’t just try SIP and then give up. SIP almost never works behind a network address translation (NAT) box or in a hotel room but Skype wanted to create a global service. “Try SIP and then give up” would have been a FAIL for that plan. Similarly a DNSSEC application like the one contemplated by the IETF DANE project will have to have a fallback strategy or it would never build market share. Some day we can expect these fallback strategies to be used less frequently—which will drive down costs and improve performance—but at no time during the lifetime of DNS and the Internet can any DNSSEC application safely assume that if no DNSSEC data appears in a response then there probably is no DNSSEC data available. Notably, the enhanced features that will be offered by an application when DNSSEC validation is possible will make the application and its data and its user more secure. We can expect attackers to deliberately force DNSSEC failures in order to disable those enhanced features and force the application into a less secure mode. That’s not something we should make easy by being too fragile in how we try to acquire the DNSSEC data necessary to prove the truth of the DNS data we consume.

These observations have policy implications, including one I had not foreseen at the time I wrote my earlier article COICA and Secure DNS when I said:

... a below-recursive policy whose goal is to make certain domain names unreachable will always be successful no matter how completely the world deploys Secure DNS.

A policy based DNSSEC failure like that contemplated by COICA would be indistinguishable from a bad middlebox or a man-in-the-middle attack. Either way any DNSSEC application which is robust enough to succeed in the market will not give up at that point. My friend Dan Kaminsky told me that he would not be willing to deploy defense-in-depth if there was any chance that his code or his users would be in violation of the law. This is a reasonable position and I share it. Anything we create that can bypass the restrictions of stupid hotel room middleboxes will also trivially bypass anything like COICA anywhere in the world. Since no responsible application designer will code “or else just break the law” into their product, something like COICA could stalemate the market’s movement toward DNSSEC. If a DNSSEC application would have to treat any DNSSEC failure as though it could be due to a lawful intercept, there could literally be no defense-in-depth, no robust DNSSEC applications, and no success in the market for enhanced features that depend on DNSSEC. And if the only benefit from the decades of cost and work that have done into DNSSEC is to protect the DNS infrastructure from data insertion and poisoning attacks—if in other words there could be no new applications which offered enhanced functionality in the presence of DNSSEC data—then DNSSEC itself would be doomed by its own economics.