IETF Logo Mail Archive

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

"John R Levine" <johnl@taugh.com> Tue, 07 January 2020 00:30 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 38516120110 for <dnsop@ietfa.amsl.com>; Mon, 6 Jan 2020 16:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=O4h/7LP2; dkim=pass (1536-bit key) header.d=taugh.com header.b=Fr/fQBfj
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 pGlQ7VAtO3wu for <dnsop@ietfa.amsl.com>; Mon, 6 Jan 2020 16:30:25 -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 E8812120041 for <dnsop@ietf.org>; Mon, 6 Jan 2020 16:30:24 -0800 (PST)
Received: (qmail 96973 invoked from network); 7 Jan 2020 00:30:22 -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=17acb.5e13d11e.k2001; i=johnl-iecc.com@submit.iecc.com; bh=frA+FvNTbHM9fdKx8xqpbI5g+WRrInCp3/OI+S7NUms=; b=O4h/7LP2SnxvKjmbB34ejqXcRTYeCdpNXViS4Ld7YKROgqJQMqeBWn3cOLuw54tb6IRo5vGTWSZdZBL6VGNSO9yEDpXektFiqfFsXiT5BahF8rP0Vgq3U97ouVSrigRM/BoLk/X79MX8zqULnPj5WVerlvNYaooOv2GQhYiWnW2jXVX7v14Mz1x7HYfQNqyld4EndWhDJiZbn3cQyj16C5VkxLf4Xh9zlMf1ALYSE2uAdU7yAp7l8n2aW1BvrZmy
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=17acb.5e13d11e.k2001; olt=johnl-iecc.com@submit.iecc.com; bh=frA+FvNTbHM9fdKx8xqpbI5g+WRrInCp3/OI+S7NUms=; b=Fr/fQBfj42oTn5+zAy6ZU5tcla/gWsjj7aj3PjZCZuQDZ3hgYj+llt5YlkmbcpnlZUkqA4b+Uqp4K2lJdkwiW2HrP8f4IX+CJ0r+LlkCuGUPcAMkfYcw1MQ38E9rv94WRAxJwHg/dlXUGzoMwhRWQUjEkuhEWO+q3u1hO6qxQ4uKygxzNCsKTBQySGGxRV65ebwzKaIUfL0YMU7i7aMvbCXsj+AdZgWB4pR7dyWrjdNEPPKzew2eJqTuJbO57DkK
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; 07 Jan 2020 00:30:22 -0000
Date: Mon, 06 Jan 2020 19:30:22 -0500
Message-ID: <alpine.OSX.2.21.99999.374.2001061926250.76429@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Michael StJohns <msj@nthpermutation.com>
Cc: John R Levine <johnl@taugh.com>, dnsop@ietf.org
In-Reply-To: <535932c3-dbc6-ee2a-4804-ffdb691981da@nthpermutation.com>
References: <20200106171326.E0E1E120301E@ary.qy> <54ddbdea-50c5-42eb-aa0c-bff4bb2d3bcc@nthpermutation.com> <alpine.OSX.2.21.99999.374.2001061311150.74676@ary.qy> <535932c3-dbc6-ee2a-4804-ffdb691981da@nthpermutation.com>
User-Agent: Alpine 2.21.99999 (OSX 374 2019-10-27)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1981695872-1578357022=:76429"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wT2YVvjSnigmiRUW2A-R0EsOlKQ>
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: Tue, 07 Jan 2020 00:30:27 -0000

> *Sigh* Not exactly.  If you have no automated applications that will use 
> this, then it depends on the human and I think that's what you mean by 
> "application".  Otherwise, I think you'll find that most automated 
> applications will want to (or probably should want to) use the same logic.

I'm sorry, but that continues to make no sense.

>> If it's an AXFR to a secondary authoritative server you might do one thing, 
>> if it's someone collecting stats on TLD zone files, they might do something 
>> else.

I actually have automated software doing both of those.  As I may have 
said once or twice, it depends on the context.

>> "Do the same thing you do now when a zone is invalid."
>
> Given that there's no fixed definition of when a "zone" is invalid, I don't 
> think I can do the "same thing"?     See below for a screed on data protocol 
> vs transport protocol.

Sheesh.  Invalid == contents do not comply with RFC specifications

> Now comes ZONEMD which wants to make a zone database wholly coherent - ANY 
> change in the contents of the zone will result in changes to the ZONEMD 
> record and to verify it, you MUST download exactly the same data as was 
> digested previously.  Unlike changes to the SOA serial, this record binds the 
> entire zone to be a very specific set of bits.

Right.  It's long overdue.  If you want to do incremental updates, that's 
fine, but that's not what this incarnation of ZONEMD binds.

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

v2.23.0 | Report a Bug | By Email