RFC 9718

DNSSEC Trust Anchor Publication for the Root Zone

📅 published January 2025, from ietf

RFC 9718: DNSSEC Trust Anchor Publication for the Root Zone 🦋

Part 1 of 3 💖

Okay bestie, first the header stuff, which is actually important because it tells you who wrote this and how official it is 💅

  • Number and title: RFC 9718, DNSSEC Trust Anchor Publication for the Root Zone ✨
  • Stream: Internet Engineering Task Force (IETF) 🌸
  • Category: Informational, so this is published for information and is not an Internet Standards Track spec 📚
  • Authors: J. Abley (Cloudflare), J. Schlyter (Kirei AB), G. Bailey (Independent), and P. Hoffman (ICANN) 👑
  • Date: January 2025 📅
  • ISSN: 2070-1721 🔢
  • Obsoletes: RFC 7958, so this one replaces it 🔄
  • Updates: the header doesn't list any RFCs being updated 🙈

Abstract

The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC). 🔐

To get secure answers from the root zone with DNSSEC, a client has to configure a suitable trust anchor. This document explains the format and the publication mechanisms IANA uses to hand out those DNSSEC trust anchors. 🦋

This document obsoletes RFC 7958. 🫶

Status of This Memo

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. ⚖️

Table of Contents 🗺️

1.  Introduction
  1.1.  Definitions
2.  IANA DNSSEC Root Zone Trust Anchor Format and Semantics
  2.1.  XML Syntax
  2.2.  XML Semantics
  2.3.  XML Example
3.  Root Zone Trust Anchor Retrieval
  3.1.  Retrieving Trust Anchors with HTTPS and HTTP
  3.2.  Accepting DNSSEC Trust Anchors
  3.3.  Changes in the Trust Model for Distribution
4.  Security Considerations
  4.1.  Security Considerations for Relying Parties
    4.1.1.  validUntil
    4.1.2.  Comparison of Digest and publickeyinfo
    4.1.3.  Different Outputs from Processing the Trust Anchor File
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Appendix A.  Changes from RFC 7958
Appendix B.  Historical Note
Acknowledgements
Authors' Addresses

1. Introduction 🌷

The global Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. DNS Security Extensions (DNSSEC) are described in [RFC9364]. 🌐

In DNSSEC, Resource Record Sets (RRsets) get signed cryptographically. That means a response to a query carries signatures, so you can verify that the RRset has integrity and authenticity. DNSSEC signatures are checked by following a chain of signatures back to a "trust anchor". Why you trust a trust anchor is decided outside the DNSSEC protocol, but you do need one or more trust anchors for DNSSEC to work at all. 🔗

Publishing trust anchors for the root zone of the DNS is an IANA function, performed by ICANN through its affiliate Public Technical Identifiers (PTI). The detailed key management practices are in [DPS]. 🏛️

This document describes the formats and distribution methods of the DNSSEC trust anchors IANA uses for the root zone. Other organizations might have their own formats and ways of distributing root zone trust anchors, but most operators and software vendors have chosen to rely on the IANA trust anchors. 💅

The formats and distribution methods here are a complement to the automated DNSSEC trust anchor update protocol in [RFC5011], not a substitute for it. That protocol handles secure in-band succession of trust anchors once trust has already been established. This document describes one way to set up an initial trust anchor that the mechanism in [RFC5011] can then use. 🔄

This document obsoletes [RFC7958]. 🫶

1.1. Definitions 📖

The term "trust anchor" gets used in lots of different contexts in the security world, and a lot of the common definitions clash because each one is tied to one specific system, like just DNSSEC or just S/MIME messages. 😵‍💫

In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative entity that trust is assumed for, not derived from. The format of that entity differs between systems, but every common use of "trust anchor" shares the core idea that the decision to trust the entity was made outside the system that relies on it. 🧠

The root zone trust anchor formats IANA publishes are defined in Section 2. [RFC4033] defines a trust anchor as a "configured DNSKEY RR or DS RR hash of a DNSKEY RR". Heads up: the formats defined here don't match the "trust anchor" definition from [RFC4033]. However, a system that wants to turn the trusted material from IANA into a Delegation Signer (DS) RR can totally do that. 🔁

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. 🎀

2. IANA DNSSEC Root Zone Trust Anchor Format and Semantics 👑

IANA publishes root zone trust anchors as an XML [W3C.REC-xml11-20060816] document. It contains hashes of the DNSKEY records and, optionally, the keys from those DNSKEY records. 🧁

The rest of this section covers that format and what it means. 🌸

Heads up, the XML document can include XML comments. IANA might use them to point you at important info on the IANA website. XML comments are only human-readable commentary, not extensions to the grammar. 💬

