- ksk-rollover - lists.icann.org

Updated Certificates for DNSSEC Trust Anchor Validation
by Andres Pavez May 29, 2026

May 29, 2026

Dear Colleagues, IANA has published a new Certificate Authority (CA) certificate that is used for validating the authenticity of the DNS root zone trust anchors file. This impacts those who verify the integrity of the DNS root zone trust anchors file (root-anchors.xml) using the detached signatures. Signatures chaining to the new certificate are expected to be published in 2028 at which time relying parties must validate using the new certificate. Both the current and new certificates are available at: https://data.iana.org/root-anchors/icannbundle.pem Considerations for updating the trust anchor are described in DNSSEC Trust Anchor Publication for the Root Zone (RFC 9718). Thank you, -- Andres Pavez Cryptographic Key Manager

1 0

Proposal for Root Zone KSK Algorithm Rollover
by Andres Pavez Feb. 3, 2026

Feb. 3, 2026

We would like to announce that the Proposal for Root Zone KSK Algorithm Rollover has been released for public comment and is available for review on the ICANN website: https://www.icann.org/en/public-comment/proceeding/proposed-root-ksk-algori… The proposal describes a multi-year plan to generate a new ECDSA Root KSK in 2027 and retire the RSA Root KSK by 2030. It includes: * Transitioning the DNS root KSK from RSA/SHA-256 to ECDSA P-256/SHA-256 * Following a traditional double-signing approach, with both algorithms running in parallel during the transition * Adjusting the RSA ZSK size from 2048 to 1536 bits prior to the transition, to reduce the possible need to truncation and retransmission over TCP. Community feedback on the methodology, timeline, operational readiness, and any additional risks is encouraged. The public comment period is open through 6 April 2026. Thanks, -- Andres Pavez Cryptographic Key Manager

1 0

Re: Reminder: New KSK Publication in DNS Root Zone
by Andres Pavez Jan. 7, 2025

Jan. 7, 2025

Please note that there is a mistake with the time in my previous email. The new Key Signing Key (KSK) will be published in the DNS root zone on January 11 around 06:00 UTC, not 00:00 UTC as originally stated. Best regards, -- Andres Pavez Cryptographic Key Manager On 1/7/25, 11:30, "Andres Pavez via ksk-rollover" <ksk-rollover(a)icann.org <mailto:ksk-rollover@icann.org>> wrote: This is a reminder that the new Key Signing Key (KSK) will be published in the DNS root zone starting January 11 at 00:00:00 UTC. This will start the process of adoption of this trust anchor in RFC 5011 aware resolvers. We encourage operators to pay attention during this process to monitor for any unexpected consequences. Publishing the KSK is part of the process of ensuring widespread adoption of the KSK prior to its use in signing, currently scheduled for October 2026. For more details, please visit: https://www.iana.org/dnssec/files <https://www.iana.org/dnssec/files> Thanks, -- Andres Pavez Cryptographic Key Manager

1 0

Reminder: New KSK Publication in DNS Root Zone
by Andres Pavez Jan. 7, 2025

Jan. 7, 2025

This is a reminder that the new Key Signing Key (KSK) will be published in the DNS root zone starting January 11 at 00:00:00 UTC. This will start the process of adoption of this trust anchor in RFC 5011 aware resolvers. We encourage operators to pay attention during this process to monitor for any unexpected consequences. Publishing the KSK is part of the process of ensuring widespread adoption of the KSK prior to its use in signing, currently scheduled for October 2026. For more details, please visit: https://www.iana.org/dnssec/files Thanks, -- Andres Pavez Cryptographic Key Manager

1 0

Clarification on Trust Anchor Kmyv6jo Validity and Resolver Behavior
by Heizou Nov. 17, 2024

Nov. 17, 2024

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

2 1

Upcoming changes to the DNSSEC root trust anchor
by Andres Pavez Nov. 5, 2024

Nov. 5, 2024

Dear Colleagues, We are reaching out to inform you of important changes to the DNSSEC trust anchor in the root zone. If you manage a validating DNS resolver or a tool that interacts with the DNS root zone you might need to change your software to handle the changes. This letter provides a summary of the upcoming changes and gives pointers to resources that describe them in detail. *Upcoming addition of the KSK-2024 trust anchor* On January 11, 2025, a new trust anchor, codenamed KSK-2024, will appear in the root zone for the global DNS. This key was generated earlier this year and will co-exist with the current trust anchor, codenamed KSK-2017. The new DNSKEY record is: . 172800 IN DNSKEY 257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/c idltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHb GiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+s iFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqp dVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ 1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUe ayffKC73PYc= As a result of this addition, some DNS responses may be larger during the transition period. If your software uses the RFC 5011 process for managing trust anchors, KSK-2024 will be automatically trusted about one month after its introduction to the root zone. There are two important planned dates: * October 11, 2026: KSK-2024 will begin signing the root zone. * January 11, 2027: KSK-2017 is scheduled to be revoked. For a detailed description of the rollover process, please refer to https://www.iana.org/dnssec/files *New trust anchor file* IANA has issued a new trust anchor file using the updated XML format described in https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/ , which has recently been approved to be published as an RFC. The new trust anchor file contains additional data that was not provided in previous versions of the file. If your software or processes use the IANA trust anchor file (published at https://data.iana.org/root-anchors/root-anchors.xml ), you should ensure you have processes to retrieve it regularly (such as weekly) and check your systems can process the revised format of the file. *Keep in touch* Operational announcements regarding trust anchors and rollovers are published on the root-dnssec-announce mailing list at https://lists.icann.org/postorius/lists/root-dnssec-announce.icann.org/ . A separate ksk-rollover mailing list is a forum for discussion specific to rollovers can be found at https://lists.icann.org/postorius/lists/ksk-rollover.icann.org/ . Best regards, -- Andres Pavez Cryptographic Key Manager

