The very next article reminded me - too late, since I'd neglected to put it in my calendar - about a webinar on the topic of "BIND's New Security Feature: DNSRPZ". I wish I'd remembered the date, but there should be a recorded version on the website soon.
On the surface these topics may appear unrelated. RPZ, or Response Policy Zones, is an ISC-developed concept, enabling recursive resolvers to intentionally block or rewrite DNS responses for specific queries, in the name of protecting clients from malware download sites, compromised web pages, botnet command and control hosts, etc. Such things have been done for a long time; my personal resolver used to have a blackhole zone in order to block a set of particularly annoying online ad providers. I stopped when the that machine began to serve other users, since I didn't think that it was right to impose my judgements about those ad providers on anyone else. It's possible they would have thanked me for saving them from yet another flashing box advertising miracle wrinkle cream, but it still seemed wrong.
RPZ implements the same thing in a much more scalable way because it uses the built-in DNS zone transfer capabilities, including incremental transfers that only propagate the changed records. A DNS 'reputation provider' can make an RPZ zone available for transfer and update hundreds of other servers with minimal bandwidth. In principle this isn't much different from what I do now with spam blocklists - my spam filter queries a blocklist to ask for a reputation score, and decides how to handle the email appropriately (or whether to even accept the message in the first place). RPZ could fill the same role and extend well beyond it. Then again, we might imagine ISPs deciding they don't want their users to see the websites of their competitors, or reaching services that place a high bandwidth load on their backbone (not that anyone has ever threatened that sort of thing).
PROTECT-IP, on the other hand, is all about allowing the courts to block access to websites involved in copyright violations. It's particularly designed to apply to DNS names registered outside the US, since anything in-country can simply be seized by the government. The proposed law would affect financial services providers, search engines and online advertising services, but the key item for ISPs is here:
An operator of a nonauthoritative domain name system server shall take the least burdensome technically feasible and reasonable measures designed to prevent the domain name described in the order from resolving to that domain name's Internet protocol address. . .In other words, the court would require US-based ISPs to rewrite DNS responses for specific queries, in the name of preventing clients from accessing copyright-infringing sites.
Does that sound familiar?
Mind you, I feel the cognitive dissonance - I don't really like the idea of PROTECT-IP, but I actively use spam reputation services and rely on them to determine whether I should accept email. I know people use manually configured DNS blocklists and I'm sure that they do good work with them, protecting their users from all sorts of badness. Were I responsible for a large number of potentially vulnerable hosts, I might do the very same thing.
It's worth noting that both RPZ and the more general concept in the PROTECT-IP bill share another problem - they will utterly break DNSSEC validation. That's okay as long as the goal is to make sure that nobody can access www.somereallybadsite.com; it doesn't work at all when the idea is to redirect the user to a page indicating why this action has been taken (or even stating that an action has been taken). The authors of the PROTECT-IP white paper cover that quite well:
By mandating redirection, PROTECT IP would require and legitimize the very behavior DNSSEC is designed to detect and suppress. Replacing responses with pointers to other resources, as PROTECT IP would require, is fundamentally incompatible with end-to-end DNSSEC. Quite simply, a DNSSEC-enabled browser or other application cannot accept an unsigned response; doing so would defeat the purpose of secure DNS. Consistent with DNSSEC, the nameserver charged with retrieving responses to a user’s DNSSEC queries cannot sign any alternate response in any manner that would enable it to validate a query.So, what are we left with? Perhaps we can say that RPZ might or might not be a good idea depending on how it's used, but if so, then surely PROTECT-IP is in the same category. Both of them break DNSSEC, because both of them break the DNS. Is one a way to protect users and the other an example of censorship? Is one more likely to be abused than the other? Is one good and the other evil?
Bill, great article! Two important reasons why RPZ could not be used to implement PROTECT-IP are: (1) RPZ stands aside whenever it sees a DNSSEC-aware client trying to access DNSSEC-signed data; and (2) the use of a filtering name server is voluntary -- any user who does not want the filtering will just pick a different name server. As to your question, voluntary filtering is never evil, whereas mandated filtering certainly can be evil.
ReplyDeleteMore online at http://www.circleid.com/posts/20110723_alignment_of_interests_in_dns_blocking/
Sorry for the late response - I'm obviously not doing a very good job keeping up with this blog ;) I agree that tools aren't inherently bad or good, and certainly RPZ seems to have been implemented in a thoughtful fashion. Much more so than the mandates in PROTECT-IP.
ReplyDeleteI wonder, though, whether you'll eventually be asked to install a switch for RPZ's DNSSEC behavior. I haven't had time to test this theory yet, but I expect that a query with DO=1 and any answer with an RRSIG will need to bypass RPZ - even if there's no chain of trust to the signature. Otherwise a DNSSEC-capable client behind an RPZ resolver would be unable to have its own trust anchors. In a possible future where many DNS clients are attempting their own DNSSEC validation, all a malefactor would need is an isolated signed zone to avoid RPZ enforcement. Since I've already heard some evidence of spammers signing their emails with DKIM in order to try to avoid naive filters, a signed zone to avoid RPZ seems like a small step.
It seem as though that's a natural outcome of DNSSEC deployment - nobody is allowed to lie about the DNS, regardless of their good intentions. Is there a way around that, one that doesn't harm DNSSEC?