You haven't specified how the hash is done, so I can't confirm the truth of your assertion that it's straightforward. :)
The "only if there are multiple record types" bit doesn't actually help, because I can't actually think of a case where it doesn't apply. That is, every RR will require a hash, as far as I can tell, in practice. 128 bits is 16 bytes—the size of an IPv6 address. It's probably true that that's shorter than the record in most cases, but I doubt it's enough shorter to make a difference. And we already know how to compare records—we need that for update. On Sun, Aug 26, 2018 at 1:58 PM Tom Pusateri <pusat...@bangj.com> wrote: > > > On Aug 26, 2018, at 1:47 PM, Tom Pusateri <pusat...@bangj.com> wrote: > > > > On Aug 26, 2018, at 12:58 PM, Ted Lemon <mel...@fugue.com> wrote: > > On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <pusat...@bangj.com> wrote: > >> I think I already agreed with you here. >> >> My main point was that the primary needs a database and it already has >> one and probably doesn’t want another one. Because of the added benefit >> that Paul points out with promoting a secondary to primary after an >> extended outage, and the points that Joe makes about treating all records >> the same, it seems logical to store the lease lifetime information as >> actual resource records and transfer them to the secondary. >> >> FWIW, I think the database storage argument is actually the best argument > for this proposal: we need a way to represent the data structure on disk, > and what we know how to store are RRs. > That said, I think that it's worth asking the question of what the right > format is, and not just assuming that it's a hash. > > > Nice properties of the hash: > > 1. the length of the output value is consistent across varying input > lengths of any RR type (128 bits in the case of the algorithm specified in > the draft) making it easy to sequence through. > 2. it’s independently verifiable between servers and across time on the > same server > 3. it’s independent of position of the RR it covers > 4. it works the same for all existing RR’s as well as RR’s yet to be > defined > > Other methods may share some of these properties but I’m just listing all > of the ones I can think of. > > > Also, remember the hash is only needed if there are multiple records types > with the same owner name / class having different timeouts (including no > timeout). > > So in the case of a unique name being added for a delegated address, the > NO HASH value can be used and no hash needs to be calculated. In the case > of both an IPv4 and IPv6 address being delegated and subsequently sending > an UPDATE with the same owner name, as long as the lease time is the same, > again, there is no need for the hash. > > If, however, an RRSIG is dynamically generated for the owner name, then > the hash will be needed. (You won’t want to timeout RRSIGs but instead > timeout the A/AAAA and then recalculate the RRSIG/NSEC/NSEC3/NSEC5 records.) > > Tom > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
