> On 7 Sep 2023, at 13:56, Paul Wouters via Datatracker <nore...@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: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
