IETF Logo Mail Archive

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

"John Levine" <johnl@taugh.com> Tue, 24 July 2018 14:32 UTC

Return-Path: <johnl@iecc.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 3EE5C130EAE for <dnsop@ietfa.amsl.com>; Tue, 24 Jul 2018 07:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ggrCNyHC; dkim=pass (1536-bit key) header.d=taugh.com header.b=E/jxAc/W
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 mc8OXaDuCSDg for <dnsop@ietfa.amsl.com>; Tue, 24 Jul 2018 07:32:55 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E4551130E97 for <dnsop@ietf.org>; Tue, 24 Jul 2018 07:32:54 -0700 (PDT)
Received: (qmail 83840 invoked from network); 24 Jul 2018 14:32:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1477d.5b573895.k1807; bh=fwDtr6z4y3kLEBrC7IMfBNuGTvQZGjVBRyB0GssRcJU=; b=ggrCNyHCZH7Z2yF5MuAv6Gvri3lTDA6bS4hLoZF8st2HKm6tdpwOV9RBqEC1mb2Rb6uWkYK9eLhs63L5PF4l5RSNqoVuK1PEsGtOWn1YQ9xFRF5+QUjrcUaVdZszH5hXTrig830fYwh7+RIcZ4A+AnMV1Q64DtHAZ4Vu7jSqz+5mL+njcL2fz+7LXs4QDESWPpvcGoVQfn2nX4q6iN/UGK5Q5W5F4mCvMGsbnI9TPTEnsPeqacIfWFEwmhBIsXYn
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1477d.5b573895.k1807; bh=fwDtr6z4y3kLEBrC7IMfBNuGTvQZGjVBRyB0GssRcJU=; b=E/jxAc/WyYEReOm8rcMY8TeZ/etd1+dwqyDWyyh/leEWui10tjuE7MkciQS+0vebS6jhQk3B32neMYM7u0Li7xyjTL4cIwaWU8pil+6nlVNqVVkTnCyWVJ8dIIFfobJsVdvHHpv4IXfnbxz6U184mfAYkaBZp296n5v2T6uZxPwrHyCjtYVeebZcx7FoIq6Sj3wui8F/c8bU7bKUGIk+oFXcY3FxF2ydG6JN6ka47yiEusmdX4SMEJTe5Fq0mYRm
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 24 Jul 2018 14:32:53 -0000
Received: by ary.qy (Postfix, from userid 501) id 83ACC2002CE789; Tue, 24 Jul 2018 10:32:53 -0400 (EDT)
Date: Tue, 24 Jul 2018 10:32:53 -0400
Message-Id: <20180724143253.83ACC2002CE789@ary.qy>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
Cc: fw@deneb.enyo.de
In-Reply-To: <87h8kp7sqf.fsf@mid.deneb.enyo.de>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/L3gOrFvp4Z9LyAkLpwtr6NeEYXI>
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 14:32:56 -0000

In article <87h8kp7sqf.fsf@mid.deneb.enyo.de> you write:
>The ZONEMD record should contain a size indicator for the zone,
>something that allows a receiver to stop downloading if it is clear
>that the served zone is too large.  Otherwise, the receiver has to
>download the entire zone before it can determine that the hash does
>not match.

I don't understand why this is a problem that needs solving.  Are we
really attacked by broken zone files with large amounts of added junk,
that are so large that reading them through before discarding them is
a practical performance problem?

I'd think that more likely problems would be that a file was
truncated, or that it was the right size but some entries are
corrupted.

R's,
John

v2.23.0 | Report a Bug | By Email