Paul Vixie Explains, In Great Detail, Why You Don't Want 'Policy Analysts' Determining DNS Rules

(Mis)Uses of Technology

from the let-the-geeks-be-geeks-please dept

There’s been plenty of talk, obviously, about the problems with SOPA and PIPA and how they treat DNS as a tool for blocking, despite the massive problems it causes for security efforts like DNSSEC. Every single working engineer who’s spoken out on this issue (that we’ve seen, at least), has made this same point. We’ve even heard from techies within the government saying the same thing. And, of course, even Comcast itself (despite supposedly being in favor of the bill) proudly admits that DNS blocking is incompatible with DNSSEC. Even as the House and Senate are trying to punt on DNS issue, they still fully expect to put it in place at a later date, so it’s important to discuss why it’s a bad, bad idea.

So far, the “pro-SOPA/PIPA” folks haven’t been able to find a legitimate working technologist who says that these plans make sense. Instead, they’ve brought out some “policy analysts” who have some basic technology background, but not a deep understanding of DNS. But, because they can toss around some tech terms, SOPA/PIPA supporters think they sound credible. However, in his latest post on the subject, Vixie walks through a step-by-step explanation for why each suggested method of DNS blocking won’t work and/or breaks DNSSEC. Basically, these “policy analysts” keep suggesting different ways that they think DNS blocking could work, and Vixie explains why they’re wrong each time, and points out the importance of actually having DNS engineers do DNS engineering — not policy analysts.

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 a 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….

And yet… it’s not being designed by DNS engineers at all. It’s being designed by policy people, with a smattering of help from some former technologists who don’t really understand DNS. That seems like a pretty big problem.

Filed Under: blocking, dns, dnssec, paul vixie, pipa, policy, protect ip, sopa, technology