Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

Tony Finch <dot@dotat.at> Sun, 18 December 2016 19:59 UTC

Return-Path: <dot@dotat.at>
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 255B4129673 for <dnsop@ietfa.amsl.com>; Sun, 18 Dec 2016 11:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.com
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 mLj40xzsKMpz for <dnsop@ietfa.amsl.com>; Sun, 18 Dec 2016 11:59:45 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7B1129411 for <dnsop@ietf.org>; Sun, 18 Dec 2016 11:59:45 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C03D6206AA; Sun, 18 Dec 2016 14:59:44 -0500 (EST)
Received: from web1 ([10.202.2.211]) by compute4.internal (MEProxy); Sun, 18 Dec 2016 14:59:44 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=59 c49c273bwP7K96Hgf5W9x9exY=; b=SZLX2EdYVTcLyvbSXVdYxNrwMaRKzha7Nr AP2LsTG4lx7aFBLXK+wklBuiXq9FWsrZ3Unp/tksmcN8O6GqR2OGBeW50OTGExQE wKHi9c77aYDb+7jg9DYV7MtatJMrWHBvsKWNTcS9GIlF4GkgwzRwdqvSuvLJHx6f XObStOcqE=
X-ME-Sender: <xms:sOpWWBinpEOESTrtcfJRX6IfvqSjwtXhOkUZ2Tz7fFXQe7dF_42GIQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id A0003AA6C5; Sun, 18 Dec 2016 14:59:44 -0500 (EST)
Message-Id: <1482091184.4026817.822869193.1FAC8153@webmail.messagingengine.com>
From: Tony Finch <dot@dotat.at>
To: Scott Schmit <i.grok@comcast.net>, dnsop@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_148209118440268170"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-85983a1c
Date: Sun, 18 Dec 2016 19:59:44 +0000
References: <148192523291.14691.3300133966679345337.idtracker@ietfa.amsl.com> <20161217184006.GB4916@odin.ULTHAR.us>
In-Reply-To: <20161217184006.GB4916@odin.ULTHAR.us>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/S6Yh93eSQHAVp8RvhNPc4hOxKQ4>
Subject: Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 18 Dec 2016 19:59:47 -0000

Scott Schmit <i.grok@comcast.net> wrote:

>

> This doesn't magically make it possible for this DNS firewall to forge
> DNSSEC-signed data, so if a validating end-system is going to have its
> behavior modified, it would need to opt in.  



That's not entirely true. An RPZ setup can lie regardless of whether a
client appears to be validating or not. If the admin's goal is to block
access to malicious sites, then a validating client will get a bogus
result or SERVFAIL, and the site will be blocked as intended.


> But it looks like the contents of this zone are intended to be kept

> secret from end-users. 



That depends entirely on the zone maintainer's policy. The admin can
easily allow clients to query or transfer an RPZ, and/or provide out of
band information about the zone on its web site.


> So this, if implemented, is ultimately a DNSSEC-killer.



I don't think so.



DNSSEC is not able to improve the availability of the DNS. The point of
DNSSEC is to ensure that if you get an answer, you can be sure it is
authentic. If your local network wants to prevent you from accessing a
malicious site, DNSSEC can't stop them.


Tony.

--

f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--
  zr8h punycode