Re: [DNSOP] adoption mechanics and disclaimers wrt dns-rpz

[Paul Vixie <[e-mail]>]

fwiw, here is the text of an RPZ brief provided to the ICANN TEG in the recent 
copenhagen meeting. the text was edited by me, and all errors or omissions are 
mine:

> What are Response Policy Zones (RPZ)?
> 
> A Response Policy Zone (RPZ) is a way to convey DNS resolution policy
> from a security provider to a security customer. The RPZ format can
> identify DNS content by name, or by name server, or by resulting IP
> address; and it can be used to prevent a DNS resolver from reaching the
> DNS content in question, either fully, or indirectly via a honeypot or
> walled garden. Like all so-called "DNS firewalls", the use of RPZ is
> optional, and must be seen by its customers as a value-add, or else it
> will not be used. RPZ was originally prototyped in the ISC BIND9 name
> server, but has since become generally available.
> 
> Fundamentally, an RPZ is a set of rules that directs a recursive name
> server how to act if the answer to a query it resolves matches one of
> the rules in the RPZ. There are different kinds of matches that cause
> the recursive server to take different actions when a match occurs.
> The overall goal of an RPZ is to avoid interacting with certain domains,
> name server, or DNS results such as IP addresses depending on the purpose
> or policy associated with the RPZ. For example, an RPZ could implement
> a policy against visiting malicious domains (such as malware sites,
> phishing sites, etc.) to protect users.
> 
> An ingenious feature of RPZ is that the policy rules themselves are
> actually encoded as standard DNS resource records in a standard DNS zone
> (hence the word "zone" in the name). Since RPZs are normal DNS zones, they
> can be easily distributed using the standard DNS zone transfer protocol,
> which moves a DNS zone from one name server to another. In the typical
> configuration, a recursive name server operating wanting to implement a
> particular policy "subscribes" to a particular RPZ offered by their own
> security team or by an external security provider. The recursive server
> obtains the RPZ using a standard DNS zone transfer from an authoritative
> server operated by the provider. Notably, the RPZ information is not
> intended for direct lookup or consumption by users. Rather, a recursive
> server internally looks up record-sets in an RPZ to direct how it should
> deal with responses it receives during its normal resolution process.
> 
> To offer a specific example, Farsight Security offers an RPZ that
> contains newly observed domains. The theory behind this particular RPZ
> is that phishing sites and malware often use newly registered domains,
> since these domains have a very low probability of already being tagged as
> malicious in various security intelligence services. Once configured with
> this RPZ, a recursive server will effectively refuse to resolve any newly
> observed domains until an incubation period has passed, ensuring that
> users of that recursive server will be protected from these new sites
> long enough to give other reputation services, and takedown services,
> enough time to complete their work. Any connotation of "dangerous" with
> "newly observed" would have to exist in the eye of the resolver operator,
> and is purely subjective.
> 
> Recursive name server implementations that offer RPZ support include
> BIND 9 (Internet Software Consortium), Knot Resolver (cz.nic), PowerDNS
> Recursor (PowerDNS), and FastRPZ (a product of Farsight Security
> that operates with ISC BIND9 and NLNetLabs Unbound).  About a dozen
> RPZ-format security feeds are currently available, some commercial,
> some free. The list of implementations and providers can be found at
> https://dnsrpz.info/.