rfc9615.original.xml		rfc9615.xml
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
	or - mmark.miek.nl" -->		<!DOCTYPE rfc [
	<rfc version="3" ipr="trust200902" docName="draft-ietf-dnsop-dnssec-bootstrappin		<!ENTITY nbsp "&#160;">
	g-11" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3		<!ENTITY zwsp "&#8203;">
	.org/2001/XInclude" updates="7344, 8078" indexInclude="true">		<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
			<rfc version="3"
			xmlns:xi="http://www.w3.org/2001/XInclude"
			submissionType="IETF" consensus="true"
			ipr="trust200902" docName="draft-ietf-dnsop-dnssec-bootstrapping-11" number="961
			5" category="std" xml:lang="en" updates="7344, 8078" tocInclude="true" symRefs=
			"true"
			sortRefs="true">
	<front>		<front>
	<title abbrev="dnssec-bootstrapping">Automatic DNSSEC Bootstrapping using Authen		<title abbrev="DNSSEC Bootstrapping">Automatic DNSSEC Bootstrapping Using Auth
	ticated Signals from the Zone's Operator</title><seriesInfo value="draft-ietf-dn		enticated Signals from the Zone's Operator</title>
	sop-dnssec-bootstrapping-11" stream="IETF" status="standard" name="Internet-Draf		<seriesInfo name="RFC" value="9615"/>
	t"></seriesInfo>		<author initials="P." surname="Thomassen" fullname="Peter Thomassen">
	<author initials="P." surname="Thomassen" fullname="Peter Thomassen"><organizati		<organization>deSEC, Secure Systems Engineering (SSE)</organization>
	on>deSEC, Secure Systems Engineering</organization><address><postal><street></st		<address>
	reet>		<postal>
	<city>Berlin</city>		<city>Berlin</city>
	<country>Germany</country>		<country>Germany</country>
	</postal><email>peter@desec.io</email>		</postal>
	</address></author><author initials="N." surname="Wisiol" fullname="Nils Wisiol"		<email>peter@desec.io</email>
	><organization>deSEC, Technische Universität Berlin</organization><address><post		</address>
	al><street></street>		</author>
	<city>Berlin</city>		<author initials="N." surname="Wisiol" fullname="Nils Wisiol">
	<country>Germany</country>		<organization>deSEC, Technische Universität Berlin</organization>
	</postal><email>nils@desec.io</email>		<address>
	</address></author><date year="2024" month="May" day="28"></date>		<postal>
	<area>Internet</area>		<city>Berlin</city>
	<workgroup>DNSOP Working Group</workgroup>		<country>Germany</country>
			</postal>
			<email>nils@desec.io</email>
			</address>
			</author>
			<date year="2024" month="July"/>
			<area>OPS</area>
			<workgroup>dnsop</workgroup>
			<keyword>DNSSEC</keyword>
			<keyword>bootstrapping</keyword>
			<keyword>DS</keyword>
			<keyword>CDS</keyword>
			<keyword>CDNSKEY</keyword>
	<abstract>		<abstract>
	<t>This document introduces an in-band method for DNS operators to		<t>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 authoritative,
	for, in an authenticated fashion and on a per-zone basis.		in an authenticated fashion and on a per-zone basis.
	The mechanism allows managed DNS operators to securely announce		The mechanism allows managed DNS operators to securely announce
	DNSSEC key parameters for zones under their management, including for		DNSSEC key parameters for zones under their management, including for
	zones that are not currently securely delegated.</t>		zones that are not currently securely delegated.</t>
	<t>Whenever DS records are absent for a zone's delegation, this signal		<t>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.		validate the CDS/CDNSKEY records found at the child's apex.
	The parent can then provision DS records for the delegation without		The 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 &quot;Accept after Delay&quot;.</t>		such as "Accept after Delay".</t>
	<t>This document establishes the DS enrollment method described in		<t>This document establishes the DS enrollment method described in
	<xref target="dnssec-bootstrapping"></xref> of this document as the preferred me thod over		Section 4 of this document as the preferred method over
	those from Section 3 of RFC 8078. It also updates RFC 7344.</t>		those from Section 3 of RFC 8078. It also updates RFC 7344.</t>
	<t>[ Ed note: This document is being collaborated on at
	<eref target="https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
	">https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/</eref>.
	The authors gratefully accept pull requests. ]</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction"><name>Introduction</name>		<section anchor="introduction"><name>Introduction</name>
	<t>Securing a DNS delegation for the first time requires that the		<t>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.		trusted channel.
	While the communication conceptually has to occur between the parent		While the communication conceptually has to occur between the parent
	registry and the DNSSEC key holder, what exactly that means and how		registry and the DNSSEC key holder, what that means exactly and how
	the communication is coordinated traditionally depends on the		communication is coordinated traditionally depends on the
	relationship the child has with the parent.</t>		relationship the child has with the parent.</t>
	<t>A typical situation is that the key is held by the child DNS		<t>A typical situation is that the key is held by the child DNS
	operator; the communication thus often involves this entity.		operator; thus, the communication often involves this entity.
	In addition, depending on the circumstances, it may also involve the		In addition, depending on the circumstances, it may also involve the
	registrar, possibly via the registrant (for details, see <xref target="RFC7344">		registrar, possibly via the registrant (for details, see <xref target="RFC7344"
	</xref>,		sectionFormat="of" section="A"></xref>.</t>
	Appendix A).</t>
	<t>As observed in <xref target="RFC7344"></xref>, these dependencies often resul t in a manual		<t>As observed in <xref target="RFC7344"></xref>, these dependencies often resul t in a manual
	process that is susceptible to mistakes and/or errors.		process that is susceptible to mistakes and/or errors.
	In addition, due to the annoyance factor of the process, involved		In addition, due to the annoyance factor of the process, involved
	parties may avoid the process of getting a DS record set (RRset)		parties may avoid the process of getting a DS resource record set (RRset)
	published in the first place.</t>		published in the first place.</t>
	<t>To alleviate these problems, automated provisioning of DS records has		<t>To alleviate these problems, automated provisioning of DS records has
	been specified in (<xref target="RFC8078"></xref>).		been specified in <xref target="RFC8078"></xref>.
	It is based on the parental agent (registry or registrar) fetching		It is based on the parental agent (registry or registrar) fetching
	DNSSEC key parameters from the CDS and CDNSKEY records (<xref target="RFC7344">< /xref>)		DNSSEC key parameters from the CDS and CDNSKEY records (<xref target="RFC7344">< /xref>)
	located at the child zone's apex, and validating them somehow.		located at the child zone's apex, and validating them somehow.
	This validation can be done using the child's existing DNSSEC chain of		This validation can be done using the child's existing DNSSEC chain of
	trust if the objective is to update an existing DS RRset (such as		trust if the objective is to update an existing DS RRset (such as
	during key rollover).		during key rollover).
	However, when bootstrapping a DNSSEC delegation, the child zone has		However, when bootstrapping a DNSSEC delegation, the child zone has
	no existing DNSSEC validation path, and other means to ensure the		no existing DNSSEC validation path, so other means to ensure the
	CDS/CDNSKEY records' legitimacy must be found.</t>		CDS/CDNSKEY records' legitimacy must be found.</t>
	<t>Due to the lack of a comprehensive DNS-innate solution, either		<t>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		out-of-band methods have been used so far to complete the chain of
	trust, or cryptographic validation has been entirely dispensed with, in		trust, or cryptographic validation has been entirely dispensed with, in
	exchange for weaker types of cross-checks such as &quot;Accept after		exchange for weaker types of cross-checks such as "Accept after
	Delay&quot; (<xref target="RFC8078"></xref> Section 3.3).		Delay" (<xref target="RFC8078" sectionFormat="of" section="3.3"></xref>).
	<xref target="RFC8078"></xref> does not define an in-band validation method for enabling		<xref target="RFC8078"></xref> does not define an in-band validation method for enabling
	DNSSEC.</t>		DNSSEC.</t>
	<t>This document aims to close this gap by introducing an in-band method		<t>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		for which they are authoritative, in an authenticated manner and on a
	per-zone basis.		per-zone basis.
	The mechanism allows managed DNS operators to securely announce		The mechanism allows managed DNS operators to securely announce
	DNSSEC key parameters for zones under their management.		DNSSEC key parameters for zones under their management.
	The parent can then use this signal to cryptographically validate the		The parent can then use this signal to cryptographically validate the
	CDS/CDNSKEY RRsets found at an insecure child zone's apex and, upon		CDS/CDNSKEY RRsets found at an insecure child zone's apex and, upon
	success, secure the delegation.</t>		success, secure the delegation.</t>
	<t>While applicable to the vast majority of domains, the protocol does		<t>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 <xref target="limitations"></xref>).</t>		only (see <xref target="limitations"></xref>).</t>
	<t>DNSSEC bootstrapping is just one application of the generic signaling		<t>DNSSEC bootstrapping is just one application of the generic signaling
	mechanism specified in this document.		mechanism specified in this document.
	Other applications might arise in the future, such as publishing		Other applications might arise in the future, such as publishing
	operational metadata or auxiliary information which the DNS operator		operational metadata or auxiliary information that the DNS operator
	likes to make known (e.g., API endpoints for third-party interaction).</t>		likes to make known (e.g., API endpoints for third-party interaction).</t>
	<t>Readers are expected to be familiar with DNSSEC <xref target="BCP237"></xref> .</t>		<t>Readers are expected to be familiar with DNSSEC <xref target="BCP237"></xref> .</t>
	<section anchor="terminology"><name>Terminology</name>		<section anchor="terminology"><name>Terminology</name>
	<t>This section defines the terminology used in this document.</t>		<t>This section defines the terminology used in this document.</t>
	<dl spacing="compact">		<dl spacing="normal">
	<dt>CDS/CDNSKEY</dt>		<dt>CDS/CDNSKEY:</dt>
	<dd>This notation refers to CDS and/or CDNSKEY, i.e., one or both.</dd>		<dd>This notation refers to CDS and/or CDNSKEY, i.e., one or both.</dd>
	<dt>Child</dt>		<dt>Child:</dt>
	<dd>see <xref target="RFC9499"></xref> Section 7</dd>		<dd>See <xref target="RFC9499" sectionFormat="of" section="7"></xref>.</dd>
	<dt>Child DNS operator</dt>		<dt>Child DNS operator:</dt>
	<dd>The entity that maintains and publishes the zone information for		<dd>The entity that maintains and publishes the zone information for
	the child DNS.</dd>		the child DNS.</dd>
	<dt>Parent</dt>		<dt>Parent:</dt>
	<dd>see <xref target="RFC9499"></xref> Section 7</dd>		<dd>See <xref target="RFC9499" sectionFormat="of" section="7"></xref>.</dd>
	<dt>Parental agent</dt>		<dt>Parental agent:</dt>
	<dd>The entity that has the authority to insert DS records into the		<dd>The entity that has the authority to insert DS records into the
	parent zone on behalf of the child.		parent zone on behalf of the child.
	(It could be the registry, registrar, a reseller, or some other		(It could be the registry, registrar, a reseller, or some other
	authorized entity.)</dd>		authorized entity.)</dd>
	<dt>Signaling domain</dt>
			<dt>Signaling domain:</dt>
	<dd>A domain name constructed by prepending the label <tt>_signal</tt> to a		<dd>A domain name constructed by prepending the label <tt>_signal</tt> to a
	hostname taken from the child's NS RRSet.		hostname taken from a delegation's NS RRset.
	There are as many signaling domains as there are distinct NS		There are as many signaling domains as there are distinct NS
	targets.</dd>		targets.</dd>
	<dt>Signaling name</dt>		<dt>Signaling name:</dt>
	<dd>The labels that are prefixed to a signaling domain in order to		<dd>The labels that are prefixed to a signaling domain in order to
	identify a signaling type and a child zone's name (see		identify a signaling type and a child zone's name (see
	<xref target="signalingnames"></xref>).</dd>		<xref target="signalingnames"></xref>).</dd>
	<dt>Signaling record</dt>		<dt>Signaling record:</dt>
	<dd>A DNS record located at a signaling name under a signaling domain.		<dd>A DNS record located at a signaling name under a signaling domain.
	Signaling records are used by the child DNS operator to publish		Signaling records are used by the child DNS operator to publish
	information about the child.</dd>		information about the child.</dd>
	<dt>Signaling type</dt>		<dt>Signaling type:</dt>
	<dd>A signal type identifier, such as <tt>_dsboot</tt> for DNSSEC bootstrapping. </dd>		<dd>A signal type identifier, such as <tt>_dsboot</tt> for DNSSEC bootstrapping. </dd>
	<dt>Signaling zone</dt>		<dt>Signaling zone:</dt>
	<dd>The zone which is authoritative for a given signaling record.</dd>		<dd>The zone that is authoritative for a given signaling record.</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="requirements-notation"><name>Requirements Notation</name>		<section anchor="requirements-notation"><name>Requirements Notation</name>
	<t>The key words &quot;<bcp14>MUST</bcp14>&quot;, &quot;<bcp14>MUST NOT</bcp14>&		<t>
	quot;, &quot;<bcp14>REQUIRED</bcp14>&quot;,		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	&quot;<bcp14>SHALL</bcp14>&quot;, &quot;<bcp14>SHALL NOT</bcp14>&quot;, &quot;<b		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	cp14>SHOULD</bcp14>&quot;, &quot;<bcp14>SHOULD NOT</bcp14>&quot;,		",
	&quot;<bcp14>RECOMMENDED</bcp14>&quot;, &quot;<bcp14>NOT RECOMMENDED</bcp14>&quo		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	t;, &quot;<bcp14>MAY</bcp14>&quot;, and		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	&quot;<bcp14>OPTIONAL</bcp14>&quot; in this document are to be interpreted as de		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	scribed in		be
	BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and o		interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
	nly when, they appear in all		target="RFC8174"/> when, and only when, they appear in all capitals, as
	capitals, as shown here.</t>		shown here.
			</t>
	</section>		</section>
	</section>		</section>
	<section anchor="updates-to-rfcs"><name>Updates to RFCs</name>		<section anchor="updates-to-rfcs"><name>Updates to RFCs</name>
	<t>The DS enrollment methods described in Section 3 of <xref target="RFC8078"></ xref> are less		<t>The DS enrollment methods described in <xref target="RFC8078" sectionFormat=" of" section="3"></xref> are less
	secure than the method described in <xref target="dnssec-bootstrapping"></xref> of this		secure than the method described in <xref target="dnssec-bootstrapping"></xref> of this
	document.		document.
	Child DNS operators and parental agents wishing to use CDS/CDNSKEY		Therefore, child DNS operators and parental agents wishing to use CDS/CDNSKEY
	records for initial DS enrollment SHOULD therefore support the		records for initial DS enrollment <bcp14>SHOULD</bcp14> support the
	authentication protocol described here.</t>		authentication protocol described here.</t>
	<t>In order to facilitate publication of signaling records for the purpose		<t>In order to facilitate publication of signaling records for the purpose
	of DNSSEC bootstrapping (see <xref target="signalingrecords"></xref>), the first bullet		of DNSSEC bootstrapping (see <xref target="signalingrecords"></xref>), the first bullet
	(&quot;Location&quot;) of <xref target="RFC7344"></xref> Section 4.1 is removed. </t>		("Location") of <xref target="RFC7344" sectionFormat="of" section="4.1"></xref> is removed.</t>
	</section>		</section>
	<section anchor="signaling"><name>Signaling</name>		<section anchor="signaling"><name>Signaling</name>
	<t>This section describes the general mechanism by which a child DNS		<t>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 the		Parental agents (or any other party) can then discover and process the
	signal.		signal.
	Authenticity is ensured through standard DNSSEC validation.</t>		Authenticity is ensured through standard DNSSEC validation.</t>
	<section anchor="chain-of-trust"><name>Chain of Trust</name>		<section anchor="chain-of-trust"><name>Chain of Trust</name>
	<t>If a child DNS operator implements this specification, each signaling		<t>If a child DNS operator implements this specification, each signaling
	zone MUST be signed and be validatable by the parental agent (i.e., have		zone <bcp14>MUST</bcp14> be signed and be validatable by the parental agent (i.e ., have
	a valid publicly resolvable DNSSEC chain of trust).		a valid publicly resolvable DNSSEC chain of trust).
	This is typically achieved by securely delegating each signaling zone.</t>		This is typically achieved by securely delegating each signaling zone.</t>
	<t>For example, when publishing a signal that relates to a child zone		<t>For example, when publishing a signal that relates to a child zone
	with NS records <tt>ns1.example.net</tt> and <tt>ns2.example.org</tt>, the child		with NS records <tt>ns1.example.net</tt> and <tt>ns2.example.org</tt>, the child
	DNS operator needs to ensure that the parental agent has a valid DNSSEC		DNS operator needs to ensure that the parental agent has a valid DNSSEC
	chain of trust for the zone(s) that are authoritative for the signaling		chain of trust for the zone(s) that are authoritative for the signaling
	domains <tt>_signal.ns1.example.net</tt> and <tt>_signal.ns2.example.org</tt>.</ t>		domains <tt>_signal.ns1.example.net</tt> and <tt>_signal.ns2.example.org</tt>.</ t>
	</section>		</section>
	<section anchor="signalingnames"><name>Signaling Names</name>		<section anchor="signalingnames"><name>Signaling Names</name>
	<t>To publish information about the child zone in an		<t>To publish information about the child zone in an
	authenticated fashion, the child DNS operator MUST publish one or		authenticated fashion, the child DNS operator <bcp14>MUST</bcp14> publish one or
	more signaling records at a signaling name under each signaling domain.</t>		more signaling records at a signaling name under each signaling domain.</t>
	<t>Signaling records MUST be accompanied by RRSIG records created with		<t>Signaling records <bcp14>MUST</bcp14> be accompanied by RRSIG records created with
	the corresponding signaling zone's key(s).		the corresponding signaling zone's key(s).
	The type and contents of these signaling records depend on the type of		The type and contents of these signaling records depend on the type of
	signal.</t>		signal.</t>
	<t>The signaling name identifies the child and the signaling type.		<t>The signaling name identifies the child and the signaling type.
	It is identical to the child name (with the final root label removed),		It is identical to the child name (with the final root label removed),
	prefixed with a label containing the signaling type.</t>		prefixed with a label containing the signaling type.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="dnssec-bootstrapping"><name>Bootstrapping a DNSSEC Delegation</ name>		<section anchor="dnssec-bootstrapping"><name>Bootstrapping a DNSSEC Delegation</ name>
	<t>When the child zone's CDS/CDNSKEY RRsets are used for setting up initial		<t>When the child zone's CDS/CDNSKEY RRsets are used for setting up initial
	trust, they need to be authenticated.		trust, they need to be authenticated.
	This is achieved by co-publishing the child's CDS/CDNSKEY RRsets as an		This is achieved by copublishing the child's CDS/CDNSKEY RRsets as an
	authenticated signal as described in <xref target="signaling"></xref>.		authenticated signal as described in <xref target="signaling"></xref>.
	The parent can discover and validate it, thus transferring trust from		The parent can discover and validate it, thus transferring trust from
	the child DNS operator nameservers' chain of trust to the child zone.</t>		the child DNS operator nameservers' chain of trust to the child zone.</t>
	<t>This protocol is not intended for updating an existing DS RRset.		<t>This protocol is not intended for updating an existing DS RRset.
	For this purpose, the parental agent can validate the child's		For this purpose, the parental agent can validate the child's
	CDS/CDNSKEY RRsets directly, using the chain of trust established by		CDS/CDNSKEY RRsets directly, using the chain of trust established by
	the existing DS RRset (<xref target="RFC7344"></xref> Section 4).</t>		the existing DS RRset (<xref target="RFC7344" sectionFormat="of" section="4"></x ref>).</t>
	<section anchor="signalingrecords"><name>Signaling Consent to Act as the Child's Signer</name>		<section anchor="signalingrecords"><name>Signaling Consent to Act as the Child's Signer</name>
	<t>To confirm its willingness to act as the child's delegated signer and		<t>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		<bcp14>MUST</bcp14> copublish them at the corresponding signaling name under eac h
	signaling domain, excluding those that would fall within the child		signaling domain, excluding those that would fall within the child
	domain (<xref target="signalingnames"></xref>).		domain (<xref target="signalingnames"></xref>).
	For simplicity, the child DNS operator MAY also co-publish the child's		For simplicity, the child DNS operator <bcp14>MAY</bcp14> also copublish the chi ld's
	CDS/CDNSKEY RRsets under signaling domains within the child domain,		CDS/CDNSKEY RRsets under signaling domains within the child domain,
	although those signaling domains are not used for validation		although those signaling domains are not used for validation
	(<xref target="cds-auth"></xref>).</t>		(<xref target="cds-auth"></xref>).</t>
	<t>Unlike the CDS/CDNSKEY RRsets at the child's apex, a signaling		<t>Unlike the CDS/CDNSKEY RRsets at the child's apex, a signaling
	record set MUST be signed with the corresponding signaling zone's		RRset <bcp14>MUST</bcp14> be signed with the corresponding signaling zone's
	key(s). Its contents MUST be identical to the corresponding		key(s). Its contents <bcp14>MUST</bcp14> be identical to the corresponding
	RRset published at the child's apex.</t>		RRset published at the child's apex.</t>
	<t>Existing use of CDS/CDNSKEY records was specified at the child apex		<t>Existing use of CDS/CDNSKEY records was specified at the child apex
	only (<xref target="RFC7344"></xref>, Section 4.1). This protocol extends the u se of		only (<xref target="RFC7344" sectionFormat="of" section="4.1"></xref>). This pr otocol 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.</t>		there <bcp14>MUST NOT</bcp14> be a zone cut at a signaling name.</t>
	<section anchor="example"><name>Example</name>		<section anchor="example"><name>Example</name>
	<t>For the purposes of bootstrapping the child zone <tt>example.co.uk</tt> with NS		<t>For the purposes of bootstrapping the child zone <tt>example.co.uk</tt> with NS
	records <tt>ns1.example.net</tt>, <tt>ns2.example.org</tt>, and <tt>ns3.example. co.uk</tt>,		records <tt>ns1.example.net</tt>, <tt>ns2.example.org</tt>, and <tt>ns3.example. co.uk</tt>,
	the required signaling domains are <tt>_signal.ns1.example.net</tt> and		the required signaling domains are <tt>_signal.ns1.example.net</tt> and
	<tt>_signal.ns2.example.org</tt>.</t>		<tt>_signal.ns2.example.org</tt>.</t>
	<t>In the zones containing these domains, the child DNS operator		<t>In the zones containing these domains, the child DNS operator
	authenticates the CDS/CDNSKEY RRsets found at the child's apex by		authenticates the CDS/CDNSKEY RRsets found at the child's apex by
	co-publishing them as CDS/CDNSKEY RRsets at the names:</t>		copublishing them as CDS/CDNSKEY RRsets at the names:</t>
	<artwork><![CDATA[_dsboot.example.co.uk._signal.ns1.example.net		<artwork><![CDATA[_dsboot.example.co.uk._signal.ns1.example.net
	_dsboot.example.co.uk._signal.ns2.example.org		_dsboot.example.co.uk._signal.ns2.example.org]]>
	]]>
	</artwork>		</artwork>
	<t>These RRsets are signed with DNSSEC just like any other zone data.</t>		<t>These RRsets are signed with DNSSEC just like any other zone data.</t>
	<t>Publication of signaling records under the in-domain name		<t>Publication of signaling records under the in-domain name
	<tt>_signal.ns3.example.co.uk</tt> is not required.</t>		<tt>_signal.ns3.example.co.uk</tt> is not required.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="cds-auth"><name>Validating CDS/CDNSKEY Records for DNSSEC Boots trapping</name>		<section anchor="cds-auth"><name>Validating CDS/CDNSKEY Records for DNSSEC Boots trapping</name>
	<t>To validate a child's CDS/CDNSKEY RRset for DNSSEC bootstrapping, the		<t>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:</t>		hostnames, <bcp14>MUST</bcp14> execute the following steps:</t>
	<ol>		<ol type="Step %d:">
	<li><t>verify that the child has no DS records published at the parent and		<li anchor="s1"><t>verify that the child has no DS records published at the pare
			nt and
	that at least one of its nameservers is outside the child domain;</t>		that at least one of its nameservers is outside the child domain;</t>
	</li>		</li>
	<li><t>query the CDS/CDNSKEY RRset at the child zone apex directly from		<li anchor="s2"><t>query the CDS/CDNSKEY RRset at the child zone apex directly f rom
	each of the authoritative servers as determined by the delegation's		each of the authoritative servers as determined by the delegation's
	(parent-side) NS RRset, without caching;</t>		(parent-side) NS RRset, without caching;</t>
	</li>		</li>
	<li><t>query the CDS/CDNSKEY RRset located at the signaling name under		<li anchor="s3"><t>query the CDS/CDNSKEY RRset located at the signaling name und er
	each signaling domain (except those falling within the child domain)		each signaling domain (except those falling within the child domain)
	using a trusted DNS resolver and enforce DNSSEC validation;</t>		using a trusted DNS resolver and enforce DNSSEC validation;</t>
	</li>		</li>
	<li><t>check (separately by record type) that all RRsets retrieved		<li anchor="s4"><t>check (separately by record type) that all RRsets retrieved
	in Steps 2 and 3 have equal contents;</t>		in Steps 2 and 3 have equal contents;</t>
	</li>		</li>
	</ol>		</ol>
	<t>If the above steps succeed without error, the CDS/CDNSKEY RRsets are		<t>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
	<xref target="RFC8078"></xref>, Section 5.</t>		<xref target="RFC8078" sectionFormat="of" section="5"></xref>.</t>
	<t>The parental agent MUST abort the procedure if an error		<t>The parental agent <bcp14>MUST</bcp14> abort the procedure if an error
	condition occurs, in particular:</t>		condition occurs, in particular:</t>
	<ul>		<ul>
	<li><t>in Step 1: the child is already securely delegated or has in-domain		<li><t>in <xref target="s1" format="none">Step 1</xref>: the child is already se curely delegated or has in-domain
	nameservers only;</t>		nameservers only;</t>
	</li>		</li>
	<li><t>in Step 2: any failure during the retrieval of the CDS/CDNSKEY		<li><t>in <xref target="s2" format="none">Step 2</xref>: 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;</t>		nameservers;</t>
	</li>		</li>
	<li><t>in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets located		<li><t>in <xref target="s3" format="none">Step 3</xref>: any failure to retrieve the CDS/CDNSKEY RRsets located
	at the signaling name under any signaling domain, including failure		at the signaling name under any signaling domain, including failure
	of DNSSEC validation, or unauthenticated data (AD bit not set);</t>		of DNSSEC validation, or unauthenticated data (AD bit not set);</t>
	</li>		</li>
	<li><t>in Step 4: inconsistent responses (for at least one of the types),		<li><t>in <xref target="s4" format="none">Step 4</xref>: inconsistent responses
	including an RRset that is empty in one of Steps 2 or 3, but		(for at least one of the types),
			including an RRset that is empty in one of Steps <xref target="s2" format="none"
			>2</xref> or <xref target="s3" format="none">3</xref>, but
	non-empty in the other.</t>		non-empty in the other.</t>
	</li>		</li>
	</ul>		</ul>
	<section anchor="example-1"><name>Example</name>		<section anchor="example-1"><name>Example</name>
	<t>To verify the CDS/CDNSKEY RRsets for the child <tt>example.co.uk</tt>, the		<t>To verify the CDS/CDNSKEY RRsets for the child <tt>example.co.uk</tt>, the
	parental agent (assuming that the child delegation's NS records are		parental agent (assuming that the child delegation's NS records are
	<tt>ns1.example.net</tt>, <tt>ns2.example.org</tt>, and <tt>ns3.example.co.uk</t t>)</t>		<tt>ns1.example.net</tt>, <tt>ns2.example.org</tt>, and <tt>ns3.example.co.uk</t t>)</t>
	<ol>		<ol>
	<li><t>checks that the child domain is not yet securely delegated;</t>		<li><t>checks that the child domain is not yet securely delegated;</t>
	</li>		</li>
	<li><t>queries the CDS/CDNSKEY RRsets for <tt>example.co.uk</tt> directly from		<li><t>queries the CDS/CDNSKEY RRsets for <tt>example.co.uk</tt> directly from
	<tt>ns1.example.net</tt>, <tt>ns2.example.org</tt>, and <tt>ns3.example.co.uk</t t>		<tt>ns1.example.net</tt>, <tt>ns2.example.org</tt>, and <tt>ns3.example.co.uk</t t>
	(without caching);</t>		(without caching);</t>
	</li>		</li>
	<li><t>queries and validates the CDS/CDNSKEY RRsets located at (see		<li><t>queries and validates the CDS/CDNSKEY RRsets located at (see
	<xref target="signalingnames"></xref>; <tt>ns3.example.co.uk</tt> is ignored bec ause it is		<xref target="signalingnames"></xref>; <tt>ns3.example.co.uk</tt> is ignored bec ause it is
	in-domain)</t>		in-domain)</t>
	</li>
	</ol>
	<artwork><![CDATA[_dsboot.example.co.uk._signal.ns1.example.net		<artwork><![CDATA[_dsboot.example.co.uk._signal.ns1.example.net
	_dsboot.example.co.uk._signal.ns2.example.org		_dsboot.example.co.uk._signal.ns2.example.org]]>
	]]>
	</artwork>		</artwork>
			</li>
	<ol spacing="compact" start="4">		<li>checks that the CDS/CDNSKEY RRsets retrieved in Steps <xref target="s2" form
	<li>checks that the CDS/CDNSKEY RRsets retrieved in Steps 2		at="none">2</xref>
	and 3 agree across responses.</li>		and <xref target="s3" format="none">3</xref> agree across responses.</li>
	</ol>		</ol>
	<t>If all these steps succeed, the parental agent can proceed to publish		<t>If all of these steps succeed, the parental agent can proceed to publish
	a DS RRset as indicated by the validated CDS/CDNSKEY RRset.</t>		a DS RRset as indicated by the validated CDS/CDNSKEY RRset.</t>
	<t>As in-domain signaling names do not have a chain of trust at		<t>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.		validation.
	Consequently, if all NS hostnames are in-domain, validation cannot be		Consequently, if all NS hostnames are in-domain, validation cannot be
	completed, and DS records are not published.</t>		completed and DS records are not published.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="triggers"><name>Triggers</name>		<section anchor="triggers"><name>Triggers</name>
	<t>Parental agents SHOULD trigger the procedure described in <xref target="cds-a uth"></xref>		<t>Parental agents <bcp14>SHOULD</bcp14> trigger the procedure described in <xre f target="cds-auth"></xref>
	once one of the following conditions is fulfilled:</t>		once one of the following conditions is fulfilled:</t>
	<ul>		<ul>
	<li><t>The parental agent receives a new or updated NS RRset for a		<li><t>The parental agent receives a new or updated NS RRset for a
	child;</t>		child;</t>
	</li>		</li>
	<li><t>The parental agent receives a notification indicating that the child		<li><t>The parental agent receives a notification indicating that the child
	wishes to have its CDS/CDNSKEY RRset processed;</t>		wishes to have its CDS/CDNSKEY RRset processed;</t>
	</li>		</li>
	<li><t>The parental agent encounters a signaling record during a proactive,		<li><t>The parental agent encounters a signaling record during a proactive,
	opportunistic scan (e.g., daily queries of signaling records for		opportunistic scan (e.g., daily queries of signaling records for
	some or all of its delegations);</t>		some or all of its delegations);</t>
	</li>		</li>
	<li><t>The parental agent encounters a signaling record during an NSEC walk		<li><t>The parental agent encounters a signaling record during an NSEC walk
	or when parsing a signaling zone (e.g., when made available via AXFR		or when parsing a signaling zone (e.g., when made available via AXFR
	by the child DNS operator);</t>		by the child DNS operator);</t>
	</li>		</li>
	<li><t>Any other condition as deemed appropriate by local policy.</t>		<li><t>Any other condition deemed appropriate by local policy.</t>
	</li>		</li>
	</ul>		</ul>
	<t>Timer-based trigger mechanisms (such as scans) exhibit undesirable		<t>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, child		triggers (like notifications) are preferable. Whenever possible, child
	DNS operators and parental agents are thus encouraged to use them,		DNS operators and parental agents are thus encouraged to use them,
	reducing both delays and the amount of scanning traffic.</t>		reducing both delays and the amount of scanning traffic.</t>
	<t>Most types of discovery (such as daily scans of delegations) are based		<t>Most types of discovery (such as daily scans of delegations) are based
	directly on the delegation's NS RRset.		directly on the delegation's NS RRset.
	In this case, these NS names can be used as is by the bootstrapping		In this case, these NS names can be used as is by the bootstrapping
	algorithm (<xref target="cds-auth"></xref>) for querying signaling records.</t>		algorithm (<xref target="cds-auth"></xref>) for querying signaling records.</t>
	<t>Some discovery methods, however, do not imply reliable knowledge of the		<t>Some discovery methods, however, do not imply reliable knowledge of the
	delegation's NS RRset.		delegation's NS RRset.
	For example, when discovering signaling names by performing an NSEC		For example, when discovering signaling names by performing an NSEC
	walk or zone transfer of a signaling zone, the parental agent MUST NOT		walk or zone transfer of a signaling zone, the parental agent <bcp14>MUST NOT</b cp14>
	assume that a nameserver under whose signaling domain a signaling		assume that a nameserver under whose signaling domain a signaling
	record appears is actually authoritative for the corresponding child.</t>		record appears is actually authoritative for the corresponding child.</t>
	<t>Instead, whenever a list of &quot;bootstrappable domains&quot; is obtained ot her		<t>Instead, whenever a list of "bootstrappable domains" is obtained by means oth er
	than directly from the parent, the parental		than directly from the parent, the parental
	agent MUST ascertain that the delegation actually contains the		agent <bcp14>MUST</bcp14> ascertain that the delegation actually contains the
	nameserver hostname seen during discovery, and ensure that signaling		nameserver hostname seen during discovery, and ensure that signaling-record quer
	record queries are only made against the proper set of nameservers as		ies are only made against the proper set of nameservers as
	listed in the child's delegation from the parent.</t>		listed in the child's delegation from the parent.</t>
	</section>		</section>
	<section anchor="limitations"><name>Limitations</name>		<section anchor="limitations"><name>Limitations</name>
	<t>As a consequence of Step 3 in <xref target="cds-auth"></xref>, DS bootstrappi		<t>As a consequence of <xref target="s3" format="none">Step 3</xref> in <xref ta
	ng does not		rget="cds-auth"></xref>, 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.		trust to the child domain is available during bootstrapping.
	(As a workaround, one can add an out-of-domain nameserver to the		(As a workaround, one can add an out-of-domain nameserver to the
	initial NS RRset and remove it once bootstrapping is completed.		initial NS RRset and remove it once bootstrapping is completed.
	Automation for this is available via CSYNC records, see <xref target="RFC7477">< /xref>.)</t>		Automation for this is available via CSYNC records, see <xref target="RFC7477">< /xref>.)</t>
	<t>Fully qualified signaling names must by valid DNS names.		<t>Fully qualified signaling names must by valid DNS names.
	Label count and length requirements for DNS names (<xref target="RFC1035"></xref		Label count and length requirements for DNS names (<xref target="RFC1035" sectio
	> Section		nFormat="of" section="3.1"></xref>) imply that the protocol does not work for un
	3.1) imply that the protocol does not work for unusually long child		usually long child
	domain names or NS hostnames.</t>		domain names or NS hostnames.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="operational-recommendations"><name>Operational Recommendations< /name>		<section anchor="operational-recommendations"><name>Operational Recommendations< /name>
	<section anchor="child-dns-operator"><name>Child DNS Operator</name>		<section anchor="child-dns-operator"><name>Child DNS Operator</name>
	<t>It is possible to add CDS/CDNSKEY records and corresponding signaling		<t>It is possible to add CDS/CDNSKEY records and corresponding signaling
	records to a zone without the domain owner's explicit knowledge.		records to a zone without the domain owner's explicit knowledge.
	To spare domain owners from being caught off guard by the ensuing DS		To spare domain owners from being caught off guard by the ensuing DS
	changes, child DNS operators following this practice are advised to make		changes, child DNS operators following this practice are advised to make
	that transparent, such as by informing the domain owner during zone		that transparent, such as by informing the domain owner during zone
	creation (e.g., in a GUI), or by notifying them via email.</t>		creation (e.g., in a GUI) or by notifying them via email.</t>
	<t>When transferring a zone to another DNS operator, the old and new child		<t>When transferring a zone to another DNS operator, the old and new child
	DNS operators need to cooperate to achieve a smooth transition, e.g.,		DNS operators need to cooperate to achieve a smooth transition, e.g.,
	by using the multi-signer protocols described in <xref target="RFC8901"></xref>.		by using the multi-signer protocols described in <xref target="RFC8901"></xref>.
	If all else fails, the domain owner might have to request the removal of		If 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
	<xref target="I-D.hardaker-dnsop-intentionally-temporary-insec"></xref>).</t>		<xref target="I-D.hardaker-dnsop-intentionally-temporary-insec"></xref>).</t>
	<t>Signaling domains SHOULD be delegated as standalone zones, so		<t>Signaling domains <bcp14>SHOULD</bcp14> be delegated as standalone zones, so
	that the signaling zone's apex coincides with the signaling domain (such		that the signaling zone's apex coincides with the signaling domain (such
	as <tt>_signal.ns1.example.net</tt>).		as <tt>_signal.ns1.example.net</tt>).
	While it is permissible for the signaling domain to be contained		While it is permissible for the signaling domain to be contained
	in a signaling zone of fewer labels (such as <tt>example.net</tt>), a		in a signaling zone of fewer labels (such as <tt>example.net</tt>), a
	zone cut ensures that bootstrapping activities do not require		zone cut ensures that bootstrapping activities do not require
	modifications of the zone containing the nameserver hostname.</t>		modifications of the zone containing the nameserver hostname.</t>
	<t>Once a Child DNS Operator determines that specific signaling record sets		<t>Once a child DNS operator determines that specific signaling record sets
	have been processed (e.g., by seeing the result in the parent zone),		have been processed (e.g., by seeing the result in the parent zone),
	they are advised to remove them.		they are advised to remove them.
	This will reduce the size of the signaling zone, and facilitate more		This will reduce the size of the signaling zone and facilitate more
	efficient bulk processing (such as via zone transfers).</t>		efficient bulk processing (such as via zone transfers).</t>
	</section>		</section>
	<section anchor="parental-agent"><name>Parental Agent</name>		<section anchor="parental-agent"><name>Parental Agent</name>
	<t>In order to ensure timely DNSSEC bootstrapping of insecure domains,		<t>In order to ensure timely DNSSEC bootstrapping of insecure domains,
	stalemate situations due to mismatch of stale cached records (Step 4 of		stalemate situations due to mismatch of stale cached records (<xref target="s4" format="none">Step 4</xref> of
	<xref target="cds-auth"></xref>) need to be avoided.		<xref target="cds-auth"></xref>) need to be avoided.
	It is thus RECOMMENDED to perform queries into signaling domains with an		It is thus <bcp14>RECOMMENDED</bcp14> that
	(initially) empty resolver cache, or using some other method for		queries into signaling domains be performed with an (initially) empty
	retrieving fresh data from authoritative servers.</t>		resolver cache, or that some other method for retrieving fresh data
	<t>It is also RECOMMENDED to use QNAME minimization <xref target="RFC9156"></xre		from authoritative servers be used.</t>
	f> when		<t>It is also <bcp14>RECOMMENDED</bcp14> that QNAME minimization <xref target="R
	resolving queries for signaling records, to guard against certain		FC9156"></xref> be used when
			resolving queries for signaling records to guard against certain
	attacks (see <xref target="security"></xref>).</t>		attacks (see <xref target="security"></xref>).</t>
	</section>		</section>
	</section>		</section>
	<section anchor="security"><name>Security Considerations</name>		<section anchor="security"><name>Security Considerations</name>
	<t>The DNSSEC bootstrapping method introduced in this document is based on		<t>The DNSSEC bootstrapping method introduced in this document is based on
	the approaches described in <xref target="RFC8078"></xref> Section 3, but		the approaches described in <xref target="RFC8078" sectionFormat="of" section="3 "></xref>, but
	adds authentication to the CDS/CDNSKEY concept.		adds authentication to the CDS/CDNSKEY concept.
	Its security level is therefore strictly higher than that of existing		Its security level is therefore strictly higher than that of existing
	approaches described in that document (e.g., &quot;Accept after Delay&quot;).		approaches described in that document (e.g., "Accept after Delay").
	Apart from this general improvement, the same Security Considerations		Apart from this general improvement, the same Security Considerations
	apply as in <xref target="RFC8078"></xref>.</t>		apply as in <xref target="RFC8078"></xref>.</t>
	<t>The level of rigor in <xref target="cds-auth"></xref> is needed to prevent pu blication of a		<t>The level of rigor in <xref target="cds-auth"></xref> is needed to prevent pu blication of an
	ill-conceived DS RRset (authorized only under a subset of NS hostnames).		ill-conceived DS RRset (authorized only under a subset of NS hostnames).
	This ensures, for example, that an operator in a multi-homed setup		This ensures, for example, that an operator in a multi-homed setup
	cannot enable DNSSEC unless all other operators agree.</t>		cannot enable DNSSEC unless all other operators agree.</t>
	<t>In any case, as the child DNS operator has authoritative knowledge of		<t>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.</t>		provisioning of DS records.</t>
	<t>In order to prevent the parents of nameserver hostnames from becoming a		<t>In order to prevent the parents of nameserver hostnames from becoming a
	single point of failure for a delegation (both in terms of resolution		single point of failure for a delegation (both in terms of resolution
	availability and for the trust model of this protocol), it is advisable		availability and for the trust model of this protocol),
	to diversify the path from the root to the child's nameserver hostnames,		diversifying the path from the root to the child's nameserver hostnames is advis
	such as by using different and independently operated TLDs for each one.</t>		able. For example, different and independently operated TLDs may be used for eac
			h one.</t>
	<t>If QNAME minimization <xref target="RFC9156"></xref> is not used when queryin g for		<t>If QNAME minimization <xref target="RFC9156"></xref> is not used when queryin g 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 answer		those CDS/CDNSKEY queries and could respond with an authoritative answer
	signed with its own key, instead of sending the referral.		signed with its own key, instead of sending the referral.
	Enabling QNAME minimization reduces the attack surface for such forgery.</t>		Enabling QNAME minimization reduces the attack surface for such forgery.</t>
	</section>		</section>
	<section anchor="iana-considerations"><name>IANA Considerations</name>		<section anchor="iana-considerations"><name>IANA Considerations</name>
	<t>Per <xref target="RFC8552"></xref>, IANA is requested to add the following en
	tries to the
	&quot;Underscored and Globally Scoped DNS Node Names&quot; registry:</t>
	<artwork><![CDATA[+---------+------------+------------+		<t>IANA has added the following entries to the
	| RR Type | _NODE NAME | Reference |		"Underscored and Globally Scoped DNS Node Names" registry <xref target="RFC8552"
	+---------+------------+------------+		/>:</t>
	| CDS | _signal | [This RFC] |		<table anchor="iana-table">
	| CDNSKEY | _signal | [This RFC] |		<name></name>
	+---------+------------+------------+		<thead>
	]]>		<tr>
	</artwork>		<th>RR Type</th>
	<t><strong>Note to the RFC Editor</strong>: please replace &quot;This RFC&quot;		<th>_NODE NAME</th>
	in the above table with a proper reference.</t>		<th>Reference</th>
	</section>		</tr>
			</thead>
	<section anchor="implementation-status"><name>Implementation Status</name>		<tbody>
	<t><strong>Note to the RFC Editor</strong>: please remove this entire section be		<tr>
	fore publication.</t>		<td>CDS</td>
	<t>In addition to the information in this section, deployment is tracked		<td>_signal</td>
	by the community at <eref target="https://github.com/oskar456/cds-updates">https		<td>RFC 9615</td>
	://github.com/oskar456/cds-updates</eref>.</t>		</tr>
			<tr>
	<section anchor="child-dns-operator-side"><name>Child DNS Operator-side</name>		<td>CDNSKEY</td>
			<td>_signal</td>
	<ul>		<td>RFC 9615</td>
	<li><t>Operator support:</t>		</tr>
			</tbody>
	<ul spacing="compact">		</table>
	<li>Cloudflare has implemented bootstrapping record synthesis for all
	signed customer zones.</li>
	<li>Glauca HexDNS publishes bootstrapping records for its customer
	zones.</li>
	<li>deSEC performs bootstrapping record synthesis for its zones using
	names <tt>_signal.ns1.desec.io</tt> and <tt>_signal.ns2.desec.org</tt>.</li>
	</ul></li>
	<li><t>Authoritative nameserver support:</t>
	<ul spacing="compact">
	<li>Knot DNS supports signaling record synthesis since version 3.3.5.</li>
	<li>An implementation of bootstrapping record synthesis in PowerDNS is
	available at <eref target="https://github.com/desec-io/desec-ns/pull/46">https:/
	/github.com/desec-io/desec-ns/pull/46</eref>.</li>
	</ul></li>
	</ul>
	</section>		</section>
	<section anchor="parental-agent-side"><name>Parental Agent-side</name>		</middle>
	<ul>
	<li><t>ccTLD:</t>
	<ul spacing="compact">		<back>
	<li>SWITCH (.ch, .li) has implemented authentication of consumed CDS		<displayreference target="I-D.hardaker-dnsop-intentionally-temporary-insec" to="
	records based on this draft.</li>		INSEC"/>
	<li>.cl is working on an implementation.</li>		<references>
	</ul></li>		<name>References</name>
	<li><t>gTLD:</t>		<references>
			<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.
			xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.
			xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7344.
			xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7477.
			xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8078.
			xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.
			xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.
			xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9156.
			xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.
			xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<referencegroup anchor="BCP237" target="https://www.rfc-editor.org/info/bcp2
			37">
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.936
			4.xml"/>
			</referencegroup>
	<ul spacing="compact">		<!-- [I-D.hardaker-dnsop-intentionally-temporary-insec] IESG state: Expired as o
	<li>Knipp has implemented consumption of DNSSEC bootstrapping records		f 05/29/24-->
	in its TANGO and CORE registry systems.</li>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hard
	<li>A deployment of this is running at .swiss.</li>		aker-dnsop-intentionally-temporary-insec.xml"/>
	</ul></li>
	<li><t>Registrars:</t>
	<ul spacing="compact">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8901.
	<li>Glauca has implemented authenticated CDS processing.</li>		xml"/>
	<li>GoDaddy is working on an implementation.</li>		</references>
	</ul></li>		</references>
	<li><t>A tool to retrieve and process signaling records for bootstrapping
	purposes, either directly or via zone walking, is available at
	<eref target="https://github.com/desec-io/dsbootstrap">https://github.com/desec-
	io/dsbootstrap</eref>.
	The tool outputs the validated DS records which then can be added
	to the parent zone.</t>
	</li>
	</ul>
	</section>
	</section>
	<section anchor="acknowledgements"><name>Acknowledgements</name>		<section anchor="acknowledgements" numbered="false"><name>Acknowledgements</name
	<t>Thanks to Brian Dickson, Ondřej Caletka, John R. Levine, Christian		>
	Elmerot, Oli Schacher, Donald Eastlake, Libor Peltan, Warren Kumari,		<t>Thanks to <contact fullname="Brian Dickson"/>, <contact fullname="Ondřej Cale
	Scott Rose, Linda Dunbar, Tim Wicinski, Paul Wouters, Paul Hoffman,		tka"/>, <contact fullname="John R. Levine"/>, <contact fullname="Christian
	Peter Yee, Benson Muite, Roman Danyliw, Éric Vyncke, and Joe Abley for		Elmerot"/>, <contact fullname="Oli Schacher"/>, <contact fullname="Donald Eastla
			ke"/>, <contact fullname="Libor Peltan"/>, <contact fullname="Warren Kumari"/>,
			<contact fullname="Scott Rose"/>, <contact fullname="Linda Dunbar"/>, <contact f
			ullname="Tim Wicinski"/>, <contact fullname="Paul Wouters"/>, <contact fullname=
			"Paul Hoffman"/>,
			<contact fullname="Peter Yee"/>, <contact fullname="Benson Muite"/>, <contact fu
			llname="Roman Danyliw"/>, <contact fullname="Éric Vyncke"/>, and <contact fullna
			me="Joe Abley"/> for
	reviewing draft proposals and offering comments and suggestions.</t>		reviewing draft proposals and offering comments and suggestions.</t>
	<t>Thanks also to Steve Crocker, Hugo Salgado, and Ulrich Wisser for		<t>Thanks also to <contact fullname="Steve Crocker"/>, <contact fullname="Hugo S algado"/>, and <contact fullname="Ulrich Wisser"/> for
	early-stage brainstorming.</t>		early-stage brainstorming.</t>
	</section>		</section>
	</middle>
	<back>
	<references><name>References</name>
	<references><name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"
	/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
	/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7344.xml"
	/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7477.xml"
	/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8078.xml"
	/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
	/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml"
	/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9156.xml"
	/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"
	/>
	</references>
	<references><name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.237.xml"
	/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hardaker
	-dnsop-intentionally-temporary-insec.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8901.xml"
	/>
	</references>
	</references>
	<section anchor="change-history-to-be-removed-before-publication"><name>Change H
	istory (to be removed before publication)</name>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-11</li>
	</ul>
	<blockquote><t>Addressed comment by Paul Wouters</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-10</li>
	</ul>
	<blockquote><t>Editorial nit</t>
	<t>Addressed comments by Paul Wouters</t>
	<t>Make capitalization of registrar/registrant consistent</t>
	<t>Editorial nit by Joe Abley</t>
	<t>Addressed comments by Éric Vyncke</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-09</li>
	</ul>
	<blockquote><t>Addressed comments by Paul Wouters</t>
	<t>Editorial nits by Roman Danyliw</t>
	<t>Editorial nits by Benson Muite</t>
	<t>Editorial nits by Peter Yee</t>
	<t>Editorial nit by Scott Rose</t>
	<t>Editorial suggestion from John Levine</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-08</li>
	</ul>
	<blockquote><t>Editorial changes from AD Review</t>
	<t>Updated implementation section</t>
	<t>Change capitalization of terms from terminology section</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-07</li>
	</ul>
	<blockquote><t>Add Glauca registrar implementation</t>
	<t>Editorial changes to Security Considerations</t>
	<t>Add/discuss on-demand triggers (notifications)</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-06</li>
	</ul>
	<blockquote><t>Add section &quot;Updates to RFCs&quot;</t>
	<t>Editorial nits</t>
	<t>Editorial changes from Secdir early review</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-05</li>
	</ul>
	<blockquote><t>Editorial changes</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-04</li>
	</ul>
	<blockquote><t>Added consent considerations.</t>
	<t>Editorial changes.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-03</li>
	</ul>
	<blockquote><t>Updated Implementation section.</t>
	<t>Typo fix.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-02</li>
	</ul>
	<blockquote><t>Clarified that RFC 8078 Section 3 is not replaced, but its method
	s are
	deprecated.</t>
	<t>Added new deployments to Implementation section.</t>
	<t>Included NSEC walk / AXFR as possible triggers for DS bootstrapping.</t>
	<t>Editorial changes.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-01</li>
	</ul>
	<blockquote><t>Allow bootstrapping when some (not all) NS hostnames are in baili
	wick.</t>
	<t>Clarified Operational Recommendations according to operator feedback.</t>
	<t>Turn loose Security Considerations points into coherent text.</t>
	<t>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.)</t>
	<t>Editorial changes.</t>
	<t>Added IANA request.</t>
	<t>Introduced Signaling Type prefix (<tt>_dsboot</tt>), renamed Signaling Name
	infix from <tt>_dsauth</tt> to <tt>_signal</tt>.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-dnssec-bootstrapping-00</li>
	</ul>
	<blockquote><t>Editorial changes.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-thomassen-dnsop-dnssec-bootstrapping-03</li>
	</ul>
	<blockquote><t>Clarified importance of record cleanup by moving paragraph up.</t
	>
	<t>Pointed out limitations.</t>
	<t>Replace <xref target="RFC8078"></xref> Section 3 with our <xref target="cds-a
	uth"></xref>.</t>
	<t>Changed <tt>_boot</tt> label to <tt>_dsauth</tt>.</t>
	<t>Removed hashing of Child name components in Signaling Names.</t>
	<t>Editorial changes.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-thomassen-dnsop-dnssec-bootstrapping-02</li>
	</ul>
	<blockquote><t>Reframed as an authentication mechanism for RFC 8078.</t>
	<t>Removed multi-signer use case (focus on RFC 8078 authentication).</t>
	<t>Triggers need to fetch NS records (if not implicit from context).</t>
	<t>Improved title.</t>
	<t>Recognized that hash collisions are dealt with by Child apex check.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-thomassen-dnsop-dnssec-bootstrapping-01</li>
	</ul>
	<blockquote><t>Add section on Triggers.</t>
	<t>Clarified title.</t>
	<t>Improved abstract.</t>
	<t>Require CDS/CDNSKEY records at the Child.</t>
	<t>Reworked Signaling Name scheme.</t>
	<t>Recommend using cold cache for consumption.</t>
	<t>Updated terminology (replace &quot;Bootstrapping&quot; by &quot;Signaling&quo
	t;).</t>
	<t>Added NSEC recommendation for Bootstrapping Zones.</t>
	<t>Added multi-signer use case.</t>
	<t>Editorial changes.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-thomassen-dnsop-dnssec-bootstrapping-00</li>
	</ul>
	<blockquote><t>Initial public draft.</t>
	</blockquote></section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 83 change blocks.
	395 lines changed or deleted		247 lines changed or added
This html diff was produced by rfcdiff 1.48.