By the way, the SRP case looks messy because SRP chooses to have different lease lifetimes for KEY records. If the lease lifetimes were all the same, as I would expect for most UPDATES, everything would be simpler.
Tom > 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
