rfc9615.original   rfc9615.txt 
DNSOP Working Group P. Thomassen Internet Engineering Task Force (IETF) P. Thomassen
Internet-Draft deSEC, Secure Systems Engineering Request for Comments: 9615 deSEC, Secure Systems Engineering (SSE)
Updates: 7344, 8078 (if approved) N. Wisiol Updates: 7344, 8078 N. Wisiol
Intended status: Standards Track deSEC, Technische Universität Berlin Category: Standards Track deSEC, Technische Universität Berlin
Expires: 29 November 2024 28 May 2024 ISSN: 2070-1721 July 2024
Automatic DNSSEC Bootstrapping using Authenticated Signals from the Automatic DNSSEC Bootstrapping Using Authenticated Signals from the
Zone's Operator Zone's Operator
draft-ietf-dnsop-dnssec-bootstrapping-11
Abstract Abstract
This document introduces an in-band method for DNS operators to This document introduces an in-band method for DNS operators to
publish arbitrary information about the zones they are authoritative publish arbitrary information about the zones for which they are
for, in an authenticated fashion and on a per-zone basis. The authoritative, in an authenticated fashion and on a per-zone basis.
mechanism allows managed DNS operators to securely announce DNSSEC The mechanism allows managed DNS operators to securely announce
key parameters for zones under their management, including for zones DNSSEC key parameters for zones under their management, including for
that are not currently securely delegated. zones that are not currently securely delegated.
Whenever DS records are absent for a zone's delegation, this signal Whenever DS records are absent for a zone's delegation, this signal
enables the parent's registry or registrar to cryptographically enables the parent's registry or registrar to cryptographically
validate the CDS/CDNSKEY records found at the child's apex. The validate the CDS/CDNSKEY records found at the child's apex. The
parent can then provision DS records for the delegation without parent can then provision DS records for the delegation without
resorting to out-of-band validation or weaker types of cross-checks resorting to out-of-band validation or weaker types of cross-checks
such as "Accept after Delay". such as "Accept after Delay".
This document establishes the DS enrollment method described in This document establishes the DS enrollment method described in
Section 4 of this document as the preferred method over those from Section 4 of this document as the preferred method over those from
Section 3 of RFC 8078. It also updates RFC 7344. Section 3 of RFC 8078. It also updates RFC 7344.
[ Ed note: This document is being collaborated on at
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
(https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
The authors gratefully accept pull requests. ]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 29 November 2024. 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/rfc9615.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Notation
2. Updates to RFCs . . . . . . . . . . . . . . . . . . . . . . . 5 2. Updates to RFCs
3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Signaling
3.1. Chain of Trust . . . . . . . . . . . . . . . . . . . . . 5 3.1. Chain of Trust
3.2. Signaling Names . . . . . . . . . . . . . . . . . . . . . 5 3.2. Signaling Names
4. Bootstrapping a DNSSEC Delegation . . . . . . . . . . . . . . 6 4. Bootstrapping a DNSSEC Delegation
4.1. Signaling Consent to Act as the Child's Signer . . . . . 6 4.1. Signaling Consent to Act as the Child's Signer
4.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Example
4.2. Validating CDS/CDNSKEY Records for DNSSEC 4.2. Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping
Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Example
4.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Triggers
4.3. Triggers . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Limitations
4.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 10 5. Operational Recommendations
5. Operational Recommendations . . . . . . . . . . . . . . . . . 10 5.1. Child DNS Operator
5.1. Child DNS Operator . . . . . . . . . . . . . . . . . . . 10 5.2. Parental Agent
5.2. Parental Agent . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. References
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References
8.1. Child DNS Operator-side . . . . . . . . . . . . . . . . . 12 8.2. Informative References
8.2. Parental Agent-side . . . . . . . . . . . . . . . . . . . 12 Acknowledgements
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Change History (to be removed before publication) . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Securing a DNS delegation for the first time requires that the Securing a DNS delegation for the first time requires that the
child's DNSSEC parameters be conveyed to the parent through some child's DNSSEC parameters be conveyed to the parent through some
trusted channel. While the communication conceptually has to occur trusted channel. While the communication conceptually has to occur
between the parent registry and the DNSSEC key holder, what exactly between the parent registry and the DNSSEC key holder, what that
that means and how the communication is coordinated traditionally means exactly and how communication is coordinated traditionally
depends on the relationship the child has with the parent. depends on the relationship the child has with the parent.
A typical situation is that the key is held by the child DNS A typical situation is that the key is held by the child DNS
operator; the communication thus often involves this entity. In operator; thus, the communication often involves this entity. In
addition, depending on the circumstances, it may also involve the addition, depending on the circumstances, it may also involve the
registrar, possibly via the registrant (for details, see [RFC7344], registrar, possibly via the registrant (for details, see Appendix A
Appendix A). of [RFC7344].
As observed in [RFC7344], these dependencies often result in a manual As observed in [RFC7344], these dependencies often result in a manual
process that is susceptible to mistakes and/or errors. In addition, process that is susceptible to mistakes and/or errors. In addition,
due to the annoyance factor of the process, involved parties may due to the annoyance factor of the process, involved parties may
avoid the process of getting a DS record set (RRset) published in the avoid the process of getting a DS resource record set (RRset)
first place. published in the first place.
To alleviate these problems, automated provisioning of DS records has To alleviate these problems, automated provisioning of DS records has
been specified in ([RFC8078]). It is based on the parental agent been specified in [RFC8078]. It is based on the parental agent
(registry or registrar) fetching DNSSEC key parameters from the CDS (registry or registrar) fetching DNSSEC key parameters from the CDS
and CDNSKEY records ([RFC7344]) located at the child zone's apex, and and CDNSKEY records ([RFC7344]) located at the child zone's apex, and
validating them somehow. This validation can be done using the validating them somehow. This validation can be done using the
child's existing DNSSEC chain of trust if the objective is to update child's existing DNSSEC chain of trust if the objective is to update
an existing DS RRset (such as during key rollover). However, when an existing DS RRset (such as during key rollover). However, when
bootstrapping a DNSSEC delegation, the child zone has no existing bootstrapping a DNSSEC delegation, the child zone has no existing
DNSSEC validation path, and other means to ensure the CDS/CDNSKEY DNSSEC validation path, so other means to ensure the CDS/CDNSKEY
records' legitimacy must be found. records' legitimacy must be found.
Due to the lack of a comprehensive DNS-innate solution, either out- Due to the lack of a comprehensive DNS-innate solution, either out-
of-band methods have been used so far to complete the chain of trust, of-band methods have been used so far to complete the chain of trust,
or cryptographic validation has been entirely dispensed with, in or cryptographic validation has been entirely dispensed with, in
exchange for weaker types of cross-checks such as "Accept after exchange for weaker types of cross-checks such as "Accept after
Delay" ([RFC8078] Section 3.3). [RFC8078] does not define an in-band Delay" (Section 3.3 of [RFC8078]). [RFC8078] does not define an in-
validation method for enabling DNSSEC. band validation method for enabling DNSSEC.
This document aims to close this gap by introducing an in-band method This document aims to close this gap by introducing an in-band method
for DNS operators to publish arbitrary information about the zones for DNS operators to publish arbitrary information about the zones
they are authoritative for, in an authenticated manner and on a per- for which they are authoritative, in an authenticated manner and on a
zone basis. The mechanism allows managed DNS operators to securely per-zone basis. The mechanism allows managed DNS operators to
announce DNSSEC key parameters for zones under their management. The securely announce DNSSEC key parameters for zones under their
parent can then use this signal to cryptographically validate the management. The parent can then use this signal to cryptographically
CDS/CDNSKEY RRsets found at an insecure child zone's apex and, upon validate the CDS/CDNSKEY RRsets found at an insecure child zone's
success, secure the delegation. apex and, upon success, secure the delegation.
While applicable to the vast majority of domains, the protocol does While applicable to the vast majority of domains, the protocol does
not support certain edge cases, such as excessively long child zone not support certain edge cases, such as excessively long child zone
names, or DNSSEC bootstrapping for domains with in-domain nameservers names, or DNSSEC bootstrapping for domains with in-domain nameservers
only (see Section 4.4). only (see Section 4.4).
DNSSEC bootstrapping is just one application of the generic signaling DNSSEC bootstrapping is just one application of the generic signaling
mechanism specified in this document. Other applications might arise mechanism specified in this document. Other applications might arise
in the future, such as publishing operational metadata or auxiliary in the future, such as publishing operational metadata or auxiliary
information which the DNS operator likes to make known (e.g., API information that the DNS operator likes to make known (e.g., API
endpoints for third-party interaction). endpoints for third-party interaction).
Readers are expected to be familiar with DNSSEC [BCP237]. Readers are expected to be familiar with DNSSEC [BCP237].
1.1. Terminology 1.1. Terminology
This section defines the terminology used in this document. This section defines the terminology used in this document.
CDS/CDNSKEY This notation refers to CDS and/or CDNSKEY, i.e., one or CDS/CDNSKEY: This notation refers to CDS and/or CDNSKEY, i.e., one
both. or both.
Child see [RFC9499] Section 7
Child DNS operator The entity that maintains and publishes the zone Child: See Section 7 of [RFC9499].
Child DNS operator: The entity that maintains and publishes the zone
information for the child DNS. information for the child DNS.
Parent see [RFC9499] Section 7
Parental agent The entity that has the authority to insert DS Parent: See Section 7 of [RFC9499].
Parental agent: The entity that has the authority to insert DS
records into the parent zone on behalf of the child. (It could be records into the parent zone on behalf of the child. (It could be
the registry, registrar, a reseller, or some other authorized the registry, registrar, a reseller, or some other authorized
entity.) entity.)
Signaling domain A domain name constructed by prepending the label
_signal to a hostname taken from the child's NS RRSet. There are Signaling domain: A domain name constructed by prepending the label
as many signaling domains as there are distinct NS targets. _signal to a hostname taken from a delegation's NS RRset. There
Signaling name The labels that are prefixed to a signaling domain in are as many signaling domains as there are distinct NS targets.
order to identify a signaling type and a child zone's name (see
Signaling name: The labels that are prefixed to a signaling domain
in order to identify a signaling type and a child zone's name (see
Section 3.2). Section 3.2).
Signaling record A DNS record located at a signaling name under a
Signaling record: A DNS record located at a signaling name under a
signaling domain. Signaling records are used by the child DNS signaling domain. Signaling records are used by the child DNS
operator to publish information about the child. operator to publish information about the child.
Signaling type A signal type identifier, such as _dsboot for DNSSEC
Signaling type: A signal type identifier, such as _dsboot for DNSSEC
bootstrapping. bootstrapping.
Signaling zone The zone which is authoritative for a given signaling
Signaling zone: The zone that is authoritative for a given signaling
record. record.
1.2. Requirements Notation 1.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Updates to RFCs 2. Updates to RFCs
The DS enrollment methods described in Section 3 of [RFC8078] are The DS enrollment methods described in Section 3 of [RFC8078] are
less secure than the method described in Section 4 of this document. less secure than the method described in Section 4 of this document.
Child DNS operators and parental agents wishing to use CDS/CDNSKEY Therefore, child DNS operators and parental agents wishing to use
records for initial DS enrollment SHOULD therefore support the CDS/CDNSKEY records for initial DS enrollment SHOULD support the
authentication protocol described here. authentication protocol described here.
In order to facilitate publication of signaling records for the In order to facilitate publication of signaling records for the
purpose of DNSSEC bootstrapping (see Section 4.1), the first bullet purpose of DNSSEC bootstrapping (see Section 4.1), the first bullet
("Location") of [RFC7344] Section 4.1 is removed. ("Location") of Section 4.1 of [RFC7344] is removed.
3. Signaling 3. Signaling
This section describes the general mechanism by which a child DNS This section describes the general mechanism by which a child DNS
operator can publish an authenticated signal about a child zone. operator can publish an authenticated signal about a child zone.
Parental agents (or any other party) can then discover and process Parental agents (or any other party) can then discover and process
the signal. Authenticity is ensured through standard DNSSEC the signal. Authenticity is ensured through standard DNSSEC
validation. validation.
3.1. Chain of Trust 3.1. Chain of Trust
skipping to change at page 6, line 17 skipping to change at line 245
these signaling records depend on the type of signal. these signaling records depend on the type of signal.
The signaling name identifies the child and the signaling type. It The signaling name identifies the child and the signaling type. It
is identical to the child name (with the final root label removed), is identical to the child name (with the final root label removed),
prefixed with a label containing the signaling type. prefixed with a label containing the signaling type.
4. Bootstrapping a DNSSEC Delegation 4. Bootstrapping a DNSSEC Delegation
When the child zone's CDS/CDNSKEY RRsets are used for setting up When the child zone's CDS/CDNSKEY RRsets are used for setting up
initial trust, they need to be authenticated. This is achieved by initial trust, they need to be authenticated. This is achieved by
co-publishing the child's CDS/CDNSKEY RRsets as an authenticated copublishing the child's CDS/CDNSKEY RRsets as an authenticated
signal as described in Section 3. The parent can discover and signal as described in Section 3. The parent can discover and
validate it, thus transferring trust from the child DNS operator validate it, thus transferring trust from the child DNS operator
nameservers' chain of trust to the child zone. nameservers' chain of trust to the child zone.
This protocol is not intended for updating an existing DS RRset. For This protocol is not intended for updating an existing DS RRset. For
this purpose, the parental agent can validate the child's CDS/CDNSKEY this purpose, the parental agent can validate the child's CDS/CDNSKEY
RRsets directly, using the chain of trust established by the existing RRsets directly, using the chain of trust established by the existing
DS RRset ([RFC7344] Section 4). DS RRset (Section 4 of [RFC7344]).
4.1. Signaling Consent to Act as the Child's Signer 4.1. Signaling Consent to Act as the Child's Signer
To confirm its willingness to act as the child's delegated signer and To confirm its willingness to act as the child's delegated signer and
authenticate the child's CDS/CDNSKEY RRsets, the child DNS operator authenticate the child's CDS/CDNSKEY RRsets, the child DNS operator
MUST co-publish them at the corresponding signaling name under each MUST copublish them at the corresponding signaling name under each
signaling domain, excluding those that would fall within the child signaling domain, excluding those that would fall within the child
domain (Section 3.2). For simplicity, the child DNS operator MAY domain (Section 3.2). For simplicity, the child DNS operator MAY
also co-publish the child's CDS/CDNSKEY RRsets under signaling also copublish the child's CDS/CDNSKEY RRsets under signaling domains
domains within the child domain, although those signaling domains are within the child domain, although those signaling domains are not
not used for validation (Section 4.2). used for validation (Section 4.2).
Unlike the CDS/CDNSKEY RRsets at the child's apex, a signaling record Unlike the CDS/CDNSKEY RRsets at the child's apex, a signaling RRset
set MUST be signed with the corresponding signaling zone's key(s). MUST be signed with the corresponding signaling zone's key(s). Its
Its contents MUST be identical to the corresponding RRset published contents MUST be identical to the corresponding RRset published at
at the child's apex. the child's apex.
Existing use of CDS/CDNSKEY records was specified at the child apex Existing use of CDS/CDNSKEY records was specified at the child apex
only ([RFC7344], Section 4.1). This protocol extends the use of only (Section 4.1 of [RFC7344]). This protocol extends the use of
these record types to non-apex owner names for the purpose of DNSSEC these record types to non-apex owner names for the purpose of DNSSEC
bootstrapping. To exclude the possibility of semantic collision, bootstrapping. To exclude the possibility of semantic collision,
there MUST NOT be a zone cut at a signaling name. there MUST NOT be a zone cut at a signaling name.
4.1.1. Example 4.1.1. Example
For the purposes of bootstrapping the child zone example.co.uk with For the purposes of bootstrapping the child zone example.co.uk with
NS records ns1.example.net, ns2.example.org, and ns3.example.co.uk, NS records ns1.example.net, ns2.example.org, and ns3.example.co.uk,
the required signaling domains are _signal.ns1.example.net and the required signaling domains are _signal.ns1.example.net and
_signal.ns2.example.org. _signal.ns2.example.org.
In the zones containing these domains, the child DNS operator In the zones containing these domains, the child DNS operator
authenticates the CDS/CDNSKEY RRsets found at the child's apex by co- authenticates the CDS/CDNSKEY RRsets found at the child's apex by
publishing them as CDS/CDNSKEY RRsets at the names: copublishing them as CDS/CDNSKEY RRsets at the names:
_dsboot.example.co.uk._signal.ns1.example.net _dsboot.example.co.uk._signal.ns1.example.net
_dsboot.example.co.uk._signal.ns2.example.org _dsboot.example.co.uk._signal.ns2.example.org
These RRsets are signed with DNSSEC just like any other zone data. These RRsets are signed with DNSSEC just like any other zone data.
Publication of signaling records under the in-domain name Publication of signaling records under the in-domain name
_signal.ns3.example.co.uk is not required. _signal.ns3.example.co.uk is not required.
4.2. Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping 4.2. Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping
To validate a child's CDS/CDNSKEY RRset for DNSSEC bootstrapping, the To validate a child's CDS/CDNSKEY RRset for DNSSEC bootstrapping, the
parental agent, knowing both the child zone name and its NS parental agent, knowing both the child zone name and its NS
hostnames, MUST execute the following steps: hostnames, MUST execute the following steps:
1. verify that the child has no DS records published at the parent Step 1: verify that the child has no DS records published at the
and that at least one of its nameservers is outside the child parent and that at least one of its nameservers is outside
domain; the child domain;
2. query the CDS/CDNSKEY RRset at the child zone apex directly from Step 2: query the CDS/CDNSKEY RRset at the child zone apex directly
each of the authoritative servers as determined by the from each of the authoritative servers as determined by the
delegation's (parent-side) NS RRset, without caching; delegation's (parent-side) NS RRset, without caching;
3. query the CDS/CDNSKEY RRset located at the signaling name under Step 3: query the CDS/CDNSKEY RRset located at the signaling name
each signaling domain (except those falling within the child under each signaling domain (except those falling within the
domain) using a trusted DNS resolver and enforce DNSSEC child domain) using a trusted DNS resolver and enforce
validation; DNSSEC validation;
4. check (separately by record type) that all RRsets retrieved in Step 4: check (separately by record type) that all RRsets retrieved
Steps 2 and 3 have equal contents; in Steps 2 and 3 have equal contents;
If the above steps succeed without error, the CDS/CDNSKEY RRsets are If the above steps succeed without error, the CDS/CDNSKEY RRsets are
successfully verified, and the parental agent can proceed with the successfully verified, and the parental agent can proceed with the
publication of the DS RRset under the precautions described in publication of the DS RRset under the precautions described in
[RFC8078], Section 5. Section 5 of [RFC8078].
The parental agent MUST abort the procedure if an error condition The parental agent MUST abort the procedure if an error condition
occurs, in particular: occurs, in particular:
* in Step 1: the child is already securely delegated or has in- * in Step 1: the child is already securely delegated or has in-
domain nameservers only; domain nameservers only;
* in Step 2: any failure during the retrieval of the CDS/CDNSKEY * in Step 2: any failure during the retrieval of the CDS/CDNSKEY
RRset located at the child apex from any of the authoritative RRset located at the child apex from any of the authoritative
nameservers; nameservers;
skipping to change at page 8, line 37 skipping to change at line 358
1. checks that the child domain is not yet securely delegated; 1. checks that the child domain is not yet securely delegated;
2. queries the CDS/CDNSKEY RRsets for example.co.uk directly from 2. queries the CDS/CDNSKEY RRsets for example.co.uk directly from
ns1.example.net, ns2.example.org, and ns3.example.co.uk (without ns1.example.net, ns2.example.org, and ns3.example.co.uk (without
caching); caching);
3. queries and validates the CDS/CDNSKEY RRsets located at (see 3. queries and validates the CDS/CDNSKEY RRsets located at (see
Section 3.2; ns3.example.co.uk is ignored because it is in- Section 3.2; ns3.example.co.uk is ignored because it is in-
domain) domain)
_dsboot.example.co.uk._signal.ns1.example.net _dsboot.example.co.uk._signal.ns1.example.net
_dsboot.example.co.uk._signal.ns2.example.org _dsboot.example.co.uk._signal.ns2.example.org
4. checks that the CDS/CDNSKEY RRsets retrieved in Steps 2 and 3 4. checks that the CDS/CDNSKEY RRsets retrieved in Steps 2 and 3
agree across responses. agree across responses.
If all these steps succeed, the parental agent can proceed to publish If all of these steps succeed, the parental agent can proceed to
a DS RRset as indicated by the validated CDS/CDNSKEY RRset. publish a DS RRset as indicated by the validated CDS/CDNSKEY RRset.
As in-domain signaling names do not have a chain of trust at As in-domain signaling names do not have a chain of trust at
bootstrapping time, the parental agent does not consider them during bootstrapping time, the parental agent does not consider them during
validation. Consequently, if all NS hostnames are in-domain, validation. Consequently, if all NS hostnames are in-domain,
validation cannot be completed, and DS records are not published. validation cannot be completed and DS records are not published.
4.3. Triggers 4.3. Triggers
Parental agents SHOULD trigger the procedure described in Section 4.2 Parental agents SHOULD trigger the procedure described in Section 4.2
once one of the following conditions is fulfilled: once one of the following conditions is fulfilled:
* The parental agent receives a new or updated NS RRset for a child; * The parental agent receives a new or updated NS RRset for a child;
* The parental agent receives a notification indicating that the * The parental agent receives a notification indicating that the
child wishes to have its CDS/CDNSKEY RRset processed; child wishes to have its CDS/CDNSKEY RRset processed;
* The parental agent encounters a signaling record during a * The parental agent encounters a signaling record during a
proactive, opportunistic scan (e.g., daily queries of signaling proactive, opportunistic scan (e.g., daily queries of signaling
records for some or all of its delegations); records for some or all of its delegations);
* The parental agent encounters a signaling record during an NSEC * The parental agent encounters a signaling record during an NSEC
walk or when parsing a signaling zone (e.g., when made available walk or when parsing a signaling zone (e.g., when made available
via AXFR by the child DNS operator); via AXFR by the child DNS operator);
* Any other condition as deemed appropriate by local policy. * Any other condition deemed appropriate by local policy.
Timer-based trigger mechanisms (such as scans) exhibit undesirable Timer-based trigger mechanisms (such as scans) exhibit undesirable
properties with respect to processing delay and scaling; on-demand properties with respect to processing delay and scaling; on-demand
triggers (like notifications) are preferable. Whenever possible, triggers (like notifications) are preferable. Whenever possible,
child DNS operators and parental agents are thus encouraged to use child DNS operators and parental agents are thus encouraged to use
them, reducing both delays and the amount of scanning traffic. them, reducing both delays and the amount of scanning traffic.
Most types of discovery (such as daily scans of delegations) are Most types of discovery (such as daily scans of delegations) are
based directly on the delegation's NS RRset. In this case, these NS based directly on the delegation's NS RRset. In this case, these NS
names can be used as is by the bootstrapping algorithm (Section 4.2) names can be used as is by the bootstrapping algorithm (Section 4.2)
for querying signaling records. for querying signaling records.
Some discovery methods, however, do not imply reliable knowledge of Some discovery methods, however, do not imply reliable knowledge of
the delegation's NS RRset. For example, when discovering signaling the delegation's NS RRset. For example, when discovering signaling
names by performing an NSEC walk or zone transfer of a signaling names by performing an NSEC walk or zone transfer of a signaling
zone, the parental agent MUST NOT assume that a nameserver under zone, the parental agent MUST NOT assume that a nameserver under
whose signaling domain a signaling record appears is actually whose signaling domain a signaling record appears is actually
authoritative for the corresponding child. authoritative for the corresponding child.
Instead, whenever a list of "bootstrappable domains" is obtained Instead, whenever a list of "bootstrappable domains" is obtained by
other than directly from the parent, the parental agent MUST means other than directly from the parent, the parental agent MUST
ascertain that the delegation actually contains the nameserver ascertain that the delegation actually contains the nameserver
hostname seen during discovery, and ensure that signaling record hostname seen during discovery, and ensure that signaling-record
queries are only made against the proper set of nameservers as listed queries are only made against the proper set of nameservers as listed
in the child's delegation from the parent. in the child's delegation from the parent.
4.4. Limitations 4.4. Limitations
As a consequence of Step 3 in Section 4.2, DS bootstrapping does not As a consequence of Step 3 in Section 4.2, DS bootstrapping does not
work for fully in-domain delegations, as no pre-existing chain of work for fully in-domain delegations, as no preexisting chain of
trust to the child domain is available during bootstrapping. (As a trust to the child domain is available during bootstrapping. (As a
workaround, one can add an out-of-domain nameserver to the initial NS workaround, one can add an out-of-domain nameserver to the initial NS
RRset and remove it once bootstrapping is completed. Automation for RRset and remove it once bootstrapping is completed. Automation for
this is available via CSYNC records, see [RFC7477].) this is available via CSYNC records, see [RFC7477].)
Fully qualified signaling names must by valid DNS names. Label count Fully qualified signaling names must by valid DNS names. Label count
and length requirements for DNS names ([RFC1035] Section 3.1) imply and length requirements for DNS names (Section 3.1 of [RFC1035])
that the protocol does not work for unusually long child domain names imply that the protocol does not work for unusually long child domain
or NS hostnames. names or NS hostnames.
5. Operational Recommendations 5. Operational Recommendations
5.1. Child DNS Operator 5.1. Child DNS Operator
It is possible to add CDS/CDNSKEY records and corresponding signaling It is possible to add CDS/CDNSKEY records and corresponding signaling
records to a zone without the domain owner's explicit knowledge. To records to a zone without the domain owner's explicit knowledge. To
spare domain owners from being caught off guard by the ensuing DS spare domain owners from being caught off guard by the ensuing DS
changes, child DNS operators following this practice are advised to changes, child DNS operators following this practice are advised to
make that transparent, such as by informing the domain owner during make that transparent, such as by informing the domain owner during
zone creation (e.g., in a GUI), or by notifying them via email. zone creation (e.g., in a GUI) or by notifying them via email.
When transferring a zone to another DNS operator, the old and new When transferring a zone to another DNS operator, the old and new
child DNS operators need to cooperate to achieve a smooth transition, child DNS operators need to cooperate to achieve a smooth transition,
e.g., by using the multi-signer protocols described in [RFC8901]. If e.g., by using the multi-signer protocols described in [RFC8901]. If
all else fails, the domain owner might have to request the removal of all else fails, the domain owner might have to request the removal of
all DS records and have the transfer performed insecurely (see all DS records and have the transfer performed insecurely (see
[I-D.hardaker-dnsop-intentionally-temporary-insec]). [INSEC]).
Signaling domains SHOULD be delegated as standalone zones, so that Signaling domains SHOULD be delegated as standalone zones, so that
the signaling zone's apex coincides with the signaling domain (such the signaling zone's apex coincides with the signaling domain (such
as _signal.ns1.example.net). While it is permissible for the as _signal.ns1.example.net). While it is permissible for the
signaling domain to be contained in a signaling zone of fewer labels signaling domain to be contained in a signaling zone of fewer labels
(such as example.net), a zone cut ensures that bootstrapping (such as example.net), a zone cut ensures that bootstrapping
activities do not require modifications of the zone containing the activities do not require modifications of the zone containing the
nameserver hostname. nameserver hostname.
Once a Child DNS Operator determines that specific signaling record Once a child DNS operator determines that specific signaling record
sets have been processed (e.g., by seeing the result in the parent sets have been processed (e.g., by seeing the result in the parent
zone), they are advised to remove them. This will reduce the size of zone), they are advised to remove them. This will reduce the size of
the signaling zone, and facilitate more efficient bulk processing the signaling zone and facilitate more efficient bulk processing
(such as via zone transfers). (such as via zone transfers).
5.2. Parental Agent 5.2. Parental Agent
In order to ensure timely DNSSEC bootstrapping of insecure domains, In order to ensure timely DNSSEC bootstrapping of insecure domains,
stalemate situations due to mismatch of stale cached records (Step 4 stalemate situations due to mismatch of stale cached records (Step 4
of Section 4.2) need to be avoided. It is thus RECOMMENDED to of Section 4.2) need to be avoided. It is thus RECOMMENDED that
perform queries into signaling domains with an (initially) empty queries into signaling domains be performed with an (initially) empty
resolver cache, or using some other method for retrieving fresh data resolver cache, or that some other method for retrieving fresh data
from authoritative servers. from authoritative servers be used.
It is also RECOMMENDED to use QNAME minimization [RFC9156] when It is also RECOMMENDED that QNAME minimization [RFC9156] be used when
resolving queries for signaling records, to guard against certain resolving queries for signaling records to guard against certain
attacks (see Section 6). attacks (see Section 6).
6. Security Considerations 6. Security Considerations
The DNSSEC bootstrapping method introduced in this document is based The DNSSEC bootstrapping method introduced in this document is based
on the approaches described in [RFC8078] Section 3, but adds on the approaches described in Section 3 of [RFC8078], but adds
authentication to the CDS/CDNSKEY concept. Its security level is authentication to the CDS/CDNSKEY concept. Its security level is
therefore strictly higher than that of existing approaches described therefore strictly higher than that of existing approaches described
in that document (e.g., "Accept after Delay"). Apart from this in that document (e.g., "Accept after Delay"). Apart from this
general improvement, the same Security Considerations apply as in general improvement, the same Security Considerations apply as in
[RFC8078]. [RFC8078].
The level of rigor in Section 4.2 is needed to prevent publication of The level of rigor in Section 4.2 is needed to prevent publication of
a ill-conceived DS RRset (authorized only under a subset of NS an ill-conceived DS RRset (authorized only under a subset of NS
hostnames). This ensures, for example, that an operator in a multi- hostnames). This ensures, for example, that an operator in a multi-
homed setup cannot enable DNSSEC unless all other operators agree. homed setup cannot enable DNSSEC unless all other operators agree.
In any case, as the child DNS operator has authoritative knowledge of In any case, as the child DNS operator has authoritative knowledge of
the child's CDS/CDNSKEY records, it can readily detect fraudulent the child's CDS/CDNSKEY records, it can readily detect fraudulent
provisioning of DS records. provisioning of DS records.
In order to prevent the parents of nameserver hostnames from becoming In order to prevent the parents of nameserver hostnames from becoming
a single point of failure for a delegation (both in terms of a single point of failure for a delegation (both in terms of
resolution availability and for the trust model of this protocol), it resolution availability and for the trust model of this protocol),
is advisable to diversify the path from the root to the child's diversifying the path from the root to the child's nameserver
nameserver hostnames, such as by using different and independently hostnames is advisable. For example, different and independently
operated TLDs for each one. operated TLDs may be used for each one.
If QNAME minimization [RFC9156] is not used when querying for If QNAME minimization [RFC9156] is not used when querying for
signaling records, an upstream parent of a signaling domain will see signaling records, an upstream parent of a signaling domain will see
those CDS/CDNSKEY queries and could respond with an authoritative those CDS/CDNSKEY queries and could respond with an authoritative
answer signed with its own key, instead of sending the referral. answer signed with its own key, instead of sending the referral.
Enabling QNAME minimization reduces the attack surface for such Enabling QNAME minimization reduces the attack surface for such
forgery. forgery.
7. IANA Considerations 7. IANA Considerations
Per [RFC8552], IANA is requested to add the following entries to the IANA has added the following entries to the "Underscored and Globally
"Underscored and Globally Scoped DNS Node Names" registry: Scoped DNS Node Names" registry [RFC8552]:
+---------+------------+------------+
| RR Type | _NODE NAME | Reference |
+---------+------------+------------+
| CDS | _signal | [This RFC] |
| CDNSKEY | _signal | [This RFC] |
+---------+------------+------------+
*Note to the RFC Editor*: please replace "This RFC" in the above
table with a proper reference.
8. Implementation Status
*Note to the RFC Editor*: please remove this entire section before
publication.
In addition to the information in this section, deployment is tracked
by the community at https://github.com/oskar456/cds-updates
(https://github.com/oskar456/cds-updates).
8.1. Child DNS Operator-side
* Operator support:
- Cloudflare has implemented bootstrapping record synthesis for
all signed customer zones.
- Glauca HexDNS publishes bootstrapping records for its customer
zones.
- deSEC performs bootstrapping record synthesis for its zones
using names _signal.ns1.desec.io and _signal.ns2.desec.org.
* Authoritative nameserver support:
- Knot DNS supports signaling record synthesis since version
3.3.5.
- An implementation of bootstrapping record synthesis in PowerDNS
is available at https://github.com/desec-io/desec-ns/pull/46
(https://github.com/desec-io/desec-ns/pull/46).
8.2. Parental Agent-side
* ccTLD:
- SWITCH (.ch, .li) has implemented authentication of consumed
CDS records based on this draft.
- .cl is working on an implementation.
* gTLD:
- Knipp has implemented consumption of DNSSEC bootstrapping
records in its TANGO and CORE registry systems.
- A deployment of this is running at .swiss.
* Registrars:
- Glauca has implemented authenticated CDS processing.
- GoDaddy is working on an implementation.
* A tool to retrieve and process signaling records for bootstrapping
purposes, either directly or via zone walking, is available at
https://github.com/desec-io/dsbootstrap (https://github.com/desec-
io/dsbootstrap). The tool outputs the validated DS records which
then can be added to the parent zone.
9. Acknowledgements
Thanks to Brian Dickson, Ondřej Caletka, John R. Levine, Christian +=========+============+===========+
Elmerot, Oli Schacher, Donald Eastlake, Libor Peltan, Warren Kumari, | RR Type | _NODE NAME | Reference |
Scott Rose, Linda Dunbar, Tim Wicinski, Paul Wouters, Paul Hoffman, +=========+============+===========+
Peter Yee, Benson Muite, Roman Danyliw, Éric Vyncke, and Joe Abley | CDS | _signal | RFC 9615 |
for reviewing draft proposals and offering comments and suggestions. +---------+------------+-----------+
| CDNSKEY | _signal | RFC 9615 |
+---------+------------+-----------+
Thanks also to Steve Crocker, Hugo Salgado, and Ulrich Wisser for Table 1
early-stage brainstorming.
10. References 8. References
10.1. Normative References 8.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 14, line 37 skipping to change at line 569
[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
Name Minimisation to Improve Privacy", RFC 9156, Name Minimisation to Improve Privacy", RFC 9156,
DOI 10.17487/RFC9156, November 2021, DOI 10.17487/RFC9156, November 2021,
<https://www.rfc-editor.org/info/rfc9156>. <https://www.rfc-editor.org/info/rfc9156>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024, RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>. <https://www.rfc-editor.org/info/rfc9499>.
10.2. Informative References 8.2. Informative References
[BCP237] Best Current Practice 237, [BCP237] Best Current Practice 237,
<https://www.rfc-editor.org/info/bcp237>. <https://www.rfc-editor.org/info/bcp237>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023, RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>. <https://www.rfc-editor.org/info/rfc9364>.
[I-D.hardaker-dnsop-intentionally-temporary-insec] [INSEC] Hardaker, W., "Intentionally Temporarily Degraded or
Hardaker, W., "Intentionally Temporarily Degraded or
Insecure", Work in Progress, Internet-Draft, draft- Insecure", Work in Progress, Internet-Draft, draft-
hardaker-dnsop-intentionally-temporary-insec-01, 21 hardaker-dnsop-intentionally-temporary-insec-01, 21
October 2021, <https://datatracker.ietf.org/doc/html/ October 2021, <https://datatracker.ietf.org/doc/html/
draft-hardaker-dnsop-intentionally-temporary-insec-01>. draft-hardaker-dnsop-intentionally-temporary-insec-01>.
[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
Blacka, "Multi-Signer DNSSEC Models", RFC 8901, Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
DOI 10.17487/RFC8901, September 2020, DOI 10.17487/RFC8901, September 2020,
<https://www.rfc-editor.org/info/rfc8901>. <https://www.rfc-editor.org/info/rfc8901>.
Appendix A. Change History (to be removed before publication) Acknowledgements
* draft-ietf-dnsop-dnssec-bootstrapping-11
| Addressed comment by Paul Wouters
* draft-ietf-dnsop-dnssec-bootstrapping-10
| Editorial nit
|
| Addressed comments by Paul Wouters
|
| Make capitalization of registrar/registrant consistent
|
| Editorial nit by Joe Abley
|
| Addressed comments by Éric Vyncke
* draft-ietf-dnsop-dnssec-bootstrapping-09
| Addressed comments by Paul Wouters
|
| Editorial nits by Roman Danyliw
|
| Editorial nits by Benson Muite
|
| Editorial nits by Peter Yee
|
| Editorial nit by Scott Rose
|
| Editorial suggestion from John Levine
* draft-ietf-dnsop-dnssec-bootstrapping-08
| Editorial changes from AD Review
|
| Updated implementation section
|
| Change capitalization of terms from terminology section
* draft-ietf-dnsop-dnssec-bootstrapping-07
| Add Glauca registrar implementation
|
| Editorial changes to Security Considerations
|
| Add/discuss on-demand triggers (notifications)
* draft-ietf-dnsop-dnssec-bootstrapping-06
| Add section "Updates to RFCs"
|
| Editorial nits
|
| Editorial changes from Secdir early review
* draft-ietf-dnsop-dnssec-bootstrapping-05
| Editorial changes
* draft-ietf-dnsop-dnssec-bootstrapping-04
| Added consent considerations.
|
| Editorial changes.
* draft-ietf-dnsop-dnssec-bootstrapping-03
| Updated Implementation section.
|
| Typo fix.
* draft-ietf-dnsop-dnssec-bootstrapping-02
| Clarified that RFC 8078 Section 3 is not replaced, but its methods
| are deprecated.
|
| Added new deployments to Implementation section.
|
| Included NSEC walk / AXFR as possible triggers for DS
| bootstrapping.
|
| Editorial changes.
* draft-ietf-dnsop-dnssec-bootstrapping-01
| Allow bootstrapping when some (not all) NS hostnames are in
| bailiwick.
|
| Clarified Operational Recommendations according to operator
| feedback.
|
| Turn loose Security Considerations points into coherent text.
|
| Do no longer suggest NSEC-walking Signaling Domains. (It does not
| work well due to the Signaling Type prefix. What's more, it's
| unclear who would do this: Parents know there delegations and can
| do a targeted scan; others are not interested.)
|
| Editorial changes.
|
| Added IANA request.
|
| Introduced Signaling Type prefix (_dsboot), renamed Signaling Name
| infix from _dsauth to _signal.
* draft-ietf-dnsop-dnssec-bootstrapping-00
| Editorial changes.
* draft-thomassen-dnsop-dnssec-bootstrapping-03
| Clarified importance of record cleanup by moving paragraph up.
|
| Pointed out limitations.
|
| Replace [RFC8078] Section 3 with our Section 4.2.
|
| Changed _boot label to _dsauth.
|
| Removed hashing of Child name components in Signaling Names.
|
| Editorial changes.
* draft-thomassen-dnsop-dnssec-bootstrapping-02
| Reframed as an authentication mechanism for RFC 8078.
|
| Removed multi-signer use case (focus on RFC 8078 authentication).
|
| Triggers need to fetch NS records (if not implicit from context).
|
| Improved title.
|
| Recognized that hash collisions are dealt with by Child apex
| check.
* draft-thomassen-dnsop-dnssec-bootstrapping-01
| Add section on Triggers.
|
| Clarified title.
|
| Improved abstract.
|
| Require CDS/CDNSKEY records at the Child.
|
| Reworked Signaling Name scheme.
|
| Recommend using cold cache for consumption.
|
| Updated terminology (replace "Bootstrapping" by "Signaling").
|
| Added NSEC recommendation for Bootstrapping Zones.
|
| Added multi-signer use case.
|
| Editorial changes.
* draft-thomassen-dnsop-dnssec-bootstrapping-00 Thanks to Brian Dickson, Ondřej Caletka, John R. Levine, Christian
Elmerot, Oli Schacher, Donald Eastlake, Libor Peltan, Warren Kumari,
Scott Rose, Linda Dunbar, Tim Wicinski, Paul Wouters, Paul Hoffman,
Peter Yee, Benson Muite, Roman Danyliw, Éric Vyncke, and Joe Abley
for reviewing draft proposals and offering comments and suggestions.
| Initial public draft. Thanks also to Steve Crocker, Hugo Salgado, and Ulrich Wisser for
early-stage brainstorming.
Authors' Addresses Authors' Addresses
Peter Thomassen Peter Thomassen
deSEC, Secure Systems Engineering deSEC, Secure Systems Engineering (SSE)
Berlin Berlin
Germany Germany
Email: peter@desec.io Email: peter@desec.io
Nils Wisiol Nils Wisiol
deSEC, Technische Universität Berlin deSEC, Technische Universität Berlin
Berlin Berlin
Germany Germany
Email: nils@desec.io Email: nils@desec.io
 End of changes. 68 change blocks. 
397 lines changed or deleted 176 lines changed or added

This html diff was produced by rfcdiff 1.48.