Clarification on Trust Anchor Kmyv6jo Validity and Resolver Behavior
Hi KSK Rollover Folks, I have a question regarding the inclusion of the trust anchor "Kmyv6jo" (Key Tag 38696) in the root-anchors.xml file with a validFrom date of 2024-07-18T00:00:00+00:00. According to this date, it appears the key is already valid for use. However, based on https://www.iana.org/dnssec/files, the key is scheduled to appear in the DNS root zone on January 11, 2025, and should not be trusted by resolvers using RFC 5011 mechanisms before February 10, 2025. Could you confirm if a resolver that periodically fetches root-anchors.xml and relies on the validFrom date can consider this key trusted as of today, without waiting for the RFC 5011 timing window? If there are any specific recommendations or risks associated with this approach, I would appreciate clarification. Thank you for your time and assistance. Best, Heizou
On 17 Nov 2024, at 05:45, Heizou via ksk-rollover <ksk-rollover@icann.org> wrote:
Hi KSK Rollover Folks,
I have a question regarding the inclusion of the trust anchor "Kmyv6jo" (Key Tag 38696) in the root-anchors.xml file with a validFrom date of 2024-07-18T00:00:00+00:00. According to this date, it appears the key is already valid for use. However, based on https://www.iana.org/dnssec/files, the key is scheduled to appear in the DNS root zone on January 11, 2025, and should not be trusted by resolvers using RFC 5011 mechanisms before February 10, 2025.
Could you confirm if a resolver that periodically fetches root-anchors.xml and relies on the validFrom date can consider this key trusted as of today, without waiting for the RFC 5011 timing window?
Periodically fetching the root-anchors.xml file, and the RFC5011 process are two independent processes. A key that is configured via fetching the XML file is valid from 2024-07-18. The validator will trust it as it is a configured trust anchor. A validator following the 5011 process will not see this key appear until 2025-01-11, will automatically configure it but not trust it until 2025-02-10, after which it is trusted. The two processes are not co-dependent.
If there are any specific recommendations or risks associated with this approach, I would appreciate clarification.
These two processes are there to support the various deployment scenarios that exist today. They complement each other and one is not a drop in substitution for the other. For instance, fetching the root-anchors.xml file (as described in RFC7958) is preferable when NO trust is established yet, as RFC5011 rollover works in a scenario when trust has already been established. I am not able to recommend a specific scenario or elaborate on risks associated with either scenario. Hope this helps Warmly Roy Arends
Thank you for your time and assistance.
Best, Heizou _______________________________________________ ksk-rollover mailing list -- ksk-rollover@icann.org To unsubscribe send an email to ksk-rollover-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (2)
-
Heizou -
Roy Arends