RFC 7958

DNSSEC Trust Anchor Publication for the Root Zone

📅 published August 2016, from ietf

DNSSEC Trust Anchor Publication for the Root Zone 🌸

okay bestie, let's get into RFC 7958 🎀 Here's the title block tea:

  • It's Request for Comments: 7958 and it's an Informational doc, so it's not a Standards Track spec 📚
  • It came in through the Independent Submission stream (ISSN 2070-1721)
  • It was published in August 2016
  • The authors are J. Abley (Dyn, Inc.), J. Schlyter (Kirei AB), G. Bailey (Independent), and P. Hoffman (ICANN) ✨
  • It doesn't obsolete or update any other RFCs, so it's a solo main character 💅

Abstract

The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC) 🔐

So to get secure answers from the root zone with DNSSEC, a client has to configure a suitable trust anchor 🦋 This doc explains the format and the publication mechanisms IANA has used to hand out those DNSSEC trust anchors 💖

Status of This Memo

This document isn't an Internet Standards Track specification. It's published for informational purposes 🧚

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about how useful it is for implementation or deployment 🙈 Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for the details 🍓

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7958.

Copyright (c) 2016 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 (http://trustee.ietf.org/license-info), as in effect on the date it was published. Please read those carefully, because they spell out your rights and restrictions for this document 📜

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
2.  IANA DNSSEC Root Zone Trust Anchor Formats and Semantics  . .   4
  2.1.  Hashes in XML . . . . . . . . . . . . . . . . . . . . . .   4
    2.1.1.  XML Syntax  . . . . . . . . . . . . . . . . . . . . .   5
    2.1.2.  XML Semantics . . . . . . . . . . . . . . . . . . . .   5
    2.1.3.  Converting from XML to DS Records . . . . . . . . . .   7
    2.1.4.  XML Example . . . . . . . . . . . . . . . . . . . . .   8
  2.2.  Certificates  . . . . . . . . . . . . . . . . . . . . . .   8
  2.3.  Certificate Signing Requests  . . . . . . . . . . . . . .   9
3.  Root Zone Trust Anchor Retrieval  . . . . . . . . . . . . . .   9
  3.1.  Retrieving Trust Anchors with HTTPS and HTTP  . . . . . .   9
4.  Accepting DNSSEC Trust Anchors  . . . . . . . . . . . . . . .  10
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
Appendix A.  Historical Note  . . . . . . . . . . . . . . . . . .  14
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction ✨

The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. DNS Security Extensions (DNSSEC) are described in [RFC4033], [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702] 🧠

There's also a discussion of operational practices for DNSSEC in [RFC6781] 🛠️

In the DNSSEC protocol, Resource Record Sets (RRSets) get signed cryptographically. That means a response to a query carries signatures that let you verify the integrity and authenticity of the RRSet 🔏 DNSSEC signatures are validated by following a chain of signatures back to a "trust anchor" 🪝 Why you trust a trust anchor is outside the DNSSEC protocol, but you do need one or more trust anchors for DNSSEC to work at all, no cap 😭

The trust anchors for the DNS root zone are published as an IANA function that ICANN performs. You can read a detailed description of the key management practices in [DPS], which lives in the IANA Repository at <https://www.iana.org/dnssec/> 📖

This document describes the formats and distribution methods of DNSSEC trust anchors that IANA has used for the DNS root zone since 2010. Other organizations might use different formats and mechanisms for distributing DNSSEC trust anchors for the root zone. Still, most operators and software vendors have chosen to rely on the IANA trust anchors 👑

Important heads up: when this was written, IANA planned to change the formats and distribution methods in the future. If that happens, IANA will post the changes on its website at <https://www.iana.org/dnssec/files> 🚨

The formats and distribution methods in this document are a complement to the automated DNSSEC trust anchor update protocol in [RFC5011], not a substitute for it. That protocol allows 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 [RFC5011] can then use 🦋

1.1. Definitions

The term "trust anchor" gets used in lots of different contexts in the security community 🌈 A bunch of the common definitions conflict because each one is specific to a particular system, like just DNSSEC or just S/MIME messages.

In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative entity whose trust is assumed and not derived 🧚 The format of that entity differs between systems, but the core idea, that trust is assumed and not derived, is shared by all the common uses of "trust anchor" 💜

The root zone trust anchor formats that 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 though: the formats defined here don't match the definition of "trust anchor" from [RFC4033]. A system that wants to turn the trusted material from IANA into a Delegation Signer (DS) RR can still do that, though 🔁

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📏

2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics 🎀

IANA publishes trust anchors for the root zone in three formats:

  • an XML document that contains the hashes of the DNSKEY records
  • certificates in PKIX format [RFC5280] that contain DS records and the full public key of DNSKEY records
  • Certificate Signing Requests (CSRs) in PKCS #10 format [RFC2986] that contain DS records and the full public key of DNSKEY records

The rest of this section describes these formats and the semantics that go with each one 💅

2.1. Hashes in XML

The XML document holds a set of hashes for the DNSKEY records that can be used to validate the root zone. The hashes match the defined presentation format of DS resource records from [RFC4034] 🫶

2.1.1. XML Syntax

Here's the RELAX NG Compact Schema [RELAX-NG] for the documents IANA uses to publish trust anchors. It's Figure 1 🧁

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

Figure 1

2.1.2. XML Semantics

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 element in the TrustAnchor element is different from the id element in the KeyDigest element, which we'll get to below 🙈

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

The Zone element in the TrustAnchor element says which DNS zone this container applies to. The root zone is shown as a single period (.) character without any quotation marks 🌍

The TrustAnchor element contains one or more KeyDigest elements. Each KeyDigest element represents the digest of a DNSKEY record in the zone named in the Zone element 🍓

The id attribute in the KeyDigest element is an opaque string that identifies the hash. Its value is used in the file names and URIs of the other trust anchor formats, which is described in Section 3.1. For example, if the id attribute in the KeyDigest element is "Kjqmt7v", the URI for the CSR tied to this hash will be <https://data.iana.org/root-anchors/Kjqmt7v.csr>. Again, the id element in the KeyDigest element is different from the id element in the TrustAnchor element described above 🦋

The validFrom and validUntil attributes in the KeyDigest element specify the range of times when the KeyDigest element can be used as a trust anchor. The KeyDigest element's validUntil is optional. If it isn't given, the trust anchor can be used until a KeyDigest element covering the same DNSKEY record, but having a validUntil attribute, is trusted by the relying party ⏳ Relying parties SHOULD NOT use a KeyDigest outside of the time range given in the validFrom and validUntil attributes 🚫

The KeyTag element in the KeyDigest element holds the key tag for the DNSKEY record represented in this KeyDigest 🏷️

The Algorithm element in the KeyDigest element holds the signing algorithm identifier for the DNSKEY record represented in this KeyDigest 🔑

The DigestType element in the KeyDigest element holds the digest algorithm identifier for the DNSKEY record represented in this KeyDigest 🧮

The Digest element in the KeyDigest element holds the hexadecimal representation of the hash for the DNSKEY record represented in this KeyDigest 💜

2.1.3. Converting from XML to DS Records 🎀

okay so if you want the DS record display format that matches a KeyDigest element, you just marshal the KeyTag, Algorithm, DigestType, and Digest elements together. ✨ Let's say the TrustAnchor element contains:

<?xml version="1.0" encoding="UTF-8"?>
<TrustAnchor
   id="AD42165F-3B1A-4778-8F42-D34A1D41FD93"
   source="http://data.iana.org/root-anchors/root-anchors.xml">
<Zone>.</Zone>
<KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00">
<KeyTag>19036</KeyTag>
<Algorithm>8</Algorithm>
<DigestType>2</DigestType>
<Digest>
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
</Digest>
</KeyDigest>
</TrustAnchor>

The DS record would be:

. IN DS 19036 8 2
   49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

2.1.4. XML Example 💜

Figure 2 describes two fictitious trust anchors for the root zone. bestie, this one is so pretty 😭

<?xml version="1.0" encoding="UTF-8"?>

<TrustAnchor
    id="AD42165F-B099-4778-8F42-D34A1D41FD93"
    source="http://data.iana.org/root-anchors/root-anchors.xml">
    <Zone>.</Zone>
    <KeyDigest id="42"
               validFrom="2010-07-01T00:00:00-00:00"
               validUntil="2010-08-01T00:00:00-00:00">
        <KeyTag>34291</KeyTag>
        <Algorithm>5</Algorithm>
        <DigestType>1</DigestType>
        <Digest>c8cb3d7fe518835490af8029c23efbce6b6ef3e2</Digest>
    </KeyDigest>
    <KeyDigest id="53"
               validFrom="2010-08-01T00:00:00-00:00">
        <KeyTag>12345</KeyTag>
        <Algorithm>5</Algorithm>
        <DigestType>1</DigestType>
        <Digest>a3cf809dbdbc835716ba22bdc370d2efa50f21c7</Digest>
    </KeyDigest>
</TrustAnchor>

Figure 2

2.2. Certificates 🦋

okay so each public key that can be used as a trust anchor shows up as a certificate in PKIX format. Every certificate gets signed by the ICANN certificate authority 💅 The SubjectPublicKeyInfo in the certificate represents the public key of the Key Signing Key (KSK). The Subject field has these attributes:

  • O: the string "ICANN".
  • OU: the string "IANA".
  • CN: the string "Root Zone KSK" followed by the time and date of key generation in the format specified in [RFC3339]. For example, a CN might be "Root Zone KSK 2010-06-16T21:19:24+00:00".
  • resourceRecord: a string in the presentation format of the DS [RFC4034] resource record for the DNSSEC public key.

The "resourceRecord" attribute in the Subject is defined as follows:

ResourceRecord
  { iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS

caseIgnoreMatch FROM SelectedAttributeTypes
    { joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 }

;

iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
    dod(6) internet(1) private(4) enterprise(1) 1000 }

iana-dns OBJECT IDENTIFIER ::= { iana 53 }

resourceRecord ATTRIBUTE ::= {
    WITH SYNTAX IA5String
    EQUALITY MATCHING RULE caseIgnoreMatch
    ID iana-dns
}

END

2.3. Certificate Signing Requests 🌸

okay so each public key that can be used as a trust anchor also shows up as a CSR in PKCS #10 format. The SubjectPublicKeyInfo and Subject field are the same as for certificates (see Section 2.2 above). Same vibes, different format ✨

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 described in Section 2.1 is <https://data.iana.org/root-anchors/root-anchors.xml>.

The URL for retrieving the PKIX certificate described in Section 2.2 is <https://data.iana.org/root-anchors/KEYDIGEST-ID.crt>, with the string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest element from the XML file, as described in Section 2.1.2.

The URL for retrieving the CSR described in Section 2.3 is <https://data.iana.org/root-anchors/KEYDIGEST-ID.csr>, with the string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest element from the XML file, as described in Section 2.1.2.

4. 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 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. It is also important to note that the ICANN CA cannot be used to verify the origin of the trust anchor in the CSR format.

The content and origin of the XML file 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 file. The URL for a detached CMS signature for the XML file is <https://data.iana.org/root-anchors/root-anchors.p7s>.

(IANA also provided a detached OpenPGP [RFC4880] signature as a second parallel verification mechanism for the first trust anchor publication but has indicated that it will not use this parallel mechanism in the future.)

Another method IANA uses to help validator operators verify the content and origin of 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. 🫶

5. IANA Considerations 📋

This document defines id-mod-dns-resource-record, value 70 (see Section 2.2), in the "SMI Security for PKIX Module Identifier" registry.

6. 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 is serious, bestie, do not skip this part.

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

7. References 📚

7.1. Normative References 💖

7.2. Informative References 🧠

Appendix A. Historical Note 🕰️

The first KSK for use in the root zone of the DNS was generated at a key ceremony at an ICANN Key Management Facility (KMF) in Culpeper, Virginia, USA on 2010-06-16. This 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. ✨

Acknowledgements 🎀

okay so this part is the thank-you section, and honestly it's giving gratitude era 🥹 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. 🫶 Like, these people did the hard early work so the rest of us could sign the root zone, and that deserves a shoutout.

This document incorporates suggestions made by Alfred Hoenes and Russ Housley, whose contributions are appreciated. ✨ Alfred and Russ helped make this spec better, so they get their flowers too 💐

Authors' Addresses 💌

Joe Abley Dyn, Inc. 300-184 York Street London, ON N6A 1B5 Canada

Phone: +1 519 670 9327 Email: jabley@dyn.com

Jakob Schlyter Kirei AB

Email: jakob@kirei.se

Guillaume Bailey Independent

Email: GuillaumeBailey@outlook.com

Paul Hoffman ICANN

Email: paul.hoffman@icann.org

That's the whole doc, bestie! 🦋 Thanks for reading along and being such a loyal networking girlie 💖💅👑

📦 where this page comes from