rfc9975.original   rfc9975.txt 
DNSOP Working Group P. Thomassen Internet Engineering Task Force (IETF) P. Thomassen
Internet-Draft SSE - Secure Systems Engineering GmbH Request for Comments: 9975 SSE - Secure Systems Engineering GmbH
Updates: 7344, 7477 (if approved) 11 December 2025 Updates: 7344, 7477 May 2026
Intended status: Standards Track Category: Standards Track
Expires: 14 June 2026 ISSN: 2070-1721
Clarifications on CDS/CDNSKEY and CSYNC Consistency Clarifications on CDS/CDNSKEY and CSYNC Consistency
draft-ietf-dnsop-cds-consistency-11
Abstract Abstract
Maintenance of DNS delegations requires occasional changes of the DS Maintenance of DNS delegations requires occasional changes of the DS
and NS record sets on the parent side of the delegation. For the and NS record sets on the parent side of the delegation. For the
case of DS records, "Automating DNSSEC Delegation Trust Maintenance" case of DS records, "Automating DNSSEC Delegation Trust Maintenance"
(RFC 7344) provides automation by allowing the child to publish CDS (RFC 7344) provides automation by allowing the child to publish CDS
and/or CDNSKEY records holding the prospective DS parameters which and/or CDNSKEY records holding the prospective DS parameters that the
the parent can ingest. Similarly, "Child-to-Parent Synchronization parent can ingest. Similarly, "Child-to-Parent Synchronization in
in DNS" (RFC 7477) specifies CSYNC records to indicate a desired DNS" (RFC 7477) specifies CSYNC records to indicate a desired update
update of the delegation's NS (and glue) records. Parent-side of the delegation's NS (and glue) records. Parent-side entities
entities (e.g., Registries and Registrars) can query these records (e.g., Registries and Registrars) can query these records from the
from the child and, after validation, use them to update the parent- child and, after validation, use them to update the parent-side
side Resource Record Sets (RRsets) of the delegation. Resource Record Sets (RRsets) of the delegation.
This document specifies under which conditions the target states This document specifies under which conditions the target states
expressed via CDS/CDNSKEY and CSYNC records are considered expressed via CDS/CDNSKEY and CSYNC records are considered
"consistent". Parent-side entities accepting such records from the "consistent". Parent-side entities accepting such records from the
child have to ensure that update requests retrieved from different child have to ensure that update requests retrieved from different
authoritative nameservers satisfy these consistency requirements authoritative nameservers satisfy these consistency requirements
before taking any action based on them. before taking any action based on them.
This document updates RFC 7344 and RFC 7477. This document updates RFCs 7344 and 7477.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9975.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 June 2026.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology
2. Updates to RFC 7344 and RFC 7477 . . . . . . . . . . . . . . 4 2. Updates to RFCs 7344 and 7477
3. Processing Requirements . . . . . . . . . . . . . . . . . . . 5 3. Processing Requirements
3.1. CDS and CDNSKEY . . . . . . . . . . . . . . . . . . . . . 6 3.1. CDS and CDNSKEY
3.2. CSYNC . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. CSYNC
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 6. References
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Failure Scenarios due to Inconsistencies
8.2. Informative References . . . . . . . . . . . . . . . . . 10 A.1. DS Breakage due to Replication Lag
Appendix A. Failure Scenarios due to Inconsistencies . . . . . . 11 A.2. Escalation of Lame Delegation Takeover
A.1. DS Breakage due to Replication Lag . . . . . . . . . . . 11 A.3. Multi-Provider (Permanent Multi-Signer)
A.2. Escalation of Lame Delegation Takeover . . . . . . . . . 11 A.3.1. DS Breakage
A.3. Multi-Provider (Permanent Multi-Signer) . . . . . . . . . 12 A.3.2. NS Breakage
A.3.1. DS Breakage . . . . . . . . . . . . . . . . . . . . . 12 A.4. Bogus Provider Change (Temporary Multi-Signer)
A.3.2. NS Breakage . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgments
A.4. Bogus Provider Change (Temporary Multi-Signer) . . . . . 13 Author's Address
Appendix B. Change History (to be removed before publication) . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
[RFC7344] automates DNSSEC delegation trust maintenance by having the [RFC7344] automates DNS Security Extensions (DNSSEC) delegation trust
child publish CDS and/or CDNSKEY records which describe the maintenance by having the child publish CDS and/or CDNSKEY records
prospective DS parameters. Similarly, [RFC7477] specifies CSYNC that describe the prospective DS parameters. Similarly, [RFC7477]
records indicating a desired update of the delegation's NS and specifies CSYNC records indicating a desired update of the
associated glue records. Parent-side entities (e.g., Registries and delegation's NS and associated glue records. Parent-side entities
Registrars) can use these records to update the corresponding records (e.g., Registries and Registrars) can use these records to update the
of the delegation. corresponding records of the delegation.
For ingesting CSYNC records, Section 3.1 of [RFC7477] advocates that For ingesting CSYNC records, Section 3.1 of [RFC7477] advocates that
Parental Agents limit queries to a single authoritative nameserver Parental Agents limit queries to a single authoritative nameserver
(as typically done in normal resolution). The corresponding (as done in normal resolution). The corresponding Section 6.1 of
Section 6.1 of [RFC7344] (CDS/CDNSKEY) contains no provision for how [RFC7344] (CDS/CDNSKEY) contains no provision for how specifically
specifically queries for these records should be done. queries for these records should be done.
Retrieving records from just one authoritative server (e.g., by 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. However, problems may arise if under ideal operating scenarios. However, problems may arise if
CDS/CDNSKEY/CSYNC record sets are inconsistent across authoritative CDS/CDNSKEY/CSYNC record sets are inconsistent across authoritative
nameservers, either because they are out of sync (e.g., during a Key nameserver either because they are out of sync (e.g., during a Key
Signing Key (KSK) rollover), or because they are not controlled by Signing Key (KSK) rollover) or because they are not controlled by the
the same entity (e.g., in a multi-signer setup [RFC8901]). same entity (e.g., in a multi-signer setup [RFC8901]).
In such cases, if CDS/CDNSKEY/CSYNC records are retrieved from one 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 nameserver can unilaterally trigger an update of the delegation's DS
or NS record set. or NS record set.
For example, a single provider in a multi-signer setup may For example, a single provider in a multi-signer setup may
(accidentally or maliciously) cause another provider's trust anchors (accidentally or maliciously) cause another provider's trust anchors
and/or nameservers to be removed from the delegation. This can occur and/or nameservers to be removed from the delegation. This can occur
both when the multi-signer configuration is temporary (e.g., during a both when the multi-signer configuration is temporary (e.g., during a
skipping to change at page 3, line 51 skipping to change at line 132
Similar breakage can occur when the delegation has lame nameservers, Similar breakage can occur when the delegation has lame nameservers,
where an attacker may illegitimately initialize a DS record set and where an attacker may illegitimately initialize a DS record set and
then manipulate the delegation's NS record set at will. More then manipulate the delegation's NS record set at will. More
detailed examples are given in Appendix A. detailed examples are given in Appendix A.
For a CDS/CDNSKEY/CSYNC consumer, it is generally impossible to For a CDS/CDNSKEY/CSYNC consumer, it is generally impossible to
estimate the impact of a requested delegation update unless all of estimate the impact of a requested delegation update unless all of
the child's authoritative nameservers are inspected. At the same the child's authoritative nameservers are inspected. At the same
time, applying an automated delegation update "MUST NOT break the time, applying an automated delegation update "MUST NOT break the
current delegation" ([RFC7344], Section 4.1), i.e., it must not current delegation" (per [RFC7344], Section 4.1), i.e., it must not
hamper availability or validatability of the Child's resolution. As hamper availability or validatability of the Child's resolution. As
part of a more holistic treatment of the problem space, part of a more holistic treatment of the problem space,
[I-D.ietf-dnsop-ds-automation] provides more specific guidance on [DS-AUTOMATION] provides more-specific guidance on such safety
such safety checks. checks.
This document therefore specifies that parent-side entities need to Therefore, this document specifies that parent-side entities need to
ensure that the updates indicated by CDS/CDNSKEY and CSYNC record ensure that the updates indicated by CDS/CDNSKEY and CSYNC record
sets are plausibly consistent across the child's nameservers, before sets are plausibly consistent across the child's nameservers before
taking any action based on these records. taking any action based on these records.
Readers are expected to be familiar with DNSSEC [RFC9364], in Readers are expected to be familiar with DNSSEC [RFC9364], in
particular [RFC4033], [RFC4034], [RFC4035], [RFC7344], and [RFC7477]. particular, [RFC4033], [RFC4034], [RFC4035], [RFC7344], and
For an overview of related operational practices, refer to [RFC6781] [RFC7477]. For an overview of related operational practices, refer
and [RFC8901]. to [RFC6781] and [RFC8901].
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terminology 1.2. Terminology
Multi-provider setup: A constellation where several providers Multi-provider setup: A constellation where several providers
independently operate authoritative DNS service for a domain, independently operate authoritative DNS service for a domain,
usually for purposes of redundancy. This includes setups both usually for purposes of redundancy. This includes setups both
with and without DNSSEC. with and without DNSSEC.
Multi-signer setup: A multi-provider setup for a DNSSEC-enabled Multi-signer setup: A multi-provider setup for a DNSSEC-enabled
domain with multiple independent signing entities [RFC8901]. Such domain with multiple independent signing entities [RFC8901]. Such
a setup may be permanent (for redundancy) or temporary (for a setup may be permanent (for redundancy) or temporary (for
continuity of DNSSEC operation while changing the provider of a continuity of DNSSEC operation while changing the provider of a
domain that normally uses a single one). domain that normally uses a single one).
Otherwise, the terminology in this document is as defined in Otherwise, the terminology in this document is as defined in
[RFC7344]. [RFC7344].
2. Updates to RFC 7344 and RFC 7477 2. Updates to RFCs 7344 and 7477
Section 4.1 of [RFC7344] lists acceptance rules for CDS/CDNSKEY Section 4.1 of [RFC7344] lists acceptance rules for CDS/CDNSKEY
records. This list is extended with the consistency requirements records. This list is extended with the consistency requirements
defined in this document. This document does not modify any other defined in this document. This document does not modify any other
part of [RFC7344]. part of [RFC7344].
Sections 3.1 and 4.2 of [RFC7477] have logic for deciding from which Sections 3.1 and 4.2 of [RFC7477] have logic for deciding from which
nameserver to query CSYNC information. This logic is replaced with nameserver to query CSYNC information. This logic is replaced with
the CSYNC consistency requirements defined in this document. the CSYNC consistency requirements defined in this document.
3. Processing Requirements 3. Processing Requirements
Consistency requirements that apply equally to CDS/CDNSKEY and CSYNC Consistency requirements that apply equally to CDS/CDNSKEY and CSYNC
are listed first; type-specific consistency criteria are described in are listed first; type-specific consistency criteria are described in
separate subsections. separate subsections.
In order to determine plausible consistency of CDS/CDNSKEY or CSYNC In order to determine plausible consistency of CDS/CDNSKEY or CSYNC
RRsets across the child's nameservers, the Parental Agent MUST fetch RRsets across the child's nameservers, the Parental Agent MUST fetch
all IP addresses for each nameserver hostname as listed in the all IP addresses for each nameserver hostname as listed in the
Child's delegation from the Parent using a validating resolver, and Child's delegation from the Parent using a validating resolver,
including glue records if available. Before acting on any CDS/ including any available glue records. Before acting on any CDS/
CDNSKEY or CSYNC record for the child, the Parental Agent MUST have CDNSKEY or CSYNC record for the child, the Parental Agent MUST have
established plausible consistency by querying all of these IP established plausible consistency by querying all of these IP
addresses for the record set(s) in question, as per the guidelines addresses for the record set(s) in question, as per the guidelines
spelled out in the following subsections. spelled out in the following subsections.
In all cases, consistency is REQUIRED across received responses only. In all cases, consistency is REQUIRED across received responses only.
(A NODATA response is a received response.) (A NODATA response is a received response.)
When a response cannot be obtained from a given nameserver, the When a response cannot be obtained from a given nameserver, the
Parental Agent SHOULD attempt to obtain it at a later time, before Parental Agent SHOULD attempt to obtain it at a later time, before
skipping to change at page 5, line 37 skipping to change at line 215
removing it from consideration. A configurable retry schedule is removing it from consideration. A configurable retry schedule is
RECOMMENDED to increase the likelihood of collecting data from all RECOMMENDED to increase the likelihood of collecting data from all
nameservers. An exponential back-off schedule (e.g., 5, 10, 20, 40, nameservers. An exponential back-off schedule (e.g., 5, 10, 20, 40,
... minutes) provides a balance between faster task completion while ... minutes) provides a balance between faster task completion while
accommodating transient unreachability. To sidestep localized accommodating transient unreachability. To sidestep localized
routing issues, the Parental Agent MAY also attempt contacting the routing issues, the Parental Agent MAY also attempt contacting the
nameserver from another network vantage point. nameserver from another network vantage point.
If an inconsistent state is encountered, the Parental Agent MUST If an inconsistent state is encountered, the Parental Agent MUST
abort the operation. Specifically, it MUST NOT delete or alter any abort the operation. Specifically, it MUST NOT delete or alter any
existing RRset that would have been deleted or altered, and MUST NOT existing RRset that would have been deleted or altered, and it MUST
create any RRsets that would have been created, had the nameservers NOT create any RRsets that would have been created had the
given consistent responses. nameservers given consistent responses.
To accommodate transient inconsistencies (e.g., replication delays), To accommodate transient inconsistencies (e.g., replication delays),
implementations MAY be configurable to undertake a retry of the full implementations MAY be configurable to undertake a retry of the full
process, repeating all queries (suggested default: enabled with process, repeating all queries (suggested default: enabled with
exponential back-off). exponential back-off).
Any pending queries can immediately be dequeued when encountering a 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. This is because any subsequent responses could only explicitly. This is because any subsequent responses could only
confirm that nothing needs to happen, or give an inconsistent result confirm that nothing needs to happen or give an inconsistent result
in which case nothing needs to happen. The parent may apply local in which case nothing needs to happen. The parent may apply local
policy in determining whether the requested update is consistent or policy in determining whether the requested update is consistent or
not with the status quo, as illustrated in the type-specific sections not with the status quo, as illustrated in the type-specific sections
below. In any case, queries may be continued across all nameservers below. In any case, queries may be continued across all nameservers
for reporting purposes. for reporting purposes.
Existing requirements for ensuring integrity remain in effect. In Existing requirements for ensuring integrity remain in effect. In
particular, DNSSEC signatures MUST be requested and validated for all particular, DNSSEC signatures MUST be requested and validated for all
queries unless otherwise noted. queries unless otherwise noted.
3.1. CDS and CDNSKEY 3.1. CDS and CDNSKEY
To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust 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, MUST ascertain that queries are made against all
nameservers listed in the Child's delegation from the Parent, and nameservers listed in the Child's delegation from the Parent and
ensure that each key referenced in any of the received answers is ensure that each key referenced in any of the received answers is
also referenced in all other received responses, or that responses also referenced in all other received responses, or that responses
consistently indicate a request for removal of the entire DS RRset consistently indicate a request for removal of the entire DS RRset
([RFC8078], Section 6). ([RFC8078], Section 6).
In other words, CDS/CDNSKEY records at the Child zone apex must be 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. When a key is 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 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 vice versa), or returned by one nameserver but is missing from at
least one other nameserver's answer, the CDS/CDNSKEY state MUST be least one other nameserver's answer, the CDS/CDNSKEY state MUST be
considered inconsistent. Similarly, the state MUST be considered considered inconsistent. Similarly, the state MUST be considered
inconsistent if there is a CDS or CDNSKEY response that indicates a inconsistent if there is a CDS or CDNSKEY response that indicates a
removal request for the DS RRset whereas another response indicates removal request for the DS RRset whereas another response indicates
no change (NODATA) or a DS update. no change (NODATA) or a DS update.
As an example of local policy, the parent may restrict the choice of As an example of local policy, the parent may restrict the choice of
hash digest types used when publishing a DS RRset (notwithstanding hash digest types used when publishing a DS RRset (notwithstanding
the requirements specified in [DS-IANA]). (The set of keys the requirements specified in [DS-IANA]). (The set of keys
referenced in the DS RRset is not up to local policy. Only if all referenced in the DS RRset is not up to local policy. Only if all
keys from the CDS/CDNSKEY RRsets are included, the DS RRset is keys from the CDS/CDNSKEY RRsets are included is the DS RRset
considered consistent.) considered consistent.)
During initial DS provisioning (DNSSEC bootstrapping), conventional During initial DS provisioning (DNSSEC bootstrapping), conventional
DNSSEC validation for CDS/CDNSKEY responses is not (yet) available; DNSSEC validation for CDS/CDNSKEY responses is not (yet) available;
in this case, authenticated bootstrapping ([RFC9615]) should be used. in this case, authenticated bootstrapping [RFC9615] should be used.
3.2. CSYNC 3.2. CSYNC
A CSYNC-based workflow generally consists of (1) querying the CSYNC A CSYNC-based workflow generally consists of:
(and possibly SOA) record to determine which data records shall be
synchronized from child to parent, and (2) querying for these data 1. querying the CSYNC (and possibly SOA) record to determine which
records (e.g. NS), before placing them in the parent zone. If the data records shall be synchronized from child to parent, and
below conditions are not met during these steps, the CSYNC state MUST
be considered inconsistent. 2. querying for these data records (e.g., NS) before placing them in
the parent zone.
If the below conditions are not met during these steps, the CSYNC
state MUST be considered inconsistent.
When querying the CSYNC record, the Parental Agent MUST ascertain When querying the CSYNC record, the Parental Agent MUST ascertain
that queries are made against all nameservers listed in the Child's that queries are made against all nameservers listed in the Child's
delegation from the Parent, and ensure that the record's immediate delegation from the Parent and ensure that the record's immediate
flag and type bitmap are equal across received responses. flag and type bitmap are equal across received responses.
The CSYNC record's SOA serial field and soaminimum flag might 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. Instead, setups); thus, equality is not required across responses. Instead,
for a given response, processing of these values MUST occur with for a given response, processing of these values MUST occur with
respect to the SOA record as obtained from the same nameserver. If respect to the SOA record as obtained from the same nameserver. If
the resulting per-nameserver assessments of whether the update is 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 MUST be considered
inconsistent. inconsistent.
Further, when retrieving the data record sets as indicated in the Further, when retrieving the data record sets as indicated in the
CSYNC record (such as NS or A/AAAA records), the Parental Agent MUST CSYNC record (such as NS or A/AAAA records), the Parental Agent MUST
ascertain that all queries are made against all nameservers from ascertain that all queries are made against all nameservers from
which a CSYNC record was received, and ensure that all return which a CSYNC record was received and ensure that all of them return
responses with equal rdata sets (including all empty). responses with equal rdata sets (including cases where all are
empty).
As an example of local policy, the parent may choose to accept glue As an example of local policy, the parent may choose to accept glue
records only for in-domain or sibling NS hostnames [RFC9499]. records only for in-domain or sibling NS hostnames [RFC9499].
Other CSYNC processing rules from Section 3 of [RFC7477] remain in Other CSYNC processing rules from Section 3 of [RFC7477] remain in
place without modification. For example, when the NS type flag is place without modification. For example, when the NS type flag is
present, associated NS processing has to occur before potential glue present, associated NS processing has to occur before potential glue
updates to ensure that glue addresses match the right set of updates to ensure that glue addresses match the right set of
nameservers. Also, when the type bitmap contains the A/AAAA flags, nameservers. Also, when the type bitmap contains the A/AAAA flags,
corresponding address queries are only to be sent for NS hostnames corresponding address queries are only to be sent for NS hostnames
"that are in bailiwick", while out-of-bailiwick NS records are that are in bailiwick, while out-of-bailiwick NS records are ignored.
ignored. Refer to Sections 3.2.2 and 4.3 [RFC7477] for more details. Refer to Sections 3.2.2 and 4.3 of [RFC7477] for more details.
CSYNC-based updates may cause validation or even insecure resolution CSYNC-based updates may cause validation or even insecure resolution
to break (e.g., by changing the delegation to a set of nameservers 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 that do not serve required DNSKEY records or do not know the zone at
all). Parental Agents SHOULD check that CSYNC-based updates, if all). Parental Agents SHOULD check that CSYNC-based updates, if
applied, do not break the delegation. applied, do not break the delegation.
4. IANA Considerations 4. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
5. Security Considerations 5. Security Considerations
The level of rigor mandated by this document is needed to prevent 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 that a single operator cannot unilaterally modify the delegation (add
or remove trust anchors or nameservers) when other operators are or remove trust anchors or nameservers) when other operators are
present. This applies both when the setup is intentional and when it present. This applies both when the setup is intentional and when it
is unintentional (such as in the case of lame delegation hijacking). is unintentional (such as in the case of lame-delegation hijacking).
As a consequence, the delegation's records can only be modified when 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. Both availability and integrity of the domain owner's intentions. Both availability and integrity of the
domain's DNS service benefit from this policy. domain's DNS service benefit from this policy.
In order to resolve situations in which consensus about child zone 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 operators is uncooperative), Parental Agents SHOULD continue to
accept DS and NS/glue update requests from the domain owner via an accept DS and NS/glue update requests from the domain owner via an
authenticated out-of-band channel (such as EPP [RFC5730]), authenticated out-of-band channel (such as EPP [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 Availability of such an interface also enables recovery from a
situation where the private key is no longer available for signing situation where the private key is no longer available for signing
the CDS/CDNSKEY or CSYNC records in the child zone. the CDS/CDNSKEY or CSYNC records in the child zone.
6. Implementation Status 6. References
*Note to the RFC Editor*: please remove this entire section before
publication.
This draft has been implemented by
* TANGO Registry Services
* CORE Registry
7. Acknowledgments
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.
8. References 6.1. Normative References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
skipping to change at page 10, line 10 skipping to change at line 407
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023, RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>. <https://www.rfc-editor.org/info/rfc9364>.
[RFC9615] Thomassen, P. and N. Wisiol, "Automatic DNSSEC [RFC9615] Thomassen, P. and N. Wisiol, "Automatic DNSSEC
Bootstrapping Using Authenticated Signals from the Zone's Bootstrapping Using Authenticated Signals from the Zone's
Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024, Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024,
<https://www.rfc-editor.org/info/rfc9615>. <https://www.rfc-editor.org/info/rfc9615>.
8.2. Informative References 6.2. Informative References
[DS-IANA] IANA, "Delegation Signer (DS) Resource Record (RR) Type [DS-IANA] IANA, "DNSSEC Delegation Signer (DS) Resource Record (RR)
Digest Algorithms", Type Digest Algorithms",
<http://www.iana.org/assignments/ds-rr-types>. <https://www.iana.org/assignments/ds-rr-types>.
[I-D.ietf-dnsop-ds-automation] [DS-AUTOMATION]
Sheng, S. and P. Thomassen, "Operational Recommendations Sheng, S. and P. Thomassen, "Operational Recommendations
for DS Automation", Work in Progress, Internet-Draft, for DNSSEC Delegation Signer (DS) Automation", Work in
draft-ietf-dnsop-ds-automation-01, 20 October 2025, Progress, Internet-Draft, draft-ietf-dnsop-ds-automation-
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop- 05, 17 April 2026, <https://datatracker.ietf.org/doc/html/
ds-automation-01>. draft-ietf-dnsop-ds-automation-05>.
[LAME1] Akiwate, G., Jonker, M., Sommese, R., Foster, I., Voelker, [LAME1] Akiwate, G., Jonker, M., Sommese, R., Foster, I., Voelker,
G. M., Savage, S., Claffy, K., and ACM, "Unresolved G. M., Savage, S., and K. Claffy, "Unresolved Issues:
Issues: Prevalence, Persistence, and Perils of Lame Prevalence, Persistence, and Perils of Lame Delegations",
Delegations", Proceedings of the ACM Internet Measurement IMC '20: Proceedings of the ACM Internet Measurement
Conference, DOI 10.1145/3419394.3423623, 27 October 2020, Conference, pp. 281-294, DOI 10.1145/3419394.3423623, 27
<http://dx.doi.org/10.1145/3419394.3423623>. October 2020, <https://doi.org/10.1145/3419394.3423623>.
[LAME2] Akiwate, G., Savage, S., Voelker, G. M., Claffy, K C, and [LAME2] Akiwate, G., Savage, S., Voelker, G. M., and K. Claffy,
ACM, "Risky BIZness: risks derived from registrar name "Risky BIZness: risks derived from registrar name
management", Proceedings of the 21st ACM Internet management", IMC '21: Proceedings of the 21st ACM Internet
Measurement Conference, DOI 10.1145/3487552.3487816, 2 Measurement Conference, pp. 673-686,
November 2021, DOI 10.1145/3487552.3487816, 2 November 2021,
<http://dx.doi.org/10.1145/3487552.3487816>. <https://doi.org/10.1145/3487552.3487816>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012, DOI 10.17487/RFC6781, December 2012,
<https://www.rfc-editor.org/info/rfc6781>. <https://www.rfc-editor.org/info/rfc6781>.
[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
Blacka, "Multi-Signer DNSSEC Models", RFC 8901, Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
DOI 10.17487/RFC8901, September 2020, DOI 10.17487/RFC8901, September 2020,
<https://www.rfc-editor.org/info/rfc8901>. <https://www.rfc-editor.org/info/rfc8901>.
skipping to change at page 11, line 30 skipping to change at line 473
If an authoritative nameserver is lagging behind during a key If an authoritative nameserver is lagging behind during a key
rollover, the parent may see different CDS/CDNSKEY RRsets depending rollover, the parent may see different CDS/CDNSKEY RRsets depending
on the nameserver contacted. This may cause old and new DS RRsets to on the nameserver contacted. This may cause old and new DS RRsets to
be deployed in an alternating fashion and without the awareness of be deployed in an alternating fashion and without the awareness of
the zone maintainer, who may then inadvertently break the chain of the zone maintainer, who may then inadvertently break the chain of
trust by prematurely removing a DNSKEY still referenced by a (stale) trust by prematurely removing a DNSKEY still referenced by a (stale)
CDS/CDNSKEY RRset. CDS/CDNSKEY RRset.
While foreseen in Section 6.2 of [RFC7344], the solution specified While foreseen in Section 6.2 of [RFC7344], the solution specified
there requires parents to keep state on CDS/CDNSKEY RRsets. This there requires parents to keep state on CDS/CDNSKEY RRsets. This
document achieves the same without this burden, and in case the document achieves the same without this burden and, in case the
parent reports consistency errors downstream, can also help detection parent reports consistency errors downstream, can also help detection
of the child-side replication issue by the operator. of the child-side replication issue by the operator.
A.2. Escalation of Lame Delegation Takeover A.2. Escalation of Lame Delegation Takeover
A delegation may include a non-existent NS hostname, for example due A delegation may include a nonexistent NS hostname, for example, due
to a typo or when the nameserver's domain registration has expired. to a typo or the nameserver's domain registration having expired.
(Re-)registering such a non-resolvable nameserver domain allows a (Re-)registering such a non-resolvable nameserver domain allows a
third party to run authoritative DNS service for all domains third party to run authoritative DNS service for all domains
delegated to that NS hostname, serving responses different from the delegated to that NS hostname, serving responses different from the
legitimate ones. legitimate ones.
This strategy for hijacking (at least part of the) DNS traffic and This strategy for hijacking (at least part of the) DNS traffic and
spoofing responses is not new, but surprisingly common spoofing responses is not new but is surprisingly common [LAME1]
[LAME1][LAME2]. It is also known that DNSSEC reduces the impact of [LAME2]. It is also known that DNSSEC reduces the impact of such an
such an attack, as validating resolvers will reject illegitimate attack, as validating resolvers will reject illegitimate responses
responses due to lack of signatures consistent with the delegation's due to lack of signatures consistent with the delegation's DS
DS records. records.
On the other hand, if the delegation is not protected by DNSSEC, the 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 without detection: it is even possible for the attacker to escalate
the nameserver takeover to a full domain takeover. the nameserver takeover to a full domain takeover.
In particular, the rogue nameserver can publish CDS/CDNSKEY records. In particular, the rogue nameserver can publish CDS/CDNSKEY records.
If those are processed by the parent without ensuring consistency If those are processed by the parent without ensuring consistency
with other authoritative nameservers, the delegation will, with some with other authoritative nameservers, the delegation will, with some
patience, get secured with the attacker's DNSSEC keys. Of course, as patience, get secured with the attacker's DNSSEC keys. Of course, as
the parent’s query (or sometimes queries) need to hit the attacker's the parent's query (or sometimes queries) need to hit the attacker's
nameserver, this requires some statistical luck; but eventually it nameserver, this requires some statistical luck, but, eventually, it
will succeed. As responses served by the remaining legitimate will succeed. As responses served by the remaining legitimate
nameservers are not signed with these keys, validating resolvers will nameservers are not signed with these keys, validating resolvers will
start rejecting them. start rejecting them.
Once DNSSEC is established, the attacker can use CSYNC to remove Once DNSSEC is established, the attacker can use CSYNC to remove
other nameservers from the delegation at will (and potentially add other nameservers from the delegation at will (and potentially add
new ones under their control), or change glue records to point to the new ones under their control) or change glue records to point to the
attacker's nameservers. This enables the attacker to position attacker's nameservers. This enables the attacker to position itself
themself as the only party providing authoritative DNS service for as the only party providing authoritative DNS service for the victim
the victim domain, significantly augmenting the attack's impact. domain, significantly augmenting the attack's impact.
A.3. Multi-Provider (Permanent Multi-Signer) A.3. Multi-Provider (Permanent Multi-Signer)
A.3.1. DS Breakage A.3.1. DS Breakage
While performing a key rollover and adjusting the corresponding CDS/ While performing a key rollover and adjusting the corresponding CDS/
CDNSKEY records, a provider could accidentally publish CDS/CDNSKEY CDNSKEY records, a provider could accidentally publish CDS/CDNSKEY
records that only include its own keys. records that only include its own keys.
When the parent happens to retrieve the records from a nameserver 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. As a result, the zone is broken at removed from the delegation. As a result, the zone is broken (at
least for some queries. least for some queries).
A.3.2. NS Breakage A.3.2. NS Breakage
A similar scenario affects the CSYNC record, which is used to update 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 the delegation's NS record set at the parent. For example, the issue
example, when a provider accidentally includes only their own set of occurs when a provider accidentally includes only their own set of
hostnames in the local NS record set, or publishes an otherwise hostnames in the local NS record set or publishes an otherwise flawed
flawed NS record set. NS record set.
If the parent then observes a CSYNC signal and fetches the flawed NS 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. reduces the multi-provider setup to a single-provider setup.
A.4. Bogus Provider Change (Temporary Multi-Signer) A.4. Bogus Provider Change (Temporary Multi-Signer)
Transferring DNS service for a domain name from one (signing) DNS Transferring DNS service for a domain name from one (signing) DNS
provider to another, without going insecure, necessitates a brief provider to another, without going insecure, necessitates a brief
period during which the domain is operated in multi-signer mode: period during which the domain is operated in multi-signer mode.
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. Once the parent CDS/CDNSKEY records in their copy of the zone. Once the parent
learns about the updated CDS/CDNSKEY record set at the old provider, learns about the updated CDS/CDNSKEY record set at the old provider,
the delegation's DS record set is updated. Then, after waiting for 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 cache expiration, the new provider's NS hostnames can be added to the
zone's NS record set, so that queries start balancing across both zone's NS record set so that queries start balancing across both
providers. To conclude the hand-over, the old provider is removed by providers. To conclude the handover, the old provider is removed by
inverting these steps with swapped roles. inverting these steps with swapped roles.
The multi-signer phase of this process breaks when the new provider, The multi-signer phase of this process breaks when the new provider,
perhaps unaware of the situation and its intricacies, fails to perhaps unaware of the situation and its intricacies, fails to
include the old provider's keys in the DNSKEY (and CDS/CDNSKEY) include the old provider's keys in the DNSKEY (and CDS/CDNSKEY)
record sets. One obvious consequence of that is that whenever the record sets. One obvious consequence is that whenever the resolver
resolver happens to retrieve the DNSKEY record set from the new happens to retrieve the DNSKEY record set from the new provider, the
provider, the old provider's RRSIGs do no longer validate, causing old provider's RRSIGs no longer validate, causing SERVFAIL to be
SERVFAIL to be returned. returned.
However, an even worse consequence can occur when the parent performs However, an even worse consequence can occur when the parent performs
their next CDS/CDNSKEY scan: It may then happen that the incorrect their next CDS/CDNSKEY scan. The incorrect CDS/CDNSKEY record set is
CDS/CDNSKEY record set is fetched from the new provider and used to fetched from the new provider and used to update the delegation's DS
update the delegation's DS record set. As a result, the old provider record set. As a result, the old provider (who still appears in the
(who still appears in the delegation) is prematurely removed from the delegation) is prematurely removed from the domain's DNSSEC chain of
domain's DNSSEC chain of trust. The new DS record set authenticates trust. The new DS record set authenticates the new provider's
the new provider's DNSKEYs only, and DNSSEC validation fails for all DNSKEYs only, and DNSSEC validation fails for all answers served by
answers served by the old provider. the old provider.
Appendix B. Change History (to be removed before publication)
* draft-ietf-dnsop-cds-consistency-11
| Editorial nits
* draft-ietf-dnsop-cds-consistency-10
| Clarify that parents may have local policy
|
| Additional reference from IESG (Mike Bishop)
|
| Language precision from IESG (Andy Newton)
|
| Editorial nits from IESG (Gorry Fairhurst, Paul Wouters)
|
| Editorial nits from Vijay Gurbani
* draft-ietf-dnsop-cds-consistency-09
| Editorial changes
|
| Nits from Mohamed Boucadair
* draft-ietf-dnsop-cds-consistency-08
| Take into account RFC 7344 Section 6.2 for Appendix A.1
| considerations
* draft-ietf-dnsop-cds-consistency-07
| Clarify that "all nameservers" means fetching all delegation NS
| IPs
* draft-ietf-dnsop-cds-consistency-06
| Editorial changes from Dnsdir early review
|
| Add Implementation Status
* draft-ietf-dnsop-cds-consistency-05
| Editorial overhaul
* draft-ietf-dnsop-cds-consistency-04
| Clarify that existing CSYNC NS and glue processing rules remain in
| place
|
| Editorial changes
|
| Clean up "multi-homing" and define "multi-provider"/"multi-signer"
* draft-ietf-dnsop-cds-consistency-03
| Clarify that CSYNC updates should not break delegations
|
| Describe consistency requirements for CSYNC soaminimum
|
| Editorial changes
* draft-ietf-dnsop-cds-consistency-02
| Retry before assuming a nameserver is permanently unreachable
* draft-ietf-dnsop-cds-consistency-01
| Make nits tool happy
|
| New failure mode: DS Breakage due to Replication Lag
|
| Point out zero overhead if nothing changed, and need for OOB
| interface
|
| Editorial changes
|
| Moved Failure Scenarios to appendix
* draft-ietf-dnsop-cds-consistency-00
| Point out zero overhead if nothing changed, and need for OOB
| interface
|
| Editorial changes.
* draft-thomassen-dnsop-cds-consistency-03
| Describe risk from lame delegations
|
| Acknowledgments
|
| Say what is being updated
|
| Editorial changes.
|
| Retry mechanism to resolve inconsistencies
* draft-thomassen-dnsop-cds-consistency-02
| Don't ignore DoE responses from individual nameservers (instead,
| require consistency across all responses received)
* draft-thomassen-dnsop-cds-consistency-01
| Allow for nameservers that don't respond or provide DoE (i.e.
| require consistency only among the non-empty answers received)
|
| Define similar requirements for CSYNC.
|
| Editorial changes.
* draft-thomassen-dnsop-cds-consistency-00 Acknowledgments
| Initial public draft. 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, and Warren Kumari.
Author's Address Author's Address
Peter Thomassen Peter Thomassen
SSE - Secure Systems Engineering GmbH SSE - Secure Systems Engineering GmbH
Hauptstraße 3 Hauptstraße 3
10827 Berlin 10827 Berlin
Germany Germany
Email: pth@systemsecurity.com Email: pth@systemsecurity.com
 End of changes. 56 change blocks. 
288 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.48.