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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to