IETF Logo Mail Archive

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Mark Andrews <marka@isc.org> Tue, 15 August 2017 07:08 UTC

Return-Path: <marka@isc.org>
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 D298E13250C for <dnsop@ietfa.amsl.com>; Tue, 15 Aug 2017 00:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 rvZOghNKJ8m2 for <dnsop@ietfa.amsl.com>; Tue, 15 Aug 2017 00:07:59 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 8715613250B for <dnsop@ietf.org>; Tue, 15 Aug 2017 00:07:59 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 17CC734C21D; Tue, 15 Aug 2017 07:07:57 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 08146160067; Tue, 15 Aug 2017 07:07:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E99EE160070; Tue, 15 Aug 2017 07:07:56 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y1MQrxj43qL6; Tue, 15 Aug 2017 07:07:56 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A8E34160067; Tue, 15 Aug 2017 07:07:56 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B1E1182668F1; Tue, 15 Aug 2017 17:07:54 +1000 (AEST)
To: Vernon Schryver <vjs@rhyolite.com>
Cc: dnsop@ietf.org
From: Mark Andrews <marka@isc.org>
References: <201708150651.v7F6ptN7005525@calcite.rhyolite.com>
In-reply-to: Your message of "Tue, 15 Aug 2017 06:51:55 +0000." <201708150651.v7F6ptN7005525@calcite.rhyolite.com>
Date: Tue, 15 Aug 2017 17:07:54 +1000
Message-Id: <20170815070754.B1E1182668F1@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WBqEEigxi_GjZjb9inY7HxqqUDo>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
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: Tue, 15 Aug 2017 07:08:01 -0000

In message <201708150651.v7F6ptN7005525@calcite.rhyolite.com>, Vernon Schryver 
writes:
> ] From: Mark Andrews <marka@isc.org>
> 
> ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
> ] DNSSEC.

I should have been more precise RPZ breaks DNSSEC for down stream
validators if it modifies responses from signed zones.  RPZ
implementations can be configured to do this.

> I describe the same facts as the opposite, as "either DNSSEC breaks RPZ
> or DNSSEC and RPZ work together perfectly well"  (in either case,
> assuming a trusted path such as (trusted) localhost name or 127.0.0.1
> address to a trusted resolver, where "trusted resolver" includes
> "trusted to rewrite."  Of course, without a trusted path to a trusted
> resolver or a verifying stub, DNSSEC doesn't mean much.)
> 
> As Mark Andrews understands but many people don't, the common RPZ
> implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks
> DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast
> that RPZ invalidates and removes signatures and so verifying stubbs
> and verifying downstream resolvers will not accept rewritten answers."
> 
> Also, in the two RPZ implementations I've written, the default
> BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ.
> 
> 
> Vernon Schryver    vjs@rhyolite.com
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email