[dns-operations] DNS RPS (response policy service) API

[Paul Vixie]

hello campers. in the release notes for BIND9 9.12.0B1, we see
this text:

> The DNS Response Policy Service (DNSRPS) API, a mechanism to allow
> named to use an external response policy provider, is now supported.
> (One example of such a provider is "FastRPZ" from Farsight Security,
> Inc.) This allows the same types of policy filtering as standard RPZ,
> but can reduce the workload for named, particularly when using large
> and frequently-updated policy zones. It also enables named to share
> response policy providers with other DNS implementations such as
> Unbound.
>
> This feature is avaiable if BIND is built with configure
> --enable-dnsrps, if a DNSRPS provider is installed, and if
> dnsrps-enable is set to "yes" in named.conf. Standard built-in RPZ is
> used otherwise.
>
> Thanks to Vernon Schryver and Farsight Security for the contribution.
> [RT #43376]

(https://kb.isc.org/article/AA-01532/81/BIND-9.12.0b1-Release-Notes.html)

i'd like to provide some background.

the DNS RPS API is open, and patches to implement it in BIND9 and 
Unbound are completely unencumbered -- donated to ISC and NLNetLabs, 
respectively, and owned by them under their own copyrights. ISC has 
integrated the DNS RPS patches in BIND9 as of 9.12.0.

because it looks self-serving for farsight to develop an API like this 
and then donate the hooks necessary to call it from popular name 
servers, i want to say: yes it will improve our business conditions, 
just as openmarket's patches to create the CGI ad-hoc standard in apache 
back in the 1990's improved their business conditions. but, we think DNS 
RPS will be, as CGI was, a rising tide that lifts all boats.

regrettably, we don't currently have a stub implementation of DNS RPS 
that we can publish as an unencumbered demo, and the DNS RPS API is 
itself not well documented outside the *.h files we donated to ISC and 
NLNetLabs. we'll improve those aspects shortly.

innovation in DNS Response Policy is vital. we can't afford to keep 
giving criminals the same great DNS service we want for non-criminals -- 
they are using our own strength against us, and that's got to stop. 
vernon schryver and paul vixie have been driving the response policy 
revolution since 2010 or so, with two related open technologies (RPZ and 
RPS) and with one related proprietary technology (FastRPZ). these should 
be understood as follows:

RPZ is an open, unencumbered publish-subscribe protocol based on 
AXFR/IXFR/NOTIFY/TSIG, that allows any number of security policy 
publishers to push DNS response policy in real time to any number of 
security policy consumers. it's implemented in BIND9 and PowerDNS, and 
there are plans to include it in Knot Recursive in the near future.

RPS is an open, unencumbered API based on the concept of "hooks" whereby 
a name server can dynamically connect, at runtime, to a local service 
that implements some kind of response policy -- for example, RPS can 
implement RPZ. not all response policy will be based on RPZ, and this 
"hook interface" will allow and encourage third-party software 
developers to create their own policy systems that might look very 
different from RPZ, and then portably implement those systems across 
multiple name servers (for example, BIND9 and Unbound, for which open, 
unencumbered RPS patches have been developed and contributed to ISC and 
NLNetLabs) using a single code base.

FastRPZ is an implementation of RPZ in the form of RPS. it offloads the 
underlying RPZ maintainance processing from the name server, allowing 
the name server to dynamically connect to FastRPZ via the RPS API. 
FastRPZ is not open source; it's available only to Passive DNS sensor 
operators who contribute their cache miss traffic to the Security 
Information Exchange (SIE). FastRPZ can be used with BIND9 natively, or 
with Unbound after installing some open, unencumbered patches to same.

it's my hope that both RPZ and RPS will evolve according to the will of 
the community. FastRPZ will track both RPZ and RPS in the future. fellow 
travelers are hereby welcomed.

-- 
P Vixie