Re: [DNSOP] draft-ietf-dnsop-dns-rpz

Paul Vixie <> Fri, 06 October 2017 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E71281349F4 for <>; Fri, 6 Oct 2017 09:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BH_BhYyGOm5i for <>; Fri, 6 Oct 2017 09:00:58 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F7021331D9 for <>; Fri, 6 Oct 2017 09:00:58 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:d5f2:bb80:f31d:6e7f] (unknown [IPv6:2001:559:8000:c9:d5f2:bb80:f31d:6e7f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id C5FD061FA3; Fri, 6 Oct 2017 16:00:57 +0000 (UTC)
Message-ID: <>
Date: Fri, 06 Oct 2017 09:00:57 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.19 (Windows/20170908)
MIME-Version: 1.0
To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <>
CC: Vernon Schryver <>,
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Oct 2017 16:01:00 -0000

Vladimír Čunát wrote:
> Hi.
> On 10/06/2017 05:00 PM, Vernon Schryver wrote:
>> If you will include hooks for an RPZ implementation in your shipped
>> code as opposed to modified source in a 'contrib' directory that
>> users must compile specially, I'd be happy to try to propose such
>> hooks.  In other words, I could try to make a patch for Knot Resolver
>> like the patch that I wrote for Unbound (without cost to NLnet Labs).
>> If you prefer, you could write the code.
> The current very limited implementation of RPZ in knot-resolver [1] is
> done via a couple dozen lines of lua code, i.e. only JIT-compiled.  The
> approach might remain similar, perhaps a bit more modularized, but in
> any case I expect it would be included by default, so I wouldn't fear
> about users having to recompile.

let me clarify. there is an rpz implementation for bind9 and unbound 
which is mostly outside the server itself. so, it's a duplication of 
effort for bind9, which has its own internal implementation of rpz, but 
it's new functionality for unbound, which does not have rpz built in.

this rpz implementation consists of a daemon, a command line tool, a 
shared library, and a shared memory (mmap'd file) segment. the api for 
the shared library is meant to be not just name server implementation 
(thus, it works on bind9 and unbound), but also policy implementation 
(thus, it could work for a policy system other than rpz, though we've 
not tested it.)

the implementation we have (farsight security) is not open source, but, 
the API is entirely unencumbered. thus, someone other than us could 
implement a shared library and associated software that spoke to this 
API and could be dynamically loaded by bind9, unbound, and any other 
impementation of that API.

patches to make knot-recursive speak this API are what vernon offered. 
those patches, like the API it speaks to, are entirely unencumbered, and 
would therefore be compatible with your license. in fact the patches to 
make knot-recursive speak to this API would be donated to you and would 
become your property and would have only your license.

farsight's implementation of this API is called fastrpz. we don't give 
it away to the whole community; only to people who operate passive dns 
sensors for SIE. we fully expect to see fully open source competitors 
for our implementation of this API from other members of the community 
in the fullness of time.

the API now has a name, the response policy service (RPS).

please contact vernon directly if you'd be willing to accept a donation 
of patches to make knot-resolver able to call the RPS API, and thus, 
able to dynamically load any shared library that implements the RPS API.

please contact me directly if any of you would be willing to operate a 
passive DNS sensor for SIE, in exchange for a right-to-use license for 
the fastrpz implementation of the RPS API, or perhaps data trades &etc.

P Vixie