The ISP Column
A monthly column on all things Internet

ISP Column Home
Other Formats:    

DNSSEC - The Opinion
October 2006

Geoff Huston

Over the past two articles we’ve looked at the theory and practice of DNSSEC. So is DNSSEC really going to happen? Is this useful technology that will establish itself as part of the DNS infrastructure? Or is the technology fatally flawed in some fashion that will lead to its premature demise? This final article in this examination of DNSSEC will enter into areas of conjecture and opinion over the future of DNSSEC.

DNSSEC has been around for some time. The earliest internet draft I could find on the topic is one written in February 1994 (draft-ietf-dnssec-secext-00.txt) as part of the work of the DNS Security Working Group of the IETF, and there appears to have been some activity in this space in 1993. So the concepts behind DNSSEC have been in circulation for the past 13 years now. However it appears that it has been only in the past couple of years, with the refinement of the DNSSEC model and the evolution of the network and end system capabilities that DNSSEC looks to be readily deployable.

So if DNSSEC is now readily deployable why haven’t we deployed DNSSEC already? Is DNSSEC really hanging by a thread, and is it really a case of “now or never”, as a relatively recent Internet T-Shirt by Olaf Kolkman suggests?

Lets look at the various perceptions of DNSSEC and see if we can add to the already hefty set of opinions and conjectures about DNSSEC.

DNSSEC – The Negatives

What appears to be the common negative perceptions of DNSSEC?

DNSSEC – The Positives

So why bother with DNSSEC? Because having DNSSEC is far better than not, in terms of the network’s integrity. The Internet is not a network-centric communications architecture. The network itself is not the privileged possessor of user’s credentials, nor does it perpetuate a model of limitation transactions with end devices that attempts to protect its own integrity. In the Internet’s architecture the network loses this distinguished role and undertakes a far more basic role of commodity packet switching. In consequence, users are placed in the position of establishing new forms of mutual trust that are, at times, completely unfounded and very vulnerable to deliberate efforts of subversion.

There are perhaps two deep areas of trust on which the integrity of the entire network relies upon – routing and the domain name system. And in both cases the associated information distribution model is unauthenticated, and in both cases it is vulnerable to various attack as a result. In the case of the DNS the problem lies in DNS spoofing, where a query receives a response which has been tampered with by the attacker. In and of itself this is not a significant issue, but when the application uses this false information to create a session and undertake transactions, then the risk factors tend to multiply.

DNSSEC - Some Personal Opinions

Despite the obvious potential of DNSSEC to be a positive contribution to the Internet in its role of public communications utility. There is something that has been deeply unsatisfying about the exercise I documented in the previous column in an attempt to set up DNSSEC-signed zones and a DNSSEC-aware local resolver, and perhaps this is due to the related observation that, for me, there is something deeply unsatisfying about the state of DNSSEC today.

I suspect that the original vision of DNSSEC was, and still is, a sound and worthy one – I suspect that the original technology vision was a relatively lightweight mechanism of authentication of DNS responses that would allow DNS users (the you and I of the Internet world that use the DNS to drive browsers, mail, and almost every other application) to be able to test that the DNS responses that they get are “genuine” responses that have not been tampered with. Certainly the DNS is a major point of vulnerability for the Internet, and this, hopefully simple, mechanism of DNS authentication has the potential to make some significant progress in risk mitigation within the DNS.

But somewhere in the past 10 years of the DNSSEC development effort we seem to have deviated somewhat from this overall direction and admitted some further complexities into the model that are unhelpful at best. It seems that the issue over the exposure of zone contents through the implicit walk-though of NSEC records and the consequent development of the rather complex NSEC3 framework is one that has nothing to do with users, and way too much to do with the commercial concerns of the domain name supply industry. Zone enumeration is not an implicit security weakness – it’s a business issue over information exposure. The fundamentals in authentication is that some level of information has to be exposed to allow a relying party to perform adequate authentication actions. To deliberately occlude the contents of a zone file in order to make the negative information response required for authentication essentially a meaningless one does appear to be a triumph of “we can do that” over “we should do that”.

While NSEC3 is an interesting case study of computational complexity imposition, the situation with respect to trust injection in DNSSEC is perhaps the more dire aspect of DNSSEC today. The continued lack of a signed root, and the lack of signed top level domains, has turned the task of configuring DNSSEC resolvers into a rather frustrating game of trusted key hide and seek, a game that really does not work for operators of DNS resolvers. The response of working on lookaside vector approaches relating to trust key aggregation do not appear to represent a viable replacement to the original model of a comprehensively signed DNS infrastructure, and appear to me as ad hoc responses with poorly constructed trust models that can do no better than the https certificate efforts in terms of robust authenticatable trust.

