I’m not sure I understand your comment. I believe I just showed you how SRP does work in the existing draft. If I’ve somehow mis-understood how SRP works, please let me know.
Tom > On Aug 26, 2018, at 10:48 PM, Ted Lemon <mel...@fugue.com> wrote: > > 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 <pusat...@bangj.com> wrote: >> >> >>> On Aug 26, 2018, at 8:12 PM, Ted Lemon <mel...@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 >> >> >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
