As a strong proponent of the private right of action for all Internet endpoints and users, I’ve long been aware of the costs in complexity and chaos of any kind of “blocking” that deliberately keeps something from working. I saw this as a founder at MAPS (Mail Abuse Prevention System LLC) back in 1997 or so when we created the first RBL (Realtime Blackhole List) to put some distributed controls in place to prevent the transmission of unwanted e-mail from low reputation Internet addresses. What we saw was that in addition to the expected costs (to spammers) and benefits (to victims) of this new technology there were unintended costs to system and network operators whose diagnostic and repair work for problems related to e-mail delivery was made more complex because of the new consideration for every trouble ticket: “was this e-mail message blocked or on purpose?”

Now that ISC (Internet System Consortium) has created DNS Response Policy Zones (see Taking Back the DNS) to bring a common interchange format and framework for putting distributed policy controls in place for DNS lookups, and now that ISC BIND9 9.8.0 has been published containing an implementation of this new technology, I’ve been pondering the possible side effects of “DNS blocking” as this kind of policy framework is sometimes called. In addition to the foreseeable complexities for system and network operators and their diagnostic workload, I envision some impact on end users and perhaps on Internet governance and policy, especially considering the possible interactions with Secure DNS. In this article I’ll briefly explain how end users will interact with Secure DNS (sometimes called DNSSEC) and on the possible ways that “DNS blocking” could affect those interactions.

Secure DNS

Briefly, Secure DNS involves signing and verifying DNS signals to prove their authenticity. The details of how this works and how to make it work are ably described in the literature so for the purpose of this article it’s enough to note that Secure DNS adds only two features to DNS and we are only able to use one of them at the moment.

The first new feature of Secure DNS is provable inauthenticity of forged DNS data and we use this today in the data path between authoritative name servers (for example the root or .COM servers) and recursive name servers (for example whatever your DHCP server told your laptop to use right now). By being able to prove that forged data is inauthentic, Secure DNS protects end users against DNS poisoning by “man in the middle” attackers. This is a good and useful feature and I’m glad we finally have it—but this feature alone would never have justified the incredible investments of time and money that have gone into the development and deployment of Secure DNS.

The second new feature of Secure DNS is provable authenticity of non-forged DNS data. We are not using this yet but it’s the real reason the DNS industry and Internet community has spent so many years and so much money developing Secure DNS. What this feature will ultimately bring us is new applications designed to behave differently in the face of provably authentic DNS data. Normal (unsecured) DNS data is inherently non-trustworthy and so no application whose needs are sensitive can afford to depend on the authenticity of data they retrieve from DNS.

Examples of “sensitive applications” are electronic banking or commerce, encrypted or signed messages, or anything else where the value of successfully poisoning or attacking DNS is higher than the (relatively low) cost of such a poisoning attack. Most current and contemplated “sensitive applications” use some other kind of security to assure themselves that the data they get from DNS does not lead them astray. Sadly, some applications which ought to worry about this kind of thing just blithely proceed and hope for the best—like when we use unsecured e-mail controlled by unsecured DNS to reset a supposedly secure web password. To open the way for new sensitive distributed applications and to better secure the sensitive distributed applications we have today, we needed Secure DNS.

But, in Secure DNS’s eventual and more important role of proving the authenticity of DNS data for sensitive applications we will need a rather large upgrade of everybody’s laptop, desktop, and mobile devices; almost every wireless or wired gateway in almost every home and in every hotel and coffee shop; and, most enterprise firewalls. This isn’t coming soon other than in isolated applications who have tricky ways to tunnel their Secure DNS needs over existing protocols, sort of like BitTorrent does for peer-to-peer file transfers. So, as important as this feature is to the eventual success and relevance (and cost justification) of Secure DNS, it is not happening at the moment and it is not imminent. That means we have to consider it in our planning but we don’t have to worry about it today.

The distinction between the role of Secure DNS in proving that forged data is inauthentic vs. its role in proving that unforged data is authentic is vital to understanding the interaction between “DNS blocking” and Secure DNS because in one case we don’t care at all and in the other case we don’t care mostly.

DNS Blocking

For the purpose of this article I’m going to distinguish among several forms of “DNS blocking” since some forms are going to interact poorly with Secure DNS while other forms will pass Secure DNS like “ships in the night”.