Maybe its another aspect of the politicization (and commercialization) of the DNS that has occurred over the past decade. The DNS is no longer primarily motivated by users who want reliable resolution of name strings, but by name registrars and domain servers who have highly focussed commercial interests that, obviously, have considerable sway over the DNS. If we want to make DNSSEC simple and useful then we really want to avoid haphazard trust injection into DNSSEC and, preferably, we’d really like to use a comprehensive DNSSEC deployment framework, from the root down. After all this is all about allowing end users to validate the authenticity of information that they receive via the DNS. The question DNSSEC is attempting to answer, on behalf of the end user, the resolving party, is: “Is this precisely the same information that was placed there by the DNS zone manager?” A comprehensive DNSSEC structure allows this question to be posed with a minimum of overhead on the part of the end user. But the acceptance of a comprehensive DNSSEC framework appears to hinge on the determination of those with a stake in the DNS root to proceed with the signing of this root zone. It also implies that the next level down, that of the various top level domains operators, that they also perceive sufficient commercial value in DNSSEC deployment that would at the very least offset the incremental costs associated with its deployment, and, preferably, generate handsome profits from such a DNSSEC investment. Obviously, given the relative paucity of DNSSEC deployment right now, this is not happening at present.

Where we are today, with small-scale partial deployment of DNSSEC and apparently random placement of associated points of trust, is not a useful blueprint for long-lived global deployment of technology. DNSSEC technology may be perfectly fine (although I’m still personally somewhat sceptical of NSEC3 records), but the associated DNSSEC trust model we have wandered in to today is potentially a fatal flaw for DNSSEC. Today the pain and cost of adoption by servers and users is not balanced by the benefits of having a mechanism to potentially validate a subset of DNS responses. Without a clear rendezvous mechanism between DNS publisher and DNS consumer, then even if you, as a DNS publisher go to the trouble (and cost) to sign your zone and all its descendants, then how can I, as a DNS consumer, figure out that you have done this? Where are your current trust keys? And I should trust them or not? As a DNS consumer my enduring value proposition lies in the ability for applications that I run to be able to apply a validation test to each and every DNS response. This implies that each and every DNS zone publisher sees value in signing their zone and maintaining current keys with their zone parents all the way up to the root. For DNS zone publishers, the enduring value of DNSSEC lies in an outcome where all resolvers chose to validate responses as a preference, and are unwilling to use unvalidatable DNS responses under any circumstances.

The current impasse has the appearance of a mutual deadlock situation, where the supplier and the consumer remain immobile while they wait for the other party to make a move. The longer term problem with such a situation is that after spending some years in one of these pre-deployment stasis situations the technology itself stands the risk of being labelled as a commercial failure, irrespective of its actual merits or potential utility in the future.

I suspect that DNSSEC sits in this form of stasis right now. It’s not a problem looking for a solution. It is indeed a reasonable solution for a known problem (well, I’m not completely sure about NSEC3 when making this claim, but the rest of DNSSEC looks logically consistent to me!), and can make other problems easier to address as a beneficial side-effect. The situation with DNSSEC appears to be one of making this particular solution easy, simple, cheap and useful to deploy, and easy, simple, cheap and valuable to use.

The true leverage of DNSSEC is perhaps only realized in retrospect – if we get to the position where all servers and all resolvers are using this technology, then the value of DNSSEC in protecting the integrity of the DNS in an efficient manner would probably be clearly evident to all. But getting from here to there appears to involve a path of incremental steps that I’m not sure that either the DNS “producer” or DNS “consumer” is really willing to follow right now. How to identify natural incentives for more DNS “producers” and DNS “consumers” to go through the same exercise of zone signing and response validation appears to be an important near-term goal in the path to DNSSEC deployment.

Personally I would be pleased to see DNSSEC head off into widespread, indeed ubiquitous, deployment – the Internet would be all the better if this were to happen. But I’m still not sure that I can see a clear path from where we are today to where DNSSEC needs to be in terms of deployment. We’ll see.

Further Reading:



The above views do not necessarily represent the views of the Asia Pacific Network Information Centre, nor those of the Internet Society.

About the Author

GEOFF HUSTON holds a B.Sc. and a M.Sc. from the Australian National University. He has been closely involved with the development of the Internet for many years, particularly within Australia, where he was responsible for the initial build of the Internet within the Australian academic and research sector. He is author of a number of Internet-related books, and is currently the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region. He was a member of the Internet Architecture Board from 1999 until 2005, and served on the Board of the Internet Society from 1992 until 2001.