1 0

Update to DNSSEC trust anchors
by James Mitchell July 24, 2024

July 24, 2024

IANA has published an update to the trust anchors for DNSSEC at https://www.iana.org/dnssec/files. This update adds a new key that is planned to be used to sign the DNS root zone starting in 2026. Software vendors and system package maintainers are encouraged to begin their processes for distributing this new trust anchor. The new trust anchor is currently available in a format suitable for constructing a DS record. The file is expected to be expanded in October 2024 to add data for also constructing the associated DNSKEY record. We plan to pre-publish the new KSK in the DNS starting on 11 January 2025, with a standby period of nearly two years before a rollover in October 2026. This provides ample opportunity to propagate the new trust anchor, and also provides the capability to roll to it sooner should an emergency rollover be required. Kind regards, James Mitchell Director IANA Technical Services

1 0

Policies and procedures for Root KSK operations
by Micha Bailey March 5, 2024

March 5, 2024

Is there any estimate for when updated versions of the [various policies, procedures, etc.](https://www.iana.org/dnssec/procedures) are expected to be published, addressing the changes that are necessary to accommodate the HSM migration? It seems to me that significant parts of the concept need to be reworked. If I understand correctly, today the RKSHs hold a copy of the SMK, which otherwise exists only on (and is exportable from) the HSMs, and is used to allow for the use of the key backup that only exists in the KMFs alongside the HSMs, such that the only scenario in which RKSHs are in play would be some catastrophic event that destroys/tampers all HSMs while not physically destroying the KMFs to the extent that the application backup cards are inaccessible. With the new HSMs seemingly allowing backups exclusively to other HSMs, which presumably would not be any more hardened/less volatile than the main operational ones when it comes to environmental factors, is the RKSH role still relevant? As far as I can tell, the new HSMs don’t have any type of credential that would be required in a backup recovery situation that wouldn’t be similarly required in more mundane scenarios such as normal replacement of HSMs over the lifespan of the keys. Hypothetically there could be dedicated backup HSMs, with CO credentials held exclusively by the RKSHs, but that would seem to not align with the general concepts that seem to underlie the processes in place, which prioritize availability and tamper-*evidence *over strict security (e.g. with the CO credentials themselves all being stored onsite, in order to explicitly allow for forced entry, drilling, etc. when there’s no better option). The only scenario that comes to mind is would be if backup HSMs were introduced that would be stored offsite, outside the KMFs, whereby the RKSHs would provide an additional level of security, but that doesn’t sound particularly likely.

2 3

Thales Luna Credentials questions
by Will Tubby March 4, 2024

March 4, 2024

Hi, I have a few questions about the key cards. >From looking at the document linked in response to mike I believe that the CO and SO cards act the same as they did on the Keyper. It also appears that the AAK and APP cards are combined to form the domain cards. Is this correct? I can not seem to find an alternative to the OP cards, is there a reason for this. Additionally I can not seem to find a replacement for SMK cards. I attempted to investigate myself and found that when the SMK cards were used to set up a new HSM only 3 cards were used and they were already in the KMF. I thought that SMK cards are held by RKSHs and that 5 are required, not 3. Also a backup HSM is mentioned in the document. Is this in place of an APP card? What credentials will be required to transfer a KSK to a new HSM? What credentials will be required to apply existing cards to a new HSM? What credentials will be required to decrypt the KSK backup? Kind Regards Will

4 6

ICANN to generate new KSK
by James Mitchell March 4, 2024

March 4, 2024

ICANN has announced the schedule to generate the next KSK. Generating a new KSK restarts the process announced last year, which was suspended after it was identified that a supplier of key equipment used to store the KSK (known as a Hardware Security Module, or HSM) would be exiting the business during the expected lifespan of the new KSK. The next KSK will be generated on new Thales Luna USB G7 HSMs. The announcement and information regarding the new HSMs is published at https://www.icann.org/en/announcements/details/icann-to-generate-new-dns-cr…. James Mitchell IANA

5 6