The XML document has a set of hashes for the DNSKEY records that can be used to validate the root zone. Those hashes match the defined presentation format of a DS resource. 🧩

The XML document can also carry the keys and flags from the DNSKEY records, and those match the defined presentation format of a DNSKEY resource. 🔑

Note that the hashes are mandatory in the syntax, but the keys are optional. ✨

2.1. XML Syntax 🧾

Here's the RELAX NG Compact Schema [RELAX-NG] for the documents used to publish trust anchors. It's giving formal, but it's the boss. 😤

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" } }

2.2. XML Semantics 🔍

Okay, here's what each piece of that schema actually means. This is the fun part, bestie. 🦋

The TrustAnchor element is the container for all of the trust anchors in the file. 📦

The id attribute on TrustAnchor is an opaque string that identifies the set of trust anchors, and its value has no particular semantics. Note that this id is different from the id attribute on the KeyDigest element, which is described below. 🆔

The source attribute on TrustAnchor tells you where to get the TrustAnchor container. It's likely to be a URL, and it's advisory only. 🗺️

The Zone element inside TrustAnchor says which DNS zone this container applies to. Zone is in the presentation format from [RFC1035], including the trailing dot. The root zone is written as a single period (.) character, no quotation marks. 🌍

TrustAnchor holds one or more KeyDigest elements. Each KeyDigest element is the digest of a past, current, or potential future DNSKEY record for the zone named in the Zone element. The values for the elements inside KeyDigest are defined in [RFC4034], and the IANA registries for DNSSEC-related values are described in [RFC9157]. 📚

The KeyDigest id attribute is an opaque string that identifies the hash. It's different from the id attribute on TrustAnchor, so don't mix them up. 🙈

The validFrom and validUntil attributes on KeyDigest specify the range of times that KeyDigest can be used as a trust anchor. ⏰

The KeyTag element in KeyDigest holds the key tag for the DNSKEY record that this KeyDigest represents. 🏷️

The Algorithm element in KeyDigest holds the DNSSEC signing algorithm identifier for that same DNSKEY record. ✍️

The DigestType element in KeyDigest holds the DNSSEC digest algorithm identifier for that DNSKEY record. 🧮

The Digest element in KeyDigest holds the hexadecimal representation of the hash for that DNSKEY record. 🔢

The publickeyinfo named pattern inside KeyDigest has two mandatory elements: the base64 representation of the public key for the DNSKEY record, and the flags of that DNSKEY record. publickeyinfo is optional, and it's new in this specification. It can be useful when IANA has a trust anchor that hasn't been published in the DNS root yet, and for calculating a comparison to the Digest element. 💖

2.3. XML Example ✨

