Home / Blogs

Refusing REFUSED

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.

By Paul Vixie, VP and Distinguished Engineer, AWS Security

Dr. Paul Vixie is the CEO of Farsight Security. He previously served as President, Chairman and Founder of Internet Systems Consortium (ISC), as President of MAPS, PAIX and MIBH, as CTO of Abovenet/MFN, and on the board of several for-profit and non-profit companies. He served on the ARIN Board of Trustees from 2005 to 2013, and as Chairman in 2008 and 2009. Vixie is a founding member of ICANN Root Server System Advisory Committee (RSSAC) and ICANN Security and Stability Advisory Committee (SSAC).

Visit Page

Filed Under


Which Paul Vixie do we believe? John Erickson  –  Jan 13, 2012 4:01 AM

Which Paul Vixie do we believe?  Previously you stated, “We need informed debate on the question of mandated ‘DNS blocking’ but we should be true to the facts and the details. Secure DNS and ‘DNS blocking’ are ships in the night at the moment and whenever the goal of ‘DNS blocking’ is merely domain name disappearance and not content insertion then ‘DNS blocking’ will not break Secure DNS or even slow it down.”  So, do we believe the Paul Vixie who was concerned about “being true to the facts and details,” who said something totally inconsistent with this post, or do we believe the Paul Vixie that posted above?

If DNS blocking “breaks the Internet” why are you selling a functionality (DNS RPZ) that provides for DNS blocking? 

How do you intend to engage in DNS filtering under RPZ after DNSSEC is rolled out?  If, per this post, you can’t anymore, have you been telling your customers that you are selling them something that slows down DNSSEC deployment and will not be usable after DNSSEC has been fully deployed?   

Other DNS blocking services are widely used now to stop people from visiting malware sites.  Are you saying this important cyber security tool will no longer be possible after DNSSEC? 

OpenDNS has said they can still provide their DNS blocking product after the full rollout of DNSSEC—either they’re not being accurate or your not.  Which is it?

The question is whose interests are being protected. Phillip Hallam-Baker  –  Jan 18, 2012 11:17 PM

I really don't see passage of PIPA/SOPA this session as being very likely. With such enormous corporate interests stacked up in its favor the most likely outcome is the rent seekers will find some way to avoid passing the bill this time round so that they can collect a new set of contributions (i.e. bribes) in the next Congress. Even should the bill pass there will be a four year cycle between enactment and deployment of a new bill to deal with the last iteration. At the moment the technique of domain name blocking is used almost exclusively to protect the end user. Protecting the interests of Rupert Murdoch and his gang is not on their agenda. The measures proposed are intentionally designed to allow large corporations to censor small ones without any effective legal recourse. So it is really rather unlikely that end users will be interested in being controlled in the manner that SOPA/PIPA attempts. As a thought experiment, consider what happens if the DNS protocol is expanded to add a new response 'censored'. It is pretty obvious that people would be using applications that caused an automatic redirect of the query to another server in this case. As I have pointed out before, there is no real leverage in coercing ICANN either. If ICANN is coerced we will see ICANN replaced. The US Congress does not have the leverage it imagines it has here.

On Belief, DNS RPZ, and OpenDNS Paul Vixie  –  Jan 14, 2012 11:56 PM

As to belief:

I’ve always thought that good ideas were more compelling than famous people. It doesn’t matter “which Paul Vixie” you believe, only that if you hear truth you recognize it and act on it, no matter where you heard it or from whom. I hope that readers of the article quoted in the above comment will also read the followup where I explain as follows:

Anything we create that can bypass the restrictions of stupid hotel room middleboxes will also trivially bypass anything like COICA anywhere in the world. Since no responsible application designer will code “or else just break the law” into their product, something like COICA could stalemate the market’s movement toward DNSSEC.

I think that interested readers can discern for themselves where the truth is here, regardless of whether the speaker is me or whether my later observations are informed by my earlier observations.

As to RPZ:

If DNS blocking “breaks the Internet” why are you selling a functionality (DNS RPZ) that provides for DNS blocking?

Sometimes I really do wish we (Internet Systems Consortium, the home of BIND and other Internet infrastructure technologies) were selling our software. If ISC had a dollar for every computer that ever ran our free software, then I would probably have a bit less fund raising to do. So, when you say “sell” you pique my curiousity—do you not know that ISC’s BIND software which runs 85% of the world’s name servers is absolutely free to use and/or redistribute?

The reasons why ISC invented DNS RPZ and implemented it in our free BIND software have been explained elsewhere but as they relate to mandated DNS blocking I recommend reading my article on alignment of interests as well.

How do you intend to engage in DNS filtering under RPZ after DNSSEC is rolled out?  If, per this post, you can’t anymore, have you been telling your customers that you are selling them something that slows down DNSSEC deployment and will not be usable after DNSSEC has been fully deployed?

The free and unencumbered DNS RPZ technology as implemented in the free and unencumbered BIND software currently gives DNSSEC a get-out-of-jail-free card. We know that this is a problem, since when a signed domain is accessed by a secure validator then we currently have no way to override the response. notedly there are very few signed domains and even fewer secure validators at the moment.

Before we get to the point where DNSSEC actually and operationally frustrates the policy needs of a domain name system operator I expect to propose a new RFC on this topic. My approach will be that DNSSEC name servers will continue to speak truth, and will also speak of the relevant policy in case the secure validator finds it useful. I do want secure validators whose users’ interests are aligned with the interests of their name server operators to be able to voluntarily accept policy as a value added service. That’s very different from “mandated” filtering, since an end user would have to deliberately opt-in to such policy, and would do so only if they thought that the name server’s policy was helpful (like stopping spam or malware).

Other DNS blocking services are widely used now to stop people from visiting malware sites.  Are you saying this important cyber security tool will no longer be possible after DNSSEC?

No. See above. Also, the DNS blocking services you’re talking about are most often web URL blocking services (sometimes called “nannyware”) installed by an end user on their own computer, not “provider in the middle” attacks on the DNS, mandated by law, enforced by an ISP. If you conflate these things you will end in confusion.

As to OpenDNS:

OpenDNS has said they can still provide their DNS blocking product after the full rollout of DNSSEC — either they’re not being accurate or your not.  Which is it?

I would have to see and study their specific technical proposal before I could tell you whether I think it will work.

In conclusion:

Thanks for your questions, they’re quite illuminative.


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global


Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix


Sponsored byVerisign

Domain Names

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API