> On Aug 24, 2018, at 9:11 AM, Ted Lemon <[email protected]> wrote: > > On Aug 23, 2018, at 11:44 PM, Tom Pusateri <[email protected]> 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.
We thought about sorting and indexing but that seemed way more error prone and not as general. The hash is a general solution that works well for these immediate uses and for any future uses that we can’t anticipate. It also provides the basis of a unique identifier that could be used for other non-related DNS extensions that need a unique identifier, so this code could be re-used. With the current libraries available, it’s not particularly complicated or onerous. > 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. > Yes, it was intended to be more general than for service registration. It’s directly applicable to name registration for IP addresses. I can add a section on other uses if more motivation is desired. Mark Andrews had some uses as well that hopefully, he can share. If others have uses in mind that this solves I would love to hear about them. > If a zone is signed, are the TIMEOUT records signed? > No. The draft says they are skipped. Thanks, Tom _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
