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

Vernon Schryver <> Fri, 06 October 2017 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AC6E134C88 for <>; Fri, 6 Oct 2017 13:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KLGygS_igmHL for <>; Fri, 6 Oct 2017 13:08:53 -0700 (PDT)
Received: from ( [IPv6:2001:470:4b:581::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79D8F134C84 for <>; Fri, 6 Oct 2017 13:08:53 -0700 (PDT)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTPS id v96K8Zxc062071 ( version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <> env-from <>; Fri, 6 Oct 2017 20:08:36 GMT
Received: (from vjs@localhost) by (8.15.2/8.15.2/Submit) id v96K8Z3M062070 for; Fri, 6 Oct 2017 20:08:35 GMT
Date: Fri, 6 Oct 2017 20:08:35 GMT
From: Vernon Schryver <>
Message-Id: <>
In-Reply-To: <>
X-DCC-Rhyolite-Metrics:; whitelist
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 20:08:55 -0000

> From: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <>

> There's a functionality [1] to do all these things (and more), you
> just can't read/write complicated rules from RPC compatible format
> (DNS zone files). Feel free to contribute of course.

On the contrary, as far as I can see from the table in
none the features that originally justified RPZ are present in the
Knot mechanism.  It lacks
   - distributed, simultaneous multi-source polices
   - IP triggers
   - full client-IP triggers
   - redirecting to walled gardens
   - NSDNAME and NSIP triggers (although those were added after my
       first versions by user demand)
   - walled gardens (according to the table, but I don't understand
       how that is missing)

The Knot mechanism might be a lot better than RPZ, but it is *NOT*
RPZ.  Because it uses a different rule source-resolver protocol, it
can be neither a subset nor a superset of RPZ.  Calling it "rpz" is
like calling the ancient DEC name scheme (I've forgotten its name) or
NIS (YP) "DNS."  Those things could do things that DNS cannot do.  The
DEC protocol was arguably better all around than DNS, but it was not
DNS, no matter how often or how hard its advocates tried to sell as DNS.

One might say "it's a subset without the bits that some mistakenly
claim are important and it uses an incompatible protocol but it's still
rpz," but that would be like saying a Chevrolet Spark is a subset of
a 40 ton tractor, or vice versa.
That the Spark is more useful to more people and that most people
could not use a large tractor does not make one a subset of the
other.  They simply differ.

Again, the Knot mechanism might be better than RPZ, especially if it
were given a few of what seem to me like easy additions.  RPZ has
suffered from feaping creaturism; something simpler could be better.
But please don't call it RPZ, because it is not RPZ.

Vernon Schryver