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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 18 May 2021 20:36:25 -0700

Benjamin Kaduk 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:
----------------------------------------------------------------------

I put a (small) handful of editorial suggestions up at
https://github.com/PowerDNS/draft-dnsop-nsec-ttl/pull/11 .

Section 3.1, etc.

   |  The TTL of the NSEC RR that is returned MUST be the lesser of the
   |  MINIMUM field of the SOA record and the TTL of the SOA itself.
   |  This matches the definition of the TTL for negative responses in
   |  [RFC2308].  A signer MAY cause the TTL of the NSEC RR to have a
   |  deviating value after the SOA record has been updated, to allow
   |  for an incremental update of the NSEC chain.

I don't think I understand what a "deviating value" would be (and in
which direction it would deviate).

Section 3.4

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

The original 8198 has "SHOULD reduce", but now we only have "MAY limit".
Why should the requirements level be weaker for the new, more-correct,
guidance?

Section 4

   If signers & DNS servers for a zone cannot immediately be updated to
   conform to this document, zone operators are encouraged to consider
   setting their SOA record TTL and the SOA MINIMUM field to the same
   value.  That way, the TTL used for aggressive NSEC and NSEC3 use
   matches the SOA TTL for negative responses.

Are there any negative consequences of such a move that would need to be
weighed against the stated benefits?

Section 8

Why is RFC 8174 only an informative reference?  Shouldn't it be given
the same treatment as RFC 2119?

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 19 May 2021 12:28:16 +0200

Hello Benjamin,

On Tue, 2021-05-18 at 20:36 -0700, Benjamin Kaduk via Datatracker

Thanks, I merged them!

> which direction it would deviate).

This sentence was added because some implementations may need time to
rework the whole NSEC/NSEC3 chain after a TTL change. The deviation
would be 'part of the chain still has the old, wrong, value - for a
while'. I'll ponder better words - suggestions are very welcome, of
course.

> Why should the requirements level be weaker for the new, more-correct,

Rob Wilton also raised this - please see my reply here: 
https://mailarchive.ietf.org/arch/msg/dnsop/pMPe-KcbWUrFVcITCf3fmGk5ztY/

> weighed against the stated benefits?

Signers might use either value (the SOA TTL or the SOA MINIMUM) as a
default for some other value. For example, PowerDNS uses the SOA
MINIMUM value as the TTL for DNSKEYs. So, lowering the SOA MINIMUM
would also lower the DNSKEY TTL (in PowerDNS).

A quick skim of the BIND dnssec-keygen manual page suggests that BIND
might sometimes take the SOA TTL as the DNSKEY TTL.

So, yes, there might be consequences. I will add a note.

> the same treatment as RFC 2119?

An oversight, already fixed in my local copy.

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

---

From: Job Snijders <[email-masked]>
Date: Wed, 19 May 2021 13:10:27 +0200

> while'. I'll ponder better words - suggestions are very welcome, of

Perhaps:

	Because some signers incrementally update the NSEC chain, a transient
	inconsistency between the observed and expected TTL MAY exist.

Kind regards,

Job

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 May 2021 08:58:15 -0700

Thanks, Job -- that looks better than anything I would have come up with!

-Ben

---

From: Peter van Dijk <[email-masked]>
Date: Thu, 20 May 2021 10:04:06 +0200

> while'. I'll ponder better words - suggestions are very welcome, of

I took Job's text for this, thanks Job!

I have now added this:

> Note that some signers might use the SOA TTL or MINIMUM as a default
for other values, like the TTL for DNSKEY records. Operators should
consult documentation before changing values.

Kind regards,