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, Intellectual Property, 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 7:26 AM PDT

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

Explore Topics

Industry Updates – Sponsored Posts

Meet Boston Ivy, Home to Some of the Most Specialized TLDs in the Financial Services Sector

Move Beyond Defensive Domain Name Registrations, Towards Strategic Thinking

Is Your TLD Threat Mitigation Strategy up to Scratch?

Verisign Launches New gTLDs for the Korean Market, .닷컴 and .닷넷

Verisign Opens Landrush Program Period for .コム Domain Names

Domain Management Handbook from MarkMonitor

Afilias Announces Relaunch of .GREEN TLD

New .PROMO Domain Sunrise Period Begins Today

US Court Grants DCA Trust's Motion for Preliminary Injunction on .Africa gTLD

Minds + Machines Group Announces Outsourcing Agreements, Web Address Change

.STORE Opens its Doors to Brands

What Holds Firms Back from Choosing Cloud-Based External DNS?

February Biggest Month to Date for Radix, Over 750K Domain Registrations

Best Practices from Verizon - Proactively Mitigating Emerging Fraudulent Activities

Radix & WHMCS Offer Free .HOST Domains to All WHMCS Customers

New .BET Domain Now Available to the Public

Radix and SnapNames Announce Exclusive Partnership

Radix Gives Its TLD .SPACE a Makeover

New .PET Domain Available to the Public

2015 Trends: Multi-channel, Streaming Media and the Growth of Fraud

Sponsored Topics


DNS Security

Sponsored by
Afilias - Mobile & Web Services


Sponsored by
Afilias - Mobile & Web Services


Sponsored by


Sponsored by