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

[Paul Wouters via Datatracker <[e-mail]>]

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?

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" ?