Paul Vixie declares war on malicious domain names.

Paul Vixie has been more or less in charge of BIND development for over 20 years. He is also notable for creating the first anti-spam blacklist, the MAPS RBL, in 1997.

Although usenet and email were the first serious Internet battlegrounds, the main problem now is attacks on web browsers and their users. There have been some efforts at adding blacklists to browsers, for example Google's safe browsing list, and although modern browsers use them there are still a lot of old unsafe browsers out there.

So instead of relying on users to upgrade their browsers, another approach is to put the blacklist into the DNS resolver. This approach was pioneered by OpenDNS. Their resolvers deliberately lie to protect their users. The problem with lying resolvers is that they can also lie in unhelpful ways, the worst being typo squatting - directing the user to an ad-laden money-generating portal instead of simply saying a name doesn't exist. Even if the resolver only makes white lies, you might not want to entirely outsource your DNS resolvers just for an extra safety feature.

This week Vixie announced his solution to this problem at the Black Hat and DefCon security conferences. He has effectively specified a way that a recursive resolver can easily take a data feed of malicious domain names, for which it will either deny their existence or redirect the user to a "walled garden" web server that explains why they can't get to the web site they expected or which does more fine-grained filtering.

This is not just an attack on malicious domain names: it is also an attempt to build the foundations for a competitive market in DNS reputation providers, as there already is for email DNSBLs. Vixie also wants to allow resolvers to make "white lies" without also encouraging typo squatting and other grubby activity. He also has an eye on making this work with DNSSEC, which is designed to prevent any kind of lying.

I'm keen for this to work. I'm in favour of judicious measures that make it harder for criminals to exploit the Internet. However I'm not entirely sure that Vixie's proposal is quite right as currently specified.

"Response Policy Zones" encode two things: the list of domains that the RPZ provider says are malicious, and the kind of reply that the resolver should give when a user makes a query for one of those domains. Replies can be NXDOMAIN or NODATA resolution failures, or replacement answers that can be used to redirect the user to a walled garden.

This is different from email DNS blacklists. Existing DNSBLs are just lists of bad domains or IP addresses, possibly qualified with some information about why each item is listed. DNSBLs encode no policy: it's up to the postmaster whether to block a listed site, or give it a slightly spammier score, or anything else.

This built-in policy is probably OK if the RPZ just says the domains it lists should not exist. However in the case of a redirection, the subscriber to the RPZ is likely to want to run their own walled garden, or they may want to outsource it to someone other than the provider of the RPZ. But the RPZ fixes the target of the redirect. This niggle is acknowledged in section 4.7 of the spec but the suggested solutions aren't great.

RPZs are designed to use standard DNS distribution protocols, and these are designed to copy the data verbatim. Typical implementations do not have any hooks you can use to filter a replicated zone. The alternative of getting the provider to do the customization at their end will be expensive and clumsy.

There is another possibility, which is for redirections in the RPZ to take the form of CNAME records pointing at a magic private domain name. Each RPZ subscriber can create a local private zone containing this magic name and pointing it at whatever walled garden they wish to deploy. However it might not be possible to use this trick to turn a redirect policy into an NXDOMAIN or NODATA - the spec is unclear.

I would be happier if, like DNSBLs, the RPZ proposal left the choice of countermeasures to the subscriber, leaving RPZ providers to just list the zones they don't like.