Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Ted Lemon <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>
>>
>>
>> On Aug 26, 2018, at 1:47 PM, Tom Pusateri <[e-mail]> wrote:
>>
>>
>>
>> On Aug 26, 2018, at 12:58 PM, Ted Lemon <[e-mail]> wrote:
>>
>> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <[e-mail]> 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
>>
>>
>>