| RFC 9718 | Root Zone Trust Anchor Publication | January 2025 |
| Abley, et al. | Informational | [Page] |
The root zone of the global Domain Name System (DNS) iscryptographically signed using DNS Security Extensions (DNSSEC).¶
In order to obtain secure answers from the root zone of the DNS usingDNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors.¶
This document obsoletes RFC 7958.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9718.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The global Domain Name System (DNS) is described in[RFC1034] and[RFC1035].DNS Security Extensions (DNSSEC) are described in[RFC9364].¶
In the DNSSEC protocol, Resource Record Sets (RRsets) are signedcryptographically. This means that a response to a query containssignatures that allow the integrity and authenticity of the RRset tobe verified. DNSSEC signatures are validated by following a chain ofsignatures to a "trust anchor". The reason for trusting a trustanchor is outside the DNSSEC protocol, but having one or more trustanchors is required for the DNSSEC protocol to work.¶
The publication of trust anchors for the root zone of the DNS is anIANA function performed by ICANN, through its affiliate Public Technical Identifiers (PTI). A detailed description ofcorresponding key management practices can be found in[DPS].¶
This document describes the formats and distribution methods ofDNSSEC trust anchors that are used by IANA for the root zone ofthe DNS. Other organizations might have different formatsand mechanisms for distributing DNSSEC trust anchors for the rootzone; however, most operators and software vendors have chosen torely on the IANA trust anchors.¶
The formats and distribution methods described in this document are acomplement to, not a substitute for, the automated DNSSEC trustanchor update protocol described in[RFC5011]. That protocol allowsfor secure in-band succession of trust anchors when trust has alreadybeen established. This document describes one way to establish aninitial trust anchor that can be used by the mechanism defined in[RFC5011].¶
This document obsoletes[RFC7958].¶
The term "trust anchor" is used in many different contexts in thesecurity community. Many of the common definitions conflict becausethey are specific to a specific system, such as just for DNSSEC orjust for S/MIME messages.¶
In cryptographic systems with hierarchical structure, a trust anchor is anauthoritative entity for which trust is assumed and not derived. The formatof the entity differs in different systems, but all common uses of the term"trust anchor" share the basic idea that the decision to trust this entity ismade outside of the system that relies on it.¶
The root zone trust anchor formats published by IANA are defined inSection 2.[RFC4033] defines a trust anchor as a "configured DNSKEY RR or DS RR hash of a DNSKEY RR". Note that the formats defined here do not match the definition of "trust anchor" from[RFC4033]; however, a system that wants to convert the trusted material from IANA into a Delegation Signer (DS) RR can do so.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
IANA publishes trust anchors for the root zone as an XML[W3C.REC-xml11-20060816] document that contains the hashes of the DNSKEY recordsand optionally the keys from the DNSKEY records.¶
This format and the associated semantics are described inthe rest of this section.¶
Note that the XML document can have XML comments.For example, IANA might use these comments to add pointers to important information on the IANA website.XML comments are only used as human-readable commentary, not extensions to the grammar.¶
The XML document contains a set of hashes for the DNSKEY records thatcan be used to validate the root zone. The hashes are consistentwith the defined presentation format of a DS resource.¶
The XML document can also contain the keys and flags from the DNSKEY records.The keys and flags are consistent with the defined presentation format of a DNSKEY resource.¶
Note that the hashes are mandatory in the syntax, but the keys are optional.¶
Below is the RELAX NG Compact Schema[RELAX-NG] for the documents used to publish trust anchors:¶
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"start = element TrustAnchor { attribute id { xsd:string }, attribute source { xsd:string }, element Zone { xsd:string }, keydigest+}keydigest = element KeyDigest { attribute id { xsd:string }, attribute validFrom { xsd:dateTime }, attribute validUntil { xsd:dateTime }?, element KeyTag { xsd:nonNegativeInteger { maxInclusive = "65535" } }, element Algorithm { xsd:nonNegativeInteger { maxInclusive = "255" } }, element DigestType { xsd:nonNegativeInteger { maxInclusive = "255" } }, element Digest { xsd:hexBinary }, publickeyinfo?}publickeyinfo = element PublicKey { xsd:base64Binary }, element Flags { xsd:nonNegativeInteger { maxInclusive = "65535" } }¶TheTrustAnchor element is the container for all of the trust anchorsin the file.¶
Theid attribute in theTrustAnchor element is an opaque string thatidentifies the set of trust anchors. Its value has no particularsemantics. Note that theid attribute in theTrustAnchor element isdifferent than theid attribute in theKeyDigest element describedbelow.¶
Thesource attribute in theTrustAnchor element gives informationabout where to obtain theTrustAnchor container. It is likely to bea URL and is advisory only.¶
TheZone element in theTrustAnchor element states to which DNS zonethis container applies.TheZone element is in presentation format as specified in[RFC1035], including the trailing dot.The root zone is indicated by a singleperiod (.) character without any quotation marks.¶
TheTrustAnchor element contains one or moreKeyDigest elements.EachKeyDigest element represents the digest of a past, current, orpotential future DNSKEY record of the zone defined in theZone element.The values for the elements in theKeyDigest element are defined in[RFC4034].The IANA registries for DNSSEC-related values are described in[RFC9157].¶
Theid attribute in theKeyDigest element is an opaque string thatidentifies the hash.Note that theid attribute in theKeyDigest element is different thantheid attribute in theTrustAnchor element described above.¶
ThevalidFrom andvalidUntil attributes in theKeyDigest element specifythe range of times that theKeyDigest element can be used as a trust anchor.¶
TheKeyTag element in theKeyDigest element contains the key tag forthe DNSKEY record represented in thisKeyDigest.¶
TheAlgorithm element in theKeyDigest element contains the DNSSEC signingalgorithm identifier for the DNSKEY record represented in thisKeyDigest.¶
TheDigestType element in theKeyDigest element contains the DNSSEC digestalgorithm identifier for the DNSKEY record represented in thisKeyDigest.¶
TheDigest element in theKeyDigest element contains the hexadecimalrepresentation of the hash for the DNSKEY record represented in thisKeyDigest.¶
Thepublickeyinfo named pattern in theKeyDigest element contains two mandatory elements: the base64 representation of the public key for the DNSKEY record represented in thisKeyDigest and the flags of the DNSKEY record represented in thisKeyDigest. Thepublickeyinfo named pattern is optional and is new in this specification. It can be useful when IANA has a trust anchor that has not yet been published in the DNS root and for calculating a comparison to theDigest element.¶
The following is an example of what the trust anchor file might look like. The full public key is only given for a trust anchor that does not have avalidFrom time in the past.¶
<?xml version="1.0" encoding="UTF-8"?><TrustAnchor source="http://data.iana.org/root-anchors/root-anchors.xml"> <Zone>.</Zone> <KeyDigest validFrom="2010-07-15T00:00:00+00:00" validUntil="2019-01-11T00:00:00+00:00"> <!-- This key is no longer valid, since validUntil is in the past --> <KeyTag>19036</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest>49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 </Digest> </KeyDigest> <KeyDigest validFrom="2017-02-02T00:00:00+00:00"> <KeyTag>20326</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest>E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D </Digest> <PublicKey> AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4Rg WOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQ uCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj /EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Ap xz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXG Xws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= </PublicKey> <Flags>257</Flags> </KeyDigest> <!-- The following is called "KSK-2024" as a shorthand name --> <KeyDigest validFrom="2024-07-18T00:00:00+00:00"> <KeyTag>38696</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest>683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 </Digest> </KeyDigest></TrustAnchor>¶
The DS RRset derived from this example is:¶
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16¶
Note that this DS record set only has two records.A potential third record, one that includes the key tag 19036, is already invalid based on thevalidUntil attribute's value and is thus not part of the trust anchor set.¶
The DNSKEY RRset derived from this example is:¶
. IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=¶
Note that this DNSKEY record set only has one record.A potential second record, one based on the key tag 19036, is already invalid based on thevalidUntil attribute's value and is thus not part of the trust anchor set.Another potential second record, one based on the key tag 38696, does not contain the optionalpublickeyinfo named pattern; therefore, the DNSKEY record for it cannot be calculated.¶
Trust anchors are available for retrieval using HTTPS and HTTP.¶
In this section, all URLs are given using the "https:" scheme. IfHTTPS cannot be used, replace the "https:" scheme with "http:".¶
The URL for retrieving the set of hashes in the XML document described inSection 2 is<https://data.iana.org/root-anchors/root-anchors.xml>.¶
A validator operator can choose whether or not to accept the trustanchors described in this document using whatever policy they want.In order to help validator operators verify the content and origin oftrust anchors they receive, IANA uses digital signatures that chainto an ICANN-controlled Certificate Authority (CA) over the trustanchor data.¶
It is important to note that the ICANN CA is not a DNSSEC trustanchor. Instead, it is an optional mechanism for verifying thecontent and origin of the XML and certificate trust anchors.¶
The content and origin of the XML document can be verified using adigital signature on the file. IANA provides a detachedCryptographic Message Syntax (CMS)[RFC5652] signature that chains tothe ICANN CA with the XML document.This can be useful for validator operators who have received a copyof the ICANN CA's public key in a trusted out-of-band fashion.The URL for a detached CMS signaturefor the XML document is<https://data.iana.org/root-anchors/root-anchors.p7s>.¶
Another method IANA uses to help validator operators verify thecontent and origin of trust anchors they receive is to use theTransport Layer Security (TLS) protocol for distributing the trustanchors. Currently, the CA used for "data.iana.org" is well known,that is, one that is a WebTrust-accredited CA. If a systemretrieving the trust anchors trusts the CA that IANA uses for the"data.iana.org" web server, HTTPSSHOULD be used instead of HTTP inorder to have assurance of data origin.¶
IANA used to distribute trust anchors as a self-signed Pretty Good Privacy (PGP) messageand as a self-issued certificate signing request; this was described in[RFC7958].This document removes those methods because they rely on a trust modelthat mixes out-of-band trust of authentication keys with out-of-band trust of the DNSSEC root keys.Note, however, that cryptographic assurance for the contents of the trust anchor nowcomes from the Web PKI or the ICANN CA as described inSection 3.2.This cryptographic assurance is bolstered by informal comparisons made by users of thetrust anchors, such as software vendors comparing the trust anchor files they are using.¶
This document describes how DNSSEC trust anchors for the root zone ofthe DNS are published. Many DNSSEC clients will only configure IANA-issuedtrust anchors for the DNS root to perform validation. As aconsequence, reliable publication of trust anchors is important.¶
This document aims to specify carefully the means by which such trustanchors are published, with the goal of making it easier for thosetrust anchors to be integrated into user environments.Some of the methods described (such as accessing over the Webwith or without verifying the signature on the file) have different security properties;users of the trust anchor file need to consider these when choosing whether to load the set of trust anchors.¶
The body of this document does not specify any particular behavior for relying parties.Specifically, it does not say how a relying party should treat the trust anchor file as a whole.However, some of the contents of the trust anchor file require particular attention for relying parties.¶
validUntilNote that thevalidUntil attribute of theKeyDigest element is optional.If the relying party is using a trust anchor that has aKeyDigest elementthat does not have avalidUntil attribute, it can change to a trust anchorwith aKeyDigest element that does have avalidUntil attribute,as long as that trust anchor'svalidUntil attribute is in the future and theKeyTag,Algorithm,DigestType, andDigest elements of theKeyDigest are the same as those in the previous trust anchor.¶
Relying partiesSHOULD NOT use aKeyDigest outside of the time range givenin thevalidFrom andvalidUntil attributes.¶
Digest andpublickeyinfoAKeyDigest element can contain both aDigest and apublickeyinfo named pattern.If theDigest element would not be a proper DS record for a DNSKEY record represented by thepublickeyinfo named pattern,relying partiesMUST NOT use thatKeyDigest as a trust anchor.A relying party that wants to make such a comparison needs to marshal the elements of the DNSKEY record that became the DS record using the algorithm specified inSection 5.1.4 of [RFC4034].¶
Relying parties need to implement trust anchor matching carefully.A single trust anchor represented by aKeyDigest element can potentially change itsDigest andKeyTag values between two versions of the trust anchor file, for example, when the key is revoked or the flag value changes for some other reason.Relying parties that fail to take this property into account are at risk of using an incorrect set of trust anchors.¶
Relying parties that require the optionalpublickeyinfo named pattern to create trust anchors will store fewer trust anchors than those that only require aDigest element.Thus, two systems processing the same trust anchor file can end up with a different set of trust anchors.¶
Each time IANA produces a new trust anchor,itMUST publish that trust anchor using the format described in this document.¶
IANAMAY delay the publication of a new trust anchor for operational reasons,such as having a newly created key in multiple facilities.¶
When a trust anchor that was previously published is no longer suitable for use,IANAMUST update the trust anchor file accordingly by setting avalidUntil date for that trust anchor.ThevalidUntil attribute that is addedMAY be a date in the past or in the future, depending on IANA's operational choices.¶
More information about IANA's policies and procedures for how the cryptographic keys for the DNS root zone are managed(also known as "DNSSEC Practice Statements" or "DPSs")can be found at<https://www.iana.org/dnssec/procedures>.¶
[RFC7958] defined id-mod-dns-resource-record, value 70, which was added to the "SMI Security for PKIX Module Identifier" registry.This document does not use that identifier.¶
This document includes the following changes:¶
Made a significant technical change perErratum ID 5932.This change is in the seventh paragraph ofSection 2.2.¶
Added the optionalpublickeyinfo named pattern with two mandatory elements,PublicKey andFlags.¶
Removed the certificates and certificate signing mechanisms.¶
Removed the detached OpenPGP signature mechanism.¶
Updated the reference to the DNSSEC Practice Statement[DPS].¶
Stated explicitly that the XML documents might have XML comments in them.¶
Clarified the use of the detached CMS signature.¶
Updated theIANA Considerations section to indicate requirements on IANA.¶
Simplified the description of using thevalidFrom andvalidUntil attributes.¶
Added new security considerations.¶
Made some editorial changes.¶
The first Key Signing Key (KSK) for use in the root zone of the DNS wasgenerated at a key ceremony at the ICANN Key Management Facility(KMF) in Culpeper, Virginia, USA on 2010-06-16. This keyentered production during a second key ceremony held at anICANN KMF in El Segundo, California, USA on 2010-07-12.The resulting trust anchor was first published on 2010-07-15.¶
The second KSK for use in the root zone of the DNS wasgenerated at key ceremony #27 at the ICANN KMF in Culpeper, Virginia, USA on 2016-10-27.This key entered production during key ceremony #28 held atthe ICANN KMF in El Segundo, California, USA on 2017-02-02.The resulting trust anchor was first published on 2018-11-11.¶
More information about the key ceremonies,including full records of previous ceremonies and plans for future ceremonies,can be found at<https://www.iana.org/dnssec/ceremonies>.¶
Many pioneers paved the way for the deployment of DNSSEC in the root zone of the DNS, and the authors hereby acknowledge their substantial collective contribution.¶
RFC 7958 incorporated suggestions made byAlfred Hoenes andRuss Housley, whose contributions are appreciated.¶