Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

Philip Homburg <pch-dnsop-3@u-1.phicoh.com> Tue, 31 July 2018 09:44 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.com>
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 BFA8A130E08 for <dnsop@ietfa.amsl.com>; Tue, 31 Jul 2018 02:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZJ0XiNn3krha for <dnsop@ietfa.amsl.com>; Tue, 31 Jul 2018 02:44:50 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 52604130E04 for <dnsop@ietf.org>; Tue, 31 Jul 2018 02:44:50 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fkRCk-0000GTC; Tue, 31 Jul 2018 11:44:34 +0200
Message-Id: <m1fkRCk-0000GTC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: Wes Hardaker <wjhns1@hardakers.net>
From: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.com
References: <CADyWQ+HizOJsE9EZ=VEvrbnnyPwaG_yBRg7fP5VvUNTdnidXZA@mail.gmail.com> <ybl4lgg6ztm.fsf@w7.hardakers.net>
In-reply-to: Your message of "Mon, 30 Jul 2018 16:58:29 -0700 ." <ybl4lgg6ztm.fsf@w7.hardakers.net>
Date: Tue, 31 Jul 2018 11:44:24 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/H47AONGdfj5B2d7N2ZQRo6fMTEY>
Subject: Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
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: Tue, 31 Jul 2018 09:44:53 -0000

> > The draft states in the Motivation section:
> >
> >     "The motivation and design of this protocol enhancement is tied to the 
> DNS root zone [InterNIC]."
> 
> That may be a motivation, but as a prospective user I want to use
> it for much more.  My LocalRoot server is already going to be
> serving 3 zones, and I have plans for many more.  It would be
> helpful to know that on the distribution side of things that I had
> indeed grabbed an authentic source before sending it off to all
> the resolvers that want to pre-cache a random zone X.
> 
> Be careful that we don't collectively interpret the sentence you
> quote as meaning 'this is only useful for the root zone' just
> because that was the original motivation.

I think there is a big difference between distributing the root zone and
distributing a few 'local' zones.

In the first case you need something that is massively scalable.

In the second case, just create a tar file with a zone file and a hash, put
it up on a web server and the problem is solved. Verifying the contents of a
file is not exactly a new problem. 

I wonder if there still is a use case for distributing the root zone. With
QNAME minimization and NXDOMAIN based on NSEC records, the major use cases
seem to be gone. Compared to other zones, the root is massively over
provisioned. So if (from an availability point of view) there is need to have
a local copy of the root, then you would need a local copy of .com as well.

Though I'm sure that are people who want to reinvent DNSSEC.

One final remark, maybe it is worth investigating a 'NSDEL' record type,
and possibly 'ADEL' and 'AAAADEL'. Which are the equivalents of NS, A, AAAA
for delegations/glue. With separate record types, we can define that they are
covered by a RRSIG. Solving issues with data not being signed.