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, 06 Jan 2021 20:11:18 +0100

Hi Matthijs,

On Fri, 2020-12-18 at 18:02 +0100, Matthijs Mekking wrote:
> Hi Peter,
> 
> I reviewed the draft and it mostly looks good.

Thanks!

> Some minor comments:
> 
> 1. Perhaps instead of using ".com" as an example, use ".example" (per 
> RFC 2606)?

Noted at https://github.com/PowerDNS/draft-dnsop-nsec-ttl/issues/3

> 2. Shouldn't this document also update some text parts from RFC 8198?

Hmm. Obviously, some of the text in 8198 is wrong, but there is no
action for 8198 implementers here. Noted at 
https://github.com/PowerDNS/draft-dnsop-nsec-ttl/issues/4 for more
pondering.

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

Yes, that makes sense, it is relevant background. I took your text plus
something extra and put it at 
https://github.com/PowerDNS/draft-dnsop-nsec-ttl/pull/5

Thanks!

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

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 06 Jan 2021 21:01:41 +0100

Hello Vladimir,

On Sat, 2020-12-12 at 11:46 +0100, Vladimír Čunát wrote:
>  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*.

That depends on whether a resolver caches wildcards with the TTL of the
wildcard RRset, or of the NSECs proving that the wildcard expansion is
valid. My suspicion is that most resolvers today do the former, and
when they grow the 'aggressive NSEC for wildcards' feature, they'll
take MIN(former, latter).

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

Whether signing a zone lowers the TTL on an expanded wildcard depends entirely on the implementation - basically my previous paragraph in this email. I'd say the right approach is the MIN(..) from the previous paragraph.

However, I'm unsure what text the document should have about this. As in my response to Matthijs, the problem flows from 8198 but the problem is not in 8198. That said, we can always put more explanations in this document - perhaps even a Background section, and then I can shorten the Introduction section to only explain the core of the problem.
 
Kind regards,

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 8 Jan 2021 11:33:07 +0100

> take MIN(former, latter).

Well, if the client requests the proof (+dnssec), you have to include 
those NSEC*s and I'd consider it incorrect to prolong their TTL.  I'd be 
surprised if someone chose that lack of +dnssec could change this TTL 
behavior, except for implementations without DNSSEC support.  At least 
that's _my_ understanding of the current RFCs (even before 
DNSSEC-aggressive caching).

> However, I'm unsure what text the document should have about this. As in my response to Matthijs, the problem flows from 8198 but the problem is not in 8198. That said, we can always put more expla…

I had in mind adding a simple note about this (possible?) consequence, 
as I don't think it's completely obvious and it wasn't happening before 
implementing this RFC.

--Vladimir

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 13 Jan 2021 10:21:24 +0100

> DNSSEC-aggressive caching).

Ah yes, now I get it. The impact of NSEC TTL on wildcard validity is
not really something that 8198 did, or that this document does. This
document does, of course, change that TTL for some setups.

> as I don't think it's completely obvious and it wasn't happening before 

It took me a while to understand the question, but now that I get it, I
have found that at least one validator implementation does not
currently cap the TTL of expanded wildcards to the lowest TTL in the
proof. Now I wonder if that needs to be written down explicitly, and
whether that should also go into this document (which we would then
retitle 'NSEC(3) TTL clarifications'?).

Kind regards,

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 13 Jan 2021 10:28:48 +0100

> document does, of course, change that TTL for some setups.

I was wrong, 8198 says this:

   |  Once the records are validated, DNSSEC-enabled validating      |
   |  resolvers SHOULD use wildcards and NSEC/NSEC3 resource records |
   |  to generate positive and negative responses until the          |
   |  effective TTLs or signatures for those records expire.  

4035 only vaguely hints at it. So, a correct implementation of 8198
would get the TTLs right, but an implementer that only read other
documents might not realise that they should only keep the wildcard
around as long as the proof is valid - even though it is obvious once
you think about it :-)

That all said, I now no longer think we need to do a whole
update/clarification thing on this, but I will add a note to my
document saying that changing the NSEC TTL might affect wildcards, as
you requested earlier.

Kind regards,

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 13 Jan 2021 14:36:26 +0100

> document saying that changing the NSEC TTL might affect wildcards, as

Sounds good to me.  Thanks.

--Vladimir