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

[Tom Pusateri <[e-mail]>]

> On Aug 26, 2018, at 10:51 PM, Mark Andrews <[e-mail]> wrote:
> 
> I would add a covered type field to TIMEOUT (c.f. RRSIG).  I also wouldn’t have more than
> a single timeout per record.  I’m tempted to say a single hash as well.  If there is multiple
> timeouts per record then the blocks need to be sorted in timeout order.
> 
> Covered is there to reduce the number of RR’s that need to be hashed to remove a record.
> It will also reduce the size of IXFR’s as you don’t need to re-construct a new TIMEOUT
> record that covers every timeout at a name on each change.
> 
> For all records at a name is often more expensive that for all records of type covered.
> Name servers are optimised for looking up <name,type,class> tuples rather than <name,class>
> tuples.
> 
> Sorting of timeout blocks is so that you can look at the first timeout when working out
> which TIMEOUT needs to be processed first in a zone.
> 
> -- 
> Mark Andrews, ISC

We didn’t anticipate multiple lifetimes per record (although the current draft doesn’t prevent this). Things get tricky with multiple lifetimes on a record because if you keep the most future date only and then that record disappears, you may need to restore a less future date but if you didn’t keep it, you can’t. So keeping all the lifetimes is the only way to ensure you handle changes correctly.

Sorting the timeouts is a good idea.

Adding TYPE would increase the number of blocks but reduce the number of hashes needed. This might simplify SRP complexity. Some analysis is required to determine if this is a net benefit.

Thanks,
Tom