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

[Daniel Migault <[e-mail]>]

Hi Peter,

Thanks for the feedbacks. I agree that the idea of shortening the TTL based
on all TTLs of the chains may be too intrusive and not respect the
willingness of the authoritative server - which also needs to be taken into
account. One other reason we removed such recommendation was also that it
is not implemented and would somehow give the message that to operate a
resolver some checks remains to be implemented. I also discussed with ISP
for which that issue seemed acceptable. As a result we removed such
recommendations. The current draft only mentions the possibility to cap all
TTLs which is an existing mechanism enabled by default I think with a 1 day
default TTL.

I agree with the example you provide, and this is exactly the example I
think we started with. As far as I know, I do not think that mechanisms can
easily implement the mechanism you mention - which is very similar to the
one Viktor provided and the one we had initially in mind. I think the
reason is that a hash table is used to store the RRsets in the cache.  This
is why we came to shorten the TTL right before caching the RRSet. We
expected that mechanism to be easier to implement as there are already some
operations around the TTL ( like Hammer for example ). This discussion also
pushes us to avoid implementing non standard mechanisms - or at least to be
careful.

Yours,
Daniel

On Fri, May 19, 2023 at 5:18 AM Peter Thomassen <[e-mail]> wrote:

> Hi Daniel,
>
> On 5/18/23 02:26, Daniel Migault wrote:
> >     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,
>
> No, it is almost a defining feature of the DNS that it only gives
> eventually consistent responses. The DNS is not a real-time database.
>
> > 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...
>
> Some may find that unfortunate, but capping TTLs at the lowest value in
> the trust chain harms scalability.
>
> In addition, when resolvers apply various ways of "fixing" the auth's
> TTls, behavior will end up differing across the Internet. That harms
> interoperability and makes debugging harder.
>
> > this is seen by many MNOs as an issue.
>
> How can it be an issue if the zone operator declares that this is the TTL
> they want?
>
> It's completely legit for an auth to set a TTL of (say) 1 day, at the cost
> of slow updates, but with the benefit of more resiliency against short
> period of auth unreachability. Why take that flexibility away from them?
>
> > 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 ?
>
> There is no extra check. Imagine the following situation:
>
> Day 1
> - DS/DNSKEY TTL 1 hour, records fetched at 10:30am UTC
> - MX TTL 24 hrs, record fetched at 10:30am UTC
> - cache otherwise empty
>
> Day 2
> - DS/DNSKEY not currently in cache (expired 1 hour after the fetch on Day
> 1)
> - MX TTL is still valid! (until 10:30am)
>
> Imagine that some time in the morning of Day 2, the AAAA record is
> queried, let's say at 06:00am UTC. The DS/DNSKEY records are have long
> expired from the cache (on Day 1), so they will also be re-fetched in order
> to validate the AAAA response.
>
> If the DS and DNSKEY records turn out are the same as before, no problem.
> But let's say that the re-fetched the keys have changed completely since
> yesterday, for whatever reason. The resolver will then use the new key
> information to validate the AAAA response.
>
> And it is *now* that the resolver could say "oh, actually, I still have
> this MX record cached until 10:30am, but I know that the keys I used for
> its validation are no longer there". The resolver COULD then remove the MX
> record from the cache.
>
> This is very different from applying the minimum of the various TTLs: when
> you do that, the MX record would already have expired on Day 1 at 11:10am.
>
> I'm fine with resolvers doing that, but I'm not in favor of a general
> recommendation. It's primarily the zone maintainer's task to get their zone
> content in order.
>
> Best,
> Peter
>
> --
> https://desec.io/
>


-- 
Daniel Migault
Ericsson