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

Florian Weimer <fw@deneb.enyo.de> Tue, 24 July 2018 07:10 UTC

Return-Path: <fw@deneb.enyo.de>
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 1EF09130E4A for <dnsop@ietfa.amsl.com>; Tue, 24 Jul 2018 00:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 4Bco4SnXeADH for <dnsop@ietfa.amsl.com>; Tue, 24 Jul 2018 00:10:40 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [5.158.152.32]) (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 E5151130E12 for <dnsop@ietf.org>; Tue, 24 Jul 2018 00:10:39 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1fhrSu-000134-T6; Tue, 24 Jul 2018 07:10:36 +0000
Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from <fw@deneb.enyo.de>) id 1fhrOo-0003FL-0d; Tue, 24 Jul 2018 09:06:22 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: "Wessels\, Duane" <dwessels@verisign.com>
Cc: dnsop <dnsop@ietf.org>
References: <4DCC5A51-1AB0-47B6-92B5-79B6894F9A9C@verisign.com> <87h8kp7sqf.fsf@mid.deneb.enyo.de> <445C5C76-06B3-4F0B-BB7E-FD0254E26019@verisign.com>
Date: Tue, 24 Jul 2018 09:06:22 +0200
In-Reply-To: <445C5C76-06B3-4F0B-BB7E-FD0254E26019@verisign.com> (Duane Wessels's message of "Mon, 23 Jul 2018 20:40:00 +0000")
Message-ID: <87fu09xgcx.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I4kPCKQkUZU0QskCXBI5l-J1024>
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: Tue, 24 Jul 2018 07:10:42 -0000

* Duane Wessels:

> I wouldn't be opposed to this in principle -- say an RR count field.  

That doesn't really bound the amount of transferred data, I think,
because RR size can still vary widely.  I believe something that
counts the hashed bytes would be more helpful and about as easy to
implement.

> For this to be useful in an unsigned zone then all you need is for the
> ZONEMD (with RR count field) to be received early in the AXFR.  If it
> is at the end then this field doesn't help.
>
> For a signed zone, we'd have to think about whether the ZONEMD record
> should be DNSSEC validated before trusting the RR count field.  If yes
> then you need the signatures and NSEC* records too, so it becomes sort
> of complex when you'd be able to trust and check the RR count.

Could you query it before the transfer.

> But it seems to me like this is better suited to be a feature of AXFR
> in general, rather than ZONEMD.

It depends on what you want to achieve with ZONEMD.  If you want to
prevent trivial, but potentially persistent DoS attacks with custom
root servers, you need it in ZONEMD.