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" ? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
