At the end of July, Paul Vixie wrote a post entitled Taking Back the DNS wherein he proposed the use of a new technology called the Response Policy Zone, or RPZ (you can read the current draft here, it’s rather implementation specific).
The RPZ is essentially a DNSBL at the routing layer for Internet traffic. The way a typical IP blocklist in a DNSBL is that you analyze the incoming IP address that is sending sending the email. If it is on the DNSBL, then mail from the IP address is rejected. To simplify the RPZ concept, if a request for a particular domain resolves to an A-record that is listed in a known list of bad or abusive IP space, then the DNS resolver can deny the request. That’s not quite how it works according to the spec but that is the general flow.
Example) Internet browser wants to navigate to http://my_abusive_url.com. This domain resolves to the IP address 218.104.22.168. The web browser asks his DNS server to get the A-record for that domain who contacts the name server. The name server looks it up and responds with the correct IP addresses. The DNS server sees that this IP is in a blocklist and refuses to resolve the domain my_abusive_url.com. The user is unable to browse to the web page. Again, this is vastly oversimplified but the net effect is that traffic to abusive locations is disallowed.
You might be wondering how this is any different than, say, Internet Explorer 8 or Firefox 3 which already have a list of known bad URLs which prevent the user from navigating to them. The main difference is that this is done at the DNS layer. Rather than the user having to upgrade his web browser (and 1/6 users are still on IE 6 for some reason) to take advantage of this type of protection, instead the ISP can implement this technology. They don’t need to wait upon user behavior to run the latest and greatest security patches. Instead, they can preempt their user base entirely and prevent any of them from attempting to inadvertently connect to malicious locations on the Internet. It is a technology aimed for ISPs, rather than technology aimed at end users. This major difference has the potential to have greater impact on the problem of botnets than most users’ upgrading to new browsers.
Another difference is that not all Internet traffic that connects to botnets is done through the web browser. Indeed, most bots run silently in the background. Using the RPZ, an ISP could disallow 100% of traffic intended for a malicious destination rather than limiting the scope of prevention to the user’s browsing session. In this mechanism, they are now not only preventing browsing to malicious sites, but have also extended the scope of the coverage to prevent communication to whatever source the bot is trying to communicate with. So, if a bot is in the background trying to do something nefarious like capture keystrokes (username and password combinations) and transmit that back to the bot herder, an ISP at the DNS layer can prevent that communication from taking place.
Like anything, the RPZ cannot be intended to be a catch-all for the problem of cyber crime. However, it is another arrow in the quiver that ISPs can use to combat the malicious actors and disrupt their cost model.