Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

"John R Levine" <johnl@taugh.com> Wed, 08 January 2020 19:07 UTC

Return-Path: <johnl@taugh.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 018A21200CC for <dnsop@ietfa.amsl.com>; Wed, 8 Jan 2020 11:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=COH6U9fZ; dkim=pass (1536-bit key) header.d=taugh.com header.b=qLY4pHG+
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 z-n9ZA-Vl5fY for <dnsop@ietfa.amsl.com>; Wed, 8 Jan 2020 11:07:22 -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 646F41200B8 for <dnsop@ietf.org>; Wed, 8 Jan 2020 11:07:22 -0800 (PST)
Received: (qmail 69085 invoked from network); 8 Jan 2020 19:07:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10ddb.5e162869.k2001; i=johnl-iecc.com@submit.iecc.com; bh=uLrs8lXtjlXmun5PcrxKMFx7e3WIKcLRbye7aI+PRZw=; b=COH6U9fZuMbSEgw2B/S7SMuve9SivsCBTJtZwhSP1M+SzFWvSeNOv/e96Kt0eZcur2iJCcgHWj8SMmAG/4ODNTSKcSINC+sbfBNQ7HGctnFAMCHKaCO4zTrksOVBAw4kH4XgkUKawSE9mmB4G/QT/301tZhe5LavWrHNLe6nv+XAYJEVoJZShlcmAFh5R5PDmjhmvWxmKmXUbcf+6kXjaIee1Dq7bmTuV2J9rkR07fGch7F2RPqZtTCD7OwqEGAf
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10ddb.5e162869.k2001; olt=johnl-iecc.com@submit.iecc.com; bh=uLrs8lXtjlXmun5PcrxKMFx7e3WIKcLRbye7aI+PRZw=; b=qLY4pHG+vwSALEaCVKbj6Vcmuz7kQNEsPJq/XMk4Bs+OcNUIZNbGdh8sW10u9gwT5fiIBxXUsl90wQOTqmdarD5N7ADQd0dunjz9D8w0iUgMOoxsehV/R28vliDR9XKHPV0xOb8YbHXbcRBiEktS9JvtDbeA+UOAs5IwjoiXfO1duRZMfrBYv/VSqp44loB5KR8JPP6F/G95e1lr8WNwsbooA1wyIpN5XitN6kkiz33hmMCk8nMw6s/HFhwPzGgv
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 08 Jan 2020 19:07:20 -0000
Date: Wed, 08 Jan 2020 14:07:20 -0500
Message-ID: <alpine.OSX.2.21.99999.374.2001081359350.85317@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Michael StJohns <msj@nthpermutation.com>
Cc: dnsop@ietf.org
In-Reply-To: <ce52989c-f6cc-f4e5-0c49-d528d366e350@nthpermutation.com>
References: <20200107023630.628251208AAF@ary.qy> <ce52989c-f6cc-f4e5-0c49-d528d366e350@nthpermutation.com>
User-Agent: Alpine 2.21.99999 (OSX 374 2019-10-27)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1780641900-1578510440=:85317"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CaXN0SpcUB2IX6CZijIizSjrldo>
Subject: Re: [DNSOP] 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: Wed, 08 Jan 2020 19:07:24 -0000

> Could you give me a b) for each of these please?   E.g. How does ZONEMD make 
> your life better in each of these and what would happen if you - in a future 
> world - were getting ZONEMD data and validation failed?

Unless someone else says they find this level of anecdotal detail useful, 
I'll pass.

As I keep telling you, there is nothing new about dealing with invalid 
zones.  This is just another way to find that a zone is invalid, and it is 
hard to imagine how anyone who would use ZONEMD wouldn't already have 
experience dealing with other zone transfer or validation failures.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly