[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-cds-consistency-03.txt

[Peter Thomassen <[e-mail]>]

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: [e-mail]
To: Peter Thomassen <[e-mail]>


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