NSEC and NSEC3: TTLs and Aggressive Use
draft-ietf-dnsop-nsec-ttl-05

[Ballot 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?

[Ballot 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

[Ballot comment]
Please make RFC 8174 a normative reference rather than an informative one.  (RFC 2119 already is, but the two documents together make up BCP 14, so I don't think you can split them as was done here.)

[Ballot comment]
Thank to Tiru Reddy for the SECDIR review.

Section 5.  Per:

An attacker can prevent future records from appearing in a cache by
  seeding the cache with queries that cause NSEC or NSEC3 responses to
  be cached, for aggressive use purposes.  This document reduces the
  impact of that attack in cases where the NSEC or NSEC3 TTL is higher
  than the zone operator intended.

Shouldn’t this text read s/An attacker can prevent future records/An attacker can delay future records/?  Per Section 9 of RFC8198, “If the resolver is making aggressive use of NSEC/NSEC3, one successful attack would be able to suppress many queries for new names, up to the negative TTL."  If the timing is right, this delay could be indefinite.  Isn't the mitigation provided here that the attacker needs to seed the cache more often?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-nsec-ttl-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

For the following, two existing registrations:

TYPE: NSEC
Value: 47
Meaning: NSEC

TYPE: NSEC3
Value: 50
Meaning: NSEC3

the references for these registrations will have [ RFC-to-be ] added to the existing reference information.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

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

Working Group Summary:

Working group consensus was strong.

Document Quality:

While these are updates to existing standards, there is an implementation section where
open source software has implemented this.

Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is solid.  There was one issue raised by Mr. StJohn on this
being a standards track document.  We believe the author worked through these issues but we wanted
the IESG to be aware of this, and welcome any guidance on the issue:
https://mailarchive.ietf.org/arch/msg/dnsop/bGJmfwLZQPBH7K72lQ8mOf3-s7k/


(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFCs 4034. 4035, and 5155, and they are in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate.

(18) There are no new IANA registries, only an update to the "Domain Name System
(DNS) Parameters" registry to reference this document.


(19) N/A

(20) No Yang Necessary

The following Last Call announcement was sent out (ends 2021-05-04):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-nsec-ttl@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (NSEC and NSEC3 TTLs and NSEC Aggressive Use) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'NSEC and NSEC3 TTLs and NSEC
Aggressive Use'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-05-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/



No IPR declarations have been submitted directly on this I-D.

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

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

Working Group Summary:

Working group consensus was strong.

Document Quality:

While these are updates to existing standards, there is an implementation section where
open source software has implemented this.

Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is solid.  There was one issue raised by Mr. St John on this
being a standards track document.  We believe the author worked through these issues but we wanted
the IESG to be aware of this, and welcome any guidance on the issue:
https://mailarchive.ietf.org/arch/msg/dnsop/bGJmfwLZQPBH7K72lQ8mOf3-s7k/


(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFCs 4034. 4035, and 5155, and they are in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate.

(18) There are no new IANA registries, only an update to the "Domain Name System
(DNS) Parameters" registry to reference this document.


(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

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

Working Group Summary:

Working group consensus was strong.

Document Quality:

While these are updates to existing standards, there is an implementation section where
open source software has implemented this.

Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is solid.  There was one issue raised by Mr. St John on this
being a standards track document.  We believe the author worked through these issues but we wanted
the IESG to be aware of this, and welcome any guidance on the issue:
https://mailarchive.ietf.org/arch/msg/dnsop/bGJmfwLZQPBH7K72lQ8mOf3-s7k/


(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFCs 4034. 4035, and 5155, and they are in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate.

(18) There are no new IANA registries, only an update to the "Domain Name System
(DNS) Parameters" registry to reference this document.


(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

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

Working Group Summary:

Working group consensus was strong.

Document Quality:

While these are updates to existing standards, there is an implementation section where
open source software has implemented this.

Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFCs 4034. 4035, and 5155, and they are in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate.

(18) There are no new IANA registries, only an update to the "Domain Name System
(DNS) Parameters" registry to reference this document.


(19) N/A

(20) No Yang Necessary