NSEC and NSEC3: TTLs and Aggressive Use
draft-ietf-dnsop-nsec-ttl-05
Yes
Erik Kline
Warren Kumari
No Objection
Francesca Palombini
John Scudder
Éric Vyncke
(Alvaro Retana)
(Lars Eggert)
Note: This ballot was opened for revision 04 and is now closed.
Erik Kline
Yes
Warren Kumari
Yes
Francesca Palombini
No Objection
John Scudder
No Objection
Murray Kucherawy
No Objection
Comment
(2021-05-17 for -04)
Sent
Roman Danyliw
No Objection
Comment
(2021-05-20)
Sent for earlier
Thank to Tiru Reddy for the SECDIR review. Thanks for addressing my COMMENT feedback.
Éric Vyncke
No Objection
Alvaro Retana Former IESG member
No Objection
No Objection
(for -04)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2021-05-18 for -04)
Sent
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?
Lars Eggert Former IESG member
No Objection
No Objection
(for -04)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(2021-05-07 for -04)
Sent
No need for a response on these: Please expand TTL and SOA on first use.
Robert Wilton Former IESG member
No Objection
No Objection
(2021-05-18 for -04)
Sent
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