Subject: Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

From: Peter van Dijk <[email-masked]>
Date: Wed, 09 Dec 2020 22:34:43 +0100

Hello DNSOP,

On Mon, 2020-11-23 at 21:16 +0100, Peter van Dijk wrote:
> 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.

I believe this draft is non-controversial. I am inclined to see the lack of response as a lack of controversy as well.

Chairs, I believe this document could go through the motions to publication quite quickly if no objections appear. Can I request a call for adoption please?

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Dec 2020 21:54:57 +0000

> I believe this draft is non-controversial. I am inclined to see the lack of response as a lack of controversy as well.

Errrr, that was why I didn't respond: it is uncontroversial. I guess I should have said "Good catch! This update should be made to the docs listed".

> Chairs, I believe this document could go through the motions to publication quite quickly if no objections appear. Can I request a call for adoption please?

I support this being a quick WG document. I will contribute (likely minor) text and will review.

--Paul Hoffman

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 11 Dec 2020 11:22:56 -0500

Peter

After a read, I agree it's non-controversial.  I'll get moving on this.

tim

On Wed, Dec 9, 2020 at 4:35 PM Peter van Dijk <[email-masked]>
wrote:

> I believe this draft is non-controversial. I am inclined to see the lack
> of response as a lack of controversy as well.
>
> Chairs, I believe this document could go through the motions to
> publication quite quickly if no objections appear. Can I request a call for
> adoption please?
>
> Kind regards,
> --
> Peter van Dijk
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Vladimír Čunát <[email-masked]>
Date: Sat, 12 Dec 2020 11:46:46 +0100

Hello.

 From resolver point of view... this implies that signed *positive* 
wildcard answers will now get cached with this shorter "negative TTL", 
right?  These do need to deny existence of non-wildcard match, so they 
need to contain NSEC*.

Maybe the final text would better explicitly note such implications, but 
that certainly can wait way past WG adoption. Also it might be confusing 
that just by singing a zone the effective TTL of these answers would get 
lower - assuming I got your intention right (if not, perhaps the current 
text wasn't clear enough anyway).

--Vladimir @ Knot Resolver

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 18 Dec 2020 18:02:31 +0100

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