> On Sep 6, 2023, at 8:56 PM, Paul Wouters via Datatracker <nore...@ietf.org>
> wrote:
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this document and my apologies for being involved/related to two
> of the five outages you described :-)
Ha! :-)
>
>
> Consistent with [RFC2308], resolution failures MUST NOT be cached
> for longer than 5 minutes.
>
> If an expired RRSIG has a TTL of 3600, what should happen? The resolution
> failed because the signature is no longer valid but the individual
> components of this validation failure are all successful lookups of RRs that
> are now in the cache. Wouldn't this result in a resolution failure of
> 3600? How would an implementation limit this to 5 minutes? By deleting
> the RRSIG from its cache within 5 minutes, overriding its TTL?
>
> If so, is there value stating this in the document?
Section 4.7 of RFC 4035 talks about the “BAD cache” where an implementation can
cache data with invalid signatures. It says:
o Since RRsets that fail to validate do not have trustworthy TTLs,
the implementation MUST assign a TTL. This TTL SHOULD be small,
in order to mitigate the effect of caching the results of an
attack.
I would expect an implementation to treat an expired signature the same
as described here, and not cache it for the full 3600 seconds in your
example, but rather the TTLs we talk about in this draft, from 1-300 seconds
(ideally with backoff).
>
>
> also known as 'lame'
>
> I thought the WG agreed the definition of 'lame' was not agreed upon and
> the term is no longer being favoured for use. Why not just remove this part?
In this text where lame appears we are simply quoting RFC 4697. Given the
can of worms that was the lame delegation discussion, we are somewhat
reluctant to write more about it in this document. Although we could make
a reference to the new terminology document if you think that would be helpful.
>
> To prevent such unnecessary DNS traffic, security-aware resolvers
> MUST cache DNSSEC validation failures, with some restrictions.
>
> What are these "some restrictions" ?
>
Here our intention is to update this statement from RFC 4035 so that MAY
becomes MUST and "invalid signatures" becomes "validation failures while
leaving the "some restrictions" in place. AFAICT the restrictions that 4035
talks about are using short TTLs (as above) and (I think) to have some
query threshold for caching validation failures. i.e., retry before
caching.
DW
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
