When you are connected to a network (Internet or private), your TCP/IP stack must know which DNS server(s) use to resolve host names into IP addresses.
For a while, publicly alternative DNS servers – like OpenDNS or Google DNS – implemented a blacklist protection mechanism. If a domain is suspected of delivering malicious content such as malwares, those services redirect you to special warning pages or alternative sites. This action is performed at DNS level. Basically, it’s a good initiative but some problems may arise.
First, DNS is a critical service on your network. Can you really trust an external server? By using an external DNS server, you allow 3rd parties to redirect your traffic to unwanted servers. Second, in a corporate environment, it is normally not permitted to use external DNS servers. Finally, you maybe don’t need a full bullet-proof blacklist but you just need a quick way to block malicious or unwanted sites.
Why not implement a home-made solution? If you operate your own DNS servers, ISC announced a solution for you: DNS RPZ or “Response Policy Zone“. How does it work? If you maintain a Bind server to perform recursive queries, it may be configured with a rule to forbid specific domain name (it won’t resolve them). The goal is to link your DNS with a good reputation provider which will provide the rules. The support of RPZ is provided for Bind 9 via a patch. Once patched, your Bind will recognize the new option called “response-policy”:
options {
// Enable RPZ
response-policy { zone "rpz.provider.com"; };
};
Honestly, if you get Response Policy Zones from an external partner, you don’t solve the trust issue explained above, you just moved it! But those zones are transferred like any zone using standard protocols (AXFR). It could be possible to review them.
RPZ is not a brand new blacklist technology. To prevent users to visit some sites for multiple reasons (corporate policy, malware protection, children protection, …), two methods are used: at application level (via a proxy + content filtering) or at DNS level. RPZ can be an interesting in this case with a reduced time to implement a new blacklist entries. It will also consume less resources.
Finally, don’t forget that RPZ could be used at the 8st layer of the ISO model: the “political layer“. Censorship could easily occur with RPZ implemented in ISP’s or Government name servers!
RPZ is a larger step in fighting spam that most people realize providing your DNS provider signs up.
Perhaps it will just be a method to get people to switch to reputable/response DNS service provers like opendns… although googledns only offers to be fast and actually promises that it won’t selectively exclude or filter entries… so googledns may still continue to serve malware hosting dns unlike opendns and unlike countless other dns services if only they are willing to subscribe to “rpz spamhaus” or “rpz surbl” commercial services.
RBL in the mail world works because there are free services including services from spamaus and surbl.
It’s close to a year later and Bind 9.8.0 has RPZ integrated so this option is no longer a separate patch.
Rereading this article I’ll comment on the final line and refer to the second line so if there is a government entity that would try to impose some restrictions (per final line), already there are services like opendns and googledns (per second line) that circumvent their dns.
RPZ isn’t a method for censorship as consumers have the option of choosing and configuring whichever DNS service provider they choose…
Ultimately a user can host their own DNS and totally avoid RPZ.
RPZ is not a means of censorship… governments and other bodies will take larger more significant steps to actually sensor users so that a user couldn’t simply change their DNS or have their own local service.