IETF Logo Mail Archive

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

"Wessels, Duane" <dwessels@verisign.com> Mon, 30 July 2018 21:44 UTC

Return-Path: <dwessels@verisign.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 7E089130EF3 for <dnsop@ietfa.amsl.com>; Mon, 30 Jul 2018 14:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 JB31juNHNhZo for <dnsop@ietfa.amsl.com>; Mon, 30 Jul 2018 14:44:31 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.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 90B62130EF0 for <dnsop@ietf.org>; Mon, 30 Jul 2018 14:44:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=7960; q=dns/txt; s=VRSN; t=1532987072; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=0p36pHkQaCOMbQw6hpGqa9el2Vz8Sj+YNTGhxZZGOK8=; b=lgikUzk8aFtqXCwpKsZamnkLGMaBjO+xF/yamvkyztpcl0jrHJBHHA39 f88Yc/yxt8H5Qp56GuwvKk+pyo61kMinCvAc8x88IFm4b+g5XHzjQ8ovI Kpdw9KSx2Y/m48vGcKTMysoJAijL+EcasxJ9nZxvOKw7oTY92iJWs4buh unLcPwhcKQUdKjjpapuUS9F+O8hOjU/Z6d14W3y8Sa8orLemBMlv12sn1 QXiQZD5XgMAeXI6COXNySynojF8NIjNFfYx4qC2asiO1yDm+bZvhzsxnJ 6O4igSyHmQeAv9K8/cr4jsJVXYe5BZKmUrRBpiys5W2JgNTW6A4WvwHJC w==;
X-IronPort-AV: E=Sophos; i="5.51,424,1526342400"; d="p7s'?scan'208"; a="5346269"
IronPort-PHdr: 9a23:d3VLHhTx7mfgbvpyCOVRfCz2Q9psv+yvbD5Q0YIujvd0So/mwa6zYR2N2/xhgRfzUJnB7Loc0qyK6/6mATRIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+KPjrFY7OlcS30P2594HObwlSizexfbJ/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbDVwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4rx1QxH0ligIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2ROQ9xRWjRBDI2icoUPE+QPM+VWr4b/plsBsRSxCBKjBO/zzz9FnGP60bEk3+knDArI3BYgH9ULsHnMotn6NLkdUfuuzKbWyTXDdOta0irz5ojVaB8hp++DUbxtesfW1EYuGR3Kjk6LqYP7OzOVzf8As3aF4Op6VOKvkG8nqw53ojS12sgsjYzJi5sTx1vZ9it52J44KcCkREJhfNKpEpVduzuHO4Z2TM4uWW5ltSIixrEbpZK3ZjUGxZY7yxLFdvCKfIuF7gj+WOuSOTt4imxqdbGjixu39EWv0O7xW82v31tPoCdJjMTDu3EI2hPI7sWKS/lw80Kv1DuB1Q3c9+dJKl0um6XBMZ4u2Lswm4IWsUTEAyD5hl37jLSTdkU44uio7PnnYqn+qp+cKYB0jgb+P7wzl8KjGeo0LwgBUXCU9+u9yLHv41f1QKtWgf0xiKnZqIrWKt4GqaKjHQ9VyJ0j6xClAzi619QYmGELLFNDeB2Zk4jkI0zCLOziAfuigVmhni1ny+3GM7DvGJnAIXzOnK/kfbln6k5czAQzzcpY55JRErwOPfzyVVHqtNzDEBA5Nxe0zv35CNpjzIMeWHmPAq6WMKPUq1OH+uUvI+yUaI8PpDn9M+Ql5+LpjXIhm18deqmp3Z0TaH2jAvRpOViZYXXsgtsbDWgKuQ8+RvTwiFKeST5Te2qyX6Uk6z4mDoKmFoDDRpi2jbyAwii7ApNWanpBClCWHnfib5+EVOsUaCKOPs9hlSQJVbavSoI6yB6hqgn6xKR8IebO5CIYs5Li1N9v6+LOix5hvQBzWuaa02fFa2xqn2UFD2s026B5pWRhw0qM0e5zhPkORvJJ4PYcGDg3LoXRy/c+Q/zvUwTMNJ/dREmrWc6rBSoZUN8rwsQPbEA7ENKn2EOQlxG2CqMYwuTYTKc/9bjRij2of55w
X-IPAS-Result: A2F9AQBuhl9b/zGZrQpcGgEBAQEBAgEBAQEIAQEBAYVYCppDl0sIA4RsAoM1OBQBAgEBAQEBAQIBAQKBEYI1JAGCXgEBAQECAXcCBQsCAQgYLgIwJQIEDgUOgxIBgXerNBGCT4RehVkPiRmBQj6BEicfgkyIMIIkApIQiAADBgKDZYFZmACSEAIEAgQFAhSBWIF0cBVlAYI+giQBFxGOBm8BjiyBGwEB
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Mon, 30 Jul 2018 17:44:13 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1466.003; Mon, 30 Jul 2018 17:44:13 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: John Levine <johnl@taugh.com>
CC: "dnsop@ietf.org" <dnsop@ietf.org>, "fw@deneb.enyo.de" <fw@deneb.enyo.de>
Thread-Topic: [EXTERNAL] [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
Thread-Index: AQHUKE50u8IOpnZd206LtdpbcMthjQ==
Date: Mon, 30 Jul 2018 21:44:13 +0000
Message-ID: <84FAA6E0-DF87-4C3B-B033-2830AD6C7675@verisign.com>
References: <20180724143253.83ACC2002CE789@ary.qy>
In-Reply-To: <20180724143253.83ACC2002CE789@ary.qy>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_0838A71D-62B2-4D45-A0BC-7775077A69B2"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eyKDL_cfXT1M2KmgFzL3Ft4cwD4>
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: Mon, 30 Jul 2018 21:44:35 -0000


> On Jul 24, 2018, at 7:32 AM, John Levine <johnl@taugh.com> wrote:
> 
> 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.

I agree with John.

ZONEMD is not about securing any particular transport, AXFR or what-have-you.

While I wouldn't necessarily be opposed to having an RR count field of some kind if there is good reason to have it, my preference would be to omit it and keep the record simpler.

DW

v2.23.0 | Report a Bug | By Email