Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Peter,


> -----Original Message-----
> From: Peter van Dijk <[e-mail]>
> Sent: 18 May 2021 18:26
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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/