[dns-operations] DNS RPS (response policy service) API
paul at redbarn.org
Fri Oct 20 15:54:34 UTC 2017
hello campers. in the release notes for BIND9 9.12.0B1, we see
> 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
> 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]
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.
More information about the dns-operations