Wes,
On 06-09-17 18:05, Wes Hardaker wrote:
> Matthijs Mekking <matth...@pletterpet.nl> writes:
>
> Thanks for all your points, and I've gone through and handled them all
> in the text (including discussing that we update 7583 per your request).
>
>> 2. waitTime only adds one queryInterval, while Itrp adds two. I believe
>> to be safe on the publishing side, two queryIntervals is needed. RFC
>> 7583 explains:
>>
>> A validator will treat it as a trust anchor the next
>> time it retrieves the RRset, a process that can take up to another
>> queryInterval (the third term).
>
> This is the one that had me think with a whiteboard for a while. If I
> can sum it up differently, the problem is that 30 days may not be a
> factor of the queryInterval. Thus:
But it is:
queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
1/2*RRSigExpirationInterval))
Since the 5011-enabled resolver should see at least two queries with the
new trust anchor, the 15 days (30/2) is in the above equation defined in
RFC 5011.
> N * queryInterval >= >
> Where N is the number of queries to get somewhere over 30 days.
Sure, but N does not need to be higher than two, and in that case:
2 * queryInterval = MAX(2 hr, MIN (30 days, OrigTTL,
RRSigExpirationInterval))
In other words, never more than 30 days.
> So Irtp is waiting an extra queryInterval to account for this
> possibility.
Right, and since it is a possibility, it should be taken into account.
An important observation is that once the add hold-down timer expires,
the new key will be added as a trust anchor *only* the next time the
validated RRset with the new key is seen at the resolver.
This is the reason why the second queryInterval must be part of the
equation.
> Mathematically, I think the actually time needed to wait is 30 %
> queryInterval, which may actually be 0 in some cases and just shy of
> queryInterval in others. Sound about right?
I am sorry, I don't understand this logic, can you elaborate?
The way I see it, queryInterval is always at minimal 1 hr and at most 15
days (not taking into account retryTime).
Best regards,
Matthijs
>> 4. Both definitions (Itrp and waitTime) don't really take into
>> consideration the retryTime defined in RFC 5011. Perhaps that can be
>> used for defining the extra safety margin.
>
> I'll have to add some text about that. I don't think we can solve the
> case for broken networks, though. But it's an important point to bring up.
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
