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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 18 May 2021 08:04:06 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-nsec-ttl-04: No Objection

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/

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

Regards,
Rob

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 18 May 2021 19:26:16 +0200

Hello Rob,

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.

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.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 19 May 2021 09:30:47 +0000

Hi Peter,

> -----Original Message-----
> From: Peter van Dijk <[email-masked]>
> Sent: 18 May 2021 18:26
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-
> nsec-ttl-04: (with COMMENT)
> 
> Hello Rob,
> 
> > 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.
> 
[RW] 
I think so, or at least I'm happy to defer to the WG's judgement here.

Thanks for the explanation.

Regards,
Rob