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
