<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" --> encoding="UTF-8"?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc version="3" ipr="trust200902" docName="draft-ietf-dnsop-cds-consistency-11" number="9975" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" updates="7344, 7477" indexInclude="true"> obsoletes="" tocInclude="true" symRefs="true" sortRefs="false" consensus="true">

  <front>

<!--[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 abbrev="CDS Consistency">Clarifications on CDS/CDNSKEY and CSYNC Consistency</title><seriesInfo value="draft-ietf-dnsop-cds-consistency-11" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo> Consistency</title>
    <seriesInfo name="RFC" value="9975"/>
    <author initials="P." surname="Thomassen" fullname="Peter Thomassen"><organization>SSE Thomassen">
      <organization>SSE - Secure Systems Engineering GmbH</organization><address><postal><street>Hauptstraße 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="2025" month="December" day="11"></date>
<area>Internet</area>
<workgroup>DNSOP Working Group</workgroup>
	</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>
  <t>Maintenance of DNS delegations requires occasional changes of the DS and
NS record sets on the parent side of the delegation.
For the case of DS records, &quot;Automating "Automating DNSSEC Delegation Trust Maintenance&quot; Maintenance" (RFC 7344) provides automation by allowing the
child to publish CDS and/or CDNSKEY records holding the prospective DS
parameters which that the parent can ingest.
Similarly, &quot;Child-to-Parent "Child-to-Parent Synchronization in DNS&quot; DNS" (RFC 7477) specifies CSYNC records to indicate a desired update
of the delegation's NS (and glue) records.
Parent-side entities (e.g., Registries and Registrars) can query these
records from the child and, after validation, use them to update the
parent-side Resource Record Sets (RRsets) of the delegation.</t>
<t>This document specifies under which conditions the target states expressed
via CDS/CDNSKEY and CSYNC records are considered &quot;consistent&quot;. "consistent". Parent-side
entities accepting such records from the child have to ensure that update
requests retrieved from different authoritative nameservers satisfy these
consistency requirements before taking any action based on them.</t>
<t>This document updates RFC RFCs 7344 and RFC 7477.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t><xref target="RFC7344"></xref> target="RFC7344"/> automates DNSSEC DNS Security Extensions (DNSSEC) delegation trust maintenance by having the
child publish CDS and/or CDNSKEY records which that describe the prospective DS
parameters.
Similarly, <xref target="RFC7477"></xref> target="RFC7477"/> specifies CSYNC records indicating a desired
update of the delegation's NS and associated glue records.
Parent-side entities (e.g., Registries and Registrars) can use these records
to update the corresponding records of the delegation.</t>
<t>For ingesting CSYNC records, Section 3.1 of <xref target="RFC7477"></xref> section="3.1" target="RFC7477"/> advocates that
Parental Agents limit queries to a single authoritative nameserver (as
typically
done in normal resolution).

<!--[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 target="RFC7344"></xref> section="6.1" target="RFC7344"/> (CDS/CDNSKEY) contains no
provision for how specifically queries for these records should be done.</t>
<t>Retrieving records from just one authoritative server (e.g., by
directing queries towards a trusted validating resolver) works well
under ideal operating scenarios.
However, problems may arise if CDS/CDNSKEY/CSYNC record sets are
inconsistent across authoritative nameservers, nameserver either because they are
out of sync (e.g., during a Key Signing Key (KSK) rollover), rollover) or because they are not
controlled by the same entity (e.g., in a multi-signer setup
<xref target="RFC8901"></xref>).</t> target="RFC8901"/>).</t>
<t>In such cases, if CDS/CDNSKEY/CSYNC records are retrieved from one
nameserver only (&quot;naively&quot;, ("naively", without a consistency check), each
nameserver can unilaterally trigger an update of the delegation's DS or
NS record set.</t>
<t>For example, a single provider in a multi-signer setup may (accidentally
or maliciously) cause another provider's trust anchors and/or
nameservers to be removed from the delegation.
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).

