On 1/6/21 9:01 PM, Peter van Dijk wrote:
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).
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).
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.
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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
