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

"John R Levine" <johnl@taugh.com> Mon, 06 January 2020 18:48 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 E9BEF1200EB for <dnsop@ietfa.amsl.com>; Mon, 6 Jan 2020 10:48:06 -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=Fcs1MrNH; dkim=pass (1536-bit key) header.d=taugh.com header.b=OKYlw9/R
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 b15awkoT9HOW for <dnsop@ietfa.amsl.com>; Mon, 6 Jan 2020 10:48:05 -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 EFBC1120077 for <dnsop@ietf.org>; Mon, 6 Jan 2020 10:48:04 -0800 (PST)
Received: (qmail 21563 invoked from network); 6 Jan 2020 18:48:03 -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:content-id:user-agent; s=5436.5e1380e3.k2001; i=johnl-iecc.com@submit.iecc.com; bh=KysoSR1KAfTIJbc33EA2WBbq4K8kh9KL3j0zDHTL94s=; b=Fcs1MrNHjB+slqjqPIaBWXdfQxhOl9QmPfvO6W7KbORiUfAEYBzHxHJEdqY53VLKkuLhBjz2hylRYlZhH3ECVvYwQJADu5S37NqtZuYXz63IX992Byq5IVfgyjK6WjJ24PNOmx78eQN05W5RVie1HmtR6GOjYZtNRxqQwQZD5ep5PavPSxiKkcw6RnmGv5lg+/od5zkAB8hfSNGgDrMwnlM2N7CXPe2Tj8DAeTsBBxRQ06vkR7CrvR+rRd7mocoT
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:content-id:user-agent; s=5436.5e1380e3.k2001; olt=johnl-iecc.com@submit.iecc.com; bh=KysoSR1KAfTIJbc33EA2WBbq4K8kh9KL3j0zDHTL94s=; b=OKYlw9/Rjoeoa0D8wN+FMH5LXrcXC9r5FDvzA3ZpmYZf6+HJ44nrxW9iWDG+wBBn6LpFudtDueFZbeZA8/OlPRbJLJ0QM43fUocVdG5AkWX7ReUeH9hoGtRTmra/SluKz5UeRLzeI07orc8U2rwNHRuXwcYncOqNGPhRooFlpeI4FvbGQhwtEnbNKk8RCBurLjLB+/7lznnbUiD8Rqt3N/m/qaCk7hD+nW00X8ovenVp0b1RAsIRG7B8277Wzb5U
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; 06 Jan 2020 18:48:03 -0000
Date: Mon, 06 Jan 2020 13:48:03 -0500
Message-ID: <alpine.OSX.2.21.99999.374.2001061311150.74676@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Michael StJohns <msj@nthpermutation.com>
Cc: dnsop@ietf.org
In-Reply-To: <54ddbdea-50c5-42eb-aa0c-bff4bb2d3bcc@nthpermutation.com>
References: <20200106171326.E0E1E120301E@ary.qy> <54ddbdea-50c5-42eb-aa0c-bff4bb2d3bcc@nthpermutation.com>
User-Agent: Alpine 2.21.99999 (OSX 374 2019-10-27)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-219940228-1578334537=:74676"
Content-ID: <alpine.OSX.2.21.99999.374.2001061333540.74827@ary.qy>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/j8yDCTzenerHhbZ5yI7_nYJpz2k>
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: Mon, 06 Jan 2020 18:48:07 -0000

>> Well, OK, here's a concrete example.  I download the COM zone every
>> day from Verisign, and also a separate file with an MD5 hash of the
>> main file.  Using RFC 2119 language, what do I do if the hash I get
>> doesn't match their hash? ...

> Ok - you've described half of this - the download and the validation.   Let's 
> move on to the use.   E.g. you now have a zone with a good ZONEMD - you throw 
> it into what application?   Or you now have a zone with a bad (unable to 
> validate) ZONEMD, do you still throw it into the application. Does the 
> application check the ZONEMD or did you do that manually?   If you throw the 
> zone into the application without validation then what?   Do you retry to 
> download it?  How often and how long between tries?

No matter how many times you ask, the answer is the same: it depends on 
the application.

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 don't see any benefit to anyone to try to guess how people we don't know 
will use this in applications we don't know about at unknown times in the 
future.  Not only are we not the DNS Police, we're not the Omniscient DNS 
Experts either.

> Please provide a general rule for automated handling of failed validations.

"Do the same thing you do now when a zone is invalid."

Do the same thing you do now when a name is more than 255 octets.

Do the same thing you do now when a RR has an RRTYPE of 252 or 255.

Do the same thing you do now when an SOA isn't long enough to include all 
seven fields, or the SOAs at the beginning and end of an AXFR don't match.

Do the same thing you do now when a TXT character string is longer than 
the RR's RDLENGTH.

Do the same thing you do now when the offset in a compressed name points 
past tne end of the packet, or the pointers create a loop.

I'm sure you can come up with others.

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