Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-03.txt

From: [email-masked]
Date: Tue, 09 Feb 2021 12:17:58 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : NSEC and NSEC3 TTLs and NSEC Aggressive Use
        Author          : Peter van Dijk
	Filename        : draft-ietf-dnsop-nsec-ttl-03.txt
	Pages           : 9
	Date            : 2021-02-09

Abstract:
   Due to a combination of unfortunate wording in earlier documents,
   aggressive use of NSEC and NSEC3 records may deny names far beyond
   the intended lifetime of a denial.  This document changes the
   definition of the NSEC and NSEC3 TTL to correct that situation.  This
   document updates RFC 4034, RFC 4035, RFC 5155, and RFC 8198.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 09 Feb 2021 22:06:31 +0100

Hello dnsop,

thank you to all who responded in the WGLC thread. After the discussion
I felt I had nothing to ask or add, so instead, here is a draft
revision that I feel addresses everything that was said.

(Matthijs, this revision changes the requirements back to MUST as that
feels like it more closely matches the majority opinion voiced, but I
added a section allowing for the incremental signer situation - please
let me know if this is workable for you.)

My understanding of the discussion is that the document failed to
address various assorted vagueness, and separations between developer
and operator concerns, and role differences between signers,
authoritatives and resolvers/validators, in the original documents.
Paul Hoffman provided a bunch of text clarifying 'what goes where' so
that this document can improve that situation, thanks Paul!

Changes in this version, as listed in the Document History section:

* document now updates resolver behaviour in 8198
* lots of extra text to clarify what behaviour goes where (thanks Paul
Hoffman)
* replace 'any' with 'each' (thanks Duane)
* upgraded requirement level to MUST, plus a note on incremental
signers

Your comments are, again, very much welcome.

> ftp://ftp.ietf.org/internet-drafts/

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

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 10 Feb 2021 09:03:23 +0100

Peter,

Personally I still think we shouldn't change these SHOULDs to MUSTs. 
Quoting from RFC 2119:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

I think the text you provided on incremental signers is such a valid 
reason why we should use SHOULD here instead of MUST.

If the WG consensus is that this does need to change to a MUST then I 
would like to request the following adaptations to the draft.

- The text should update the updates to include the exception. For
   example:

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

- There should be a reason provided in the document why these SHOULD
   keywords are changed to a MUST.

Best regards,

Matthijs

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Feb 2021 15:58:20 +0000

On Feb 10, 2021, at 12:03 AM, Matthijs Mekking <[email-masked]> wrote:
> 
> Personally I still think we shouldn't change these SHOULDs to MUSTs. Quoting from RFC 2119:
> 
> I think the text you provided on incremental signers is such a valid reason why we should use SHOULD here instead of MUST.
> 
> If the WG consensus is that this does need to change to a MUST then I would like to request the following adaptations to the draft.
> 

The new wording in each of the SHOULD-to-MUST change seems fine, even if repetitive. It is good to put clarifying text near the source.

The SHOULD was changed to MUST for interoperability. That is, a resolver would not know whether this auth server was following the wiggly part of the spec without evaluating every response. The fact that the earlier documents used SHOULD without any qualification was a mistake, and we don't have to rub those authors' noses in it.

--Paul Hoffman