The U.S. Congress’ road to Stopping Online Piracy (SOPA) and PROTECT IP (PIPA) has had some twists and turns due to technical constraints imposed by the basic design of the Internet’s Domain Name System (DNS). PIPA’s (and SOPA’s) provisions regarding advertising and payment networks appear to be well grounded in the law enforcement tradition called following the money, but other provisions having to do with regulating American Internet Service Providers (ISPs) so as to block DNS resolution for pirate or infringing web sites have been shown to be ineffectual, impractical, and sometimes unintelligible.

For example an early draft of this legislative package called for DNS redirection of malicious domain names in conflict with the end-to-end DNS Security system (DNSSEC). Any such redirection would be trivially detected as a man in the middle attack by secure clients and would thus be indistinguishable from the kind of malevolent attacks that DNSSEC is designed to prevent. After the impossibility of redirection was shown supporters of PIPA and SOPA admitted that redirection (for example, showing an “FBI Warning” page when an American consumer tried to access a web site dedicated to piracy or infringement) was not actually necessary. Their next idea was no better: to return a false No Such Domain (NXDOMAIN) signal. When the DNS technical community pointed out that NXDOMAIN had the same end-to-end security as a normal DNS answer and that false NXDOMAIN would be detected and rejected by secure clients the supporters SOPA and PIPA changed their proposal once again.

The second to latest idea for some technologically noninvasive way to respond to a DNS lookup request for a pirate or infringing domain name was “just don’t answer”. That is, simulate network loss and let the question “time out”. When the DNS technical community explained that this would lead to long and mysterious delays in web browser behavior as well as an increased traffic load on ISP name servers due to the built in “retry logic” of all DNS clients in all consumer facing devices, we were ignored. However when we also observed that a DNSSEC client would treat this kind of “time out” as evidence of damage by the local hotel or coffee shop wireless gateway and could reasonably respond by trying alternative servers or proxies or even VPN paths in order to get a secure answer, the supporters of SOPA and PIPA agreed with this and moved right along.

The latest idea is to use the Administrative Denial (REFUSED) response code, which as originally defined seemed perfect for this situation. To me this latest proposal as well as the road we’ve travelled getting to this point seems like an excellent example of why network protocols should be designed by engineers rather than by bloggers. REFUSED will not work for PIPA and SOPA’s purposes, for two important reasons.

First, as I explained in DNS Policy is Hop by Hop; DNS Security is End to End, there is no security for the REFUSED signal. Since IP source addresses are easily forged no secure application can ever take an unsecure signal seriously. In DNSSEC, even failures must be secure or else any attacker can control the decisions made by an app. Since one such possible decision might be to retry an operation using a less secure method, we would call this a “downgrade attack”. DNSSEC secures the data from end to end—meaning from the DNS content server to the secure client—but does not secure any of the messages that flow hop by hop through the DNS system—including REFUSED. In fact, the intermediate servers (including the ISP name servers to be regulated by SOPA and PIPA) don’t have any kind of trust relationship with each other and can neither generate nor verify any secure messages. This may seem like an oversight but I was there and I remember this as a conscious and deliberate decision based on the cost-to-benefit ratio of adding hop by hop security to DNS. High cost, low benefit: no sale.

Second, and more importantly, REFUSED is the wrong signal. The preeminent DNS software on the Internet is BIND, whose market share has declined from 99% to 85% in the last 25 years. I maintained and rewrote BIND from 1989 or so until 1999 or so and I am also the author or co-author of a half dozen or so Internet RFC documents on the subject of DNS. So I know that we send REFUSED in response to a query when we don’t like the client’s IP address—DNS servers do not even look at the question before deciding whether to send REFUSED. On the client side, if we hear a REFUSED we give up on that server and move on to the next server—which means we assume that it was the client’s IP address that the server is refusing, not the question we happened to be asking at that moment. Microsoft Windows will actually “de-preference” a name server if they hear too many REFUSED messages from it—so BIND is not the only DNS software that interprets REFUSED in this way. What this boils down to is that REFUSED is all about the relationship between the client and the server, and has nothing to do with the particular question being asked. If SOPA or PIPA becomes law with a requirement to signal REFUSED when someone looks up an infringing or pirate domain name, then in the language of DNS we will be saying “please stop asking this server any questions at all.” There is no signal in DNS that means “that’s a bad question but please feel free to ask other questions.”

This means a classic non-secured DNS client will react to a REFUSED signal by treating the server as broken and just asking the next available server—hoping to find a server that is not broken. Whereas a newer DNSSEC client will react to REFUSED by ignoring it and continuing to wait—hoping for a real answer that might follow close on the heels of the potential forgery. In the unsecure case, the client will often do what the proponents of SOPA and PIPA would seem to want—display an error message in the web browser—but will occasionally just repeat the whole transaction a fraction of a second later, increasing the load on the ISP’s name servers. In the DNSSEC case, the client will not do PIPA or SOPA are asking, there will just be delay followed by trying some other server, or retrying through a proxy, or otherwise circumventing what will look to DNSSEC like just another broken hotel or coffee shop wireless network.

In summary, REFUSED doesn’t mean what supporters of SOPA and PIPA want it to mean and no amount of new law can change that. There is in fact no signal in DNS that conveys the meaning of SOPA and PIPA, and every protocol perturbation thus far suggested by the supporters of SOPA and PIPA will look to DNSSEC like an attack or failure requiring circumvention. I urge anyone interested in adding new signals to DNS to please participate in the Internet Engineering Task Force (IETF) to work on a new Internet RFC document on this topic. As an open and transparent peer driven engineering forum, the IETF is ideally placed to study this problem, determine whether a solution is possible, and standardize such a solution for use on the global Internet.