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

Ted Lemon <mellon@fugue.com> Mon, 27 August 2018 02:48 UTC

Return-Path: <mellon@fugue.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 C7629130E51 for <dnsop@ietfa.amsl.com>; Sun, 26 Aug 2018 19:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 5JYBd4C8Mq0r for <dnsop@ietfa.amsl.com>; Sun, 26 Aug 2018 19:48:07 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07099130E50 for <dnsop@ietf.org>; Sun, 26 Aug 2018 19:48:06 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id f17-v6so9566259qkh.4 for <dnsop@ietf.org>; Sun, 26 Aug 2018 19:48:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RTV6MMDDg6g7lcItaAffgwawJIWz2+8wt8Be3tOUUew=; b=URh5ohDprfuCkD2McpOSjkmzsnsS+gG1Ld2GODN3FJtXPWmzgVoi5C0nMMwJ56SDGm xByhXdRc/NlAhDVjKOzX7gUaoBAFEOYepXz7fNK03e1erC0gZ86ey8rjNmZBSZOEvqef yHETPIIBJ3yXaqoukVzkAGk7wXQEDQL7K2dS2qSWLM3iF0m+NN3DDz9G+PM57nfWSVho MIvDodJjQ1KzyKvHFZHP6e33c0oSjG4D5v1R2Xfa6553o0glbhH2MSJRHZVL9ZEpniGl tjRKpuk9I/lLo1WhVEMJCOt8zYdY2gRIBlNVUCzeeJETvs75EiETyBmgLG2wS7CHOXGB Ki7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RTV6MMDDg6g7lcItaAffgwawJIWz2+8wt8Be3tOUUew=; b=q0LFxytYhLZJXAfrN6u1XHAGd0Q9NB1UAhG/sCqb0uN8n4oguUouSiKpKqj6Y9dgUD C9ejw7DvOdPgOiiFcmUsC7biec4i5XoyQ0dtTlznsGy3CF1LDitCEU2zadKlOtkO+EeI ZMWKoXfTHBjpQ+OHUW6KA3E7ViMf0l0JL4Gl5gjXm3thB6M++qrQGVnVAyS1xoMCY74s DUnO5ajHYH72GIORll7hTnBhQlnH37GPSLwVNTCDVs6/wUBZfwuMQvoYf7z5cfWVE7yy aCQvke/NsTPgIhBpAZnQTgZ5vH9ysuHTnLJYIJex43iCLpfbOz/oiBsglMlfrps5C7aY ZEGQ==
X-Gm-Message-State: APzg51AuuZCmmQOZihk1yHd5jZR5Fuo7taP96QJGF8qDLdQx3X/Gs+/0 Gat2yEhwABVqNolNfs+iSbzoRQ==
X-Google-Smtp-Source: ANB0Vdb4sGBqli8/bT8oi1uXVNeYNQgXlEcVaI0KROlWYoDJvjAm8eADgF+0+JimCfZ6/RHVjkbLdQ==
X-Received: by 2002:a37:1204:: with SMTP id c4-v6mr2253711qkh.63.1535338085924; Sun, 26 Aug 2018 19:48:05 -0700 (PDT)
Received: from [10.0.100.12] (c-73-167-89-221.hsd1.ma.comcast.net. [73.167.89.221]) by smtp.gmail.com with ESMTPSA id d10-v6sm2293156qtc.53.2018.08.26.19.48.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Aug 2018 19:48:05 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <A3BB12A2-1159-40D6-8F24-96226F98E1F5@bangj.com>
Date: Sun, 26 Aug 2018 22:48:03 -0400
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6EBDFE8-2206-4F60-B4FA-DE2E16544209@fugue.com>
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>
To: Tom Pusateri <pusateri@bangj.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/l4k-zsH-Hk8wIjk5a6DJvI_yZQk>
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 02:48:10 -0000

SRP has to work.   We updated the DNS update lease spec to account for the different lease times; there may be further work to do there.   But the lease on the name and service instance name KEY records has to be able to be different than the lease on the other data—we want that data to expire quickly, but for the KEY to stick around for a while so that the name can't be claimed by a rogue service just because e.g. the printer is powered off right now.

