Home / Blogs

DNS Policy is Hop by Hop; DNS Security is End to End

Paul Vixie

The debate continues as to whether ISP's can effectively filter DNS results in order to protect brand and copyright holders from online infringement. It's noteworthy that there is no argument as to whether these rights holders and their properties deserve protection — nobody is saying "content wants to be free" and there is general agreement that it is harder to protect rights in the Internet era where perfect copies of can be made and distributed instantaneously. What we're debating now is just whether controlling DNS at the ISP level would work at all and whether the attempt to insert such controls would damage Secure DNS (sometimes called DNSSEC).

After I finished reading this op-ed, I began to see that there is not a clear understanding among DNS laymen as to the difference between "end to end" and "hop by hop" signaling systems. I hope to illuminate this difference and its relevance to the policy debate about DNS controls as contemplated by the Stop Online Piracy Act (SOPA). I will use the story of DNSSEC's treatment of NXDOMAIN as an illustrative example. My goal is to move the underlying debate forward to a new stage where the questions being debated are respectful of both the laws of physics and the rules of the DNSSEC protocol.

DNSSEC is an "end to end" system, where digital signatures are applied to DNS data by the originator of that data — who is the owner of the DNS name. So, only the United States Government (USG) can authoritatively state that the Internet address of INTERWEB.NIC.MIL is, because only USG and its contractors possess the private signing key that is known used by NIC.MIL. If any ISP who carries this DNS information decides to modify it in any way, then the digital signature will be wrong. Any DNSSEC capable name server or web browser would discard the modified DNS information because its digital signature would not match the signing key for NIC.MIL. Similarly, any DNS answer that arrives without any digital signature at all would also be discarded, since the receiving DNS server or web browser would know that NIC.MIL is signed and so would have to assume that any unsigned response is a "man in the middle" attack of the kind popularized by Dan Kaminsky in 2008.

DNS has several possible response codes, of which two (0 for "success" and 3 for "name error") are end to end, meaning that they are assertions which can only be made by the owner of a name. To secure the DNS it was necessary to add digital signatures for both of these response codes. Continuing from the above example, only USG and its contractors possess the signing key needed to authoritatively state that FOO.BAR.MIL does not exist. If any ISP between the USG name servers for ".MIL" and the end user's name server or web browser modifies a response to assert that something does not exist when it actually does exist, then this modification will be detectible by the absence of a digital signature, or by the presence of an invalid digital signature. There is just no way for intermediaries to successfully insert lies into the DNS data stream once DNSSEC is in use.

The other DNS response codes, such as 1 for "format error", 2 for "server failure", 4 for "not implemented", and 5 for "refused", are "hop by hop" codes. They tell an end user's name server or web browser nothing about the name they are looking up. Rather, these codes are statements about the name server itself. Because digital signing keys are associated with domain names and not with name servers, none of these other response codes is secured by DNSSEC. So, when an end user's name server or web browser receives a DNS message containing one of these response codes, there's a viable possibility that the message was generated by an attacker — a "man in the middle". Secure systems including both DNSSEC itself as well as any applications based on DNSSEC will necessarily ignore these unsigned responses or else they would be susceptible to a "downgrade attack". If a banking application is trying to start up in its most secure mode and sees a "NOTIMP" or "REFUSED" response, its reaction will be to try other name servers hoping to find one that is not broken in the same way. Failures and attacks have an identical appearance to a properly secured system.

It may be possible to design "hop by hop" security into DNSSEC. However, this was not a development goal during the major DNSSEC development effort from 1996 to 2009. Doubtless there are strong governments around the world who would like to be able to modify DNS data in flight without triggering any suspicion by their end user citizens or by secure applications. It is not too late for such governments to form a work party for these features and to offer their detailed design to the the IETF for consideration in a future edition of the DNSSEC protocol, and if successful, work to incorporate these new features into the Internet's operating DNS. Until and unless that is done, DNSSEC will remain tamper-proof.

It would be ignorant and wrong-headed to codify in law a requirement that hop by hop security features be used before there is proof that these features can be defined and deployed in what is today an end to end security system.

By Paul Vixie, CEO, Farsight Security. More blog posts from Paul Vixie can also be read here.

Related topics: Censorship, DNS, DNS Security, Domain Names, Law, Policy & Regulation

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:


Agree with the technical aspects, but the underlying issue is really fundamental liberty Avi Deitcher  –  Jan 03, 2012 6:26 AM PST

Paul, I agree on the technical aspects (wouldn't really want to disagree with Vixie in public on DNS details :-) ), but I think the objections to SOPA/PIPA are more fundamental. Won't copy the whole thing here, have it on the original thehill.com blog http://thehill.com/blogs/congress-blog/technology/201755-refusing-to-answer-to-policy-reasons?page=2#comments and my own http://blog.atomicinc.com/2012/01/03/paul-vixie-vs-the-hill/.

Short form: the fundamental issues are not how to rearchitect the Internet or DNS (which just goes to show the head-in-the-sand perspective of the sponsors/supporters of the bills); the issues are freedom and limits of liability.

To post comments, please login or create an account.

Related Blogs

Related News


Industry Updates – Sponsored Posts

IBCA Presentation to ICANN GAC on Protection of Geographic Names in New gTLDs

NSW Government Launches .sydney Domain

New .VOTE and .VOTO Domains Now Available

Help Ensure the Availability and Security of Your Enterprise DNS with Verisign Recursive DNS

Verisign Launches New Monthly Blog Series: Top 10 Keywords Registered in .COM and .NET

.LGBT Public Launch Begins Today

Verisign Celebrates .com's 30th Anniversary, Launches Domain Name Contest

What's in Your Attack Surface?

New .LGBT Domain Sunrise Period Begins

Minds + Machines in 2014 and 2015

DNW Podcast Interview with Antony Van Couvering

TLD Registry and Right of the Dot Establish a Domain Name Industry "Dream Team"

"Chinese Domaining Masterclass" to be Presented at NamesCon Las Vegas in January 2015

Domain Name .Africa Faces Hurdles - Q&A with Sophia Bekele

Join Paul Vixie & Robert Edmonds at the Upcoming Distinguished Speaker Series

LogicBoxes Announces Automation Solutions for ccTLD

TLD Registry Wins Best Marketing Award at China New gTLD Roadshow

Video Interviews from ICANN 51 in Los Angeles

Update on Minds + Machines' Top-Level Domain Launches

ICANN Los Angeles Recap Webinar

Sponsored Topics

Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines


Sponsored by


Sponsored by

DNS Security

Sponsored by