RFC 9718: DNSSEC Trust Anchor Publication for the Root Zone | RFC Editor

The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC).¶
In order to obtain secure answers from the root zone of the DNS using DNSSEC, 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 at https://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 signed cryptographically. This means that a response to a query contains signatures that allow the integrity and authenticity of the RRset to be verified. DNSSEC signatures are validated by following a chain of signatures to a "trust anchor". The reason for trusting a trust anchor is outside the DNSSEC protocol, but having one or more trust anchors is required for the DNSSEC protocol to work.¶
The publication of trust anchors for the root zone of the DNS is an IANA function performed by ICANN, through its affiliate Public Technical Identifiers (PTI). A detailed description of corresponding key management practices can be found in [DPS].¶
This document describes the formats and distribution methods of DNSSEC trust anchors that are used by IANA for the root zone of the DNS. Other organizations might have different formats and mechanisms for distributing DNSSEC trust anchors for the root zone; however, most operators and software vendors have chosen to rely on the IANA trust anchors.¶
The formats and distribution methods described in this document are a complement to, not a substitute for, the automated DNSSEC trust anchor update protocol described in [RFC5011]. That protocol allows for secure in-band succession of trust anchors when trust has already been established. This document describes one way to establish an initial 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 the security community. Many of the common definitions conflict because they are specific to a specific system, such as just for DNSSEC or just for S/MIME messages.¶
In cryptographic systems with hierarchical structure, a trust anchor is an authoritative entity for which trust is assumed and not derived. The format of 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 is made outside of the system that relies on it.¶
The root zone trust anchor formats published by IANA are defined in Section 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 records and optionally the keys from the DNSKEY records.¶
This format and the associated semantics are described in the 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 that can be used to validate the root zone. The hashes are consistent with 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:¶
The TrustAnchor element is the container for all of the trust anchors in the file.¶
The id attribute in the TrustAnchor element is an opaque string that identifies the set of trust anchors. Its value has no particular semantics. Note that the id attribute in the TrustAnchor element is different than the id attribute in the KeyDigest element described below.¶
The source att