Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Vernon Schryver <vjs@rhyolite.com> Fri, 17 March 2017 20:48 UTC

Return-Path: <vjs@rhyolite.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A991292F5 for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 13:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCoiUhzxcr5P for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 13:48:34 -0700 (PDT)
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0EE126D85 for <dnsop@ietf.org>; Fri, 17 Mar 2017 13:48:34 -0700 (PDT)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v2HKmI3A009913 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org> env-from <vjs@rhyolite.com>; Fri, 17 Mar 2017 20:48:18 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v2HKmITR009912 for dnsop@ietf.org; Fri, 17 Mar 2017 20:48:18 GMT
Date: Fri, 17 Mar 2017 20:48:18 +0000
From: Vernon Schryver <vjs@rhyolite.com>
Message-Id: <201703172048.v2HKmITR009912@calcite.rhyolite.com>
To: dnsop@ietf.org
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/D99-0gKT7d_2Sp9uOjADx8SDwG0>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Mar 2017 20:48:36 -0000

> > > I have proposed a method that would not change the RPZ response for a
> > > non-DNSSEC client, but would add data for DNSSEC capable clients to be

I forgot to mention what I think is a completely upward compatible
"fix" for RPZ+DNSSEC that requires no protocol or implementation changes
anywhere and little installation work.  In cartoon form, it is
"If RPZ+DNSSEC hurts, then stop doing that."

In other words, if your DNS clients verify and if they don't want to
deny themselves answers when their resolver lies, then switch to a DNS
resolver without RPZ on another IP address or port number.  If your
resolver uses BIND9, then it could switch selected clients to an honest
view (not using RPZ) on port 53 and its current IP addresses based on
client IP address or TSIG key.

This is all yet another way of saying that if changes are required in
the RPZ protocol before the current Informational draft is advanced,
then it is months too early for a last call for any draft.  Calls for
RPZ protocol changes in the current draft even as small sounding as
some sort of version signaling should be treated as calls to reject
the draft.



Perhaps ISPs and anothers running open or large scale DNS resolvers
should be encouraged to provide resolvers without RPZ if they provide
resolvers with RPZ.  Because there are plenty of DNS resolver operators
(not to mention policy zone vendors) who charge for their special
policy zone recipes, this does not sound controversial.


Vernon Schryver    vjs@rhyolite.com