BTW, another way to address this in terms of storage (which wouldn't help with zone transfers) would be to simply extend the zone format to allow a way to specify a timeout per RR.
On Sun, Aug 26, 2018 at 3:42 PM Ted Lemon <mel...@fugue.com> wrote: > 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