DNS blocking that’s done by an ISP or enterprise in order to censor content or protect end users or to insert ads into the web experience occurs between the end user’s laptop or desktop or mobile device and whatever recursive DNS server that end user is depending on. Your recursive DNS server as you read this article was most likely assigned to you by DHCP along with your IP address unless you’ve taken explicit steps to override this setting and it’s possible for the operator of your network to prevent you from successfully overriding it—which they will do if your override is costing them revenue or if their government insists. I’ll refer to these forms of “DNS blocking” which occur inside a recursive name server collectively as “below-recursive policy”.

DNS blocking that’s done by an authority server operator or by a government using deliberate DNS poisoning will happen in between an authority server and a recursive server. One could imagine a country that rewrites DNS transactions at its international borders, or that injects false IP routes for well known authority name servers thus taking over their role, or demands that all recursive name server operators in the country use a specific “alternate root” name server system whose design and configuration included various kinds of censorship and overrides. I’ll refer to these forms of “DNS blocking” which occur outside a recursive name server collectively as “above-recursive policy”.

The distinction between below-recursive policy and above-recursive policy is vital in understanding the impact of “DNS blocking” on Secure DNS since some forms of “DNS blocking” can cause problems for Secure DNS whereas other forms don’t cause any problems at all.

Interactions

Within the taxonomy now established, it’s now safe to say that most forms of above-recursive policy can be stopped or prevented or detected by Secure DNS in its mode of proving the inauthenticity of forged data. I say “most forms” because I can imagine a government requiring not only the use of an “alternate root” name server system also requiring the use of a private in-country Secure DNS key. Any situation involving an alternate root server system is outside the scope of this article.

In the more common case where the data being inserted by an above-recursive policy is not compatible with the Secure DNS key of a recursive DNS server, that data will appear to be forged and will therefore not be passed on to end users. This makes almost impossible to use above-recursive policy to send end users to “walled gardens” or other faked servers. However, if the goal of an above-recursive policy is to make some domain name unreachable, then any signal insertion or modification would achieve that goal by side effect—the result would merely be a secure failure rather than an unsecure failure. Any “DNS blocking” whose aim is to make something disappear can achieve that result no matter whether Secure DNS is in use or not. Secure DNS will change the details of the method but the end result will be the same—the domain that’s been “blocked” will in fact be unreachable.

Contrasting that we have below-recursive policy in which the recursive name server operator is deliberately telling the end user laptops and desktops and mobiles various kinds of lies in order to modify their behaviour, such as sending them to a walled garden to be told “that content has been censored for your safety” or sending them to an advertising server or sending them to a competing company. The possibilities are endless and as of today all of these possibilities are completely achievable because the end user devices aren’t doing Secure DNS yet and they are going to believe anything their recursive name server tells them. Until Secure DNS is deployed on every laptop and desktop and mobile device, all those devices will have to trust anything their recursive name servers tell them.

In the fullness of time when many end users are running Secure DNS in their laptops and desktops and mobiles then it will become impossible for a recursive name server operator or their government to insert forged data into the DNS but it will even in that case be possible to induce lookup failures. So, a below-recursive policy whose goal is to make certain domain names unreachable will always be successful no matter how completely the world deploys Secure DNS. I wish it weren’t so but if someone upstream of you can interfere with your traffic then you’ll have to use anti-censorship tools rather than Secure DNS to frustrate that interference.

COICA

I’ve been asked by several people whether ISC’s Response Policy Zone technology (referenced above) can be used to implement government mandated DNS blocking, for example to protect Hollywood against intellectual property theft or to protect children against abuse by the distribution and viewing of Child Abuse Materials or to protect a society against content deemed dangerous by its government. Sadly my answer to this is a qualified “yes.”

I say “qualified” because while I can agree that it’s worth perturbing the whole Internet ecosystem to wipe out a domain that’s being used for the distribution of Child Abuse Materials I simply cannot agree that this level of perturbation is warranted for the protection of intellectual property. One form of perturbation that I’m especially concerned about is wiping out a domain name that’s being used for both malicious and non-malicious purposes. I could imagine wiping out twitter.com or facebook.com if they were hosting Child Abuse Materials and did not respond instantly to a lawful takedown order. I can’t countenance that level of ecosystem disruption if the content in question is a copy of the latest Hollywood blockbuster movie or video game. Worriedly, I do not think that this level of fine distinction and finesse would inevitably guide the hands of governments in control of mandated “DNS blocking”.

Nevertheless the raw uncomfortable truth of the matter is that any form of mandated “DNS blocking” whose goal is to make certain domain names unreachable will be indistinguishable from the result of a Secure DNS failure—and a failure is a failure is a failure. 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.