Diff: rfc9975.original.xml

	rfc9975.original.xml	rfc9975.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" -->
	<rfc version="3" ipr="trust200902" docName="draft-ietf-dnsop-cds-consistency-11"
	submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/
	2001/XInclude" updates="7344, 7477" indexInclude="true">


	<front>	<!DOCTYPE rfc [
	<title abbrev="cds-consistency">Clarifications on CDS/CDNSKEY and CSYNC Consiste	<!ENTITY nbsp " ">
	ncy</title><seriesInfo value="draft-ietf-dnsop-cds-consistency-11" stream="IETF"	<!ENTITY zwsp "">
	status="standard" name="Internet-Draft"></seriesInfo>	<!ENTITY nbhy "‑">
	<author initials="P." surname="Thomassen" fullname="Peter Thomassen"><organizati	<!ENTITY wj "⁠">
	on>SSE - Secure Systems Engineering GmbH</organization><address><postal><street>	]>
	Hauptstraße 3</street>
	<city>Berlin</city>	<rfc version="3" ipr="trust200902" docName="draft-ietf-dnsop-cds-consistency-11"
	<code>10827</code>	number="9975" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http
	<country>Germany</country>	://www.w3.org/2001/XInclude" updates="7344, 7477" obsoletes="" tocInclude="true"
	</postal><email>pth@systemsecurity.com</email>	symRefs="true" sortRefs="false" consensus="true">
	</address></author><date year="2025" month="December" day="11"></date>
	<area>Internet</area>	<front>
	<workgroup>DNSOP Working Group</workgroup>
		<!--[rfced] Please note that we have updated the abbreviated title for
		this document from "cds-consistency" to instead read as "CDS
		Consistency". Please let us know any objections. -->

		<title abbrev="CDS Consistency">Clarifications on CDS/CDNSKEY and CSYNC Cons
		istency</title>
		<seriesInfo name="RFC" value="9975"/>
		<author initials="P." surname="Thomassen" fullname="Peter Thomassen">
		<organization>SSE - Secure Systems Engineering GmbH</organization>
		<address>
		<postal>
		<street>Hauptstraße 3</street>
		<city>Berlin</city>
		<code>10827</code>
		<country>Germany</country>
		</postal>
		<email>pth@systemsecurity.com</email>
		</address>
		</author>

		<date year="2026" month="May"/>

		<area>OPS</area>
		<workgroup>dnsop</workgroup>

		<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->

		<keyword>example</keyword>

	<abstract>	<abstract>

	<t>Maintenance of DNS delegations requires occasional changes of the DS and	<t>Maintenance of DNS delegations requires occasional changes of the DS and
	NS record sets on the parent side of the delegation.	NS record sets on the parent side of the delegation.

	For the case of DS records, "Automating DNSSEC Delegation Trust Maintenance " (RFC 7344) provides automation by allowing the	For the case of DS records, "Automating DNSSEC Delegation Trust Maintenance" (RF C 7344) provides automation by allowing the
	child to publish CDS and/or CDNSKEY records holding the prospective DS	child to publish CDS and/or CDNSKEY records holding the prospective DS

	parameters which the parent can ingest.	parameters that the parent can ingest.
	Similarly, "Child-to-Parent Synchronization in DNS" (RFC 7477) specifi	Similarly, "Child-to-Parent Synchronization in DNS" (RFC 7477) specifies CSYNC r
	es CSYNC records to indicate a desired update	ecords to indicate a desired update
	of the delegation's NS (and glue) records.	of the delegation's NS (and glue) records.
	Parent-side entities (e.g., Registries and Registrars) can query these	Parent-side entities (e.g., Registries and Registrars) can query these
	records from the child and, after validation, use them to update the	records from the child and, after validation, use them to update the
	parent-side Resource Record Sets (RRsets) of the delegation.</t>	parent-side Resource Record Sets (RRsets) of the delegation.</t>
	<t>This document specifies under which conditions the target states expressed	<t>This document specifies under which conditions the target states expressed

	via CDS/CDNSKEY and CSYNC records are considered "consistent". Parent- side	via CDS/CDNSKEY and CSYNC records are considered "consistent". Parent-side
	entities accepting such records from the child have to ensure that update	entities accepting such records from the child have to ensure that update
	requests retrieved from different authoritative nameservers satisfy these	requests retrieved from different authoritative nameservers satisfy these
	consistency requirements before taking any action based on them.</t>	consistency requirements before taking any action based on them.</t>

	<t>This document updates RFC 7344 and RFC 7477.</t>	<t>This document updates RFCs 7344 and 7477.</t>
	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

	<section anchor="introduction"><name>Introduction</name>	<section anchor="introduction"><name>Introduction</name>

	<t><xref target="RFC7344"></xref> automates DNSSEC delegation trust maintenance	<t><xref target="RFC7344"/> automates DNS Security Extensions (DNSSEC) delegatio
	by having the	n trust maintenance by having the
	child publish CDS and/or CDNSKEY records which describe the prospective DS	child publish CDS and/or CDNSKEY records that describe the prospective DS
	parameters.	parameters.

	Similarly, <xref target="RFC7477"></xref> specifies CSYNC records indicating a d esired	Similarly, <xref target="RFC7477"/> specifies CSYNC records indicating a desired
	update of the delegation's NS and associated glue records.	update of the delegation's NS and associated glue records.
	Parent-side entities (e.g., Registries and Registrars) can use these records	Parent-side entities (e.g., Registries and Registrars) can use these records
	to update the corresponding records of the delegation.</t>	to update the corresponding records of the delegation.</t>

	<t>For ingesting CSYNC records, Section 3.1 of <xref target="RFC7477"></xref> ad vocates that	<t>For ingesting CSYNC records, <xref section="3.1" target="RFC7477"/> advocates that
	Parental Agents limit queries to a single authoritative nameserver (as	Parental Agents limit queries to a single authoritative nameserver (as

	typically done in normal resolution).	done in normal resolution).
	The corresponding Section 6.1 of <xref target="RFC7344"></xref> (CDS/CDNSKEY) co
	ntains no	<!--[rfced] We had a few questions regarding the following text:

		Original:
		The corresponding Section 6.1 of [RFC7344] (CDS/CDNSKEY) contains no
		provision for how specifically queries for these records should be
		done.

		a) "The corresponding Section 6.1" sounds a bit strange (as it is being compared
		to Section 3.1 of RFC 7477). May we update as follows?

		Perhaps:
		[RFC7344] has a corresponding section (Section 6.1) (CDS/CDNSKEY) that
		contains no provision for how specifically queries for these records
		should be done.

		b) How does the parenthetical (CDS/CDNSKEY) relate to the sentence?
		It is not the title of Section 6.1. Please review.
		-->

		The corresponding <xref section="6.1" target="RFC7344"/> (CDS/CDNSKEY) contains
		no
	provision for how specifically queries for these records should be done.</t>	provision for how specifically queries for these records should be done.</t>
	<t>Retrieving records from just one authoritative server (e.g., by	<t>Retrieving records from just one authoritative server (e.g., by
	directing queries towards a trusted validating resolver) works well	directing queries towards a trusted validating resolver) works well
	under ideal operating scenarios.	under ideal operating scenarios.
	However, problems may arise if CDS/CDNSKEY/CSYNC record sets are	However, problems may arise if CDS/CDNSKEY/CSYNC record sets are

	inconsistent across authoritative nameservers, either because they are	inconsistent across authoritative nameserver either because they are
	out of sync (e.g., during a Key Signing Key (KSK) rollover), or because they are	out of sync (e.g., during a Key Signing Key (KSK) rollover) or because they are
	not	not
	controlled by the same entity (e.g., in a multi-signer setup	controlled by the same entity (e.g., in a multi-signer setup

	<xref target="RFC8901"></xref>).</t>	<xref target="RFC8901"/>).</t>
	<t>In such cases, if CDS/CDNSKEY/CSYNC records are retrieved from one	<t>In such cases, if CDS/CDNSKEY/CSYNC records are retrieved from one

	nameserver only ("naively", without a consistency check), each	nameserver only ("naively", without a consistency check), each
	nameserver can unilaterally trigger an update of the delegation's DS or	nameserver can unilaterally trigger an update of the delegation's DS or
	NS record set.</t>	NS record set.</t>
	<t>For example, a single provider in a multi-signer setup may (accidentally	<t>For example, a single provider in a multi-signer setup may (accidentally
	or maliciously) cause another provider's trust anchors and/or	or maliciously) cause another provider's trust anchors and/or
	nameservers to be removed from the delegation.	nameservers to be removed from the delegation.
	This can occur both when the multi-signer configuration is temporary	This can occur both when the multi-signer configuration is temporary
	(e.g., during a provider change) and when it is permanent (e.g., for redundancy) .	(e.g., during a provider change) and when it is permanent (e.g., for redundancy) .


		<!--[rfced] Please review this use of the plural possessive (as previous text in
		the same paragraph used singular possessive).

		Original:
		In any case, a single provider should not be in the position to remove
		the other providers' records from the delegation.

		Perhaps:
		In any case, a single provider should not be in the position to remove
		the other provider's records from the delegation.
		-->

	In any case, a single provider should not be in the position to remove	In any case, a single provider should not be in the position to remove
	the other providers' records from the delegation.</t>	the other providers' records from the delegation.</t>
	<t>Similar breakage can occur when the delegation has lame nameservers,	<t>Similar breakage can occur when the delegation has lame nameservers,
	where an attacker may illegitimately initialize a DS record set and then	where an attacker may illegitimately initialize a DS record set and then
	manipulate the delegation's NS record set at will.	manipulate the delegation's NS record set at will.

	More detailed examples are given in <xref target="scenarios"></xref>.</t>	More detailed examples are given in <xref target="scenarios"/>.</t>
	<t>For a CDS/CDNSKEY/CSYNC consumer, it is generally impossible to estimate	<t>For a CDS/CDNSKEY/CSYNC consumer, it is generally impossible to estimate
	the impact of a requested delegation update unless all of the child's	the impact of a requested delegation update unless all of the child's
	authoritative nameservers are inspected.	authoritative nameservers are inspected.

	At the same time, applying an automated delegation update "MUST NOT	At the same time, applying an automated delegation update "<bcp14>MUST NOT</bcp1
	break the current delegation" (<xref target="RFC7344"></xref>, Section 4.1)	4>
	, i.e., it must	break the current delegation" (per <xref target="RFC7344" section="4.1" sectionF
		ormat="comma"/>), i.e., it must
	not hamper availability or validatability of the Child's resolution.	not hamper availability or validatability of the Child's resolution.

	As part of a more holistic treatment of the problem space,	As part of a more holistic treatment of the problem space, <xref target="I-D.iet
	<xref target="I-D.ietf-dnsop-ds-automation"></xref> provides more specific guida	f-dnsop-ds-automation"/> provides more-specific guidance on
	nce on
	such safety checks.</t>	such safety checks.</t>

	<t>This document therefore specifies that parent-side entities need to	<t>Therefore, this document specifies that parent-side entities need to
	ensure that the updates indicated by CDS/CDNSKEY and CSYNC record sets	ensure that the updates indicated by CDS/CDNSKEY and CSYNC record sets

	are plausibly consistent across the child's nameservers, before taking	are plausibly consistent across the child's nameservers before taking
	any action based on these records.</t>	any action based on these records.</t>

	<t>Readers are expected to be familiar with DNSSEC <xref target="RFC9364"></xref	<t>Readers are expected to be familiar with DNSSEC <xref target="RFC9364"/>, in
	>, in	particular, <xref target="RFC4033"/>, <xref target="RFC4034"/>, <xref target="RF
	particular <xref target="RFC4033"></xref>, <xref target="RFC4034"></xref>, <xref	C4035"/>, <xref target="RFC7344"/>, and
	target="RFC4035"></xref>, <xref target="RFC7344"></xref>, and	<xref target="RFC7477"/>.
	<xref target="RFC7477"></xref>.	For an overview of related operational practices, refer to <xref target="RFC6781
	For an overview of related operational practices, refer to <xref target="RFC6781	"/>
	"></xref>	and <xref target="RFC8901"/>.</t>
	and <xref target="RFC8901"></xref>.</t>


	<section anchor="requirements-notation"><name>Requirements Notation</name>	<section anchor="requirements-notation">
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>&	<name>Requirements Notation</name>
	quot;, "<bcp14>REQUIRED</bcp14>",	<t>
	"<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<b	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	cp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>&quo	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	t;, "<bcp14>MAY</bcp14>", and	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as de	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	scribed in	be interpreted as
	BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and o	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	nly when, they appear in all	when, and only when, they appear in all capitals, as shown here.
	capitals, as shown here.</t>	</t>
	</section>	</section>

	<section anchor="terminology"><name>Terminology</name>	<section anchor="terminology"><name>Terminology</name>


	<dl spacing="compact">	<dl spacing="normal" newline="false">
	<dt>Multi-provider setup:</dt>	<dt>Multi-provider setup:</dt>
	<dd>A constellation where several providers independently operate authoritative	<dd>A constellation where several providers independently operate authoritative
	DNS service for a domain, usually for purposes of redundancy. This includes	DNS service for a domain, usually for purposes of redundancy. This includes
	setups both with and without DNSSEC.</dd>	setups both with and without DNSSEC.</dd>
	<dt>Multi-signer setup:</dt>	<dt>Multi-signer setup:</dt>
	<dd>A multi-provider setup for a DNSSEC-enabled domain with multiple independent	<dd>A multi-provider setup for a DNSSEC-enabled domain with multiple independent

	signing entities <xref target="RFC8901"></xref>. Such a setup may be permanent ( for redundancy)	signing entities <xref target="RFC8901"/>. Such a setup may be permanent (for re dundancy)
	or temporary (for continuity of DNSSEC operation while changing the provider	or temporary (for continuity of DNSSEC operation while changing the provider
	of a domain that normally uses a single one).</dd>	of a domain that normally uses a single one).</dd>
	</dl>	</dl>

	<t>Otherwise, the terminology in this document is as defined in <xref target="RF C7344"></xref>.</t>	<t>Otherwise, the terminology in this document is as defined in <xref target="RF C7344"/>.</t>
	</section>	</section>
	</section>	</section>


	<section anchor="updates-to-rfc-7344-and-rfc-7477"><name>Updates to RFC 7344 and	<section anchor="updates-to-rfc-7344-and-rfc-7477"><name>Updates to RFCs 7344 an
	RFC 7477</name>	d 7477</name>
	<t>Section 4.1 of <xref target="RFC7344"></xref> lists acceptance rules for CDS/	<t><xref section="4.1" target="RFC7344"/> lists acceptance rules for CDS/CDNSKEY
	CDNSKEY records.	records.
	This list is extended with the consistency requirements defined in this	This list is extended with the consistency requirements defined in this

	document. This document does not modify any other part of <xref target="RFC7344"	document. This document does not modify any other part of <xref target="RFC7344"
	></xref>.</t>	/>.</t>
	<t>Sections 3.1 and 4.2 of <xref target="RFC7477"></xref> have logic for decidin	<t>Sections <xref target="RFC7477" section="3.1" sectionFormat="bare"/> and <xre
	g from which	f target="RFC7477" section="4.2" sectionFormat="bare"/> of <xref target="RFC7477
		"/> have logic for deciding from which
	nameserver to query CSYNC information. This logic is replaced with the	nameserver to query CSYNC information. This logic is replaced with the
	CSYNC consistency requirements defined in this document.</t>	CSYNC consistency requirements defined in this document.</t>
	</section>	</section>

	<section anchor="processing-requirements"><name>Processing Requirements</name>	<section anchor="processing-requirements"><name>Processing Requirements</name>
	<t>Consistency requirements that apply equally to CDS/CDNSKEY and CSYNC are	<t>Consistency requirements that apply equally to CDS/CDNSKEY and CSYNC are
	listed first; type-specific consistency criteria are described in	listed first; type-specific consistency criteria are described in
	separate subsections.</t>	separate subsections.</t>
	<t>In order to determine plausible consistency of CDS/CDNSKEY or CSYNC	<t>In order to determine plausible consistency of CDS/CDNSKEY or CSYNC

	RRsets across the child's nameservers, the Parental Agent MUST fetch all	RRsets across the child's nameservers, the Parental Agent <bcp14>MUST</bcp14> fe tch all
	IP addresses for each nameserver hostname as listed in the Child's	IP addresses for each nameserver hostname as listed in the Child's

	delegation from the Parent using a validating resolver, and including	delegation from the Parent using a validating resolver, including
	glue records if available. Before acting on any CDS/CDNSKEY or CSYNC	any available glue records. Before acting on any CDS/CDNSKEY or CSYNC
	record for the child, the Parental Agent MUST have established plausible	record for the child, the Parental Agent <bcp14>MUST</bcp14> have established pl
		ausible
	consistency by querying all of these IP addresses for the record set(s)	consistency by querying all of these IP addresses for the record set(s)
	in question, as per the guidelines spelled out in the following	in question, as per the guidelines spelled out in the following
	subsections.</t>	subsections.</t>

	<t>In all cases, consistency is REQUIRED across received responses only.	<t>In all cases, consistency is <bcp14>REQUIRED</bcp14> across received response
		s only.

		<!--[rfced] Would it make sense to add a pointer to RFC 2308 or RFC
		9499 on first use of NODATA for the ease of the reader?

		Original:
		(A NODATA response is a received response.)

		Perhaps:
		(A NODATA response [RFC9499] is a received response.)
		-->

	(A NODATA response is a received response.)</t>	(A NODATA response is a received response.)</t>
	<t>When a response cannot be obtained from a given nameserver, the Parental	<t>When a response cannot be obtained from a given nameserver, the Parental

	Agent SHOULD attempt to obtain it at a later time, before concluding	Agent <bcp14>SHOULD</bcp14> attempt to obtain it at a later time, before conclud ing
	that the nameserver is permanently unreachable and removing it from	that the nameserver is permanently unreachable and removing it from
	consideration.	consideration.

	A configurable retry schedule is RECOMMENDED to increase the likelihood	A configurable retry schedule is <bcp14>RECOMMENDED</bcp14> to increase the like lihood
	of collecting data from all nameservers. An exponential back-off	of collecting data from all nameservers. An exponential back-off
	schedule (e.g., 5, 10, 20, 40, ... minutes) provides a balance between	schedule (e.g., 5, 10, 20, 40, ... minutes) provides a balance between
	faster task completion while accommodating transient unreachability.	faster task completion while accommodating transient unreachability.

	To sidestep localized routing issues, the Parental Agent MAY also	To sidestep localized routing issues, the Parental Agent <bcp14>MAY</bcp14> also
	attempt contacting the nameserver from another network vantage point.</t>	attempt contacting the nameserver from another network vantage point.</t>

	<t>If an inconsistent state is encountered, the Parental Agent MUST abort	<t>If an inconsistent state is encountered, the Parental Agent <bcp14>MUST</bcp1 4> abort
	the operation.	the operation.

	Specifically, it MUST NOT delete or alter any existing RRset that would	Specifically, it <bcp14>MUST NOT</bcp14> delete or alter any existing RRset that
	have been deleted or altered, and MUST NOT create any RRsets that would	would
	have been created, had the nameservers given consistent responses.</t>	have been deleted or altered, and it <bcp14>MUST NOT</bcp14> create any RRsets t
		hat would
		have been created had the nameservers given consistent responses.</t>
	<t>To accommodate transient inconsistencies (e.g., replication delays),	<t>To accommodate transient inconsistencies (e.g., replication delays),

	implementations MAY be configurable to undertake a retry of the full	implementations <bcp14>MAY</bcp14> be configurable to undertake a retry of the f ull
	process, repeating all queries (suggested default: enabled with	process, repeating all queries (suggested default: enabled with
	exponential back-off).</t>	exponential back-off).</t>


		<!--[rfced] Would it make sense to make the following update for a
		parallel between implicitly and explicitly?

		Original:
		Any pending queries can immediately be dequeued when encountering a
		response that confirms the status quo, either implicitly (NODATA) or
		explicitly.

		Perhaps:
		Any pending queries can immediately be dequeued when encountering a
		response that confirms the status quo, either implicitly (NODATA) or
		explicitly (via a response that matches the current delegation state).
		-->

	<t>Any pending queries can immediately be dequeued when encountering a	<t>Any pending queries can immediately be dequeued when encountering a
	response that confirms the status quo, either implicitly (NODATA) or	response that confirms the status quo, either implicitly (NODATA) or
	explicitly.	explicitly.
	This is because any subsequent responses could only confirm that nothing	This is because any subsequent responses could only confirm that nothing

	needs to happen, or give an inconsistent result in which case nothing	needs to happen or give an inconsistent result in which case nothing
	needs to happen.	needs to happen.
	The parent may apply local policy in determining whether the requested	The parent may apply local policy in determining whether the requested
	update is consistent or not with the status quo, as illustrated in the	update is consistent or not with the status quo, as illustrated in the
	type-specific sections below.	type-specific sections below.
	In any case, queries may be continued across all nameservers for	In any case, queries may be continued across all nameservers for
	reporting purposes.</t>	reporting purposes.</t>
	<t>Existing requirements for ensuring integrity remain in effect.	<t>Existing requirements for ensuring integrity remain in effect.

	In particular, DNSSEC signatures MUST be requested and validated for all	In particular, DNSSEC signatures <bcp14>MUST</bcp14> be requested and validated for all
	queries unless otherwise noted.</t>	queries unless otherwise noted.</t>

	<section anchor="cds-and-cdnskey"><name>CDS and CDNSKEY</name>	<section anchor="cds-and-cdnskey"><name>CDS and CDNSKEY</name>


		<!--[rfced] [AD] May we break up this sentence as follows? As it would require
		repetition of a BCP 14 keyword, please advise:

		Original:
		To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust
		maintenance, the Parental Agent, knowing both the Child zone name and
		its NS hostnames, MUST ascertain that queries are made against all
		nameservers listed in the Child's delegation from the Parent, and
		ensure that each key referenced in any of the received answers is
		also referenced in all other received responses, or that responses
		consistently indicate a request for removal of the entire DS RRset
		([RFC8078], Section 6).

		Perhaps:
		To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust
		maintenance, the Parental Agent, knowing both the Child zone name
		and its NS hostnames, MUST ascertain that queries are made against
		all nameservers listed in the Child's delegation from the Parent.
		It MUST also ensure that each key referenced in any of the received
		answers is also referenced in all other received responses or that
		responses consistently indicate a request for removal of the entire
		DS RRset ([RFC8078], Section 6).

		-->

	<t>To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust	<t>To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust
	maintenance, the Parental Agent, knowing both the Child zone name and	maintenance, the Parental Agent, knowing both the Child zone name and

	its NS hostnames, MUST ascertain that queries are made against all	its NS hostnames, <bcp14>MUST</bcp14> ascertain that queries are made against al l
	nameservers listed in the Child's delegation from the	nameservers listed in the Child's delegation from the

	Parent, and ensure that each key referenced in any of the received	Parent and ensure that each key referenced in any of the received
	answers is also referenced in all other received responses, or that	answers is also referenced in all other received responses, or that
	responses consistently indicate a request for removal of the entire	responses consistently indicate a request for removal of the entire

	DS RRset (<xref target="RFC8078"></xref>, Section 6).</t>	DS RRset (<xref target="RFC8078" section="6" sectionFormat="comma"/>).</t>
	<t>In other words, CDS/CDNSKEY records at the Child zone apex must be	<t>In other words, CDS/CDNSKEY records at the Child zone apex must be
	fetched directly from each reachable authoritative server as	fetched directly from each reachable authoritative server as
	determined by the delegation's NS record set.	determined by the delegation's NS record set.
	When a key is referenced in a CDS record set but not the CDNSKEY record	When a key is referenced in a CDS record set but not the CDNSKEY record
	set (or vice versa), or returned by one nameserver but is missing from	set (or vice versa), or returned by one nameserver but is missing from

	at least one other nameserver's answer, the CDS/CDNSKEY state MUST be	at least one other nameserver's answer, the CDS/CDNSKEY state <bcp14>MUST</bcp14 > be
	considered inconsistent.	considered inconsistent.

	Similarly, the state MUST be considered inconsistent if there is a CDS	Similarly, the state <bcp14>MUST</bcp14> be considered inconsistent if there is a CDS
	or CDNSKEY response that indicates a removal request for the DS RRset	or CDNSKEY response that indicates a removal request for the DS RRset
	whereas another response indicates no change (NODATA) or a DS update.</t>	whereas another response indicates no change (NODATA) or a DS update.</t>
	<t>As an example of local policy, the parent may restrict the choice of	<t>As an example of local policy, the parent may restrict the choice of
	hash digest types used when publishing a DS RRset (notwithstanding the	hash digest types used when publishing a DS RRset (notwithstanding the

	requirements specified in <xref target="DS-IANA"></xref>). (The set of keys refe renced in	requirements specified in <xref target="DS-IANA"/>). (The set of keys referenced in
	the DS RRset is not up to local policy. Only if all keys from the	the DS RRset is not up to local policy. Only if all keys from the

	CDS/CDNSKEY RRsets are included, the DS RRset is considered consistent.)</t>	CDS/CDNSKEY RRsets are included is the DS RRset considered consistent.)</t>
	<t>During initial DS provisioning (DNSSEC bootstrapping), conventional	<t>During initial DS provisioning (DNSSEC bootstrapping), conventional
	DNSSEC validation for CDS/CDNSKEY responses is not (yet) available; in	DNSSEC validation for CDS/CDNSKEY responses is not (yet) available; in

	this case, authenticated bootstrapping (<xref target="RFC9615"></xref>) should b e used.</t>	this case, authenticated bootstrapping <xref target="RFC9615"/> should be used.< /t>
	</section>	</section>

	<section anchor="csync"><name>CSYNC</name>	<section anchor="csync"><name>CSYNC</name>

	<t>A CSYNC-based workflow generally consists of (1) querying the CSYNC (and	<t>A CSYNC-based workflow generally consists of:</t>
		<ol>
		<li>querying the CSYNC (and
	possibly SOA) record to determine which data records shall be synchronized from	possibly SOA) record to determine which data records shall be synchronized from

	child to parent, and (2) querying for these data records (e.g. NS), before	child to parent, and</li>
	placing them in the parent zone.	<li>querying for these data records (e.g., NS) before
		placing them in the parent zone.</li></ol>
		<t>
	If the below conditions are not met during these steps, the CSYNC state	If the below conditions are not met during these steps, the CSYNC state

	MUST be considered inconsistent.</t>	<bcp14>MUST</bcp14> be considered inconsistent.</t>
	<t>When querying the CSYNC record, the Parental Agent MUST ascertain that	<t>When querying the CSYNC record, the Parental Agent <bcp14>MUST</bcp14> ascert
		ain that
	queries are made against all nameservers listed in the	queries are made against all nameservers listed in the

	Child's delegation from the Parent, and ensure that the record's	Child's delegation from the Parent and ensure that the record's
	immediate flag and type bitmap are equal across received responses.</t>	immediate flag and type bitmap are equal across received responses.</t>
	<t>The CSYNC record's SOA serial field and soaminimum flag might	<t>The CSYNC record's SOA serial field and soaminimum flag might
	legitimately differ across nameservers (such as in multi-provider	legitimately differ across nameservers (such as in multi-provider

	setups); equality is thus not required across responses.	setups); thus, equality is not required across responses.
	Instead, for a given response, processing of these values MUST	Instead, for a given response, processing of these values <bcp14>MUST</bcp14>
	occur with respect to the SOA record as obtained from the same	occur with respect to the SOA record as obtained from the same
	nameserver.	nameserver.
	If the resulting per-nameserver assessments of whether the update is	If the resulting per-nameserver assessments of whether the update is

	permissible do not all agree, the CSYNC state MUST be considered	permissible do not all agree, the CSYNC state <bcp14>MUST</bcp14> be considered
	inconsistent.</t>	inconsistent.</t>
	<t>Further, when retrieving the data record sets as indicated in the CSYNC	<t>Further, when retrieving the data record sets as indicated in the CSYNC

	record (such as NS or A/AAAA records), the Parental Agent MUST ascertain	record (such as NS or A/AAAA records), the Parental Agent <bcp14>MUST</bcp14> as certain
	that all queries are made against all nameservers from which a CSYNC	that all queries are made against all nameservers from which a CSYNC

	record was received, and ensure that all return responses with equal rdata	record was received and ensure that all of them return responses with equal rdat
	sets (including all empty).</t>	a
		sets (including cases where all are empty).</t>
	<t>As an example of local policy, the parent may choose to accept glue	<t>As an example of local policy, the parent may choose to accept glue

	records only for in-domain or sibling NS hostnames <xref target="RFC9499"></xref	records only for in-domain or sibling NS hostnames <xref target="RFC9499"/>.</t>
	>.</t>	<t>Other CSYNC processing rules from <xref section="3" target="RFC7477"/> remain
	<t>Other CSYNC processing rules from Section 3 of <xref target="RFC7477"></xref>	in place without
	remain in place without
	modification. For example, when the NS type flag is present, associated NS	modification. For example, when the NS type flag is present, associated NS
	processing has to occur before potential glue updates to ensure that glue	processing has to occur before potential glue updates to ensure that glue
	addresses match the right set of nameservers.	addresses match the right set of nameservers.
	Also, when the type bitmap contains the A/AAAA flags, corresponding address	Also, when the type bitmap contains the A/AAAA flags, corresponding address

	queries are only to be sent for NS hostnames "that are in bailiwick", while	queries are only to be sent for NS hostnames that are in bailiwick, while
	out-of-bailiwick NS records are ignored.	out-of-bailiwick NS records are ignored.

	Refer to Sections 3.2.2 and 4.3 <xref target="RFC7477"></xref> for more details. </t>	Refer to Sections <xref target="RFC7477" section="3.2.2" sectionFormat="bare"/> and <xref target="RFC7477" section="4.3" sectionFormat="bare"/> of <xref target= "RFC7477"/> for more details.</t>
	<t>CSYNC-based updates may cause validation or even insecure resolution to break	<t>CSYNC-based updates may cause validation or even insecure resolution to break
	(e.g., by changing the delegation to a set of nameservers that do not	(e.g., by changing the delegation to a set of nameservers that do not
	serve required DNSKEY records or do not know the zone at all).	serve required DNSKEY records or do not know the zone at all).

	Parental Agents SHOULD check that CSYNC-based updates, if applied, do not	Parental Agents <bcp14>SHOULD</bcp14> check that CSYNC-based updates, if applied , do not
	break the delegation.</t>	break the delegation.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="iana-considerations"><name>IANA Considerations</name>	<section anchor="iana-considerations"><name>IANA Considerations</name>
	<t>This document has no IANA actions.</t>	<t>This document has no IANA actions.</t>
	</section>	</section>

	<section anchor="security-considerations"><name>Security Considerations</name>	<section anchor="security-considerations"><name>Security Considerations</name>
	<t>The level of rigor mandated by this document is needed to prevent	<t>The level of rigor mandated by this document is needed to prevent
	publication of half-baked DS or delegation NS RRsets (authorized only	publication of half-baked DS or delegation NS RRsets (authorized only
	under an insufficient subset of authoritative nameservers), ensuring	under an insufficient subset of authoritative nameservers), ensuring
	that a single operator cannot unilaterally modify the delegation (add or	that a single operator cannot unilaterally modify the delegation (add or
	remove trust anchors or nameservers) when other operators are present.	remove trust anchors or nameservers) when other operators are present.
	This applies both when the setup is intentional and when it is	This applies both when the setup is intentional and when it is

	unintentional (such as in the case of lame delegation hijacking).</t>	unintentional (such as in the case of lame-delegation hijacking).</t>
	<t>As a consequence, the delegation's records can only be modified when	<t>As a consequence, the delegation's records can only be modified when
	zones are synchronized across operators, unanimously reflecting the	zones are synchronized across operators, unanimously reflecting the
	domain owner's intentions.	domain owner's intentions.
	Both availability and integrity of the domain's DNS service benefit from	Both availability and integrity of the domain's DNS service benefit from
	this policy.</t>	this policy.</t>
	<t>In order to resolve situations in which consensus about child zone	<t>In order to resolve situations in which consensus about child zone

	contents cannot be reached (e.g. because one of the nameserver	contents cannot be reached (e.g., because one of the nameserver
	operators is uncooperative), Parental Agents SHOULD continue to accept	operators is uncooperative), Parental Agents <bcp14>SHOULD</bcp14> continue to a
		ccept
	DS and NS/glue update requests from the domain owner via an	DS and NS/glue update requests from the domain owner via an

	authenticated out-of-band channel (such as EPP <xref target="RFC5730"></xref>),	authenticated out-of-band channel (such as EPP <xref target="RFC5730"/>),
	irrespective of the adoption of automated delegation maintenance.	irrespective of the adoption of automated delegation maintenance.
	Availability of such an interface also enables recovery from a situation	Availability of such an interface also enables recovery from a situation
	where the private key is no longer available for signing the CDS/CDNSKEY	where the private key is no longer available for signing the CDS/CDNSKEY
	or CSYNC records in the child zone.</t>	or CSYNC records in the child zone.</t>
	</section>	</section>


	<section anchor="implementation-status"><name>Implementation Status</name>
	<t><strong>Note to the RFC Editor</strong>: please remove this entire section be
	fore publication.</t>
	<t>This draft has been implemented by</t>

	<ul spacing="compact">
	<li>TANGO Registry Services</li>
	<li>CORE Registry</li>
	</ul>
	</section>

	<section anchor="acknowledgments"><name>Acknowledgments</name>
	<t>In order of first contribution or review: Viktor Dukhovni, Wes Hardaker,
	Libor Peltan, Oli Schacher, David Blacka, Charlie Kaufman, Michael Bauland,
	Patrick Mevzek, Joe Abley, Ondřej Caletka, Ondřej Surý, Mohamed Boucadair,
	Vijay Gurbani, Gorry Fairhurst, Paul Wouters, Andy Newton, Mike Bishop,
	Warren Kumari.</t>
	</section>

	</middle>	</middle>


		<!-- [rfced] Would you like the references to be alphabetized
		or left in their current order?
		-->

	<back>	<back>

		<displayreference target="I-D.ietf-dnsop-ds-automation" to="DS-AUTOMATION"/>

	<references><name>References</name>	<references><name>References</name>
	<references><name>Normative References</name>	<references><name>Normative References</name>
	<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.2119.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5730.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.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.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.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.8174.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9615.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9615.xml" />
	</references>	</references>
	<references><name>Informative References</name>	<references><name>Informative References</name>

	<reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-types" >	<reference anchor="DS-IANA" target="https://www.iana.org/assignments/ds-rr-types ">
	<front>	<front>

	<title>Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms</t itle>	<title>DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algori thms</title>
	<author fullname="IANA"></author>	<author fullname="IANA"></author>
	</front>	</front>
	</reference>	</reference>

		<!-- [I-D.ietf-dnsop-ds-automation]
		draft-ietf-dnsop-ds-automation-01
		IESG State: I-D Exists as of 01/06/26
		-->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dns op-ds-automation.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dns op-ds-automation.xml"/>

	<reference anchor="LAME1" target="http://dx.doi.org/10.1145/3419394.3423623">	<reference anchor="LAME1">
	<front>	<front>
	<title>Unresolved Issues: Prevalence, Persistence, and Perils of Lame Delega tions</title>	<title>Unresolved Issues: Prevalence, Persistence, and Perils of Lame Delega tions</title>
	<author fullname="Gautam Akiwate" surname="Akiwate">	<author fullname="Gautam Akiwate" surname="Akiwate">
	<organization>UC San Diego</organization>	<organization>UC San Diego</organization>
	</author>	</author>
	<author fullname="Mattijs Jonker" surname="Jonker">	<author fullname="Mattijs Jonker" surname="Jonker">
	<organization>University of Twente</organization>	<organization>University of Twente</organization>
	</author>	</author>
	<author fullname="Raffaele Sommese" surname="Sommese">	<author fullname="Raffaele Sommese" surname="Sommese">
	<organization>University of Twente</organization>	<organization>University of Twente</organization>

	skipping to change at line 345 ¶	skipping to change at line 451 ¶
	</author>	</author>
	<author fullname="Geoffrey M. Voelker" surname="Voelker">	<author fullname="Geoffrey M. Voelker" surname="Voelker">
	<organization>UC San Diego</organization>	<organization>UC San Diego</organization>
	</author>	</author>
	<author fullname="Stefan Savage" surname="Savage">	<author fullname="Stefan Savage" surname="Savage">
	<organization>UC San Diego</organization>	<organization>UC San Diego</organization>
	</author>	</author>
	<author fullname="KC Claffy" surname="Claffy">	<author fullname="KC Claffy" surname="Claffy">
	<organization>CAIDA/UC San Diego</organization>	<organization>CAIDA/UC San Diego</organization>
	</author>	</author>

	<author>
	<organization>ACM</organization>
	</author>
	<date year="2020" month="October" day="27"></date>	<date year="2020" month="October" day="27"></date>
	</front>	</front>
	<seriesInfo name="DOI" value="10.1145/3419394.3423623"></seriesInfo>	<seriesInfo name="DOI" value="10.1145/3419394.3423623"></seriesInfo>

	<refcontent>Proceedings of the ACM Internet Measurement Conference</refcontent >	<refcontent>IMC '20: Proceedings of the ACM Internet Measurement Conference, p p. 281-294</refcontent>
	</reference>	</reference>

	<reference anchor="LAME2" target="http://dx.doi.org/10.1145/3487552.3487816">	<reference anchor="LAME2">
	<front>	<front>
	<title>Risky BIZness: risks derived from registrar name management</title>	<title>Risky BIZness: risks derived from registrar name management</title>
	<author fullname="Gautam Akiwate" surname="Akiwate">	<author fullname="Gautam Akiwate" surname="Akiwate">
	<organization>UC San Diego</organization>	<organization>UC San Diego</organization>
	</author>	</author>
	<author fullname="Stefan Savage" surname="Savage">	<author fullname="Stefan Savage" surname="Savage">
	<organization>UC San Diego</organization>	<organization>UC San Diego</organization>
	</author>	</author>
	<author fullname="Geoffrey M. Voelker" surname="Voelker">	<author fullname="Geoffrey M. Voelker" surname="Voelker">
	<organization>UC San Diego</organization>	<organization>UC San Diego</organization>
	</author>	</author>

	<author fullname="K C Claffy" surname="Claffy">	<author fullname="KC Claffy" surname="Claffy">
	<organization>CAIDA/UC San Diego</organization>	<organization>CAIDA/UC San Diego</organization>
	</author>	</author>

	<author>
	<organization>ACM</organization>
	</author>
	<date year="2021" month="November" day="2"></date>	<date year="2021" month="November" day="2"></date>
	</front>	</front>
	<seriesInfo name="DOI" value="10.1145/3487552.3487816"></seriesInfo>	<seriesInfo name="DOI" value="10.1145/3487552.3487816"></seriesInfo>

	<refcontent>Proceedings of the 21st ACM Internet Measurement Conference</refco ntent>	<refcontent>IMC '21: Proceedings of the 21st ACM Internet Measurement Conferen ce, pp. 673-686</refcontent>
	</reference>	</reference>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6781.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6781.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8901.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8901.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml" />
	</references>	</references>
	</references>	</references>

	<section anchor="scenarios"><name>Failure Scenarios due to Inconsistencies</name >	<section anchor="scenarios"><name>Failure Scenarios due to Inconsistencies</name >
	<t>The following scenarios are informative examples of how things can go wrong w hen	<t>The following scenarios are informative examples of how things can go wrong w hen
	consistency is not enforced by the parent during CDS/CDNSKEY/CSYNC	consistency is not enforced by the parent during CDS/CDNSKEY/CSYNC

	skipping to change at line 402 ¶	skipping to change at line 502 ¶
	multi-provider configurations are intended to provide.</t>	multi-provider configurations are intended to provide.</t>

	<section anchor="ds-breakage-due-to-replication-lag"><name>DS Breakage due to Re plication Lag</name>	<section anchor="ds-breakage-due-to-replication-lag"><name>DS Breakage due to Re plication Lag</name>
	<t>If an authoritative nameserver is lagging behind during a key rollover,	<t>If an authoritative nameserver is lagging behind during a key rollover,
	the parent may see different CDS/CDNSKEY RRsets depending on the	the parent may see different CDS/CDNSKEY RRsets depending on the
	nameserver contacted. This may cause old and new DS RRsets to be	nameserver contacted. This may cause old and new DS RRsets to be
	deployed in an alternating fashion and without the awareness of the zone	deployed in an alternating fashion and without the awareness of the zone
	maintainer, who may then inadvertently break the chain of trust by	maintainer, who may then inadvertently break the chain of trust by
	prematurely removing a DNSKEY still referenced by a (stale) CDS/CDNSKEY	prematurely removing a DNSKEY still referenced by a (stale) CDS/CDNSKEY
	RRset.</t>	RRset.</t>

	<t>While foreseen in Section 6.2 of <xref target="RFC7344"></xref>, the solution specified there	<t>While foreseen in <xref section="6.2" target="RFC7344"/>, the solution specif ied there
	requires parents to keep state on CDS/CDNSKEY RRsets. This document	requires parents to keep state on CDS/CDNSKEY RRsets. This document

	achieves the same without this burden, and in case the parent reports	achieves the same without this burden and, in case the parent reports
	consistency errors downstream, can also help detection of the child-side	consistency errors downstream, can also help detection of the child-side
	replication issue by the operator.</t>	replication issue by the operator.</t>
	</section>	</section>

	<section anchor="escalation-of-lame-delegation-takeover"><name>Escalation of Lam e Delegation Takeover</name>	<section anchor="escalation-of-lame-delegation-takeover"><name>Escalation of Lam e Delegation Takeover</name>

	<t>A delegation may include a non-existent NS hostname, for example due to	<t>A delegation may include a nonexistent NS hostname, for example, due to
	a typo or when the nameserver's domain registration has expired.	a typo or the nameserver's domain registration having expired.
	(Re-)registering such a non-resolvable nameserver domain allows a third	(Re-)registering such a non-resolvable nameserver domain allows a third
	party to run authoritative DNS service for all domains delegated to that	party to run authoritative DNS service for all domains delegated to that
	NS hostname, serving responses different from the legitimate ones.</t>	NS hostname, serving responses different from the legitimate ones.</t>
	<t>This strategy for hijacking (at least part of the) DNS traffic and	<t>This strategy for hijacking (at least part of the) DNS traffic and

	spoofing responses is not new, but surprisingly common <xref target="LAME1"></xr ef><xref target="LAME2"></xref>.	spoofing responses is not new but is surprisingly common <xref target="LAME1"/> <xref target="LAME2"/>.
	It is also known that DNSSEC reduces the impact of such an attack,	It is also known that DNSSEC reduces the impact of such an attack,
	as validating resolvers will reject illegitimate responses due to lack	as validating resolvers will reject illegitimate responses due to lack
	of signatures consistent with the delegation's DS records.</t>	of signatures consistent with the delegation's DS records.</t>
	<t>On the other hand, if the delegation is not protected by DNSSEC, the	<t>On the other hand, if the delegation is not protected by DNSSEC, the
	rogue nameserver is not only able to serve unauthorized responses	rogue nameserver is not only able to serve unauthorized responses

	without detection; it is even possible for the attacker to escalate the	without detection: it is even possible for the attacker to escalate the
	nameserver takeover to a full domain takeover.</t>	nameserver takeover to a full domain takeover.</t>
	<t>In particular, the rogue nameserver can publish CDS/CDNSKEY records.	<t>In particular, the rogue nameserver can publish CDS/CDNSKEY records.
	If those are processed by the parent without ensuring consistency with	If those are processed by the parent without ensuring consistency with
	other authoritative nameservers, the delegation will, with some patience, get	other authoritative nameservers, the delegation will, with some patience, get

	secured with the attacker's DNSSEC keys. Of course, as the parent’s query (or	secured with the attacker's DNSSEC keys. Of course, as the parent's query (or
	sometimes queries) need to hit the attacker's nameserver, this requires some	sometimes queries) need to hit the attacker's nameserver, this requires some

	statistical luck; but eventually it will succeed.	statistical luck, but, eventually, it will succeed.
	As responses served by the remaining legitimate nameservers are not	As responses served by the remaining legitimate nameservers are not
	signed with these keys, validating resolvers will start rejecting them.</t>	signed with these keys, validating resolvers will start rejecting them.</t>
	<t>Once DNSSEC is established, the attacker can use CSYNC to remove other	<t>Once DNSSEC is established, the attacker can use CSYNC to remove other
	nameservers from the delegation at will (and potentially add new ones	nameservers from the delegation at will (and potentially add new ones

	under their control), or change glue records to point to the attacker's	under their control) or change glue records to point to the attacker's
	nameservers.	nameservers.

	This enables the attacker to position themself as the only party	This enables the attacker to position itself as the only party
	providing authoritative DNS service for the victim domain,	providing authoritative DNS service for the victim domain,
	significantly augmenting the attack's impact.</t>	significantly augmenting the attack's impact.</t>
	</section>	</section>

	<section anchor="multi-provider-permanent-multi-signer"><name>Multi-Provider (Pe rmanent Multi-Signer)</name>	<section anchor="multi-provider-permanent-multi-signer"><name>Multi-Provider (Pe rmanent Multi-Signer)</name>

	<section anchor="ds-breakage"><name>DS Breakage</name>	<section anchor="ds-breakage"><name>DS Breakage</name>
	<t>While performing a key rollover and adjusting the corresponding	<t>While performing a key rollover and adjusting the corresponding
	CDS/CDNSKEY records, a provider could accidentally publish CDS/CDNSKEY	CDS/CDNSKEY records, a provider could accidentally publish CDS/CDNSKEY
	records that only include its own keys.</t>	records that only include its own keys.</t>
	<t>When the parent happens to retrieve the records from a nameserver	<t>When the parent happens to retrieve the records from a nameserver
	controlled by this provider, the other providers' DS records would be	controlled by this provider, the other providers' DS records would be
	removed from the delegation.	removed from the delegation.

	As a result, the zone is broken at least for some queries.</t>	As a result, the zone is broken (at least for some queries).</t>
	</section>	</section>

	<section anchor="ns-breakage"><name>NS Breakage</name>	<section anchor="ns-breakage"><name>NS Breakage</name>
	<t>A similar scenario affects the CSYNC record, which is used to update the	<t>A similar scenario affects the CSYNC record, which is used to update the
	delegation's NS record set at the parent.	delegation's NS record set at the parent.

	The issue occurs, for example, when a provider accidentally includes	For example, the issue occurs when a provider accidentally includes
	only their own set of hostnames in the local NS record set, or publishes	only their own set of hostnames in the local NS record set or publishes
	an otherwise flawed NS record set.</t>	an otherwise flawed NS record set.</t>
	<t>If the parent then observes a CSYNC signal and fetches the flawed NS	<t>If the parent then observes a CSYNC signal and fetches the flawed NS
	record set without ensuring consistency across nameservers, the	record set without ensuring consistency across nameservers, the
	delegation may be updated in a way that breaks resolution or silently	delegation may be updated in a way that breaks resolution or silently
	reduces the multi-provider setup to a single-provider setup.</t>	reduces the multi-provider setup to a single-provider setup.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="bogus-provider-change-temporary-multi-signer"><name>Bogus Provi der Change (Temporary Multi-Signer)</name>	<section anchor="bogus-provider-change-temporary-multi-signer"><name>Bogus Provi der Change (Temporary Multi-Signer)</name>
	<t>Transferring DNS service for a domain name from one (signing) DNS	<t>Transferring DNS service for a domain name from one (signing) DNS
	provider to another, without going insecure, necessitates a brief period	provider to another, without going insecure, necessitates a brief period

	during which the domain is operated in multi-signer mode:	during which the domain is operated in multi-signer mode.
		<!--[rfced] Is this a shared copy?

		Original:
		First, the providers include each other's signing keys as DNSKEY and
		CDS/CDNSKEY records in their copy of the zone.

		Perhaps:
		First, the providers include each other's signing keys as DNSKEY and
		CDS/CDNSKEY records in their copies of the zone.

		-->

	First, the providers include each other's signing keys as DNSKEY and	First, the providers include each other's signing keys as DNSKEY and
	CDS/CDNSKEY records in their copy of the zone.	CDS/CDNSKEY records in their copy of the zone.
	Once the parent learns about the updated CDS/CDNSKEY record set at the	Once the parent learns about the updated CDS/CDNSKEY record set at the
	old provider, the delegation's DS record set is updated.	old provider, the delegation's DS record set is updated.
	Then, after waiting for cache expiration, the new provider's NS	Then, after waiting for cache expiration, the new provider's NS

	hostnames can be added to the zone's NS record set, so that queries	hostnames can be added to the zone's NS record set so that queries
	start balancing across both providers.	start balancing across both providers.

	To conclude the hand-over, the old provider is removed by inverting	To conclude the handover, the old provider is removed by inverting
	these steps with swapped roles.</t>	these steps with swapped roles.</t>
	<t>The multi-signer phase of this process breaks when the new provider,	<t>The multi-signer phase of this process breaks when the new provider,
	perhaps unaware of the situation and its intricacies, fails to include	perhaps unaware of the situation and its intricacies, fails to include
	the old provider's keys in the DNSKEY (and CDS/CDNSKEY) record sets.	the old provider's keys in the DNSKEY (and CDS/CDNSKEY) record sets.

	One obvious consequence of that is that whenever the resolver happens to	One obvious consequence is that whenever the resolver happens to
	retrieve the DNSKEY record set from the new provider, the old provider's	retrieve the DNSKEY record set from the new provider, the old provider's

	RRSIGs do no longer validate, causing SERVFAIL to be returned.</t>	RRSIGs no longer validate, causing SERVFAIL to be returned.</t>
	<t>However, an even worse consequence can occur when the parent performs	<t>However, an even worse consequence can occur when the parent performs

	their next CDS/CDNSKEY scan:	their next CDS/CDNSKEY scan.
	It may then happen that the incorrect CDS/CDNSKEY record set is fetched	The incorrect CDS/CDNSKEY record set is fetched
	from the new provider and used to update the delegation's DS record set.	from the new provider and used to update the delegation's DS record set.
	As a result, the old provider (who still appears in the delegation) is	As a result, the old provider (who still appears in the delegation) is
	prematurely removed from the domain's DNSSEC chain of trust.	prematurely removed from the domain's DNSSEC chain of trust.
	The new DS record set authenticates the new provider's DNSKEYs only, and	The new DS record set authenticates the new provider's DNSKEYs only, and
	DNSSEC validation fails for all answers served by the old provider.</t>	DNSSEC validation fails for all answers served by the old provider.</t>
	</section>	</section>
	</section>	</section>


	<section anchor="change-history-to-be-removed-before-publication"><name>Change H	<section anchor="acknowledgments" numbered="false">
	istory (to be removed before publication)</name>	<name>Acknowledgments</name>
		<t>In order of first contribution or review: <contact fullname="Viktor
		Dukhovni"/>, <contact fullname="Wes Hardaker"/>, <contact fullname="Libor
		Peltan"/>, <contact fullname="Oli Schacher"/>, <contact fullname="David
		Blacka"/>, <contact fullname="Charlie Kaufman"/>, <contact fullname="Michael
		Bauland"/>, <contact fullname="Patrick Mevzek"/>, <contact fullname="Joe
		Abley"/>, <contact fullname="Ondřej Caletka"/>, <contact fullname="Ondřej
		Surý"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Vijay
		Gurbani"/>, <contact fullname="Gorry Fairhurst"/>, <contact fullname="Paul
		Wouters"/>, <contact fullname="Andy Newton"/>, <contact fullname="Mike
		Bishop"/>, and <contact fullname="Warren Kumari"/>.</t>
		</section>


	<ul spacing="compact">	<!--[rfced] We had the following questions about abbreviations used throughout t
	<li>draft-ietf-dnsop-cds-consistency-11</li>	he document:
	</ul>
	<blockquote><t>Editorial nits</t>	a) How may we expand DS? Delegation Signer as used in RFC 4034?
	</blockquote>
	<ul spacing="compact">	b) How may we expand EPP? Extensible Provisioning Protocol as used in
	<li>draft-ietf-dnsop-cds-consistency-10</li>	RFC 5730?
	</ul>
	<blockquote><t>Clarify that parents may have local policy</t>	-->
	<t>Additional reference from IESG (Mike Bishop)</t>
	<t>Language precision from IESG (Andy Newton)</t>	<!--[rfced] The following similar forms are used throughout the document. Pleas
	<t>Editorial nits from IESG (Gorry Fairhurst, Paul Wouters)</t>	e let us know if/how they may be made uniform:
	<t>Editorial nits from Vijay Gurbani</t>
	</blockquote>	child vs. Child
	<ul spacing="compact">	parent vs. Parent
	<li>draft-ietf-dnsop-cds-consistency-09</li>	-->
	</ul>
	<blockquote><t>Editorial changes</t>	<!-- [rfced] Please review the "Inclusive Language" portion of the online
	<t>Nits from Mohamed Boucadair</t>	Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	</blockquote>	and let us know if any changes are needed. Updates of this nature typically
	<ul spacing="compact">	result in more precise language, which is helpful for readers.
	<li>draft-ietf-dnsop-cds-consistency-08</li>
	</ul>	Note that our script did not flag any words in particular, but this should
	<blockquote><t>Take into account RFC 7344 Section 6.2 for Appendix A.1 considera	still be reviewed as a best practice.
	tions</t>
	</blockquote>	-->
	<ul spacing="compact">
	<li>draft-ietf-dnsop-cds-consistency-07</li>
	</ul>
	<blockquote><t>Clarify that "all nameservers" means fetching all deleg
	ation NS IPs</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-cds-consistency-06</li>
	</ul>
	<blockquote><t>Editorial changes from Dnsdir early review</t>
	<t>Add Implementation Status</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-cds-consistency-05</li>
	</ul>
	<blockquote><t>Editorial overhaul</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-cds-consistency-04</li>
	</ul>
	<blockquote><t>Clarify that existing CSYNC NS and glue processing rules remain i
	n place</t>
	<t>Editorial changes</t>
	<t>Clean up "multi-homing" and define "multi-provider"/&quot
	;multi-signer"</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-cds-consistency-03</li>
	</ul>
	<blockquote><t>Clarify that CSYNC updates should not break delegations</t>
	<t>Describe consistency requirements for CSYNC soaminimum</t>
	<t>Editorial changes</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-cds-consistency-02</li>
	</ul>
	<blockquote><t>Retry before assuming a nameserver is permanently unreachable</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-cds-consistency-01</li>
	</ul>
	<blockquote><t>Make nits tool happy</t>
	<t>New failure mode: DS Breakage due to Replication Lag</t>
	<t>Point out zero overhead if nothing changed, and need for OOB interface</t>
	<t>Editorial changes</t>
	<t>Moved Failure Scenarios to appendix</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-ietf-dnsop-cds-consistency-00</li>
	</ul>
	<blockquote><t>Point out zero overhead if nothing changed, and need for OOB inte
	rface</t>
	<t>Editorial changes.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-thomassen-dnsop-cds-consistency-03</li>
	</ul>
	<blockquote><t>Describe risk from lame delegations</t>
	<t>Acknowledgments</t>
	<t>Say what is being updated</t>
	<t>Editorial changes.</t>
	<t>Retry mechanism to resolve inconsistencies</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-thomassen-dnsop-cds-consistency-02</li>
	</ul>
	<blockquote><t>Don't ignore DoE responses from individual nameservers (instead,
	require consistency across all responses received)</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-thomassen-dnsop-cds-consistency-01</li>
	</ul>
	<blockquote><t>Allow for nameservers that don't respond or provide DoE (i.e. req
	uire
	consistency only among the non-empty answers received)</t>
	<t>Define similar requirements for CSYNC.</t>
	<t>Editorial changes.</t>
	</blockquote>
	<ul spacing="compact">
	<li>draft-thomassen-dnsop-cds-consistency-00</li>
	</ul>
	<blockquote><t>Initial public draft.</t>
	</blockquote></section>

	</back>	</back>

	</rfc>	</rfc>

End of changes. 95 change blocks.
	289 lines changed or deleted	333 lines changed or added
This html diff was produced by rfcdiff 1.48.