Hi Peter,
I reviewed the draft and it mostly looks good. Some minor comments:
1. Perhaps instead of using ".com" as an example, use ".example" (per
RFC 2606)?
2. Shouldn't this document also update some text parts from RFC 8198?
3. About this paragraph:
Ralph Dolmans helpfully pointed out that fixing this in RFC8198 is
only possible for negative (NXDOMAIN/NoData NOERROR) responses, and
not for wildcard responses.
I think it deserves a separate section or subsection within section 4,
and not be tucked away in the acknowledgements.
Also this should be a bit more verbose, it took me three times to
understand what is exactly said here.
Proposed text:
[RFC 8198] says:
With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL
of the NSEC/NSEC3 record and the SOA.MINIMUM field are the
authoritative statement of how quickly a name can start working
within a zone.
Here, the SOA.MINIMUM field cannot be changed to "the minimum of the
SOA.MINIMUM field and the SOA TTL" because the resolver may not have
the SOA RRset in cache. However, if authoritative servers follow the
updates from this document, this should not make a difference, as the
TTL of the NSEC/NSEC3 record is already set to the minimum value.
Ralph can of course still be acknowledged for the helpful pointer.
- Matthijs
On 23-11-2020 21:16, Peter van Dijk wrote:
Hello,
in
https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/017420.html
(and earlier messages in March on the same thread), people realised
that aggressive NSEC caching might use a much longer TTL than the
negative TTL intended by a zone operator.
The initial idea was to correct this in an erratum to RFC 8198
(aggressive use of NSEC/NSEC3), but Ralph Dolmans pointed out to me
that this would not solve the wildcard case.
I did a lightning talk on the topic at OARC 29 (
https://indico.dns-oarc.net/event/29/sessions/98/#20181013), where the
audience feedback, as I recall it, was agreeable to my suggestion of
'issuing operational guidance'.
I have since come to the conclusion that it would be better to also fix
this in software. Hence, please find below my draft that updates one
sentence in 4034 and the ~same sentence in 5155. As far as I can see,
no correction to 8198 is necessary or useful.
Any editorial comments are welcome via GitHub (link is in the draft),
private email, or this WG list. Any functional comments on the content,
please post them to the WG. Thank you.
(Warren, if you feel the wording of my acknowledgement lays blame with
you in a way that you'd rather not see immortalised in an RFC, please
let me know!)
Kind regards,
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
