Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Peter Thomassen <[e-mail]>]

Hi Daniel,

On 5/17/23 22:01, Daniel Migault wrote:
> I agree but as far as can see the cap of the TTL with a revalidation will not only resync the resolver and the zone more often than could be expected otherwise but does not result in the cached RRsets differing from those provided by the zone.

These two things are not the responsibility of the resolver. It is precisely the task of the TTL to set the expectation for expiry and, when changes are made, for the convergence time to eventual consistency.

> That said, it provides the opportunity to the zone admin to eventually force that refresh in case of a mistakenly long TTL value.

Triggering sudden refetches before TTL expiry is costly. I think that cases where the TTL is misconfigured are better addressed by requesting a cache flush manually from the resolver operator.

> Now one reason I think we also came to the cap, was that though we know tweaking the TTL is possible, I had in mind that adding a field like in our case the 'revalidation TTL' was much harder. Can we assume such a mechanism can realistically be implemented ?

Such a new field would be a big change.

That said, I still don't understand what it's needed for: it seems that it's just not necessary to do revalidation / refetches (= early expiry) after the minimum of TTL_RRset and all of the TTL_DNSKEY, TTL_DS in the chain; you can achieve the same output reliability by doing it when a change in the trust chain is detected and validation would otherwise fail.

The extra field also could also be misconfigured, such as having a mistakenly long value. What then?

Thanks,
Peter

-- 
https://desec.io/