okay so this is what the trust anchor file might look like 👀🦋 the full public key only shows up for a trust anchor that does NOT have a validFrom time in the past (ngl that's the main character detail)

<?xml version="1.0" encoding="UTF-8"?>
<TrustAnchor id="E9724F53-1851-4F86-85E5-F1392102940B"
  source="http://data.iana.org/root-anchors/root-anchors.xml">
  <Zone>.</Zone>
  <KeyDigest id="Kjqmt7v"
      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 id="Klajeyz" 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 id="Kmyv6jo" 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 the validUntil 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 the validUntil 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 optional publickeyinfo named pattern; therefore, the DNSKEY record for it cannot be calculated.

3. Root Zone Trust Anchor Retrieval 🧚

3.1. Retrieving Trust Anchors with HTTPS and HTTP

trust anchors are available for retrieval using HTTPS and HTTP 🌸

in this section, all URLs are given using the "https:" scheme. if HTTPS cannot be used, replace the "https:" scheme with "http:".

the URL for retrieving the set of hashes in the XML document described in Section 2 is https://data.iana.org/root-anchors/root-anchors.xml.

3.2. Accepting DNSSEC Trust Anchors

a validator operator can choose whether or not to accept the trust anchors described in this document using whatever policy they want 💅 to help validator operators verify the content and origin of the trust anchors they receive, IANA uses digital signatures that chain to an ICANN-controlled Certificate Authority (CA) over the trust anchor data.

it is important to note that the ICANN CA is not a DNSSEC trust anchor. instead, it is an optional mechanism for verifying the content and origin of the XML and certificate trust anchors. not a trust anchor, bestie 🙈

the content and origin of the XML document can be verified using a digital signature on the file. IANA provides a detached Cryptographic Message Syntax (CMS) [RFC5652] signature that chains to the ICANN CA with the XML document. this can be useful for validator operators who have received a copy of the ICANN CA's public key in a trusted out-of-band fashion. the URL for a detached CMS signature for the XML document is https://data.iana.org/root-anchors/root-anchors.p7s.

another method IANA uses to help validator operators verify the content and origin of the trust anchors they receive is to use the Transport Layer Security (TLS) protocol for distributing the trust anchors. currently, the CA used for "data.iana.org" is well known, that is, one that is a WebTrust-accredited CA. if a system retrieving the trust anchors trusts the CA that IANA uses for the "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in order to have assurance of data origin. 🔐✨

3.3. Changes in the Trust Model for Distribution

IANA used to distribute trust anchors as a self-signed Pretty Good Privacy (PGP) message and as a self-issued certificate signing request; this was described in [RFC7958]. this document removes those methods because they rely on a trust model that 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 now comes from the Web PKI or the ICANN CA as described in Section 3.2. this cryptographic assurance is bolstered by informal comparisons made by users of the trust anchors, such as software vendors comparing the trust anchor files they are using. 🫶

4. Security Considerations ⚠️

this document describes how DNSSEC trust anchors for the root zone of the DNS are published. many DNSSEC clients will only configure IANA-issued trust anchors for the DNS root to perform validation. as a consequence, reliable publication of trust anchors is important. this part is SERIOUS, no cap 😭

this document aims to specify carefully the means by which such trust anchors are published, with the goal of making it easier for those trust anchors to be integrated into user environments. some of the methods described (such as accessing over the Web with 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.

4.1. Security Considerations for Relying Parties

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. 👀

4.1.1. validUntil

note that the validUntil attribute of the KeyDigest element is optional. if the relying party is using a trust anchor that has a KeyDigest element that does not have a validUntil attribute, it can change to a trust anchor with a KeyDigest element that does have a validUntil attribute, as long as that trust anchor's validUntil attribute is in the future and the KeyTag, Algorithm, DigestType, and Digest elements of the KeyDigest are the same as those in the previous trust anchor.

relying parties SHOULD NOT use a KeyDigest outside of the time range given in the validFrom and validUntil attributes. ⏰

4.1.2. Comparison of Digest and publickeyinfo

a KeyDigest element can contain both a Digest and a publickeyinfo named pattern. if the Digest element would not be a proper DS record for a DNSKEY record represented by the publickeyinfo named pattern, relying parties MUST NOT use that KeyDigest 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 in Section 5.1.4 of [RFC4034].

relying parties need to implement trust anchor matching carefully. a single trust anchor represented by a KeyDigest element can potentially change its Digest and KeyTag 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. the drama, the stakes 💀🔥

4.1.3. Different Outputs from Processing the Trust Anchor File

relying parties that require the optional publickeyinfo named pattern to create trust anchors will store fewer trust anchors than those that only require a Digest element. thus, two systems processing the same trust anchor file can end up with a different set of trust anchors. 🌈

5. IANA Considerations 🎀

each time IANA produces a new trust anchor, it MUST publish that trust anchor using the format described in this document.

IANA MAY 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, IANA MUST update the trust anchor file accordingly by setting a validUntil date for that trust anchor. the validUntil attribute that is added MAY 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.

6. References 📚

6.1. Normative References 📚

6.2. Informative References 🔍

Appendix A. Changes from RFC 7958 📝

okay so this is the changelog, bestie 🦋 Here's everything that changed since RFC 7958:

  • Made a significant technical change per Erratum ID 5932 <https://www.rfc-editor.org/errata/eid5932>. This change is in the seventh paragraph of Section 2.2. 😭
  • Added the optional publickeyinfo named pattern with two mandatory elements, PublicKey and Flags. 🎀
  • 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 the IANA Considerations section to indicate requirements on IANA. 🌸
  • Simplified the description of using the validFrom and validUntil attributes. ✨
  • Added new security considerations. 🔥
  • Made some editorial changes. 💖

Appendix B. Historical Note 🕰️

ngl this is a lowkey iconic bit of history 👑 The first Key Signing Key (KSK) for use in the root zone of the DNS was generated at a key ceremony at the ICANN Key Management Facility (KMF) in Culpeper, Virginia, USA on 2010-06-16. That key entered production during a second key ceremony held at an ICANN 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 was generated 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 at the 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>. 🎀

Acknowledgements 🫶

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. Honestly, they're the real MVPs 👑

RFC 7958 incorporated suggestions made by Alfred Hoenes and Russ Housley, whose contributions are appreciated. 💜

Authors' Addresses ✉️

Joe Abley
Cloudflare
Amsterdam
Netherlands
Email: jabley@cloudflare.com

Jakob Schlyter
Kirei AB
Email: jakob@kirei.se

Guillaume Bailey
Independent
Email: guillaumebailey@outlook.com

Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
📦 where this page comes from