IETF Logo Mail Archive

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

Robert Edmonds <edmonds@mycre.ws> Wed, 21 December 2016 20:37 UTC

Return-Path: <edmonds@mycre.ws>
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 04B431295FB for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 12:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, 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 sANG9RYYnVGW for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 12:37:35 -0800 (PST)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06331295A6 for <dnsop@ietf.org>; Wed, 21 Dec 2016 12:37:34 -0800 (PST)
Received: by chase.mycre.ws (Postfix, from userid 1000) id 612BB12C0EDA; Wed, 21 Dec 2016 15:37:34 -0500 (EST)
Date: Wed, 21 Dec 2016 15:37:34 -0500
From: Robert Edmonds <edmonds@mycre.ws>
To: dnsop@ietf.org
Message-ID: <20161221203734.ef4qwtd5mrgkbgyy@mycre.ws>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20161221200104.GK13486@mournblade.imrryr.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mrs9BDPfeKNPb3iax8eesfLEgv8>
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:37:36 -0000

Viktor Dukhovni wrote:
> 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 deployable–it 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?

Are you looking for RFC 2845, "Secret Key Transaction Authentication for
DNS (TSIG)"? That authenticates the transaction but the contents of the
zone is transferred in the clear. (I don't think there are any servers
that implement DNS-over-TLS for zone transfers.)

-- 
Robert Edmonds

v2.19.0 | Report a Bug | By Email