Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones
"John R Levine" <johnl@taugh.com> Sun, 05 January 2020 23:29 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 C1FD2120045 for <dnsop@ietfa.amsl.com>; Sun, 5 Jan 2020 15:29:14 -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=quCK/IF3; dkim=pass (1536-bit key) header.d=taugh.com header.b=BEZGwZlv
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 kvG9EfmvaYGH for <dnsop@ietfa.amsl.com>; Sun, 5 Jan 2020 15:29:12 -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 26896120026 for <dnsop@ietf.org>; Sun, 5 Jan 2020 15:29:11 -0800 (PST)
Received: (qmail 37222 invoked from network); 5 Jan 2020 23:29:10 -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=9164.5e127146.k2001; i=johnl-iecc.com@submit.iecc.com; bh=tgm1oF0IpU/vKGyaPOvu+jeQ04VjD2zc+ZjIf6YMClU=; b=quCK/IF3OXe5xtb5gCH041s/Y26kX/ksfazaQTC+cd6WhQMqupW89Hr6vfoBnDyZjD10iwiB+k5AFKOJsTsmUnb0SS6K6mXDJA3fImUIQArVjLLNr8dTqlIkL7kDjKLnb9T1g9FQ1wnuq2Rg0vRyrirFvGeqUCda4lxj0mzQwvtTpimPEC6j2gE0Mf/f2dQLYBeyLo2JL5QsEU16RyPnaB0+yGPo/Tood0rE876+j/c36Q+Keih+joNJlWoXLkao
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=9164.5e127146.k2001; olt=johnl-iecc.com@submit.iecc.com; bh=tgm1oF0IpU/vKGyaPOvu+jeQ04VjD2zc+ZjIf6YMClU=; b=BEZGwZlvwWV24JkW6A89hSCowK9z//gLfwOkSIlL6/AZw6hiCqZFx6mtYy4MyMuhngb1H2TifInpyP3Zxtxcd9XFElhlG48x2u6GPaXAH/dDmI7/smWp6QvjiAt1UD6xCiI3/OiehD21Zgc8kDVoDD5ru83JzBZE2h0GWfs3oV32AzOKdVpCwcBqNP/Tx8Rw0iEzda0lnXBzXi/+yWKj387suYL+JsXtyskNJ5FZz9tUqWGDxwsCLVZzh5n7IKIo
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; 05 Jan 2020 23:29:10 -0000
Date: Sun, 05 Jan 2020 18:29:09 -0500
Message-ID: <alpine.OSX.2.21.99999.374.2001051821210.71425@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Michael StJohns <msj@nthpermutation.com>
Cc: dnsop@ietf.org
In-Reply-To: <9952199f-9ea5-2d51-a5d2-6aaf805774a5@nthpermutation.com>
References: <20200105190035.753B411FCFEF@ary.qy> <9952199f-9ea5-2d51-a5d2-6aaf805774a5@nthpermutation.com>
User-Agent: Alpine 2.21.99999 (OSX 374 2019-10-27)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-581357297-1578266950=:71425"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/h7QNo2hcn2slmVqaT-oyizpwB1U>
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: Sun, 05 Jan 2020 23:29:15 -0000
We seem to have a fairly basic disagreement here about whether we can expect people who implement ZONEMD to be familiar with the way that DNS servers work. In pretty much all of the cases below, it seems to me that if the answer to the question isn't obvious, you're not the audience for this document. On Sun, 5 Jan 2020, Michael StJohns wrote: > On 1/5/2020 2:00 PM, John Levine wrote: >> In article <84650844-1d13-9377-c913-23dcbc76dc37@nthpermutation.com> you >> write: >>> 1) A recommendation for the maximum size of the zone (and for that >>> matter the maximum churn rate). This is hinted at in the abstract, but >>> missing from the body of the document. >> I don't get it. The draft makes it clear that ZONEMD in this >> implementation is intended for statically signed zones. If Verisign >> wants to put a ZONEMD in the daily download of the three hundred >> million record .com zone file, I think that would be dandy. If your >> zone of whatever size is updated too often to deal with recomputing >> ZONEMD, then don't. > > To quote one of my favorite movies: " I don't think that means what you > think it means" > > The abstract text which is usually not considered normative says: > >> As specified at this time, ZONEMD is not designed for use in large, >> dynamic zones due to the time and resources required for digest >> calculation. The ZONEMD record described in this document includes a >> field intended to enable future work to support large, dynamic zones. > > Define: "Large" and define "Dynamic" and define "large AND dynamic". A > large fairly static zone (e.g. 100K records with changes once a month) might > be a candidate. A small dynamic zone (e.g 20 records changing hourly) might > also be a candidate. > >> Also, advice about what's too big or too slow doesn't age well. I >> expect most of use remember a time when the idea of a million record >> zone file seemed absurd. > > Tim represented that "the authors feel they've performed their experiments" > and I would assume that the experiments have given them some ideas on which > zone size and churn don't cause problems. E.g. how long does it take to > canonicalize and hash various sizes of zones given a particular (or several > different) hardware implementation(s)? >> >>> 2) For each of the use cases, an explanation of how this RRSet actually >>> mitigates or solves the identified problem. >> I don't get this either. ZONEMD lets you verify that you got the >> entire zone correctly. If anything, I'd take most of this section out >> since the list of places where people get zone files isn't likely to >> age well either. > > Let's take one example: > >> As the >> root zone spreads beyond its traditional deployment boundaries, the >> need for verification of the completeness of the zone contents >> becomes increasingly important. > > I read this (and the motivation section), and I still don't know why this is > a problem. Nor what the receiver of the zone should do if it detects > "missing" data for some definition of missing. > > (Note that the "parent tells you whether the child has a zonemd record" thing > won't work here, so it's going to have to be some sort of configuration > option for the receiver to tell it what to do - e.g. pull it again, yell at > the root signers???). > > 1.3.4 comes the closest to specifying a real use. The rest - not so much. > 1.3.3 basically seems to be saying - RPZ didn't do it right and rather than > fixing it by checking DNSSEC, do this instead. > > >> >>>> This specification utilizes ZONEMD RRs located at the zone apex. >>>> Non-apex ZONEMD RRs are not forbidden, but have no meaning in this >>>> specification. >>> Instead - "non-apex ZONEMD RRs MUST be ignored by the receiving client". >> Does ignore mean they aren't included in the computation of an apex ZONEMD? >> Ugh. >> >> ZONEMD RRs MUST NOT appear anywhere other than the apex of a zone. > > What does a client do if it sees a non-apex ZONEMD RR because someone will > put it there? E.g. it "ignores it as a verifiable item". The rest of the > processing rules apply. MUST NOT means it doesn't matter. A zone with a non-apex ZONEMD does not implement this spec, so it's not useful to try and guess what the person who created the zone got wrong. It's more or less the same as what do you do with a record that has a compressed name that points past the end pf the message -- it's just wrong. >> I think that's an error. If they have the same DT and parameter, either >> they have the same serial and they're duplicates, or one of them is obsolete. > > Yup. Or the zone issuer failed to update the serial number... know any zones > (or more to the point zone operators) like this? See above -- it's broken. I don't think at this late stage that it is a good idea try and guess how people will screw things up and to propose kludges to guess what they meant. > If a computer can't figure out what to do with a failed validation absent > human interaction then you might as well say: > > "ZONEMD RRs may be safely ignored by all but the geekiest of DNS human > operators as there is no guidance on what to do if you see a zone that > appears to be incomplete due to ZONEMD RR validation as it might not actually > be incomplete" It's exactly the same thing you'd say about any other zone that has techincal errors. I don't see anything new here. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly
- Re: [DNSOP] Working Group Last Call for: Message … Vladimír Čunát
- Re: [DNSOP] Working Group Last Call for: Message … Tim Wicinski
- Re: [DNSOP] Working Group Last Call for: Message … Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John Levine
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John Levine
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- [DNSOP] Working Group Last Call for: Message Dige… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … Paul Vixie
- Re: [DNSOP] Working Group Last Call for: Message … John Levine
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- Re: [DNSOP] Working Group Last Call for: Message … John Levine
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- Re: [DNSOP] Working Group Last Call for: Message … Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Joe Abley
- Re: [DNSOP] [Ext] Working Group Last Call for: Me… Paul Hoffman
- Re: [DNSOP] [Ext] Working Group Last Call for: Me… Brian Dickson
- Re: [DNSOP] [Ext] Working Group Last Call for: Me… Bob Harold
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] [Ext] Working Group Last Call for: Me… Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- [DNSOP] future-proofing (Re: Working Group Last C… Paul Vixie
- Re: [DNSOP] future-proofing (Re: Working Group La… Brian Dickson
- Re: [DNSOP] future-proofing (Re: Working Group La… Wessels, Duane
- Re: [DNSOP] future-proofing (Re: Working Group La… Michael StJohns
- Re: [DNSOP] future-proofing (Re: Working Group La… Wessels, Duane
- Re: [DNSOP] Working Group Last Call for: Message … Michael StJohns
- Re: [DNSOP] Working Group Last Call for: Message … John R Levine
- Re: [DNSOP] Working Group Last Call for: Message … Miek Gieben
- Re: [DNSOP] Working Group Last Call for: Message … Wes Hardaker
- Re: [DNSOP] Working Group Last Call for: Message … Wes Hardaker
- Re: [DNSOP] future-proofing (Re: Working Group La… Shane Kerr
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Paul Hoffman
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Brian Dickson
- Re: [DNSOP] future-proofing (Re: Working Group La… Wessels, Duane
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Wessels, Duane
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Michael StJohns
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Paul Hoffman
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Paul Vixie
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… Michael StJohns
- Re: [DNSOP] [Ext] future-proofing (Re: Working Gr… John Levine