IETF Logo Mail Archive

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Mark Andrews <marka@isc.org> Fri, 27 July 2018 02:33 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 D5F5712785F for <dnsop@ietfa.amsl.com>; Thu, 26 Jul 2018 19:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 xqx_rG_rJqSO for <dnsop@ietfa.amsl.com>; Thu, 26 Jul 2018 19:33:40 -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 C40C61277CC for <dnsop@ietf.org>; Thu, 26 Jul 2018 19:33:40 -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 875083AB062; Fri, 27 Jul 2018 02:33:40 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5E35B160038; Fri, 27 Jul 2018 02:33:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 42C2D160075; Fri, 27 Jul 2018 02:33:40 +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 oV1muzlV0oOE; Fri, 27 Jul 2018 02:33:40 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 649DF160038; Fri, 27 Jul 2018 02:33:39 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <FF0A0A24-705F-46E3-BF31-314078636EE2@isc.org>
Date: Fri, 27 Jul 2018 12:33:36 +1000
Cc: dnsop <dnsop@ietf.org>, mweinberg=40verisign.com@dmarc.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <84636548-60C4-40F5-8C05-E5AD70886CB4@isc.org>
References: <4DCC5A51-1AB0-47B6-92B5-79B6894F9A9C@verisign.com> <CAJE_bqcELQbQeHPvvEBHOxpRyWYL76BmT_-G4jW4pTnUUXFMUw@mail.gmail.com> <CAAObRXL2LoB3f=296ZPE1Pp1nHkG---pRPAmyO1trTROxneHDQ@mail.gmail.com> <FF0A0A24-705F-46E3-BF31-314078636EE2@isc.org>
To: Davey Song <songlinjian@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xlJqvMY3k6MH9VpBEh1LpU4-qd0>
Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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, 27 Jul 2018 02:33:43 -0000


> On 27 Jul 2018, at 12:26 pm, Mark Andrews <marka@isc.org> wrote:
> 
> 
> 
>> On 27 Jul 2018, at 12:15 pm, Davey Song <songlinjian@gmail.com> wrote:
>> 
>> 
>> - It was not really clear exactly what kind of problem this digest
>>   tries to solve, especially given that the primarily intended usage
>>   is for the root zone, which is DNSSEC-signed with NSEC. 
>> 
>> It puzzled me as well. 
>> 
>> It is said in the document that diffferent from DNSSEC (and NSEC), the zone digest is for the intergirty of unsigned NS and Glue of the zone. As I asked in IETF102: why unsigned NS and glue is worth of protecting by introducing a new RRtype, addtional complexity of degesting and validation. Is it really necessary for local resolver(or local-root) aware the integity of NS and glue?  any technical problems if the NS RR and glue are modified locally? 
> 
> The problem is that when you have every recursive server in the world with a copy of the root zone from “random places” you want to reduce the possible error spaces into manageable chunks when things go wrong which they will.  Being able to verify the contents of the root zone you have are not modified helps.
> 
> It also prevents privacy leaks to parties other than the owners of the delegated zones by ensuring the NS and glue addresses records have not been changed.  QNAME minimisation helps with the residual privacy leaks by reducing it to the child zone.

Additionally most nameservers treat zone data as fully trusted.  This is reasonable when you are getting data from a “trusted" source.  For the root zone we want servers to be able to get a copy of the zone from a untrusted / less trusted source.

>> As to the discussion of re-inventing the wheels, I mean If the problem statement of zone digest is not a significance of worthing a heavey inband approach, an lightweight and existing outband approch may be a first option to consider.. 
>> 
>> -Davey
>> _______________________________________________
>> 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
> 
> _______________________________________________
> 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