Trust Anchors and Keys
The Root Key Signing Key acts as the trust anchor for DNSSEC for the Domain Name System. This trust anchor is configured in DNSSEC-aware resolvers to facilitate validation of DNS data.
This page contains data on the trust anchors for the DNS, as well as information on operational plans to change these keys (events known as key rollovers).
Root Zone Trust Anchors
IANA distributes an XML file containing the details of the trust anchor set, which validating resolvers can use to verify DNS root zone data.
File | Description |
---|---|
root-anchors.xml | DNS Root Trust Anchors Updated 2024-07-24 |
root-anchors.p7s | Signature to verify the DNS Root Trust Anchors file (S/MIME) |
icannbundle.pem | Additional ICANN certificates for validating S/MIME signature |
Validators should keep this data up-to-date. Consider the following:
- Operators of validating resolvers and other end-users of the DNSSEC trust anchors should follow their vendor's instructions for updating the trust anchors. Vendors will differ in how and when they distribute updates according to their requirements for distributing trust anchors.
- Many software packages and systems will be configured to automatically update their trust anchors using the mechanism described in Automated Updates of DNS Security (DNSSEC) Trust Anchors (RFC 5011). This mechanism establishes trust for the new key based on a period of observing the new key in the DNS root zone, signed by the current key.
- Software vendors often package and distribute up-to-date trust anchors through their regular software update mechanisms.
- The format of the XML file is documented in DNSSEC Trust Anchor Publication for the Root Zone (draft-ietf-dnsop-rfc7958bis)
- For this who download the data directly from IANA, there is a simple download assistant tool available.
Key Status
This table provides additional guidance on how keys have been issues and used. Software implementers should rely on the XML trust anchors file for normative parameters on keys.
Informal Name | Status | Details |
---|---|---|
KSK-2024 | Pre-Publication | Generated 2024-04-26 (attestation) with key tag 38696 and label Kmyv6jo. Expected to be published in DNS on 2025-01-11, and actively signing starting 2026-10-11. |
KSK-2017 | Active | Generated 2016-10-27 (attestation) with key tag 20326 and label Klajeyz. Signing since 2018-10-11. |
KSK-2023 | Abandoned | Generated 2023-04-27 (attestation) with key tag 46211 and label Kmrfl3b. Will not be used, superseded by KSK-2024. |
KSK-2010 | Retired | Generated 2010-06-16 (attestation) with key tag 19036 and label Kjqmt7v. Signing between 2010-07-15 and 2018-10-11. |
Rollovers
The process of changing the signing key is known as a rollover. Rollovers are important process in the management of DNSSEC, ensuring the ongoing security of the protocol as the cryptographic landscape evolves.
We plan an idealized three-year rollover interval, publishing the key in the DNS for about two years in a standby state before the rollover.
The three-year rollover strikes a responsible balance ensuring that procedures and software remain sufficiently agile to adopt new keys as they are commissioned, while not introducing too much operational complexity through overly-frequent changes to the KSK. The standby period will allow a lengthy pre-publication and consequently allow for the new KSK’s earlier use if there is a need to expedite a rollover.
Keep informed
Operational announcements regarding trust anchors and rollovers are published on the root-dnssec-announce mailing list. A separate ksk-rollover mailing list is a forum for discussion specific to rollovers.
Major updates will also be communicated thorough ICANN’s announcement channels.