rfc9975v1.txt   rfc9975.txt 
Internet Engineering Task Force (IETF) P. Thomassen Internet Engineering Task Force (IETF) P. Thomassen
Request for Comments: 9975 SSE - Secure Systems Engineering GmbH Request for Comments: 9975 SSE
Updates: 7344, 7477 May 2026 Updates: 7344, 7477 May 2026
Category: Standards Track Category: Standards Track
ISSN: 2070-1721 ISSN: 2070-1721
Clarifications on CDS/CDNSKEY and CSYNC Consistency Clarifications on CDS/CDNSKEY and CSYNC Consistency
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
skipping to change at line 98 skipping to change at line 98
[RFC7344] automates DNS Security Extensions (DNSSEC) delegation trust [RFC7344] automates DNS Security Extensions (DNSSEC) delegation trust
maintenance by having the child publish CDS and/or CDNSKEY records maintenance by having the child publish CDS and/or CDNSKEY records
that describe the prospective DS parameters. Similarly, [RFC7477] that describe the prospective DS parameters. Similarly, [RFC7477]
specifies CSYNC records indicating a desired update of the specifies CSYNC records indicating a desired update of the
delegation's NS and associated glue records. Parent-side entities delegation's NS and associated glue records. Parent-side entities
(e.g., Registries and Registrars) can use these records to update the (e.g., Registries and Registrars) can use these records to update the
corresponding records 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 done in normal resolution). The corresponding Section 6.1 of (as done in normal resolution). [RFC7344] (on CDS/CDNSKEY) has a
[RFC7344] (CDS/CDNSKEY) contains no provision for how specifically corresponding section (Section 6.1 of [RFC7344]) that contains no
queries for these records should be done. provision for how specifically 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
nameserver 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 the Signing Key (KSK) rollover) or because they are not controlled by 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
provider change) and when it is permanent (e.g., for redundancy). In provider change) and when it is permanent (e.g., for redundancy). In
any case, a single provider should not be in the position to remove any case, a single provider should not be in the position to remove
the other providers' records from the delegation. any other provider's records from the delegation.
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
skipping to change at line 200 skipping to change at line 201
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, Child's delegation from the Parent using a validating resolver,
including any available glue records. 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 (see [RFC9499]) 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
concluding that the nameserver is permanently unreachable and concluding that the nameserver is permanently unreachable and
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
skipping to change at line 226 skipping to change at line 227
NOT create any RRsets that would have been created had the NOT create any RRsets that would have been created had the
nameservers 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 (via a response that matches the current delegation
confirm that nothing needs to happen or give an inconsistent result state). This is because any subsequent responses could only confirm
in which case nothing needs to happen. The parent may apply local that nothing needs to happen or give an inconsistent result in which
policy in determining whether the requested update is consistent or case nothing needs to happen. The parent may apply local policy in
not with the status quo, as illustrated in the type-specific sections determining whether the requested update is consistent or not with
below. In any case, queries may be continued across all nameservers the status quo, as illustrated in the type-specific sections below.
for reporting purposes. In any case, queries may be continued across all nameservers 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 When retrieving a Child's CDS/CDNSKEY RRset for DNSSEC delegation
maintenance, the Parental Agent, knowing both the Child zone name and trust maintenance, the Parental Agent, knowing both the Child zone
its NS hostnames, MUST ascertain that queries are made against all name and its NS hostnames, MUST ascertain that queries are made
nameservers listed in the Child's delegation from the Parent. The against all nameservers listed in the Child's delegation from the
Parental Agent MUST also ensure that each key referenced in any of Parent. The Parental Agent MUST also ensure that each key referenced
the received answers is also referenced in all other received in any of the received answers is also referenced in all other
responses or that responses consistently indicate a request for received responses or that responses consistently indicate a request
removal of the entire DS RRset ([RFC8078], Section 6). for removal of the entire DS RRset ([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
skipping to change at line 346 skipping to change at line 348
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 Extensible Provisioning
irrespective of the adoption of automated delegation maintenance. Protocol (EPP) [RFC5730]), irrespective of the adoption of automated
Availability of such an interface also enables recovery from a delegation maintenance. Availability of such an interface also
situation where the private key is no longer available for signing enables recovery from a situation where the private key is no longer
the CDS/CDNSKEY or CSYNC records in the child zone. available for signing the CDS/CDNSKEY or CSYNC records in the child
zone.
6. References 6. References
6.1. Normative References 6.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>.
skipping to change at line 409 skipping to change at line 412
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>.
6.2. Informative References 6.2. Informative References
[DS-IANA] IANA, "DNSSEC Delegation Signer (DS) Resource Record (RR)
Type Digest Algorithms",
<https://www.iana.org/assignments/ds-rr-types>.
[DS-AUTOMATION] [DS-AUTOMATION]
Sheng, S. and P. Thomassen, "Operational Recommendations Sheng, S. and P. Thomassen, "Operational Recommendations
for DNSSEC Delegation Signer (DS) Automation", Work in for DNSSEC Delegation Signer (DS) Automation", Work in
Progress, Internet-Draft, draft-ietf-dnsop-ds-automation- Progress, Internet-Draft, draft-ietf-dnsop-ds-automation-
05, 17 April 2026, <https://datatracker.ietf.org/doc/html/ 05, 17 April 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-dnsop-ds-automation-05>. draft-ietf-dnsop-ds-automation-05>.
[DS-IANA] IANA, "DNSSEC Delegation Signer (DS) Resource Record (RR)
Type Digest Algorithms",
<https://www.iana.org/assignments/ds-rr-types>.
[LAME1] Akiwate, G., Jonker, M., Sommese, R., Foster, I., Voelker, [LAME1] Akiwate, G., Jonker, M., Sommese, R., Foster, I., Voelker,
G. M., Savage, S., and K. Claffy, "Unresolved Issues: G. M., Savage, S., and K. Claffy, "Unresolved Issues:
Prevalence, Persistence, and Perils of Lame Delegations", Prevalence, Persistence, and Perils of Lame Delegations",
IMC '20: Proceedings of the ACM Internet Measurement IMC '20: Proceedings of the ACM Internet Measurement
Conference, pp. 281-294, DOI 10.1145/3419394.3423623, 27 Conference, pp. 281-294, DOI 10.1145/3419394.3423623, 27
October 2020, <https://doi.org/10.1145/3419394.3423623>. October 2020, <https://doi.org/10.1145/3419394.3423623>.
[LAME2] Akiwate, G., Savage, S., Voelker, G. M., and K. Claffy, [LAME2] Akiwate, G., Savage, S., Voelker, G. M., and K. Claffy,
"Risky BIZness: risks derived from registrar name "Risky BIZness: risks derived from registrar name
management", IMC '21: Proceedings of the 21st ACM Internet management", IMC '21: Proceedings of the 21st ACM Internet
skipping to change at line 547 skipping to change at line 550
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 own 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 handover, 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)
 End of changes. 10 change blocks. 
31 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.48.