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

Mark Andrews <marka@isc.org> Mon, 27 August 2018 03:33 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 65D261274D0 for <dnsop@ietfa.amsl.com>; Sun, 26 Aug 2018 20:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 Xz7fnF2rmnTv for <dnsop@ietfa.amsl.com>; Sun, 26 Aug 2018 20:33:35 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 26A21126F72 for <dnsop@ietf.org>; Sun, 26 Aug 2018 20:33:35 -0700 (PDT)
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 E8FDA3AB03C; Mon, 27 Aug 2018 03:33:34 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A6DC516003D; Mon, 27 Aug 2018 03:33:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 95619160044; Mon, 27 Aug 2018 03:33:19 +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 w32RZTEpGXof; Mon, 27 Aug 2018 03:33:19 +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 B55D416003D; Mon, 27 Aug 2018 03:33:18 +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: <CAPt1N1mLVo917KWhU9msKsPaJWRquF=S0B796xa36+xwuGQGPw@mail.gmail.com>
Date: Mon, 27 Aug 2018 13:33:16 +1000
Cc: Tom Pusateri <pusateri@bangj.com>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FED415F-EA7F-41DC-BD88-B864380A0391@isc.org>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com> <5B7F5E07.5080100@redbarn.org> <7F91FFF7-71C3-4F8E-82CD-266B170983E0@bangj.com> <C0EE2719-B662-4231-AF51-D3B98B00AD0D@fugue.com> <6D607922-393D-4549-AAFA-49279C260CA4@bangj.com> <3C6100BD-62D6-41ED-B7BF-679F0D4E4113@fugue.com> <5063A32B-4877-4860-BA73-CCB068AB7FCB@bangj.com> <CAPt1N1=tXZNgT6ygAaLFfOMze7hbGZ6q_eN1C3iEo9ryBNcyLg@mail.gmail.com> <98EF2CAC-7C13-4E68-8D2B-EC0659EA9646@bangj.com> <CAPt1N1kFNY4=CUMsTvXmeRREeLAkY8xpBdw4vPDxujgke6QT8A@mail.gmail.com> <963460AA-14BB-44AA-87CA-7F09A707DB5D@bangj.com> <47AE41F8-9F5F-4CC8-B4F0-7E8191011E99@bangj.com> <F4335D3A-0241-437F-A428-8EA95F0A1C18@fugue.com> <56E8B2A6-7B65-4D25-B102-9EFA7E2CBE7B@bangj.com> <86D465A4-F390-4370-83EC-0E72FBE115BE@isc.org> <CAPt1N1=xy+JAtgvvF_+9LiTiefbpTy_Vd0b8gswozA1K1C57Nw@mail.gmail.com> <99FA0B76-D225-45FC-A33C-B65E2673A45E@isc.org> <CAPt1N1kp8Tg5tWEiDCMuMNTmehRsBSkkC1=u+RcvkG6ZCegE-g@mail.gmail.com> <977DF12E-178B-4500-B045-F27BF1CDF51C@isc.org> <CAPt1N1=cafnVmnNM2eSF67QbgRk8hUEAd2Gwuqx4OUehPZSmyQ@mail.gmail.com> <AC3FE6CF-CC11-44D3-8C50-BC19C295F001@bangj.com> <CAPt1N1ksyp1t_e9Qd4FTtTVsZr9+VDm11MR-jS9Oz8Kpz7J7AQ@mail.gmail.com> <9B4A76C4-3BA6-46EC-90EB-E78065FD8BD3@bangj.com> <CAPt1N1=o3KRa_X2KTuW1=KagOv1R0KM=QvT0QBf5YrOSWTr9mw@mail.gmail.com> <461B2749-E2A4-42B8-9FB3-824D96039423@bangj.com> <DEE0C8C8-5557-4D97-B3C8-6535F3EB3693@bangj.com> <CAPt1N1knPwGFy38c0=xNT_mHwo=vQZmzqNJHc_=Oshcr1OH8sQ@mail.gmail.com> <C273A347-C918-428F-9CB9-FBF9426F913A@bangj.com> <CAPt1N1mTSYcmaw3TpO1UnHA1r4CF2+BQR9UG-kSQaiTxGtk24g@mail.gmail.com> <A3BB12A2-1159-40D6-8F24-96226F98E1F5@bangj.com> <AD5AAC94-077C-47A6-A28C-9FA7D2A78E2D@isc.org> <CAPt1N1mLVo917KWhU9msKsPaJWRquF=S0B796xa36+xwuGQGPw@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/L1tsW-9OFpfxpgcBbMJGOe3YuZU>
Subject: Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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, 27 Aug 2018 03:33:36 -0000

A hash is still better than copying the RDATA to the end of the timeout record and
avoids protocol RR size limit issues.

You still have to handle multiple TIMEOUT RRs at the same name to cope with a TIMEOUT
records that would exceed 64K, the limit of what can passed in a single RR in a AXFR.
As these are never returned in a answer you don’t have to cope with the RRset exceeding
64k at the protocol level but a implementation might.

e.g. 4000 A records at a single name (~64k RRset) with individual timeouts would have a
TIMEOUT RRset much greater than 64k.

Mark

> On 27 Aug 2018, at 1:20 pm, Ted Lemon <mellon@fugue.com>; wrote:
> 
> If we do that, why do we need a hash at all?
> 
> On Sun, Aug 26, 2018 at 10:51 PM Mark Andrews <marka@isc.org>; wrote:
> I would add a covered type field to TIMEOUT (c.f. RRSIG).  I also wouldn’t have more than
> a single timeout per record.  I’m tempted to say a single hash as well.  If there is multiple
> timeouts per record then the blocks need to be sorted in timeout order.
> 
> Covered is there to reduce the number of RR’s that need to be hashed to remove a record.
> It will also reduce the size of IXFR’s as you don’t need to re-construct a new TIMEOUT
> record that covers every timeout at a name on each change.
> 
> For all records at a name is often more expensive that for all records of type covered.
> Name servers are optimised for looking up <name,type,class> tuples rather than <name,class>
> tuples.
> 
> Sorting of timeout blocks is so that you can look at the first timeout when working out
> which TIMEOUT needs to be processed first in a zone.
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org