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 207.132.116.20, 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.