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

Mark Andrews <marka@isc.org> Fri, 27 July 2018 03:07 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 48C1712785F for <dnsop@ietfa.amsl.com>; Thu, 26 Jul 2018 20:07:22 -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=unavailable 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 3dnOVrWM94mq for <dnsop@ietfa.amsl.com>; Thu, 26 Jul 2018 20:07:20 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 0D00B124C04 for <dnsop@ietf.org>; Thu, 26 Jul 2018 20:07:20 -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 3E1D73AB065; Fri, 27 Jul 2018 03:07:19 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1C66E160038; Fri, 27 Jul 2018 03:06:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 02570160068; Fri, 27 Jul 2018 03:06:49 +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 knLwsM2V-OyK; Fri, 27 Jul 2018 03:06:48 +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 E7902160038; Fri, 27 Jul 2018 03:06:47 +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: <B795E43C-E0A1-4965-995B-BD50606DCEB2@shinkuro.com>
Date: Fri, 27 Jul 2018 13:06:45 +1000
Cc: Davey Song <songlinjian@gmail.com>, dnsop <dnsop@ietf.org>, mweinberg=40verisign.com@dmarc.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9EF9C62B-896F-4A06-8C88-35D943D063DA@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> <84636548-60C4-40F5-8C05-E5AD70886CB4@isc.org> <B795E43C-E0A1-4965-995B-BD50606DCEB2@shinkuro.com>
To: Steve Crocker <steve@shinkuro.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/J2lnWgbxzMzq87pgmkaTD1OBSF0>
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 03:07:23 -0000


> On 27 Jul 2018, at 12:39 pm, Steve Crocker <steve@shinkuro.com> wrote:
> 
> The passage below puzzles me.  Why do you want servers to get the root zone from less trusted sources?

1) to spread load.
2) not all recursive servers have direct access to authoritative sources.  Some times they need to go through intermediaries.  The same will be true with transfers of the root zone.

>  And why does the source matter if the zone entries are DNSSEC-signed?

Steve please go and re-read the parts you cut out when quoting the previous message.  It gave several reasons.

Also please look at what is and isn’t signed in a zone and think about what can be done when you can change the unsigned parts.

Also think about what can be done when you change the signed parts but don’t individually verify the RRsets but rather just trust the zone content.

I have a local copy of the root zone.  It lives in a seperate view which is not accessed directly by clients  The name server validate its contents when performing recursive lookups on behalf of clients.  Such configurations are complicated and error prone.  It also doesn’t remove potential privacy leaks.

Having a way to verify the entire zone’s contents without having to verify every RRset individually after each zone transfer would make running such configurations easier.  It also removes threats that DNSSEC alone does not remove. 

> Thanks,
> 
> Steve
> 
> Sent from my iPhone
> 
>> On Jul 26, 2018, at 7:33 PM, Mark Andrews <marka@isc.org> wrote:
>> 
>> 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.

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