Home / Blogs

Defense in Depth for DNSSEC Applications

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.

By Paul Vixie, VP and Distinguished Engineer, AWS Security

Dr. Paul Vixie is the CEO of Farsight Security. He previously served as President, Chairman and Founder of Internet Systems Consortium (ISC), as President of MAPS, PAIX and MIBH, as CTO of Abovenet/MFN, and on the board of several for-profit and non-profit companies. He served on the ARIN Board of Trustees from 2005 to 2013, and as Chairman in 2008 and 2009. Vixie is a founding member of ICANN Root Server System Advisory Committee (RSSAC) and ICANN Security and Stability Advisory Committee (SSAC).

Visit Page

Filed Under


Agree, the devil is in the deployment Phillip Hallam-Baker  –  Aug 19, 2011 6:18 PM

I absolutely agree that DNSSEC needs to concentrate on finding a deployment strategy. I have been trying to persuade people that ‘hope is not a strategy’ for some time.

Building infrastructure requires a killer application that is currently unserved. In my view that should be security policy for Web Services. There is a desperate need for a mechanism for managing Web Services, DNSSEC provides the necessary infrastructure, it is a compelling value proposition.

Unfortunately what DNSSEC has been sold as a replacement for CA issued SSL certs. Which is a mature market. DNSSEC is a new entrant into that market and as you point out, until the infrastructure is built out, DNSSEC is going to be less than a 100% solution compared to the incumbent.

There is definitely a need for a basic SSL credential for enabling crypto without making any assertion about the identity of the keyholder (beyond transient holdership of the DNS domain). Once the DNSSEC infrastructure has been built out it will provide a viable basis for that credential. But expecting that particular application to drive deployment of the infrastructure is optimistic to say the least.

Security policy is the glaring security deficit in the Internet infrastructure. The DNS is the obvious infrastructure to use to publish security policy. Yet that seems to be the one application that people won’t look at.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign


Sponsored byDNIB.com