Paul Vixie and ISC have introduced patches to the latest versions of BIND to support a means to block-list malicious domains. As described in the draft specification, an organization will be able to compose a special purpose zone file, a Response Policy Zone (RPZ), upload this zone file onto a DNS resolver, and enforce how domain names are resolved by the organization's resolvers according to the policy the zone file prescribes.
The draft specification identifies four enforcement policies: return non-existent domain (NXDOMAIN), return no data, return local data (records the response policy zone administrator choose, and return an exception (process the specific queried name "normally", i.e., as if the RPZ did not exist).
Earlier today, I sent Paul an email saying:
Thank you for this, you've created an opportunity for network operators to at least raise the level of DNS policy control to what we have been struggling for 20+ years to master in firewall traffic handling, email forwarding, and application content policies.
Why am I enthused about RPZ? It adds a DNS dimension to security policy enforcement. The effect of implementing an RPZ is to a DNS resolver what configuring an access control list (ACL) is to a firewall, or what configuring allowed MIME types is to an application proxy. These are all forms of input to rules engines that perform "allow, disallow, redirect, destination unreachable/unknown" actions on traffic.
RPZ will no doubt stimulate many lively debates simply because the "P" word is present in the name. However, the RPZ patches are merely a formal specification for what many DNS and security administrators have done for years in response to threats their organizations insisted they mitigate. As recently as 2003, certain organizations considered instant messaging a threat and sought to block AIM. This was hard to do using only port numbers, so I and others encouraged administrators to configure their DNS resolvers to return localhost (127.0.0.1) as the IP address for AOL's login (OSCAR) servers (no login, no chat). As the threat landscape evolved, we recommended that DNS administrators block digital marketers, email relays, and even entire TLDs in this manner. RPZ affords organizations with a more scalable tool that can easily build policy based on reputation or block lists such as the SpamHaus DNSBL or SURBL while also allowing for local customization.
RPZ detractors argue that altering DNS resolution is navigation gamesmanship and net-nannyism and that the potential for misuse (i.e., censorship, interference with advertising and marketing) by the organization that controls the resolver(s) is high. The RPZ patches don't come with a reputation database. Every organization can choose from proven block lists or write their own. This is common practice today for many other Internet services. Localizing DNS policy may not be optimal, but managing risk associated with malicious domains has become a serious issue for many organizations. Current global policies or voluntary definition and implementation of best practices to mitigate malicious domains are not satisfying the needs of these organizations. It will be interesting to see if RPZ fills the void.
Comments