On Aug 23, 2018, at 11:44 PM, Tom Pusateri <pusat...@bangj.com> wrote: > An RRset isn’t granular enough because the components of the set could come > from different clients with different timeout values. > Therefore, a unique identifier is needed for each record. The hash provides > that unique identifier since it is calculated over the entire record > including the unique RDATA.
The hash stuff seems like a premature optimization. I can think of two other ways to do this: either just send the contents of the RR, or use an index into the RRset and define a sorting order. Bearing in mind that there's no reason for any server to store this data internally as anything other than an additional tuple in the RR itself, hashes may be the least efficient way to implement this. Remember that for zone transfers, either you transfer the whole zone, or you transfer the differences, and in either case the zone contents for any zone serial number should always be the same. Another question to ask here is, what is the application for this? If it's just for DNSSD Registration, then it might be better to implement it in a less general way. It would be worth scoping this before saying that it has to be done this way. When Stuart and I talked about this, we had a much simpler model in mind; your model is certainly more general, but who's the customer? I'm not saying your model is wrong, just that we ought to discuss it explicitly. If a zone is signed, are the TIMEOUT records signed? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
