IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Wed, 21 December 2016 20:36 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 EEA301295AE for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 12:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-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 BPLcTIL30V1M for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 12:36:50 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (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 0DFD01295C5 for <dnsop@ietf.org>; Wed, 21 Dec 2016 12:36:50 -0800 (PST)
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.ams1.isc.org (Postfix) with ESMTPS id 7942E1FCACC for <dnsop@ietf.org>; Wed, 21 Dec 2016 20:36:46 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2EAAC160054 for <dnsop@ietf.org>; Wed, 21 Dec 2016 20:36:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 152EE16006F for <dnsop@ietf.org>; Wed, 21 Dec 2016 20:36:45 +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 fcSO6GBjmwwe for <dnsop@ietf.org>; Wed, 21 Dec 2016 20:36:45 +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 ACA39160054 for <dnsop@ietf.org>; Wed, 21 Dec 2016 20:36:44 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A08F15D405ED for <dnsop@ietf.org>; Thu, 22 Dec 2016 07:36:40 +1100 (EST)
To: dnsop@ietf.org
From: Mark Andrews <marka@isc.org>
References: <C18E2D4E-EE89-4AF6-B4A0-FAD1A7A01B5E@vpnc.org> <5248A099-7E1F-437A-A1B7-C300F917D273@fl1ger.de> <CACfw2hj4VfuqsM-jRpxNc+bWNsUcSid+Y=r9U5jsA-0ZLbLRUg@mail.gmail.com> <20161221.163826.74705202.sthaug@nethelp.no> <alpine.LRH.2.20.1612211047200.13966@bofh.nohats.ca> <CAAiTEH_-LGUkpmPjDRsKpnPhXev1sNdF_2yaVXKmeWMJ7vm_eg@mail.gmail.com> <6C982A3A-721C-4094-A04F-059698581321@fugue.com> <CAAiTEH_LOUhCSRuDNggTK9f1iWw6dCQB2bJQ7FVyYn3MH49KUQ@mail.gmail.com> <20161221200104.GK13486@mournblade.imrryr.org>
In-reply-to: Your message of "Wed, 21 Dec 2016 20:01:04 -0000." <20161221200104.GK13486@mournblade.imrryr.org>
Date: Thu, 22 Dec 2016 07:36:40 +1100
Message-Id: <20161221203640.A08F15D405ED@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CLI-onxPbwJuYhmrGCnRQ-UZjbM>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
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: Wed, 21 Dec 2016 20:36:52 -0000

In message <20161221200104.GK13486@mournblade.imrryr.org>, Viktor Dukhovni writes:
> On Wed, Dec 21, 2016 at 12:39:55PM -0500, Matthew Pounsett wrote:
>
> > RPZ is not the ideal, but it works, and goes beyond being deployableit
> is
> > deployed.
>
> I am curious to understand how RPZ zone transfers are (intended to
> be) secured.  It sounds like the reason for standardizing RPZ is
> to allow interoperable sharing of policies via replication of zone
> data, and so an appropriate security mechanism would seem to be
> desirable here to authenticate the transfer of data from the RPZ
> master zone.  Is there a related specification for that?

The are just zones.  You secure them the way you secure any other
zone transfer.  Just because they contain RPZ data doesn't make
them any different.  You setup a account with a provider and use
TSIG.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.30.2 | Report a Bug | By Email | System Status