IETF Logo Mail Archive

Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

"John Levine" <johnl@taugh.com> Sat, 18 January 2020 03:07 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 00758120086 for <dnsop@ietfa.amsl.com>; Fri, 17 Jan 2020 19:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level:
X-Spam-Status: No, score=-1.751 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.249, SPF_HELO_NONE=0.001, SPF_PASS=-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=ZtGS3V53; dkim=pass (1536-bit key) header.d=taugh.com header.b=jwRWQHnM
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 AGkb7uKggPvK for <dnsop@ietfa.amsl.com>; Fri, 17 Jan 2020 19:07:06 -0800 (PST)
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 00508120041 for <dnsop@ietf.org>; Fri, 17 Jan 2020 19:07:05 -0800 (PST)
Received: (qmail 36487 invoked from network); 18 Jan 2020 03:07:04 -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=8e83.5e227658.k2001; i=printer-iecc.com@submit.iecc.com; bh=syv9P3OoR3ZpMGjACpOjQyGGVVw8sV16BtomiN/OHdQ=; b=ZtGS3V535jNqdskVGsfRALqf6uNGRL4M2scbSA61m4xF2oO+TxvVganN2WE0hQ7pD5yX90ugN/GXpfsYjoOW1yITJEo42YucWwElLf6l93NDOFmWsLOXTuiEloO9067ru8p9BywJDERP6smAifiyzDRxn6SOYSiuSN0SBMr0llsEFpF6MIAtRYCGvyhXNC3D3Tvrx9CiflfpNoRE0aw6QRDAc3cvBgPsSLd6cksOdw3QbNzX9ioC1AAgYGZrgnVD
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=8e83.5e227658.k2001; olt=printer-iecc.com@submit.iecc.com; bh=syv9P3OoR3ZpMGjACpOjQyGGVVw8sV16BtomiN/OHdQ=; b=jwRWQHnM6RpY/V0j77FVmgetEYiGDGJA6hPDpEqbhBswJvTQqxvNdjvVNxrKNwTAZQWpogGvlflVOKtbV9XMQuOl9aodntBxgoFxLJgrO50zOKvkvno/S8xmsm2ZdYC6Nyl/5abLjTWjwGw8ITMoS8Ms7fgjPa/VAlJDClZDKVN16S2ooGPj7GpCgzIGnezJQzsDvXXQ4b7tVnBiXA/M+dma7vQsnlpYFoI9H5+sSbMUEtnMwjA7RhyBU/Vl09rV
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 ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP6; 18 Jan 2020 03:07:03 -0000
Received: by ary.qy (Postfix, from userid 501) id 6B6C912C6717; Fri, 17 Jan 2020 22:07:02 -0500 (EST)
Date: Fri, 17 Jan 2020 22:07:02 -0500
Message-Id: <20200118030703.6B6C912C6717@ary.qy>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
Cc: paul.hoffman@icann.org
In-Reply-To: <1F8E8497-DBB5-49FC-A3DA-FFF4D9B95F3A@icann.org>
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/pbXQITjBNW0aU-33oUu-H5Xfif4>
Subject: Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 18 Jan 2020 03:07:07 -0000

In article <1F8E8497-DBB5-49FC-A3DA-FFF4D9B95F3A@icann.org> you write:
>On Jan 15, 2020, at 5:28 PM, Michael StJohns <msj@nthpermutation.com> wrote:
>> I think its a co-existence issue here.  I don't think you should have two different (calculation-wise) ZONEMD-like RRSets in the same
>zone for the reasons you've mentioned.  
>
>That makes good sense. When someone defines an incremental zone hash RRtype, that protocol spec should likely either prohibit ZONEMD
>RRsets, or state that their interpretation is suppressed. The WG can cross that bridge when we see a reasonably filled-out proposal for INCZOEMD.

That seems to me overdesigned.  If you are able to compute a signature
for the whole zone, put a ZONEMD at the apex.  If you can't, don't.
It includes whatever's in the zone, including INCZONEMD if there
happen to be any.

If you are updating a signed zone with IXFR, either update the ZONEMD
if you are able to recompute a new signature for the zone including
any added or changed INCZONEMD, or delete it in the more likely case
that if you can't.  Why does it have to be more complicated than that?

R's,
John

v2.23.0 | Report a Bug | By Email