Hi Peter,
> -----Original Message----- > From: Peter van Dijk <peter.van.d...@powerdns.com> > Sent: 18 May 2021 18:26 > To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org> > Cc: draft-ietf-dnsop-nsec-...@ietf.org; dnsop-cha...@ietf.org; > dnsop@ietf.org; tjw.i...@gmail.com > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop- > nsec-ttl-04: (with COMMENT) > > Hello Rob, > > On Tue, 2021-05-18 at 08:04 -0700, Robert Wilton via Datatracker wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Hi, > > > > Thanks for this document. > > > > Regarding: > > > > 3.4. Updates to RFC8198 > > > > [RFC8198] section 5.4 (Consideration on TTL) is completely replaced > > by the following text: > > > > | The TTL value of negative information is especially important, > > | because newly added domain names cannot be used while the negative > > | information is effective. > > | > > | Section 5 of [RFC2308] suggests a maximum default negative cache > > | TTL value of 3 hours (10800). It is RECOMMENDED that validating > > | resolvers limit the maximum effective TTL value of negative > > | responses (NSEC/NSEC3 RRs) to this same value. > > | > > | A resolver that supports aggressive use of NSEC and NSEC3 MAY > > | limit the TTL of NSEC and NSEC3 records to the lesser of the > > | SOA.MINIMUM field and the TTL of the SOA in a response, if > > | present. It MAY also use a previously cached SOA for a zone to > > | find these values. > > > > I'm not a DNS expert, and this is just a non binding comment, but I was > > wondering why it is only "MAY" limit the TTL on NSEC and NSEC3 records > to the > > lesser of the SOA.MINIMUM field and the TTL of the SOA in a response > rather > > than a "SHOULD". > > Thank you for your comment. > > The old text was this: > > > A resolver that supports aggressive use of NSEC and NSEC3 SHOULD reduce > the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM field in the > authority section of a negative response, if SOA.MINIMUM is smaller. > > but this text did nothing (this is also noted in section 1 of the draft), > as signers/authoritatives already took that TTL from the SOA.MINIMUM field > - which this document corrects. > > Furthermore, during WG discussion we realised that in many cases, a > validator handling NSEC/NSEC3 records would not have access to the > relevant SOA at all - for example, in wildcard responses. 'SHOULD' is > quite strong language for something that often is not even possible. [RW] I agree. > > And, finally, the MAY you ask about is behaviour that is only useful in > validators until signers/authoritatives become compliant with this draft. > It is a secondary measure (that the WG explicitly requested so as to > attempt to solve the problem in multiple places) that should become > irrelevant as signers (most of which already have software fixes pending, > merged, or released) get upgraded. > > I hope this answers your question; please let me know if not. [RW] I think so, or at least I'm happy to defer to the WG's judgement here. Thanks for the explanation. Regards, Rob > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
