Dear DNSOP, This revision of "Consistency for CDS/CDNSKEY and CSYNC is Mandatory" has the following changes:
- Advise to attempt retries to resolve inconsistencies - Added that checking C* consistency also significantly limits impact from nameserver hijacking I've been pondering a related issue, but have omitted it from the draft right now. The question is (from the perspective of a parent, such as registry): --> When ingesting a CSYNC record and subsequently setting out to update the NS RRset, should you be checking that any new NS hostnames don't break the existing DNSSEC setup? For example, it can happen that the zone served by new nameserver does not have the DNSKEY or RRSIG records as required by the DS RRset (e.g., wrong algorithm, or no matching key tag). It could also happen that the new nameserver does not advertise any of the other nameserver's DNSKEYs, so that DNSKEYs from the new nameserver and RRSIGs from an existing one are inconsistent. Depending what's retrieved and cached from which nameserver, this can lead to validation failures. There are two moving pieces, namely the delegation and the DS RRset. Changing either of them has similar implications. For DS updates, we have RFC 7344 Section 4.1: "MUST NOT break the current delegation if applied to DS RRset". So, when processing CDS/CDNSKEY records, one is supposed to check such things. Is it an omission that RFC 7477 (CSYNC) has no such acceptance rules? If so, should they be added to this draft? Practically, one could say something like "When processing CSYNC, run the same checks on the combined target configuration as when processing CDS/CDNSKEY." (Note that the CSYNC spec requires the use of DNSSEC; it would be a little weird if it could be used to break it ...) Thanks, Peter -------- Forwarded Message -------- Subject: New Version Notification for draft-thomassen-dnsop-cds-consistency-03.txt Date: Sat, 04 Mar 2023 11:58:16 -0800 From: internet-dra...@ietf.org To: Peter Thomassen <peter.thomas...@securesystems.de> A new version of I-D, draft-thomassen-dnsop-cds-consistency-03.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop-cds-consistency Revision: 03 Title: Consistency for CDS/CDNSKEY and CSYNC is Mandatory Document date: 2023-03-04 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-thomassen-dnsop-cds-consistency-03.txt Status: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ Html: https://www.ietf.org/archive/id/draft-thomassen-dnsop-cds-consistency-03.html Htmlized: https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-cds-consistency Diff: https://author-tools.ietf.org/iddiff?url2=draft-thomassen-dnsop-cds-consistency-03 Abstract: Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. [RFC7344] automates this for DS records by having the child publish CDS and/or CDNSKEY records which hold the prospective DS parameters. Similarly, CSYNC records indicate a desired update of the delegation's NS records [RFC7477]. Parent-side entities (e.g. Registries, Registrars) typically discover these records by periodically querying them from the child ("polling"), before using them to update the delegation's parameters. This document specifies that if polling is used, parent-side entities MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records are consistent across the child's authoritative nameservers, before taking any action based on these records.
The IETF Secretariat _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
