Hi Peter, Thanks for the response. I think I need to understand better how revalidation is performed.
Yours, Daniel On Wed, May 17, 2023 at 4:26 PM Peter Thomassen <pe...@desec.io> wrote: > 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 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. > > I agree but if a DRO can implement some mechanism that avoids the cache to remain incoherent, I think that is good - especially in a situation where many different zones are involved. Typically, the DRO remains the one serving responses and if one says: the cache does not reflect what I see on the authoritative side... this is seen by many MNOs as an issue. > 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. > > By forcing a refresh I meant respecting the TTL, not an emergency roll-over. This at least provides a limit for the RRset. > > 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. > Then, do we have an easy way to implement Viktor's revalidation ? TTL cap is at least a (costly) way to implement it. > > 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. > Then I might be missing how this could be implemented. How do we check that the validation will fail? Does the resolver check the key tags for every response ? > > The extra field also could also be misconfigured, such as having a > mistakenly long value. What then? > > Just to clarify, the field I was referring to was the DS, DNSKEY TTL of the RRSet. The field is not sent over the network, but a field in the resolver database. > Thanks, > Peter > > -- > https://desec.io/ > -- Daniel Migault Ericsson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