> On Aug 26, 2018, at 10:22 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> 
> 
>> On Aug 26, 2018, at 8:12 PM, Ted Lemon <mellon@fugue.com> wrote:
>> 
>> The timeout isn't the same for DNSSD Registration Protocol.
> 
> Ok, this is a little detailed but let's take what the current draft says and be explicit about your particular SRP case. I think I am representing SRP correctly but if not, please correct me.
> 
> <srp>
> [1. One thing that’s not clear about SRP is if the same host registers more than one service, does your particular form of UPDATE (which isn’t standard UPDATE) have to contain the same A and/or AAAA records in both registrations and if so, what is the server to do about different lifetimes?]
> [2. Also, does SRP recommend including PTR records for name registrations of A & AAAA names? It doesn’t appear to but should it?]
> [3. I think you’re going to run into trouble having non-standard UPDATE rules.]
> (These are separate discussions about SRP for another forum and if you want to follow up on these, we should follow up on the dns-sd list.)
> </srp>
> 
> At the end, I’ll do the more simple case of just A & AAAA records.
> 
> Let’s assume 3 clients, all with the same service type (different service types will have different owner names). We will use _ipp._tcp.example.com as an example.
> 
> Client A sends a registration at time Ta with lease life L1a for PTR, SRV, A, AAAA, TXT records, lease life L2a for KEY record.
> Client B sends a registration at time Tb with lease life L1b for PTR, SRV, A, TXT records (no AAAA), lease life L2b for KEY record.
> Client C sends two different instances of the same service (different instance names) at time Tc with lease life L1c for PTR, SRV, A, AAAA, TXT records, lease life L2c for KEY record.
> 
> Client A’s UPDATE contains:
> 
> _ipp._tcp.example.com PTR p1._ipp._tcp.example.com
> p1._ipp._tcp.example.com SRV 0 0 631 p1.example.com
> p1._ipp._tcp.example.com TXT paper=A4
> p1.example.com  A  192.0.2.1
> p1.example.com  AAAA  2001:db8::1
> p1.example.com  KEY “key material here"
> 
> Client B's UPDATE contains:
> 
> _ipp._tcp.example.com PTR p2._ipp._tcp.example.com
> p2._ipp._tcp.example.com SRV 0 0 631 p2.example.com
> p2._ipp._tcp.example.com TXT paper=A4
> p2.example.com  A  192.0.2.2
> p2.example.com  KEY “key material here”
> 2.2.0.192.in-addr.arpa.                       PTR   p2.example.com.
> 2.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. PTR   p2.example.com. (using bytes instead of nibbles for compactness)
> 
> Client C's UPDATE contains two services at the same time with the same lease lifes:
> 
> _ipp._tcp.example.com PTR p3._ipp._tcp.example.com
> p3._ipp._tcp.example.com SRV 0 0 631 p3.example.com
> p3._ipp._tcp.example.com TXT paper=A4
> p3.example.com  A  192.0.2.3
> p3.example.com  AAAA  2001:db8::3
> p3.example.com  KEY “key material here”
> 
> _ipp._tcp.example.com PTR p4._ipp._tcp.example.com
> p4._ipp._tcp.example.com SRV 0 0 631 p4.example.com
> p4._ipp._tcp.example.com TXT paper=A4
> p4.example.com  A  192.0.2.4
> p4.example.com  AAAA  2001:db8::4
> p4.example.com  KEY “key material here”
> 
> The TIMEOUT records on the server would look like the following:
> (owner_name TIMEOUT count algorithm expire hash_list, count algorithm expire hash_list, etc.)
> 
> _ipp.tcp.example.com TIMEOUT 1 1 Ta+L1a (#hash for p1._ipp._tcp.example.com PTR record)
>                             1 1 Tb+L1b (#hash for p2._ipp._tcp.example.com PTR record)
>                             2 1 Tc+L1c (#hash for p3._ipp._tcp.example.com PTR record) (#hash for p4._ipp._tcp.example.com PTR record)
> 
> p1._ipp._tcp.example.com TIMEOUT 0 0 Ta+L1a
> 
> p2._ipp._tcp.example.com TIMEOUT 0 0 Tb+L1b
> 
> p3._ipp._tcp.example.com TIMEOUT 0 0 Tc+L1c
> 
> p4._ipp._tcp.example.com TIMEOUT 0 0 Tc+L1c
> 
> p1.example.com  TIMEOUT  2 1 Ta+L1a (#hash for 192.0.2.1 A record) (#hash for 2001:db8::1 AAAA record)
>                         1 1 Ta+L2a (#hash for p1.example.com KEY record)
> 
> p2.example.com  TIMEOUT  1 1 Tb+L1b (#hash for 192.0.2.2 A record)
>                         1 1 Tb+L2b (#hash for p2.example.com KEY record)
> 
> p3.example.com  TIMEOUT  2 1 Tc+L1c (#hash for 192.0.2.3 A record) (#hash for 2001:db8::3 AAAA record)
>                         1 1 Tc+L2c (#hash for p3.example.com KEY record)
> 
> p4.example.com  TIMEOUT  2 1 Tc+L1c (#hash for 192.0.2.4 A record) (#hash for 2001:db8::4 AAAA record)
>                         1 1 Tc+L2c (#hash for p4.example.com KEY record)
> 
> 2.2.0.192.in-addr.arpa.                       TIMEOUT 0 0 Tb+L1b
> 2.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. TIMEOUT 0 0 Tb+L1b (using bytes instead of nibbles for compactness)
> 
> 
> So, in general, for any one service registration without PTR records for addresses, you will create:
> 3 TIMEOUT records, 2 with a hash and 1 without a hash
> 
> or with PTR records for names included, you will create:
> 5 TIMEOUT records, 2 with a hash and 3 without a hash.
> 
> 
> For the simpler case, a host sending a name registration at time Tn for A & AAAA records with lease lifetime Ln would have an UPDATE that contains:
> 
> name_n.example.com                            A     192.0.2.5
> name_n.example.com                            AAAA  2001:db8::5
> 5.2.0.192.in-addr.arpa.                       PTR   name_n.example.com.
> 5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. PTR   name_n.example.com. (using bytes instead of nibbles for compactness)
> 
> None of the 3 TIMEOUT records on the server would contain a hash:
> 
> name_n.example.com                            TIMEOUT 0 0 Tn+Ln
> 5.2.0.192.in-addr.arpa.                       TIMEOUT 0 0 Tn+Ln
> 5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. TIMEOUT 0 0 Tn+Ln (using bytes instead of nibbles for compactness)
> 
> 
> Hope this makes things more clear.
> 
> Tom
> 
> 
>