Not true. You have PTR records with the same service name from multiple clients each with different RDATA and unique timeouts as I demonstrated yesterday in the example.
Tom > On Aug 27, 2018, at 3:27 PM, Ted Lemon <[email protected]> wrote: > > For service instance names, there is only one service. So there shouldn’t be > a problem. > > On Mon, Aug 27, 2018 at 2:28 PM Tom Pusateri <[email protected] > <mailto:[email protected]>> wrote: > Because even if you add TYPE, you have multiple PTR records (instance names) > with the same owner name, class, and type that can timeout differently. > > Tom > >> On Aug 26, 2018, at 11:20 PM, Ted Lemon <[email protected] >> <mailto:[email protected]>> wrote: >> >> If we do that, why do we need a hash at all? >> >> On Sun, Aug 26, 2018 at 10:51 PM Mark Andrews <[email protected] >> <mailto:[email protected]>> 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 >> <https://maps.google.com/?q=1+Seymour+St.,+Dundas+Valley,+NSW+2117,+Australia&entry=gmail&source=g> >> PHONE: +61 2 9871 4742 INTERNET: [email protected] >> <mailto:[email protected]> >> > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