<!--[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
the other providers' records from the delegation.</t>
<t>Similar breakage can occur when the delegation has lame nameservers,
where an attacker may illegitimately initialize a DS record set and then
manipulate the delegation's NS record set at will.
More detailed examples are given in <xref target="scenarios"></xref>.</t> target="scenarios"/>.</t>
<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
authoritative nameservers are inspected.
At the same time, applying an automated delegation update &quot;MUST NOT "<bcp14>MUST NOT</bcp14>
break the current delegation&quot; (<xref target="RFC7344"></xref>, Section 4.1), delegation" (per <xref target="RFC7344" section="4.1" sectionFormat="comma"/>), i.e., it must
not hamper availability or validatability of the Child's resolution.
As part of a more holistic treatment of the problem space, <xref target="I-D.ietf-dnsop-ds-automation"></xref> target="I-D.ietf-dnsop-ds-automation"/> provides more specific more-specific guidance on
such safety checks.</t>
<t>This
<t>Therefore, this document therefore specifies that parent-side entities need to
ensure that the updates indicated by CDS/CDNSKEY and CSYNC record sets
are plausibly consistent across the child's nameservers, nameservers before taking
any action based on these records.</t>
<t>Readers are expected to be familiar with DNSSEC <xref target="RFC9364"></xref>, target="RFC9364"/>, in
particular
particular, <xref target="RFC4033"></xref>, target="RFC4033"/>, <xref target="RFC4034"></xref>, target="RFC4034"/>, <xref target="RFC4035"></xref>, target="RFC4035"/>, <xref target="RFC7344"></xref>, target="RFC7344"/>, and
<xref target="RFC7477"></xref>. target="RFC7477"/>.
For an overview of related operational practices, refer to <xref target="RFC6781"></xref> target="RFC6781"/>
and <xref target="RFC8901"></xref>.</t> target="RFC8901"/>.</t>

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

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

<dl spacing="compact"> spacing="normal" newline="false">
<dt>Multi-provider setup:</dt>
<dd>A constellation where several providers independently operate authoritative
DNS service for a domain, usually for purposes of redundancy. This includes
setups both with and without DNSSEC.</dd>
<dt>Multi-signer setup:</dt>
<dd>A multi-provider setup for a DNSSEC-enabled domain with multiple independent
signing entities <xref target="RFC8901"></xref>. target="RFC8901"/>. Such a setup may be permanent (for redundancy)
or temporary (for continuity of DNSSEC operation while changing the provider
of a domain that normally uses a single one).</dd>
</dl>
<t>Otherwise, the terminology in this document is as defined in <xref target="RFC7344"></xref>.</t> target="RFC7344"/>.</t>
</section>
</section>

<section anchor="updates-to-rfc-7344-and-rfc-7477"><name>Updates to RFC RFCs 7344 and RFC 7477</name>
<t>Section 4.1 of <xref target="RFC7344"></xref>
<t><xref section="4.1" target="RFC7344"/> lists acceptance rules for CDS/CDNSKEY records.
This list is extended with the consistency requirements defined in this
document. This document does not modify any other part of <xref target="RFC7344"></xref>.</t> target="RFC7344"/>.</t>
<t>Sections 3.1 <xref target="RFC7477" section="3.1" sectionFormat="bare"/> and 4.2 <xref target="RFC7477" section="4.2" sectionFormat="bare"/> of <xref target="RFC7477"></xref> target="RFC7477"/> have logic for deciding from which
nameserver to query CSYNC information. This logic is replaced with the
CSYNC consistency requirements defined in this document.</t>
</section>

<section anchor="processing-requirements"><name>Processing Requirements</name>
<t>Consistency requirements that apply equally to CDS/CDNSKEY and CSYNC are
listed first; type-specific consistency criteria are described in
separate subsections.</t>
<t>In order to determine plausible consistency of CDS/CDNSKEY or CSYNC
RRsets across the child's nameservers, the Parental Agent MUST <bcp14>MUST</bcp14> fetch all
IP addresses for each nameserver hostname as listed in the Child's
delegation from the Parent using a validating resolver, and including
any available glue records if available. records. Before acting on any CDS/CDNSKEY or CSYNC
record for the child, the Parental Agent MUST <bcp14>MUST</bcp14> have established plausible
consistency by querying all of these IP addresses for the record set(s)
in question, as per the guidelines spelled out in the following
subsections.</t>
<t>In all cases, consistency is REQUIRED <bcp14>REQUIRED</bcp14> across received responses 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>
<t>When a response cannot be obtained from a given nameserver, the Parental
Agent SHOULD <bcp14>SHOULD</bcp14> attempt to obtain it at a later time, before concluding
that the nameserver is permanently unreachable and removing it from
consideration.
A configurable retry schedule is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to increase the likelihood
of collecting data from all nameservers. An exponential back-off
schedule (e.g., 5, 10, 20, 40, ... minutes) provides a balance between
faster task completion while accommodating transient unreachability.
To sidestep localized routing issues, the Parental Agent MAY <bcp14>MAY</bcp14> also
attempt contacting the nameserver from another network vantage point.</t>
<t>If an inconsistent state is encountered, the Parental Agent MUST <bcp14>MUST</bcp14> abort
the operation.
Specifically, it MUST NOT <bcp14>MUST NOT</bcp14> delete or alter any existing RRset that would
have been deleted or altered, and MUST NOT it <bcp14>MUST NOT</bcp14> create any RRsets that would
have been created, created had the nameservers given consistent responses.</t>
<t>To accommodate transient inconsistencies (e.g., replication delays),
implementations MAY <bcp14>MAY</bcp14> be configurable to undertake a retry of the full
process, repeating all queries (suggested default: enabled with
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
response that confirms the status quo, either implicitly (NODATA) or
explicitly.
This is because any subsequent responses could only confirm that nothing
needs to happen, happen or give an inconsistent result in which case nothing
needs to happen.
The parent may apply local policy in determining whether the requested
update is consistent or not with the status quo, as illustrated in the
type-specific sections below.
In any case, queries may be continued across all nameservers for
reporting purposes.</t>
<t>Existing requirements for ensuring integrity remain in effect.
In particular, DNSSEC signatures MUST <bcp14>MUST</bcp14> be requested and validated for all
queries unless otherwise noted.</t>

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

<!--[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 (<xref target="RFC8078"></xref>,
   ([RFC8078], Section 6).</t> 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
maintenance, the Parental Agent, knowing both the Child zone name and
its NS hostnames, <bcp14>MUST</bcp14> 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 (<xref target="RFC8078" section="6" sectionFormat="comma"/>).</t>
<t>In other words, CDS/CDNSKEY records at the Child zone apex must be
fetched directly from each reachable authoritative server as
determined by the delegation's NS record set.
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
at least one other nameserver's answer, the CDS/CDNSKEY state MUST <bcp14>MUST</bcp14> be
considered inconsistent.
Similarly, the state MUST <bcp14>MUST</bcp14> be considered inconsistent if there is a CDS
or CDNSKEY response that indicates a removal request for the DS RRset
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
hash digest types used when publishing a DS RRset (notwithstanding the
requirements specified in <xref target="DS-IANA"></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
CDS/CDNSKEY RRsets are included, included is the DS RRset is considered consistent.)</t>
<t>During initial DS provisioning (DNSSEC bootstrapping), conventional
DNSSEC validation for CDS/CDNSKEY responses is not (yet) available; in
this case, authenticated bootstrapping (<xref target="RFC9615"></xref>) <xref target="RFC9615"/> should be used.</t>
</section>

<section anchor="csync"><name>CSYNC</name>
<t>A CSYNC-based workflow generally consists of (1) querying of:</t>
<ol>
  <li>querying the CSYNC (and
possibly SOA) record to determine which data records shall be synchronized from
child to parent, and (2) querying and</li>
<li>querying for these data records (e.g. NS), (e.g., NS) before
placing them in the parent zone. zone.</li></ol>
<t>
If the below conditions are not met during these steps, the CSYNC state
MUST
<bcp14>MUST</bcp14> be considered inconsistent.</t>
<t>When querying the CSYNC record, the Parental Agent MUST <bcp14>MUST</bcp14> ascertain that
queries are made against all nameservers listed in the
Child's delegation from the Parent, Parent and ensure that the record's
immediate flag and type bitmap are equal across received responses.</t>
<t>The CSYNC record's SOA serial field and soaminimum flag might
legitimately differ across nameservers (such as in multi-provider
setups); thus, equality is thus not required across responses.
Instead, for a given response, processing of these values MUST <bcp14>MUST</bcp14>
occur with respect to the SOA record as obtained from the same
nameserver.
If the resulting per-nameserver assessments of whether the update is
permissible do not all agree, the CSYNC state MUST <bcp14>MUST</bcp14> be considered
inconsistent.</t>
<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 <bcp14>MUST</bcp14> ascertain
that all queries are made against all nameservers from which a CSYNC
record was received, received and ensure that all of them return responses with equal rdata
sets (including cases where all are empty).</t>
<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>.</t> target="RFC9499"/>.</t>
<t>Other CSYNC processing rules from Section 3 of <xref target="RFC7477"></xref> section="3" target="RFC7477"/> remain in place without
modification. For example, when the NS type flag is present, associated NS
processing has to occur before potential glue updates to ensure that glue
addresses match the right set of nameservers.
Also, when the type bitmap contains the A/AAAA flags, corresponding address
queries are only to be sent for NS hostnames &quot;that that are in bailiwick&quot;, bailiwick, while
out-of-bailiwick NS records are ignored.
Refer to Sections 3.2.2 <xref target="RFC7477" section="3.2.2" sectionFormat="bare"/> and 4.3 <xref target="RFC7477"></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
(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).
Parental Agents SHOULD <bcp14>SHOULD</bcp14> check that CSYNC-based updates, if applied, do not
break the delegation.</t>
</section>
</section>

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

<section anchor="security-considerations"><name>Security Considerations</name>
<t>The level of rigor mandated by this document is needed to prevent
publication of half-baked DS or delegation NS RRsets (authorized only
under an insufficient subset of authoritative nameservers), ensuring
that a single operator cannot unilaterally modify the delegation (add or
remove trust anchors or nameservers) when other operators are present.
This applies both when the setup is intentional and when it is
unintentional (such as in the case of lame delegation lame-delegation hijacking).</t>
<t>As a consequence, the delegation's records can only be modified when
zones are synchronized across operators, unanimously reflecting the
domain owner's intentions.
Both availability and integrity of the domain's DNS service benefit from
this policy.</t>
<t>In order to resolve situations in which consensus about child zone
contents cannot be reached (e.g. (e.g., because one of the nameserver
operators is uncooperative), Parental Agents SHOULD <bcp14>SHOULD</bcp14> continue to accept
DS and NS/glue update requests from the domain owner via an
authenticated out-of-band channel (such as EPP <xref target="RFC5730"></xref>), target="RFC5730"/>),
irrespective of the adoption of automated delegation maintenance.
Availability of such an interface also enables recovery from a situation
where the private key is no longer available for signing the CDS/CDNSKEY
or CSYNC records in the child zone.</t>
</section>

<section anchor="implementation-status"><name>Implementation Status</name>
<t><strong>Note to

</middle>

<!-- [rfced] Would you like the RFC Editor</strong>: please remove this entire section before 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 references to be alphabetized
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> left in their current order?
-->

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

<references><name>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.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.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.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.9364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9615.xml"/>
</references>
<references><name>Informative References</name>
<reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-types"> target="https://www.iana.org/assignments/ds-rr-types">
  <front>
    <title>Delegation
    <title>DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms</title>
    <author fullname="IANA"></author>
  </front>
</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-dnsop-ds-automation.xml"/>
<reference anchor="LAME1" target="http://dx.doi.org/10.1145/3419394.3423623"> anchor="LAME1">
  <front>
    <title>Unresolved Issues: Prevalence, Persistence, and Perils of Lame Delegations</title>
    <author fullname="Gautam Akiwate" surname="Akiwate">
      <organization>UC San Diego</organization>
    </author>
    <author fullname="Mattijs Jonker" surname="Jonker">
      <organization>University of Twente</organization>
    </author>
    <author fullname="Raffaele Sommese" surname="Sommese">
      <organization>University of Twente</organization>
    </author>
    <author fullname="Ian Foster" surname="Foster">
      <organization>DNS Coffee</organization>
    </author>
    <author fullname="Geoffrey M. Voelker" surname="Voelker">
      <organization>UC San Diego</organization>
    </author>
    <author fullname="Stefan Savage" surname="Savage">
      <organization>UC San Diego</organization>
    </author>
    <author fullname="KC Claffy" surname="Claffy">
      <organization>CAIDA/UC San Diego</organization>
    </author>
    <author>
      <organization>ACM</organization>
    </author>
    <date year="2020" month="October" day="27"></date>
  </front>
  <seriesInfo name="DOI" value="10.1145/3419394.3423623"></seriesInfo>
  <refcontent>Proceedings
  <refcontent>IMC '20: Proceedings of the ACM Internet Measurement Conference</refcontent> Conference, pp. 281-294</refcontent>
</reference>
<reference anchor="LAME2" target="http://dx.doi.org/10.1145/3487552.3487816"> anchor="LAME2">
  <front>
    <title>Risky BIZness: risks derived from registrar name management</title>
    <author fullname="Gautam Akiwate" surname="Akiwate">
      <organization>UC San Diego</organization>
    </author>
    <author fullname="Stefan Savage" surname="Savage">
      <organization>UC San Diego</organization>
    </author>
    <author fullname="Geoffrey M. Voelker" surname="Voelker">
      <organization>UC San Diego</organization>
    </author>
    <author fullname="K C fullname="KC Claffy" surname="Claffy">
      <organization>CAIDA/UC San Diego</organization>
    </author>
    <author>
      <organization>ACM</organization>
    </author>
    <date year="2021" month="November" day="2"></date>
  </front>
  <seriesInfo name="DOI" value="10.1145/3487552.3487816"></seriesInfo>
  <refcontent>Proceedings
  <refcontent>IMC '21: Proceedings of the 21st ACM Internet Measurement Conference</refcontent> Conference, pp. 673-686</refcontent>
</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.8901.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
</references>
</references>

<section anchor="scenarios"><name>Failure Scenarios due to Inconsistencies</name>
<t>The following scenarios are informative examples of how things can go wrong when
consistency is not enforced by the parent during CDS/CDNSKEY/CSYNC
processing.
Other scenarios that cause similar (or perhaps even more) harm may
exist.</t>
<t>The common feature of these scenarios is that if one nameserver steps
out of line and the parent is not careful, DNS resolution and/or
validation will break down. When several DNS providers are involved,
this undermines the very guarantees of operator independence that
multi-provider configurations are intended to provide.</t>

<section anchor="ds-breakage-due-to-replication-lag"><name>DS Breakage due to Replication Lag</name>
<t>If an authoritative nameserver is lagging behind during a key rollover,
the parent may see different CDS/CDNSKEY RRsets depending on the
nameserver contacted. This may cause old and new DS RRsets to be
deployed in an alternating fashion and without the awareness of the zone
maintainer, who may then inadvertently break the chain of trust by
prematurely removing a DNSKEY still referenced by a (stale) CDS/CDNSKEY
RRset.</t>
<t>While foreseen in Section 6.2 of <xref target="RFC7344"></xref>, section="6.2" target="RFC7344"/>, the solution specified there
requires parents to keep state on CDS/CDNSKEY RRsets. This document
achieves the same without this burden, and burden and, in case the parent reports
consistency errors downstream, can also help detection of the child-side
replication issue by the operator.</t>
</section>

<section anchor="escalation-of-lame-delegation-takeover"><name>Escalation of Lame Delegation Takeover</name>
<t>A delegation may include a non-existent nonexistent NS hostname, for example example, due to
a typo or when the nameserver's domain registration has having expired.
(Re-)registering such a non-resolvable nameserver domain allows a third
party to run authoritative DNS service for all domains delegated to that
NS hostname, serving responses different from the legitimate ones.</t>
<t>This strategy for hijacking (at least part of the) DNS traffic and
spoofing responses is not new, new but is surprisingly common <xref target="LAME1"></xref><xref target="LAME2"></xref>. target="LAME1"/> <xref target="LAME2"/>.
It is also known that DNSSEC reduces the impact of such an attack,
as validating resolvers will reject illegitimate responses due to lack
of signatures consistent with the delegation's DS records.</t>
<t>On the other hand, if the delegation is not protected by DNSSEC, the
rogue nameserver is not only able to serve unauthorized responses
without detection; detection: it is even possible for the attacker to escalate the
nameserver takeover to a full domain takeover.</t>
<t>In particular, the rogue nameserver can publish CDS/CDNSKEY records.
If those are processed by the parent without ensuring consistency with
other authoritative nameservers, the delegation will, with some patience, get
secured with the attacker's DNSSEC keys. Of course, as the parent’s parent's query (or
sometimes queries) need to hit the attacker's nameserver, this requires some
statistical luck; but eventually luck, but, eventually, it will succeed.
As responses served by the remaining legitimate nameservers are not
signed with these keys, validating resolvers will start rejecting them.</t>
<t>Once DNSSEC is established, the attacker can use CSYNC to remove other
nameservers from the delegation at will (and potentially add new ones
under their control), control) or change glue records to point to the attacker's
nameservers.
This enables the attacker to position themself itself as the only party
providing authoritative DNS service for the victim domain,
significantly augmenting the attack's impact.</t>
</section>

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

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

<section anchor="ns-breakage"><name>NS Breakage</name>
<t>A similar scenario affects the CSYNC record, which is used to update the
delegation's NS record set at the parent.
The issue occurs, for
For example, the issue occurs when a provider accidentally includes
only their own set of hostnames in the local NS record set, set or publishes
an otherwise flawed NS record set.</t>
<t>If the parent then observes a CSYNC signal and fetches the flawed NS
record set without ensuring consistency across nameservers, the
delegation may be updated in a way that breaks resolution or silently
reduces the multi-provider setup to a single-provider setup.</t>
</section>
</section>

<section anchor="bogus-provider-change-temporary-multi-signer"><name>Bogus Provider Change (Temporary Multi-Signer)</name>
<t>Transferring DNS service for a domain name from one (signing) DNS
provider to another, without going insecure, necessitates a brief period
during which the domain is operated in multi-signer mode: 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
CDS/CDNSKEY records in their copy of the zone.
Once the parent learns about the updated CDS/CDNSKEY record set at the
old provider, the delegation's DS record set is updated.
Then, after waiting for cache expiration, the new provider's NS
hostnames can be added to the zone's NS record set, set so that queries
start balancing across both providers.
To conclude the hand-over, handover, the old provider is removed by inverting
these steps with swapped roles.</t>
<t>The multi-signer phase of this process breaks when the new provider,
perhaps unaware of the situation and its intricacies, fails to include
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
retrieve the DNSKEY record set from the new provider, the old provider's
RRSIGs do no longer validate, causing SERVFAIL to be returned.</t>
<t>However, an even worse consequence can occur when the parent performs
their next CDS/CDNSKEY scan:
It may then happen that the scan.
The incorrect CDS/CDNSKEY record set is fetched
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
prematurely removed from the domain's DNSSEC chain of trust.
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>
</section>
</section>

<section anchor="change-history-to-be-removed-before-publication"><name>Change History (to be removed before publication)</name>

<ul spacing="compact">
<li>draft-ietf-dnsop-cds-consistency-11</li>
</ul>
<blockquote><t>Editorial nits</t>
</blockquote>
<ul spacing="compact">
<li>draft-ietf-dnsop-cds-consistency-10</li>
</ul>
<blockquote><t>Clarify that parents anchor="acknowledgments" numbered="false">
<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>

<!--[rfced] We had the following questions about abbreviations used throughout the document:

a) How may have local policy</t>
<t>Additional reference from IESG (Mike Bishop)</t>
<t>Language precision from IESG (Andy Newton)</t>
<t>Editorial nits from IESG (Gorry Fairhurst, Paul Wouters)</t>
<t>Editorial nits from Vijay Gurbani</t>
</blockquote>
<ul spacing="compact">
<li>draft-ietf-dnsop-cds-consistency-09</li>
</ul>
<blockquote><t>Editorial changes</t>
<t>Nits from Mohamed Boucadair</t>
</blockquote>
<ul spacing="compact">
<li>draft-ietf-dnsop-cds-consistency-08</li>
</ul>
<blockquote><t>Take into account we expand DS?  Delegation Signer as used in RFC 7344 Section 6.2 for Appendix A.1 considerations</t>
</blockquote>
<ul spacing="compact">
<li>draft-ietf-dnsop-cds-consistency-07</li>
</ul>
<blockquote><t>Clarify that &quot;all nameservers&quot; means fetching all delegation 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 4034?

b) How may we expand EPP?  Extensible Provisioning Protocol as used in place</t>
<t>Editorial changes</t>
<t>Clean up &quot;multi-homing&quot; and define &quot;multi-provider&quot;/&quot;multi-signer&quot;</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,
RFC 5730?

-->

<!--[rfced] The following similar forms are used throughout the document.  Please let us know if/how they may be made uniform:

child vs. Child
parent vs. Parent
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
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 let us know if nothing changed, and need for OOB interface</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 any changes are needed.  Updates of this nature typically
result in more precise language, which 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 helpful for nameservers readers.

Note that don't respond or provide DoE (i.e. require
  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> our script did not flag any words in particular, but this should
still be reviewed as a best practice.

-->

</back>

</rfc>