Re: [DNSOP] [Technical Errata Reported] RFC6781 (6692)

I am going to assume that the DNSKEY of this zone is not a trust anchor.

So it is going to use the DS RRset, not a cached DNSKEY RRset, to 
authenticate the child zone's apex DNSKEY RRset (the one from the 
response). Then from RFC 4035:

  o  The matching DNSKEY RR in the child zone has the Zone Flag bit
     set, the corresponding private key has signed the child zone's
     apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
     child zone's apex DNSKEY RRset.

I read this as the cached DNSKEY RRset does not come into play when 
validating the DNSKEY RRset from the response, and any implementation 
that does otherwise is not compliant.

- Matthijs

On 24-09-2021 15:01, Paul Wouters wrote:
> On Fri, 24 Sep 2021, Matthijs Mekking wrote:
> 
>> Second, I believe the corner case you mentioned is for Figure 15 (the 
>> one in Appendix D), and I don't understand the scenario you are 
>> describing. What do you mean with "the resolver getting the DNKSEY 
>> RRset for NS_B would not contain a valid key for the DNSKEY RRset of 
>> NS_B". I think the resolver would get a new DNSKEY RRset with a 
>> pre-fetch (or if the DNSKEY RRset was expired from cache) and that 
>> would be validated with the DNSKEY from the response.
> 
> If it has a valid unexpired DNSKEY RRset, and a resolver fetches that
> DNSKEY RRset again, will it use the cached DNSKEY RRset or the DNSKEY RRset
> from the fetched record set to validate the signature against the cached
> DS RRset ? Or is this implementation specific?
> 
> Paul
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop