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 <mel...@fugue.com> 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 <pusat...@bangj.com > <mailto:pusat...@bangj.com>> 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 <mel...@fugue.com >> <mailto:mel...@fugue.com>> wrote: >> >> If we do that, why do we need a hash at all? >> >> On Sun, Aug 26, 2018 at 10:51 PM Mark Andrews <ma...@isc.org >> <mailto:ma...@isc.org>> 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: ma...@isc.org >> <mailto:ma...@isc.org> >> > > _______________________________________________ > 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
