On Wed, 2021-01-13 at 10:21 +0100, Peter van Dijk wrote: > On Fri, 2021-01-08 at 11:33 +0100, Vladimír Čunát wrote: > > 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). > > 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.
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, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
