Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

Mark Andrews <marka@isc.org> Thu, 21 February 2019 22:24 UTC

Return-Path: <marka@isc.org>
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 044B2131246 for <dnsop@ietfa.amsl.com>; Thu, 21 Feb 2019 14:24:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 hR1BOajRvL8P for <dnsop@ietfa.amsl.com>; Thu, 21 Feb 2019 14:24:40 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 64B7E12D4E7 for <dnsop@ietf.org>; Thu, 21 Feb 2019 14:24:40 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D75553AB043; Thu, 21 Feb 2019 22:24:39 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 72772160050; Thu, 21 Feb 2019 22:24:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 483B7160073; Thu, 21 Feb 2019 22:24:39 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1b37H4nXzyMb; Thu, 21 Feb 2019 22:24:39 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id CD873160050; Thu, 21 Feb 2019 22:24:37 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <75CA917D-1A6C-4717-934C-965570DC51C0@fugue.com>
Date: Fri, 22 Feb 2019 09:24:35 +1100
Cc: Dick Franks <rwfranks@acm.org>, Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>, Joe Abley <jabley@hopcount.ca>
Content-Transfer-Encoding: quoted-printable
Message-Id: <597BB37C-3111-437D-A646-0F6D7A22B86A@isc.org>
References: <155053239541.25848.12960190085730298684.idtracker@ietfa.amsl.com> <969D8BA1-6ED3-47E8-AFFD-2BEE8EA3E66B@bangj.com> <alpine.DEB.2.20.1902191219070.766@grey.csi.cam.ac.uk> <0DE33073-93B1-4CF5-B12D-B7266E21E8B2@timwattenberg.de> <alpine.LRH.2.21.1902191715230.30381@bofh.nohats.ca> <1F461BFA-638A-4607-84BD-F8B8597A1114@isc.org> <alpine.LRH.2.21.1902200028210.29865@bofh.nohats.ca> <646C86F6-C10D-43DF-ADE8-19222994E4D1@hopcount.ca> <E41DDEED-DF50-481F-9378-D721C3612643@isc.org> <alpine.DEB.2.20.1902201928250.19193@grey.csi.cam.ac.uk> <9330E97B-76BF-4C6F-8F6F-01349A3E7427@isc.org> <alpine.DEB.2.20.1902211215480.19193@grey.csi.cam.ac.uk> <CAKW6Ri7u5uCwcXgDrovgpEnhZCpkGGDMrxLHxbFVNvnveUPwWA@mail.gmail.com> <382BAB3C-C127-46E1-B931-4717A33BD75A@fugue.com> <4BF142EA-B2FB-4B00-9940-8A70FFEE5F6C@isc.org> <34BC472C-EF14-4872-BAC6-945AC18A7767@fugue.com> <5B21B95D-55D6-4916-8D1B-C921AB9712AA@isc.org> <75CA917D-1A6C-4717-934C-965570DC51C0@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/boa8_8AHz_BNaalY5TqOQcQwQow>
Subject: Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt
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: Thu, 21 Feb 2019 22:24:42 -0000


> On 22 Feb 2019, at 8:02 am, Ted Lemon <mellon@fugue.com> wrote:
> 
> On Feb 21, 2019, at 11:24 AM, Mark Andrews <marka@isc.org> wrote:
>> Ted. It has to work post zone transfer.
> 
> That’s not a problem, since the representation would be more compact, but would not be lossy: the interchange through the zone transfer would be the same regardless of how the data is stored.

Implementation details are beyond the scope of RFCs.

Also you mentioned caches which basically will never see these records unless they are queried for.

Yes, there is a minuscule probability of a hash collision.  The alternative is to define a type for rdlen + rdata in canonical DNSSEC form. The primary server can use/replace a hash when the rdata + length is longer than the hash, checking for collisions first.  If such a type is defined I would give it the value 1 and make the first actual hash 2.

Additionally in section 4.5 Cryptographic Hashes

"Any names contained in a resource record MUST be hashed in an uncompressed form."

needs to be replaced with

"The record MUST be in canonical DNSSEC form ([RFC4034] Section 6)."

The latter works with primary servers that don’t preserve case when transferring zones.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org