rfc9975v2.txt   rfc9975.txt 
skipping to change at line 248 skipping to change at line 248
queries unless otherwise noted. queries unless otherwise noted.
3.1. CDS and CDNSKEY 3.1. CDS and CDNSKEY
When retrieving a Child's CDS/CDNSKEY RRset for DNSSEC delegation When retrieving a Child's CDS/CDNSKEY RRset for DNSSEC delegation
trust maintenance, the Parental Agent, knowing both the Child zone trust maintenance, the Parental Agent, knowing both the Child zone
name and its NS hostnames, MUST ascertain that queries are made name and its NS hostnames, MUST ascertain that queries are made
against all nameservers listed in the Child's delegation from the against all nameservers listed in the Child's delegation from the
Parent. The Parental Agent MUST also ensure that each key referenced Parent. The Parental Agent MUST also ensure that each key referenced
in any of the received answers is also referenced in all other in any of the received answers is also referenced in all other
received responses or that responses consistently indicate a request received responses (subject to the CDS digest type considerations
for removal of the entire DS RRset ([RFC8078], Section 6). below) or that responses consistently indicate a request 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 an eligible CDS record set but not the CDNSKEY record
vice versa), or returned by one nameserver but is missing from at set (or vice versa), or returned by one nameserver but is missing
least one other nameserver's answer, the CDS/CDNSKEY state MUST be from at least one other nameserver's answer, the CDS/CDNSKEY state
considered inconsistent. Similarly, the state MUST be considered MUST be considered inconsistent. Similarly, the state MUST be
inconsistent if there is a CDS or CDNSKEY response that indicates a considered inconsistent if there is a CDS or CDNSKEY response that
removal request for the DS RRset whereas another response indicates indicates a removal request for the DS RRset whereas another response
no change (NODATA) or a DS update. indicates no change (NODATA) or a DS update.
As an example of local policy, the parent may restrict the choice of CDS records MUST be considered for consistency only when their digest
hash digest types used when publishing a DS RRset (notwithstanding type field is designated as "MUST" in the "Implement for DNSSEC
the requirements specified in [DS-IANA]). (The set of keys Delegation" column of the "Digest Algorithms" registry [DS-IANA]).
referenced in the DS RRset is not up to local policy. Only if all Consistency of records with other digest types need not be verified,
keys from the CDS/CDNSKEY RRsets are included is the DS RRset especially when the digest type is unsupported; such records can be
considered consistent.) ignored.
Independently of this, the parent may, as a matter of local policy,
make its own choice regarding the hash digest types used when
publishing a DS RRset (notwithstanding the requirements specified in
[DS-IANA]). (The set of keys referenced in the DS RRset is not up to
local policy. Only if all keys from the CDNSKEY RRset and eligible
CDS records are included is the DS RRset 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: A CSYNC-based workflow generally consists of:
1. querying the CSYNC (and possibly SOA) record to determine which 1. querying the CSYNC (and possibly SOA) record to determine which
skipping to change at line 416 skipping to change at line 424
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-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/ 07, 18 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-dnsop-ds-automation-05>. draft-ietf-dnsop-ds-automation-07>.
[DS-IANA] IANA, "DNSSEC Delegation Signer (DS) Resource Record (RR) [DS-IANA] IANA, "DNSSEC Delegation Signer (DS) Resource Record (RR)
Type Digest Algorithms", Type Digest Algorithms",
<https://www.iana.org/assignments/ds-rr-types>. <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
 End of changes. 4 change blocks. 
17 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48.