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

Mark Andrews <marka@isc.org> Tue, 28 August 2018 01:05 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 8A623130F2A for <dnsop@ietfa.amsl.com>; Mon, 27 Aug 2018 18:05:17 -0700 (PDT)
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 APTvoBZ3Bpff for <dnsop@ietfa.amsl.com>; Mon, 27 Aug 2018 18:05:15 -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 9AA9F130F13 for <dnsop@ietf.org>; Mon, 27 Aug 2018 18:05:15 -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 761583AB03E; Tue, 28 Aug 2018 01:05:15 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1BA35160042; Tue, 28 Aug 2018 01:05:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7A07E16006C; Tue, 28 Aug 2018 01:05:07 +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 kQHG4dC2Qm9o; Tue, 28 Aug 2018 01:05:07 +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 6BF70160042; Tue, 28 Aug 2018 01:05:06 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAPt1N1=E4hJ9dfkoVzQtO7pm_0FMt1Us5DAnFRJ_UW=hNSZvFw@mail.gmail.com>
Date: Tue, 28 Aug 2018 11:05:04 +1000
Cc: Tom Pusateri <pusateri@bangj.com>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <430C7A36-C044-440F-B2A1-D030C9AC6297@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> <7259D997-7915-4664-AE6E-6DE20A08852E@bangj.com> <CAPt1N1k3fK4YsYUJG2zNvspPjdDxZsFsQb9eqMT1pXzoxrWDQQ@mail.gmail.com> <53E0A9E9-7E7B-4AD9-8739-BCEA08ED89D0@bangj.com> <5A2EEB89-1247-4848-938F-6A2A145A6542@fugue.com> <A17A617F-8D5D-4061-887F-4A7B9F32B1E6@isc.org> <CAPt1N1=E4hJ9dfkoVzQtO7pm_0FMt1Us5DAnFRJ_UW=hNSZvFw@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/OnZ7YLDYjMdgqsBSaTnMzI8nexw>
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: Tue, 28 Aug 2018 01:05:18 -0000

MS does something in the LDAP backend. It does however show that there is
a need for the functionality.

> On 28 Aug 2018, at 10:04 am, Ted Lemon <mellon@fugue.com>; wrote:
> 
> How do they handle that?
> 
> On Mon, Aug 27, 2018 at 8:02 PM Mark Andrews <marka@isc.org>; wrote:
> Active directory has each domain controller updating its own SRV record
> on the same <qname,qtype,qclass> tuple.  These updates happen at different
> times and need to expire if a domain controller becomes unreachable.
> 
> A different case is when you have multiple prefixes from different
> providers with different lifetimes.  You then end up with multiple AAAA
> records that need to expire at different times.
> 
> Mark
> 
> > On 28 Aug 2018, at 8:34 am, Ted Lemon <mellon@fugue.com>; wrote:
> > 
> > Sorry, I realized that I accidentally hit "reply" instead of "reply all."
> > 
> > The issue that I raised with Tom is that for the DNSSD SRP use case, the only names that receive updates from multiple services are service names (IOW, not service instance names).   In the case of SRP, PTR RRs in service names always point to service instance names, which are per-service, and hence can be counted on to expire on a single schedule.   So for the use case of SRP, the easiest way to handle deleting service name PTR RRs is to take advantage of the semantics of DNSSD: when a service instance SRV record expires, also delete the PTR RR on the service name that points to it.
> > 
> > The reason I bring this up is that it's the most complicated use case I know of.   Is there some other use case where we expect more than one DNS Update client to be updating RRs of the same type on the same name?   How would this even work without SRP semantics?   If this is not expected, then any complexity in the timeout RR that's present only to support that use case is unnecessary.
> > 
> > This is what has been motivating my questions about use cases.   I'm sorry I didn't make that clear earlier.
> 
> -- 
> 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