Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On 7 Sep 2023, at 13:56, Paul Wouters via Datatracker <noreply@ietf.org> wrote:
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-dnsop-caching-resolution-failures-07: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this document and my apologies for being involved/related to two
> of the five outages you described :-)
> 
> 
>        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?

The server shouldn’t be caching the RRset and it’s RRSIGs unless they validate
successfully.  This is a requirement of DNSSEC.  This is also why recursive
servers need to validate responses so that garbage is not cached.

> If so, is there value stating this in the document?
> 
> 
>        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?
> 
>        To prevent such unnecessary DNS traffic, security-aware resolvers
>        MUST cache DNSSEC validation failures, with some restrictions.
> 
> What are these "some restrictions" ?
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org